Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Possibility to load and execute hl bytecode in runtime #179

Open
Grabli66 opened this issue Sep 17, 2018 · 7 comments

Comments

@Grabli66
Copy link

commented Sep 17, 2018

No description provided.

@ncannasse

This comment has been minimized.

Copy link
Member

commented Sep 17, 2018

This is a bit tricky, as ATM we only have one single "module" that can be loaded. However this should only affect very specific parts of the runtime, mostly requiring to change module.c to keep and search into a list of modules, as well as changes in debugger.c to support multiple modules debugging.

Exposing then a load_module function would be doing pretty much what main.c is doing already (reading the file, loading the bytecode, jitting it and calling the main entry point).

The main question is about what kind of interoperability/communications we want between the two otherwise completely isolated modules.

@Grabli66

This comment has been minimized.

Copy link
Author

commented Sep 17, 2018

I see it like a possibility to load and use types from other module, to create plugins, extensions. Like this(pseudo haxe code):

import hl.ModuleLoader;

interface IPlugin {
function myMethod() : Int;
}

var module = ModuleLoader.loadModule("extension.hl");
var myPlugin = cast(new module.Plugin(), IPlugin);
trace(myPlugin.myMethod());

But if modules are isolated, then i think there will be a problems with shared types between that modules, cause it will be different types in each module. But i am not sure :)

@ncannasse

This comment has been minimized.

Copy link
Member

commented Sep 17, 2018

Yes exactly, in that case both plugin and core module would have their own IPlugin type, one not matching the other. Thinking about it, all required would be to remap all loaded module types to loader types in case they match exactly (same name, same fields, etc.). Definitely feasible but requires a bit of extra work.

@gdeverlant

This comment has been minimized.

Copy link

commented Mar 9, 2019

How about thinking of something that was working really well inside of Adobe Flash/AIR with the Loader class. Doing something like this with ApplicationDomain and dynamic resources loading. We can inspire ourselves with a really good design.

@ncannasse

This comment has been minimized.

Copy link
Member

commented Jul 7, 2019

Some progress has been made in recent changes, as we now allow several JIT modules to be loaded.

@sonygod

This comment has been minimized.

Copy link

commented Jul 29, 2019

any progress? Are there any example to show this feature? @ncannasse

@gdeverlant

This comment has been minimized.

Copy link

commented Jul 29, 2019

I would like to port my OSGi runtime framework from Actionscript to Haxe but for that I need ApplicationDomain and Loader. The ability to Loader.load() and Loader.unload() will allow me to bring hot code swapping.

Right now it works really well in Actionscript 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.