Jorge Luis Zapata Muga a écrit :
On Wed, Jul 29, 2009 at 6:10 PM, Jorge Luis Zapata
Muga<[email protected]> wrote:
Hi all,
Im trying to integrate nekovm into a project im doing, but i have some
problems, i hope someone can help me out :)
Basically the idea is that i have a library in C with some kind of
object abstraction similar to what gobject is. For that i've written
some neko "bindings", some .c (.ndll) and .neko files, similar to what
http://lists.motion-twin.com/pipermail/neko/2007-March/001653.html
explains. Then i have a library in C, which uses this object
abstraction library, loads xml based files and calls neko exported
functions, in a similar form as html+js. the problem i have is that
for example on the following xml,
<script file="myscript.n"/>
<object onmouseclick="myfun()">
I have a callback in c that whenever that event is triggered i should
call the myfun() neko function on myscript.n, that part is working
correctly but now i want that the "this" value on the neko callback be
the object that triggered the event. So basically the object is
already created (i can't use my neko bindings to create a new
object), i need to just wrap that object and pass it to val_CallEx as
the first argument, the logic way would be to create a new abstract
value and assing the object's kind, i.e
static value object_ref(Object *o)
{
value i;
i = alloc_abstract(k_object, o);
val_gc(i, object_delete);
return i;
}
But the above k_object and object_delete are part of my bindings, not
this library. How to handle that situation? specially the k_object
thing, i dont mind duplicating the code, but is there a better way to
handle this situation? link my c lib against the .nddl too and export
the k_object? kind of a hack tho ...
For the record ... i've found a function kind_share() which basically
does what i need,
Yes, kind_share was added in order to be able to share the same vkind
between different NDLL.
the only problem im facing now is that i can't load
a .ndll without calling a function on it and i need the
DEFINE_ENTRY_POINT to be called (as that's the place where the kinds
are shared), so i added a do-nothing function.
Indeed, the default loader require a primitive name to load+initialize
the library. But please note that the order of initialization is not
important. The first loaded NDLL will define the vkind , then subsequent
kind_share done with the same "name" will retrieve the first one.
So you can wait until your NDLL is actually used.
Best,
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
