Neko VM: global objects and routines

68 views
Skip to first unread message

Milla Von Weiss

unread,
Nov 17, 2015, 4:20:58 PM11/17/15
to Haxe

Hi there! I am embedding Neko VM into my Qt powered desktop application.

I have succesfully redefined the loadmodule method of loader object. Now it is possible to load and execute Neko VM modules from the application resources.

Now I need to expose some global objects (data tables, buffers and strings) to Neko VM. How can I do it?


Let me try to explain what I'm trying to implement:

1. The C++ application starts, initializes some data tables, creates some buffers and shows the UI.
2. When the user wants to open a data file:
2.1. The application starts the Neko VM,
2.2. Exposes some global objects and routines to provide access to the file system, internal tables and buffers of C++ application,
2.3. Loads and executes a module which reads the input file, processes some data and fills the application's buffers and data tables.
2.4. The application stops and cleans the Neko VM.
3. The objects (data tables, buffers) are cleaned on application exit.

These global objects should outlive the VM. So it is not about primitives, that can be created from within the Neko VM. It is all about $loader-like objects.

Adrian Veith

unread,
Nov 18, 2015, 3:02:24 AM11/18/15
to haxe...@googlegroups.com
Hi,

to expose an object from your native application, you will need a function that returns that object to the neko side, packed as an abstract type (which is a pointer to your object) of some vkind.
You should define your different vkind types to identify the type of your pointer. a) to be able to check what is passed from neko to your app. and b) you must do your memory management depending on the type of the abstract pointer.
If your application has more than one global context (maybe you want to run more than one VM in different threads), you should create a context object, which holds all that information that you call "global" and attach it to the neko VM via neko_vm_set_custom(). If your neko app needs a resource from that global context it calls function in your app, which get this global context via neko_vm_custom(). It can check the type of the context with the vkind if you need to.
Finally the function returns the resource wrapped as a valid neko type:
- values as Int, Bool, Float must converted via the alloc_... functions
- String types are returned as neko strings. On the neko side they should be converted to Haxe String.
- same with arrays which are returned as neko arrays and must be converted to Haxe Arrays
- other types like c++ objects must be returned as abstracts with a proper vkind. Allways remember, that neko is GCed ! this can (and will) bite you with manual memory management. You can attach a callback, which informs you when the abstract is collected, but since you don't know when this happens you should take care not to free an object twice (or use an object, which is manually freed in your app)

hope this answers some of your questions.

Best, Adrian.
--
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.

Philippe Elsass

unread,
Nov 18, 2015, 3:29:56 AM11/18/15
to Haxe

Tutorial!

Message has been deleted

Milla Von Weiss

unread,
Nov 18, 2015, 5:01:13 AM11/18/15
to haxe...@googlegroups.com
Thanks for your prompt reply!

> to expose an object from your native application, you will need a function that returns that object to the neko side, packed as an abstract type (which is a pointer to your object) of some vkind.

Do i need to override the "loadprim" method of the $loader object to
expose this function to the Neko VM?
> You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.
Message has been deleted
Message has been deleted
Message has been deleted

Adrian Veith

unread,
Nov 18, 2015, 6:23:52 AM11/18/15
to haxe...@googlegroups.com
if the function is inside a .ndll and exported no - but if the function is inside your app (and therefore not exported), then yes, you will need your own loader which will find that function. You can simplify this by inheriting the standard loader and in your overridden method you can check if you can find the function in your app. If not, you call the standard loader. I have some pascal code, which does this all here:

https://github.com/AdrianV/pascal4neko/blob/master/source/nekoHelper.pas

look at myLoadPrim.

best Adrian.

Adrian Veith

unread,
Nov 18, 2015, 9:49:58 AM11/18/15
to haxe...@googlegroups.com
yes - I should start to document and share.

Am 18.11.2015 um 09:29 schrieb Philippe Elsass:
>
> Tutorial!
>

Reply all
Reply to author
Forward
0 new messages