haxe.org | The haxe.org website | Static Site Generator library

try.haxe.org assumes that the class that contains the entry point main() is called Test, while the code example you linked uses Main.

It appears to work fine once you change class Main to class Test in the code snippet: https://try.haxe.org/#68274

Note that some other code examples from the manual may not compile because try.haxe.org still runs Haxe 3.4.4, while the current release is 4.0.5. To work around this, people usually use this fork of try.haxe that lets you specify the Haxe version to use in the options tab:

http://try-haxe.mrcdk.com/

Alternatively, you can convert Int64 to Float yourself by combining high/low halves:

@:build() indeed isn't the right approach here, since that just builds one particular type. Instead, you could use an initialization macro in combination with Context.defineType():

From the Haxelib docs you linked:

Libraries with either a run.n helper or a main class defined in haxelib.json, can be executed using haxelib run.

Since you're providing a main class, Haxelib is trying to run your code in Haxe's built-in macro interpreter using the --interp argument.

Haxe 3's macro interpreter did not support threading, hence the error. You can work around this by compiling a run.n file and packaging that with your library, so the script is executed in Neko VM:

I don't think such a thing exists.

To make sure getTarget() doesn't silently break when a new target is added (and you're compiling for it), you could have it throw a compiler error in that case:

The closest thing I know is const-type-parameter. But I do not feel generic build is a good choice here.

Const type parameters can be used without @:genericBuild - a const type parameter in combination with @:generic is enough to get the desired optimization:

With Haxe 4 you will be able to use haxe.ds.Map.

Meanwhile, you should be able to access haxe's Map with std.Map.

That's quite an interesting interaction there, here's what happens in order:

• sys.Http receives the response and calls onStatus().
• You call responseBytes.getBytes(), which ends up invalidating the internal buffer in haxe.io.BytesBuffer.getBytes(). The docs of that method state "Once called, the buffer can no longer be used", as it sets the internal buffer b to null.
• The Http class then attempts to write to that same buffer, which is no longer valid.
• Since there's a catch-all around the entire logic, the onError() callback is called due to the null reference.

The status code passed to onStatus() is 200 (OK), so apart from the getBytes() call, the request seems to work as expected. And according to apitester.com, data is empty for this particular request.

My bad, there was a link to source in one of the links I posted above.

https://github.com/HaxeFoundation/haxe/blob/3.4.7/std/haxe/ds/Vector.hx