![]() ![]() The routine would thus return a null path and would try to find the correct execution path again when invoked the next time, running and parsing ps over and over just to get the same null result again and again and causing a massive slowdown of the application. Unfortunately, when run with arguments, the arguments would be included in the ps output to give something like /boot/common/non-packaged/bin/freac abc which could no longer be interpreted as a filename. This would normally yield something like /boot/common/non-packaged/bin/freac which could be interpreted as a filename to get the path. This part is system specific and on Haiku the original implementation parsed the output of the ps command in order to get that path. Fortunately, I quickly found out what was going on then: fre:ac tries to find the directory it is executed from in order to locate its resource files (language files, images, extensions etc.). I left this untouched for a while and came back after a few days. Really weird as fre:ac doesn't do anything with these arguments, but simply ignores them. freac abc from the command line, many operations, like loading codecs and extensions, took much longer than when simply running. Start it without any arguments and it would run at normal speed.Īt first, I added some timing code and it showed that when running. On Haiku OS, and only there, fre:ac would run very slowly - to a point where it would be unusable - when started with arguments on the command line. This one was tricky and riddled me for quite a while. Haiku OS: fre:ac running slowly when started with arguments I talked a lot about bug fixes in the previous report and have some more of them for this issue, too: Development in April was very active with work on many different areas and I can finally talk about some upcoming features now. Here's an update on fre:ac development in the past month.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |