Quasi-Missing File?

[zauberparacelsus]

When I tried running a basic HaxePunk template from the Getting Started page, I found that it would not run when I ran "lime test neko". I get the following error output:

[zauber@manjaro HaxePunkTest]$ lime test neko
/opt/haxe/std/haxe/macro/Context.hx:75: characters 20-55 : File not found '/home/zauber/libs/haxelib/HaxePunk/2,5,3/assets/font/04B_03__.ttf'
/home/zauber/libs/haxelib/openfl/2,2,4/openfl/_v2/Assets.hx:1869: characters 14-44 : Called from
/home/zauber/libs/haxelib/openfl/2,2,4/openfl/_v2/text/Font.hx:10: characters 2-11 : Called from
Aborted

Upon further inspection, I find that the missing file being referenced actualy does exist. Not sure what's going on here. Perhaps the problem is because the commas in the path are not escaped?

[scriptorum]

Are you running on Linux? I see references to this as a Linux issue popping up from time to time on OpenFL. I'd try running haxelib upgrade and getting on the latest OpenFL (2.2.7 is the latest). The commas are not an issue, although I feel a similar distress looking at the commas in the haxelib libs folder.

[zauberparacelsus]

Yeah, I'm running on Manjaro Linux. Earlier this morning I did upgrade to OpenFL 2.2.7, and unfortunately the issue is still occuring.

[scriptorum]

Ok. It's been a while since I've run Linux. Did you install OpenFL using the a package manager or the Linux install script (which they recommend)? Have you tested other targets, such as lime test flash?

This issue is referenced in https://github.com/openfl/openfl/pull/261 by @bendmorris and https://github.com/openfl/lime-tools/issues/87, although both issues were closed last year.

[zauberparacelsus]

It was a while ago that I installed OpenFL. I was on Ubuntu when I did, and preserved my /home partition when I switched to Manjaro. In light of that, I should probably do a full reinstall of all the haxelib stuff.

EDIT: No luck. Didn't fix anything.

[zauberparacelsus]

I used the haxelib set openfl [version] command to backtrack through every previous version of OpenFL that I could.

No changes until I got to version 2.0.1, which gave this error:

/home/zauber/haxelib/openfl/2,0,1/openfl/Assets.hx:579: characters 31-57 : Type name __ASSET__font_04b_03___ttf is already defined in this module

I chose not to downgrade further, as I am not entirely sure that they would remain compatible. I upgraded back to 2.2.7. Previously, I was testing with the neko target. I tried flash, but I get an error saying the SWF library could not be found, even after installing it. I tried native a C++ target, but got the same error as the neko target.

I tried the HTML5 target then, and it would run, but gave nothing but a blank screen. It had some warning messages on the console:

Warning: Could not find generated font file "/home/zauber/haxelib/HaxePunk/2,5,3/assets/font/04B_03__.woff"
Warning: Could not find generated font file "/home/zauber/haxelib/HaxePunk/2,5,3/assets/font/04B_03__.svg"
Warning: Could not find generated font file "assets/font/04B_03__.woff"
Warning: Could not find generated font file "assets/font/04B_03__.svg"

[scriptorum]

haxelib run HaxePunk new XXX creates a blank project in the XXX folder, so a blank window without errors is the expected result. To test a more useful example, either modify the files as instructed in HaxePunk Basics or try compiling the demo app in the examples folder.

If I understand it correctly, it looks like @bendmorris's fix was applied to the "next" OpenFL, as opposed to the "legacy" (indicated by the _v2 part in your error message). OpenFL has a sort of dual nature right now while Lime is in flux, with _v2 code being substituted if the older legacy lime binaries are detected. That's always been confusing to me, because v2 would seem to imply it's superior.

You could try to apply Ben's fix by forcing the use of the "next" with -Dnext, but I suspect that simply won't compile. This issue was referenced previously in https://github.com/HaxePunk/HaxePunk/issues/294, but I don't see how OpenFL 2.1 fixed it. Someone smarter than me (<cough> @ibilon <cough>) needs to take a look at this. ;)

[bendmorris]

