A ’small‘ project in haxe, pt. 2: the problems

When I sent the tool to my friend to test it, I was expecting it to crash instantly. Because that always happens to my apps on his computer, no matter how much I test them before. Ok, a missing dll, not a problem at all. At least not at that time. I can be very persistent in terms of finding solutions to problems, which seem hard enough. I might have already found a temporary solution for a problem, but most of the time I don’t actually like these kind of ‚hacky‘ fixes. (I know, that’s very atypical for a programmer, but having to include an additional dll file for such a simple program just doesn’t look very nice. And as always: the time spent doing that kind of research often helps me to understand the language and programming environment better.)

Most haxe developers tend to express how great the haxe community is. That’s true, you can ask in a Google groups powered discussion board (which is a pain per se) and might get an answer pretty fast. The downside of this is that for big parts of the language or the libraries there is either little to no documentation or the few explaining lines that exist are outdated. Okay, this is not very surprising as the language itself changes quite fast, so the work needed to keep it updated is a lot. On the other, hand for developers this means that you cannot easily google a problem like you would with other programming languages. Instead you have to post a question and wait for answers, which results in not being able to progress for more or less long time span.

For my problem, compiling a statically linked executable for the C++ target, there were questions. And answers. Most of them sounding like: ‚it should be possible, but I don’t know how.‘ The most helpful resource I found is an example C++ code snippet which also is, apart from its helpfulness,… Well, outdated.
Ok, it was outdated. I wrote some lines of documentation, made a pull request and three hours later it got accepted. (Wow, the devs are really fast.) You can find the instructions following the link above.

With that issue fixed, we could go on. Very soon I released: his system is literally a test parcour for any developer. More than once I truly believed he just organizes his files and settings in a special way to annoy any software developer on earth! Running Adam J. Calhoun’s punctuation script on the list of all of his folder names would probably result in the full Unicode specification! The first path he tried my tool on included a dot, German umlauts, an ampersand, brackets, a minus and a sharp. Getting infected with some ransomware, which also encrypts file names, would actually fix many software problems on his computer.

And this my friends was the point when I found out that haxe couldn’t handle Unicode characters when using FileIO functions. Apparently, the haxe developers prefer to add a hl target – something no one knows anything about, something no one will use for years – instead of fixing problems that are known since 2014 and should be considered crucial for any modern language. (More information here; Unicode support is planned for the next release.)

A partition solution: use Utf8.decode and Utf8.encode whenever you read paths or pass them to any FileIO function. This doesn’t resolve all problems, but a majority. Creating more workarounds didn’t seem worthwhile as the program includes a fuzzy search option, which finds these non-matched Unicode files, and because it is planned to be fixed in the next version of haxe. Hopefully…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.