neko equivalent of ApplicationDomain?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

neko equivalent of ApplicationDomain?

Simon Krajewski
  Hello,

during some .swf experiments, I tried creating some really small module
.swf files by abusing --gen-hx-classes in order to create header files
(all extern declarations) of some haxe classes and the hsl lib. After
torturing them even further with Franco's great --dead-code-elimination,
I ended up with ~6kb .swf files that a central application can load into
its ApplicationDomain.

I then tried doing the same on neko target, but I realized that the type
resolver does not like it. I get exceptions like
Uncaught exception - Invalid field access : new
when trying to create a hsl class. The main application does include
hsl, so is there any way to do something like "load it into the same
ApplicationDomain" in neko? I solved the unserializing issues by having
a custom resolver class check the module classes, but I couldn't find
any way of doing something similar for types in general.

Thanks in advance
Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Nicolas Cannasse
Le 17/01/2011 13:38, Simon Krajewski a écrit :

> Hello,
>
> during some .swf experiments, I tried creating some really small module
> .swf files by abusing --gen-hx-classes in order to create header files
> (all extern declarations) of some haxe classes and the hsl lib. After
> torturing them even further with Franco's great --dead-code-elimination,
> I ended up with ~6kb .swf files that a central application can load into
> its ApplicationDomain.
>
> I then tried doing the same on neko target, but I realized that the type
> resolver does not like it. I get exceptions like
> Uncaught exception - Invalid field access : new

Try using haxe --neko-source to see how haXe classes are generated in
Neko, and read the neko.vm.Module class documentation.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Simon Krajewski
  Am 17.01.2011 14:51, schrieb Nicolas Cannasse:
> Try using haxe --neko-source to see how haXe classes are generated in
> Neko, and read the neko.vm.Module class documentation.
I can access to the sub-module's classes by using its export table, and
I can probably find a way to pass the main-module's classes to the sub
as well. I just can't figure out how to get the class resolver to
actually find them, e.g. when using new hsl.haxe.DirectSignaler().

Any help appreciated
Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Nicolas Cannasse
Le 17/01/2011 16:12, Simon Krajewski a écrit :
> I can access to the sub-module's classes by using its export table, and
> I can probably find a way to pass the main-module's classes to the sub
> as well. I just can't figure out how to get the class resolver to
> actually find them, e.g. when using new hsl.haxe.DirectSignaler().

You need to either define the global hsl with

untyped hsl = ...

Or inject the DirectSignaler class into hsl.haxe package (if it exists
already)

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Simon Krajewski
  Am 17.01.2011 18:24, schrieb Nicolas Cannasse:
> You need to either define the global hsl with
>
> untyped hsl = ...
>
> Or inject the DirectSignaler class into hsl.haxe package (if it exists
> already)

That was surprisingly easy... Thanks! Is there any global object x I can
use like Reflect.setField(x, "hsl", ...) so I can automate the whole
process?

Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Cauê W.
by the way, is there any easy way to provide a type of isolation that would be possible to implement a hot code swapping server in neko?
I've implemented the ThreadRemotingServer on C#-hx, and am trying to implement hot code swapping with it. It would be great to provide some global (haxe) solution for appdomain handling, if any possible

2011/1/17 Simon Krajewski <[hidden email]>
 Am 17.01.2011 18:24, schrieb Nicolas Cannasse:

You need to either define the global hsl with

untyped hsl = ...

Or inject the DirectSignaler class into hsl.haxe package (if it exists already)

That was surprisingly easy... Thanks! Is there any global object x I can use like Reflect.setField(x, "hsl", ...) so I can automate the whole process?

Simon


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Nicolas Cannasse
In reply to this post by Simon Krajewski
Le 17/01/2011 19:21, Simon Krajewski a écrit :

> Am 17.01.2011 18:24, schrieb Nicolas Cannasse:
>> You need to either define the global hsl with
>>
>> untyped hsl = ...
>>
>> Or inject the DirectSignaler class into hsl.haxe package (if it exists
>> already)
>
> That was surprisingly easy... Thanks! Is there any global object x I can
> use like Reflect.setField(x, "hsl", ...) so I can automate the whole
> process?

No, but you can decompile your own module with format.neko and use that
to access the globals names table.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Nicolas Cannasse
In reply to this post by Cauê W.
Le 17/01/2011 19:49, Cauê Waneck a écrit :
> by the way, is there any easy way to provide a type of isolation that
> would be possible to implement a hot code swapping server in neko?
> I've implemented the ThreadRemotingServer on C#-hx, and am trying to
> implement hot code swapping with it. It would be great to provide some
> global (haxe) solution for appdomain handling, if any possible

There's already a per-module isolation in NekoVM.

It might be possible to dynamically swap the classes prototypes, the
only issue will be with closures that will keep a reference to previous
method version, leading to unexpected errors.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: neko equivalent of ApplicationDomain?

Cauê W.

There's already a per-module isolation in NekoVM.

It might be possible to dynamically swap the classes prototypes, the only issue will be with closures that will keep a reference to previous method version, leading to unexpected errors.

What I'm doing with C# is to define a whole separate appdomain for the context definition part, so the RemotingServer will be able to serve both versions - the new for connections made after the dll update, and the old for connections made before. This works great since the threadserver handles the context by reflection. I'm having issues, though, when passing a callback to the remoting server (since all appdomain communication is made by remoting on a local connection internally by the CLR).


Cheers!
Cauê

--
haXe - an open source web programming language
http://haxe.org