I just verified, the fix is present in both openfl and openfl/_v2 (https://github.com/openfl/openfl/blob/master/openfl/_v2/Assets.hx#L1767). It looks correct to me. I'm using legacy myself and am not seeing this issue.

[bendmorris]

Ah, so it was applied, but not for fonts.

This line is the culprit: https://github.com/openfl/openfl/blob/master/openfl/_v2/Assets.hx#L1869

Change that line to:

path = filePath; if (!sys.FileSystem.exists(filePath)) { path = Context.resolvePath (filePath); }

and rebuild Lime. See if that fixes it.

I usually only use bitmap fonts, so I get to avoid all the font embedding issues you all have to deal with :)

edit: I don't think rebuilding Lime is actually necessary, I just reflexively rebuild it whenever I change anything...

[zauberparacelsus]

@bendmorris Thanks. Changing that one line has fixed it!

[bendmorris]

Great, thanks for confirming. I'll shoot this as a pull request to OpenFL later today for all versions - I'm sure you're not the only one who will have this issue.

[zauberparacelsus]

To be honest, I had been thinking of going down the route of Lua with the Love framework because of this issue. However, love2d.org has been down all morning, so I decided to exercise a bit more patience ;-)

[ghost]

Love2d is cool but it does not have 3d ;)

[zauberparacelsus]

Actually, Love does have 3D capabilities, albeit very limited.

[ghost]

It does via extensions

[scriptorum]

Thanks for stepping in @bendmorris. Ahhh. I looked at the blames for both files and your name came up in a find on Asset.hx, but not on _v2/Asset.hx. So I looked for embedFont and saw the fix wasn't in that method, and from that I assumed the fix was in next but not v2. And you know what they say about assumptions...

[bendmorris]

With so many new versions of OpenFL in such a short time, frankly I'm surprised that I show up in the blames at all...

[ghost]

Off topic : Does any of you know something low level like glew which works on android?The language does not matter.

[zauberparacelsus]

Seeing a return of this issue (or some variant of it), after having done a clean reinstall of Haxe. The code in OpenFL's Assets.hx file on the reported line has code similar to the fix recommended above, so not sure what is going on this time.

[zauber@manjaro hxParacosm]$ lime test cpp

/usr/lib/haxe/std/haxe/macro/Context.hx:75: characters 20-55 : File not found '/home/zauber/haxelib/HaxePunk/2,5,3/assets/font/04B_03__.ttf.png'
/home/zauber/haxelib/lime/2,3,3/lime/Assets.hx:1289: characters 18-48 : Called from
/home/zauber/haxelib/lime/2,3,3/lime/Assets.hx:1437: characters 15-35 : Called from
/home/zauber/haxelib/lime/2,3,3/lime/graphics/Image.hx:49: characters 2-11 : Called from
Aborted

[scriptorum]

It looks like this hasn't been fixed yet, neither in default or legacy.

It may get fixed in the next version if we all chant repeatedly, "we heart U, @bendmorris." ;)

[bendmorris]

It's in!

[scriptorum]

We heart U, @bendmorris! :)

@zauberparacelsus: Not sure why you saw a regression if you were pointing to your own dev OpenFL, but it possibly has something to do with the V2/Next switch being flipped. You could try -Dlegacy. Please run it against the latest dev version once Ben's pull request is merged and let us know how it goes.

[bendmorris]

Pull request is merged, so give the OpenFL master branch a try and see if your issue is resolved.

[zauberparacelsus]

@bendmorris Compiling failed:

[zauber@manjaro HaxePunk]$ ant
Buildfile: /home/zauber/BUILD/HaxePunk/build.xml

clean:

tools:
     [exec] -- HaxePunk 2.5.3 --
     [exec] 
     [exec] USAGE: haxelib run HaxePunk doc
     [exec] USAGE: haxelib run HaxePunk setup
     [exec] USAGE: haxelib run HaxePunk update
     [exec] USAGE: haxelib run HaxePunk new [options] [PROJECT_NAME]
     [exec] Options:
     [exec]   -s <width>x<height> : Set default size of window (default: 640x480)
     [exec]   -r <framerate>      : Set target frame rate (default: 60)
     [exec]   -c <class>          : Set name of main class (default: Main)

