Loading Haxe Code At Runtime

[Ashiq A.]

Hi,

I'm (again) looking at runtime loading in Haxe. Is this possible? I'm stuck on both parts:

1) Creating some sort of artifact (ndll? DLL?) from Haxe code that contains a class I want to reuse

2) Loading that class at runtime

So far, I looked at:

- Lib.load, but it requires an NDLL, which, if I understand correctly, is something made in C++

- hscript, which doesn't allow you to define new classes

- haxelib, which requires you to specify the dependency at compile-time in your XML/config

To give a C#/Java analog of what I'm trying to do, in either of those languages, you can:

- Create a library (DLL or JAR) which contains classes

- Load that library at runtime and list classes

- Create classes from that library at runtime

(I know Haxe can do that last step using Type.createInstance)

This is useful for creating extensible architectures, like a plugin archiecture.

Any pointers would be appreciated. If it matters, I primarily care about Windows and Linux targets for this, not necessary Flash (and loading SWFs/assets).

--Ashiq

[Ashiq A.]

Hi,

I figured this out. It took a fair amount of poking around through the
old emails and the API docs. I'll write it up for my Haxe blog
shortly.

The short of it is:

- Build the plugin code and compile it as a Neko module (.n file)
- Use a loader to load the module and get exportTable().__classes
- Use Reflect.fields(classes) to iterate over classes
- Use clazz.__interfaces__ to get all implemented interfaces
- Use Reflect.field(s) to get the interface name and check if it's the
one I want

I'll test if this integrates well on Windows with a simple HaxeFlixel
game as step two.

Regards,

--Ashiq

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

[Marcelo de Moraes Serpa]

Hi Ashiq,

That’s pretty cool! Might worth blogging this up. I’m not into native with Haxe (yet), but loading classes at runtime would be awesome for plugins and or maybe an update engine for apps.

— Marcelo.

[Ashiq A.]

Hi,

Thanks, that's exactly my intention: write a game for Windows/Linux
that has plugins. I'm not into writing C++ either, so the plugins must
also be in Haxe.

Here's my blog post:
http://haxers.herokuapp.com/2015/plugin-architecture-neko-reflection-and-interfaces/

Any feedback or suggestions from the community would be great. Digging
into exportTable() and __interfaces__ makes me wonder if I'm using a
non-public Haxe API that could break in a future release, but I don't
know any other way to make this work right now.

--Ashiq

[Chii Chan]

That's pretty awesome! I've been trying to figure out a simple way to do live/hot reload for haxeflixel (but without avail) - i want it to work across all platforms (at least, it needs to work in flash, windows/neko, android and preferably iOS).

I was watching handmadehero.org videos, and in that project, the author made live reload possible (in C as well) by compiling the game logic into a dll, and ensuring that all memory that the dll uses only comes from "outside", and so on reload, there won't be any wrong pointers to any memory location anywhere. I couldn't figure out the equivalents in haxe for dynamic libraries.

[Marcelo de Moraes Serpa]

Chii,

Opening a parenthesis here, thank you for mentioning handmadehereo.com! Looks amazing. I just bought it in fact. 

— Marcelo.

On Feb 18, 2015, at 9:41 PM, Chii Chan <sangoh...@gmail.com> wrote:

That's pretty awesome! I've been trying to figure out a simple way to do live/hot reload for haxeflixel (but without avail) - i want it to work across all platforms (at least, it needs to work in flash, windows/neko, android and preferably iOS).

I was watching handmadehero.org videos, and in that project, the author made live reload possible (in C as well) by compiling the game logic into a dll, and ensuring that all memory that the dll uses only comes from "outside", and so on reload, there won't be any wrong pointers to any memory location anywhere. I couldn't figure out the equivalents in haxe for dynamic libraries.

[Marcelo de Moraes Serpa]

> On Feb 18, 2015, at 9:41 PM, Chii Chan <sangoh...@gmail.com> wrote:
>
> That's pretty awesome! I've been trying to figure out a simple way to do live/hot reload for haxeflixel (but without avail) - i want it to work across all platforms (at least, it needs to work in flash, windows/neko, android and preferably iOS).
>
> I was watching handmadehero.org videos, and in that project, the author made live reload possible (in C as well) by compiling the game logic into a dll, and ensuring that all memory that the dll uses only comes from "outside", and so on reload, there won't be any wrong pointers to any memory location anywhere. I couldn't figure out the equivalents in haxe for dynamic libraries.

