How to call haxe function from native code? about hashlink HOT 8 CLOSED

I have started documenting things here https://github.com/HaxeFoundation/hashlink/wiki
Tell me if you have more questions, I'll add more documentation as I get more questions ;)

from hashlink.

This is something I'm keen to do too, I'll planning to have go at it over the weekend

It'll be good to hear what @ncannasse 's thoughts are on this - if there's mechanism how this is handled already or if it's an area to investigate (I'm keen to contribute here if I can!)

A hack in the short term might be to just look at the C function signatures generated by haxe and call those directly from your C code - if you search through the generated C source code you'll find a function that corresponds to test(foo:Int) (just not with exactly the same name!)

However, for a more robust solution you'd want to control how those signatures are generated, perhaps in a similar way the @:expose metadata is used for the javascript target.

from hashlink.

I did a small investigation, and if I understood correctly, it's impossible to call function by name, because functions stored by function id. So we should store name of functions in sort of key-value storage.
The solution that I use now, to call haxe functions from native code, is that I'm passing a pointer to a function and than just call it. It's more hack than a real solution

from hashlink.

Btw, is it possible to create hl native function at runtime? To avoid module loading(I don't wanna one more dll)

from hashlink.

A Haxe function would be represented as a vclosure* on C side. You can call it dynamically with hl_dyn_call. ATM there is no way for the C code to "resolve" a function from its path. You will have to pass it from Haxe to C by doing something such as registerFunction(Test.test) which can store the vclosure and reuse it later.

You also need to store it in some root if you don't want it to be GC'ed

from hashlink.

One other solution to implement such method resolution is to do write the following:

function resolveStaticMethod( className hl.Bytes, methodName : hl.Bytes ) : Dynamic {
     var c = Type.resolveClass(@:privateAccess String.fromUTF8(bytes));
     return Reflect.field(c, @:privateAccess String.fromUTF8(methodName));
}

You can then share this method to C

from hashlink.

A Haxe function would be represented as a vclosure* on C side. You can call it dynamically with hl_dyn_call.

I do use vclosure->fun pointer to avoid hl_dyn_call, is it ok?
It's probably not safe, but it should be faster

You also need to store it in some root if you don't want it to be GC'ed

how is it can be done? and how is the memory can be prevented from being GC'ed?
And what is the differences between hl_gc_alloc_noptr, hl_gc_alloc and hl_gc_alloc_dyn?

@ncannasse btw, when the new HashLink in depth blogpost will be released? 👍

from hashlink.

Also want to know what is the differences between hl_gc_alloc_noptr, hl_gc_alloc, hl_gc_alloc_raw?

from hashlink.