doc:
     [exec] Parsing xmls/haxepunk.xml
     [exec] Dox.hx:124: Error while parsing xmls/haxepunk.xml
     [exec] Called from ? line 1
     [exec] Called from dox/Dox.hx line 135
     [exec] Called from dox/Dox.hx line 125
     [exec] Uncaught exception - xml.c(80) : Xml parse error : Expected > at line 30289 : ...\\&*()[]{}<>|:;_-+=?,. '">
     [exec]     <c...

BUILD FAILED
/home/zauber/BUILD/HaxePunk/build.xml:69: exec returned: 1

Total time: 1 second

[scriptorum]

That's a different issue. I'm pretty sure that's from the latest lime outputting improperly escaped characters, in the -xml output which is used for generating documentation. I was just discussing this issue here: https://github.com/dpeek/dox/issues/123.

To validate Ben's fix, please try testing on a project or in the demo. Thanks!

[zauberparacelsus]

How do I test it if I can't compile it?

[bendmorris]

Pardon my ignorance but is building with ant necessary for anything other than the command line tool and docs? If you have an existing project, you shouldn't need either of those to use HaxePunk - just "haxelib dev HaxePunk /path/to/haxepunk" and you're good to go.

[zauberparacelsus]

I think I'm more the one who is ignorant since I don't really know how to do things in Haxe just yet.

[zauberparacelsus]

I tested and found that the asset errors were still occuring. I decided to wipe the project and create a new one, but now I get new errors from the create command:

[zauber@manjaro Paracosm]$ haxelib run HaxePunk new hxParacosm
Called from ? line 1
Called from CLI.hx line 153
Called from CLI.hx line 9
Called from a C function
Called from CLI.hx line 28
Called from CLI.hx line 47
Called from Project.hx line 85
Called from Project.hx line 95
Called from sys/io/File.hx line 50
Uncaught exception - [file_open,template.zip]

[scriptorum]

Right, HaxePunk is ready to use without Ant. Ant here is used to generate documentation, run unit tests, remove temporary files (like template.zip), prepare the new template, and stuff like that. Because the dox generation is choking, I think it's removed template.zip without rebuilding it, which is necessary for haxelib run HaxePunk new to work. Try getting template.zip from the server then running your command again: git checkout template.zip.

[zauberparacelsus]

Okay, I checked out template.zip, and now project creation works. Unfortunately, I'm still getting the font errors:

[zauber@manjaro hxParacosm]$ lime test neko

/usr/lib/haxe/std/haxe/macro/Context.hx:75: characters 20-55 : File not found '/home/zauber/BUILD/HaxePunk/assets/font/04B_03__.ttf.png'
/home/zauber/haxelib/lime/2,3,3/lime/Assets.hx:1289: characters 18-48 : Called from
/home/zauber/haxelib/lime/2,3,3/lime/Assets.hx:1437: characters 15-35 : Called from
/home/zauber/haxelib/lime/2,3,3/lime/graphics/Image.hx:49: characters 2-11 : Called from
Aborted

[bendmorris]

Looks like Assets.hx moved to Lime, so this needs to be fixed in Lime as well:

https://github.com/openfl/lime/blob/master/lime/Assets.hx#L1289 https://github.com/openfl/lime/blob/master/lime/Assets.hx#L1385

I'll get in a second pull request tonight...

[zauberparacelsus]

Ack >.<

[bendmorris]

For the time being, you could try applying the same fix yourself to the two lines I linked.

[zauberparacelsus]

Aye, I'll try that.

[bendmorris]

Sorry about that! Lime/OpenFL are moving targets, hard to keep up with all the changes...

[zauberparacelsus]

Okay, applying the fix to those two lines appears to work. Thanks again!

[zauberparacelsus]

Oh ****, I just read back and realized I misread the instructions. I was told to test out the OpenFL master branch, but for some reason I interpreted that as the HaxePunk master branch.

This is what I get for skipping breakfast. And lunch :-/

[bendmorris]

Fix is merged into Lime master as well, so this should be resolved.

[scriptorum]

Great! Thanks, Ben.