Good points.

Maybe it helps to be near the metal with C. I have almost no experience with low-level languages, but I guess such feature could be abstracted away by some clever use of target-specific magic + macros and by keeping a uniform API whenever possible at the (so that say, if compiled to Flash, the loaded class deliverable would be a SWF file, if compiled to Neko and C++, a ndll, if Python, a Python module, and so on…) at the Haxe language level? Would worth the experiment!

[Ashiq A.]

Although obvious in hindsight, this doesn't work outside of Neko,
because the loader/module classes only exist in neko
namespaces/packages.

Is there any way to accomplish this without the neko target?

If not, I would have to distribute the neko version of my game. Since
this depends on neko being installed on the user's machine, is there
any way to build a single EXE that contains everything (including
Neko)?

I found xcross, but it seems defect (doesn't exist on Haxelib any
more): https://code.google.com/p/xcross/

--Ashiq

[Jason O'Neil]

Hi

I've never used xcross but you could download it from the legacy site:

http://lib.haxe.org/legacy/p/xcross

That would include both the source code (if you want to build it yourself) and the compiled "run.n" file.

I'm not sure if it is helpful for what you want, but:

    nekotools boot myfile.n

will generate a standalone executable that runs without neko.  Not sure how cross platform it is, but I imagine it works on Linux Mac and Windows.

[Ashiq A.]

Thanks, I'll give it a try.

Haxe.org (and lib.haxe.org) seem to be down right now.

--Ashiq

[Ashiq A.]

It doesn't seem to work. I get "Uncaught exception - std@module_read."

The docs also mention that "f you want to use additional libraries,
you'll have to make a custom build of xCross."

It seems like this is a dead end. Are there any other options?

--Ashiq

[Ashiq A.]

I'm pursuing this elsewhere (other thread and OpenFL discussion).

Now, a different topic: is it possible to extend this kind of
functionality (loading pre-compiled libraries at runtime; reflecting
over classes; finding interface implementations) to other platforms
(at least the desktop ones)? I think it comes down to storing
meta-information about classes. I know Java and C# have strong support
for accessing type metadata at runtime.

Also, the current implementation for Neko is poorly documented and
hidden away. Does it makes more sense to move the
exportTable().__classes and clazz.__interfaces__ parts somewhere else?
Maybe the latter can go in the Type class somewhere, like
Type.interfaceOf(...) or Type.interfaces(...)

--Ashiq

[Dion Whitehead Amago]

If your runtime is a language like Javascript this is possible.

I built interface code for Flambe to use Cocos2dx-JS. This is using the Spidermonkey JS engine for mobile games. So the JS code can be reloaded at runtime with zero problems, and still call native functions via bindings.

Something similar might be technically easier, since JS engines like SpiderMonkey can easily have bindings to native code.

[Darmie Akinlaja]

Hi Ashiq, were you able to find a solution to this? I really want the implementation in my current project.

I want to be able to load haxe libraries at runtime.

[Ashiq A.]

Hi,

I didn't pursue this further. I actually switched back to C# for this (MonoGame).

It seems to me that Haxe (for some reason) doesn't have enough supporting functionality for this. The neko stuff which I documented, other than only working on neko, seems mostly like internal implementation details -- it's not guaranteed to be a stable, reliable API (at least that's my perception of it).

--Ashiq

On Fri, Sep 30, 2016 at 1:46 PM, Darmie Akinlaja <dreak...@gmail.com> wrote:

Hi Ashiq, were you able to find a solution to this? I really want the implementation in my current project.

I want to be able to load haxe libraries at runtime.

[Marcelo de Moraes Serpa]

Doesn't hxcpp have support for this?

[Ben jiro]

So far, i have found very little in the hxccp. You can compile to dll's and load but its not very streamlined. Neko is the only Haxe target with relative easy real time loading.

[PSvils]

WIth hxcpp you want to compile a cppia, and load that. Smooth as butter.

[Ashiq A.]

Are there any code examples / small self-standing projects that demonstrate how to do that?  Documentation is somewhere between sparse and non-existent last time I checked.