More types

[Aurel300]

Haxe side:

• Void
• function types for callbacks
• enums (cannot be proper Haxe enums though)

Native side:

• the various integer widths + signedness + integer-type aliases
  • eval - properly handle int32
• float (rather than double)
• structs - Haxe won't do struct passing in general but we can construct a struct at the callsite from the object; may not be very performant
• buffers with arbitrary size relations - e.g. a function may return a block of bytes that is 2 times larger than the input; allow the user to specify an adapter type that knows how to convert each target-specific representation to Haxe types
• abstract datatypes - a pointer allocated (and later freed) by the native library; should ideally be wrapped in a GC abstract block in case the native pointer is freed
• typed buffers - pass a raw pointer, type it as e.g. a Vector<Float> in Haxe

[melMass]

Thanks a lot for making Ammer <3

I was wondering how to deal with other types in an efficient way.
I mainly want to use Eigen matrices and vectors from native to Haxe but I'm not sure of the best approach?

[Aurel300]

@melMass Good point!

An efficient way to pass a vector/contiguous array of primitives across the FFI sounds useful. The problem is that not all targets will actually have a way to represent this efficiently, so there may be some copying to deal with this … Fortunately, both HashLink and hxcpp have an efficient runtime representation.

I'm also interested in more details about your intended application for this, if you are willing to share! I assume this is for a math or ML library?

[melMass]

I'm personally mainly interested in those targets, to be honest :)
Yes I want to build a geometry library using libgl

Edit: Your answer raised another question, sorry, do you plan to support more targets with Ammer? Is it even possible?

[Aurel300]

@melMass I didn't see your edit until now! Yes, more targets are in the works. For now I just have #2 open for supporting Lua (when running with LuaJIT). I am reasonably certain all Haxe sys targets could theoretically support ammer. Some would probably be more painful to support than others. Feel free to open an issue for a particular target if you have a use case.

[melMass]

By any chance are you still interested by the idea of adding vector types ?
If not would you recommend a way to cast them as Bytes to Haxe ?

[Aurel300]

@melMass Well, neither this issue nor this project is abandoned, though I have not had much free time to work on it. When I do, reorganising the types will be one of the top priorities.

If you want to experiment in the meanwhile: you might get lucky and get away with unsafe casts between Bytes(Data) and Vector(Data). There is also haxe.io.Float64Array (and similar), these should work directly on top of bytes reasonably easily, but I don't know how good their performance is (or what your performance demands are on the Haxe side).

[melMass]

Thanks for the answer, it's good to know that Ammer is still alive.
I'll try those roads for now. 😉

[melMass]

I just saw your presentation (maybe you should link it in the readme it's very interesting).
I managed to build small samples since I opened this issue, but I plan to wrap a more extensive test in the following days, mainly about types and casting, I'll post my questions/progress here!

Congrats on the documentation aswel!!!

[kevinresol]

Would like to add native enum to the list too

[Aurel300]

@kevinresol Yes, I had issues with trying to make enums work like Haxe enums consistently on all targets… For now you can just model individual enum cases with static variables.

class SomeLIbrary extends ammer.Library<"foo"> {
  public static var SOME_ENUM_CASE:Int;
}

[kevinresol]

What if a library function returns a native enum?

ok nvm, I missed the fact that enum is already in the TODO list.

[Aurel300]

@kevinresol Yes, I added that after your first comment. If a library function returns a native enum, it's fine in C, where it is just an integer. So the method can be defined with an Int return. In C++ (with enum classes), it's more annoying since it requires a cast.

[kevinresol]

In yoga there is a struct YGValue which is essential an ADT so can be mapped perfectly to Haxe enum:

enum YGValue {
  Undefined;
  Auto;
  Point(v:Single);
  Percent(v:Single);
}

while its native representation is:

typedef struct YGValue {
  float value;
  YGUnit unit; // enum YGUnit {...}
} YGValue;

Are there any tricks so that I can write custom glue code to support it?

[Aurel300]

Yeah, that looks almost like an ADT. At the moment that is not mappable to an enum for sure (without writing your own mapping). I'll have to think about this a bit more. There is a similar pattern in SDL, with its events (event type + union of event data types).