Apparently a malformed CSV file is able to make FDIMPLES freeze

[cardpuncher]

Me again Jerome,

I gave the Turkish version of FDIMPLES a try in VirtualBox and when the the lower part of the screen displays "Bilgi yok" (No information" in Turkish), selecting a package freezes FDIMPLES. The screenshot below shows such a case (I selected Gopherus from the Network section, and FDIMPLES became unresponsive, I had to reset the VM).

I don't even have a packet driver installed but when the package information is properly displayed, there is no such issue so I think this is coming from the malformed CSV. Hopefully the new CSV files attached to shidel/fd-nls#12 will fix the problem, but I'm reporting this because IMHO, no matter how malformed, a CSV shouldn't be able to crash or freeze FDIMPLES.

Moar work for you :P

[shidel]

It is probably a bug in FDIMPLES somewhere. However, it is possible for it to be elsewhere and you are just seeing a symptom while using the app. I have seen that several times for different VM platforms and have implemented different work arounds. But, the odds are it is in FDIMPLES somewhere.

It would not be caused by a malformed CSV. FDIMPLES does not use those directly and at no point reads them. The RBE (Release Build Environment) parses and validates the language translation CSV data and creates and/or update languages specific LSM meta data files accordingly. However, it is possible that there is something in the created LSM files causing an issue.

Although FDIMPLES looks very simple, it pulls data from a number of sources. The number of places can range from about 6 to about 20. That depends on a number of various factors. Afterwards, it takes all of that information correlates and formats it into the information you see. It uses internal memory management and data caching to repeatedly load, use and purge that data. All of that just for a UI. The actual package installation and removal is handled by an external program FDINST (part of the FDNPKG package). For the the most part, that doesn't matter except for one thing. Generally, FDINST and FDIMPLES get alone well. However with some large packages, FDINST requires a lot of RAM. That requirement has put the more recent versions of FDIMPLES under extreme memory constraints. I've had to reduce the amount of memory available to FDIMPLES so much, I'm often amazed it manages to run at all.

All of that to basically say, it could just be getting stuck in a load/purge loop due to lack of RAM. Which would be a bug.

However, I have seen occasions when FDIMPLES looked stuck. But, it was doing so much cache management it was only extremely unresponsive and pressing the escape key to just "quickly" exit took nearly a minute to respond.

I really need to rewrite FDIMPLES from the ground up. Adding multi-repository support to the current version would be nearly impossible. Also by doing a rewrite, I can incorporate some tricks I did for PGME to make the maximum amounts of memory available to FDINST regardless of how much FDIMPLES uses.

( A side note on free RAM and PGME... PGME is huge. Yet when it launches a menu item, it reduces it's memory footprint all the way down to about 10k. If originally started by its BAT script, PGME can run things and maintain a 0k memory footprint. )

All that to say, I'll see what I can find. :-)

FYI, I have some plans over the next couple days. So, I will rarely be on the computer and mostly (or completely) unavailable for a little while.

[shidel]

Minor change in plans, not going away until later this week. :-)

[shidel]

Sorry, it took forever for me to get around to looking into it. But, I think it is now fixed in latest version 0.9.20.
It was locking up at "what appeared" to be random times when checking/unckecking packages. It was a Low Memory Issue. Basically, It was running out of memory in the data reading/caching section. So, I added a couple more tests and cache purges. I've been unable to get the new version to lockup. (yet).
:-)