Re: libseed-list js extensions for native modules



I reverted my seed-sandbox.c to current git, but I had only this small change which I thought was a typo fix:

--- a/modules/sandbox/seed-sandbox.c
+++ b/modules/sandbox/seed-sandbox.c
@@ -126,7 +126,7 @@ seed_static_function context_funcs[] = {
   {"eval", seed_context_eval, 0},
   {"add_globals", seed_sandbox_context_add_globals, 0},
   {"destroy", seed_sandbox_context_destroy, 0},
-  {"get_global_object", seed_sandbox_context_get_global_object },
+  {"get_global_object", seed_sandbox_context_get_global_object, 0},
   {NULL, NULL, 0}
 };

Anyhow, now it loads the sandbox module...

But I still can't add to the prototype:

> imports.sandbox.Context.prototype.foo = function() { print("test") };
function () { print("test"); }
> c = new imports.sandbox.Context
[object Context]
> c.foo()
TypeError Result of expression 'c.foo' [undefined] is not a function.
> c.eval("1+2")
3

Could this be a difference in JSC version? I'm with webkit 1.1.15.2-1 in ubuntu.

/Jonatan

Alan Knowles wrote:
It failed to load the sandbox module by the looks of things.

It's probably worth running with --seed-debug=all to find out what's going on. - if you built seed with debug on.

Regards
Alan


--- On 29/Jun/2010, Jonatan Liljedahl wrote:
Doesn't work here, but now something else is strange (first try to get sandbox failed):

 > imports.sandbox.Context.prototype.foo = function() { print("test") };
function () { print("test"); }
 > c = new imports.sandbox.Context
TypeError Result of expression 'imports.sandbox' [undefined] is not an object.
 > c = new imports.sandbox.Context
[object Context]
 > c.foo()
TypeError Result of expression 'c.foo' [undefined] is not a function.
 >


Alan Knowles wrote:
Did I miss something - this works perfectly..


GLib = imports.gi.GLib;

imports.sandbox.Context.prototype.eval_file = function(fn) { var script = {}; print("load " + fn); GLib.file_get_contents(fn,script); return this.eval(script.contents); };

c = new imports.sandbox.Context;
c.eval_file("test.js");

#output>>>
load test.js

** (seed:3644): CRITICAL **: Line 10 in /tmp/seedtest.js: GFileError Failed to open file 'test.js': No such file or directory

Regards
Alan



--- On 29/Jun/2010, Jonatan Liljedahl wrote:
This should be made to work - It's probably going to take a bit of
 > working out how to support it...

I'm trying to understand how this works, am I right that native modules create their classes with seed_create_class() (JSClassCreate()), while the Gir importer sets up an object with a 'prototype' property "by hand"?

 From the JSC API docs:

"Standard JavaScript practice calls for storing function objects in prototypes, so they can be shared. The default JSClass created by JSClassCreate follows this idiom, instantiating objects with a shared, automatically generating prototype containing the class's function objects. The kJSClassAttributeNoAutomaticPrototype attribute specifies that a JSClass should not automatically generate such a prototype."

So, the question is why the prototype is not writable and if it can be made to be that. I tried this hackish function on the constructor but it didn't work:

gboolean
seed_make_extendable (JSContextRef ctx, JSObjectRef object)
{
   JSStringRef jname = JSStringCreateWithUTF8CString ("prototype");
   JSValueRef exception = NULL;
   JSValueRef proto = JSObjectGetPrototype(ctx, object);
   if (proto)
     {
       JSObjectSetProperty (ctx, (JSObjectRef) object, jname, proto,
       kJSPropertyAttributeDontEnum|kJSPropertyAttributeDontDelete,
			   &exception);
     }

   JSStringRelease (jname);
   return TRUE;
}

Once JSClassCreate has made the prototype, it seems to be fixed and read-only.

Perhaps one should create classes more "manually" like the Gir importer does instead of using JSClassCreate()?

Looking through the code, it's either we have to explicitly overlay
the prototype properties in the constructor, or we set the
parent_class of Context to a standard object..
parent_class can only be a JSClassRef, and it says it should be NULL for the normal Object class, which I guess it should be. Seems like JavaScriptCore has classic inherited OOP internally, and that parent_class has nothing to do with prototype. (but that all objects has Object as parent_class)

I'm not sure I understand what you mean by overlay the prototype properties..

/Jonatan

Regarsd Alan

--- On 21/Jun/2010, Jonatan Liljedahl wrote:
Also, it should work to add methods to SomeClass.prototype in
native modules. Currently it does not:

imports.sandbox.Context.prototype.eval_file = function(fn) { var
script = {}; GLib.file_get_contents(fn,script); return
this.eval(script.contents); };

c = new imports.sandbox.Context; c.eval_file(foobar);

TypeError Result of expression 'ctx.eval_file' [undefined] is not a
 function.

It does work for GI modules, as seen in extensions/Gtk.js

/Jonatan

Jonatan Liljedahl wrote:
The gi_importer tries to import extensions/name.js by evaluating
 "imports.extensions.name". It would be nice if this also worked
for native modules, I imagine it to be quite common that you
write a module with core parts in C and some high-level stuff in
js.

The question is, how should this be handled regarding searchpaths
etc?

If your module is installed in /usr/local/lib/seed, then you
probably installed the extension js in
/usr/local/share/seed/extensions, and imports.extensions would be
the right thing.

But what happens if your module is installed somewhere else? It
should probably start with the same dir as the native module,
then go on with imports.searchPath, and if the file is found call
 seed_importer_handle_file() on it..

BTW, what happens if you have 'extensions' folder in more than
one search path? will extensions.foo search for 'foo' in all of
those or only the first match for 'extensions'? Just doing a
'imports.extensions' will of course create only one dir_importer
for that folder, hiding possible 'extensions' folders later in
the searchpath. I don't know if this is a good thing...

/Jonatan _______________________________________________ libseed-list mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list
_______________________________________________ libseed-list
mailing list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list
_______________________________________________ libseed-list mailing
list libseed-list gnome org http://mail.gnome.org/mailman/listinfo/libseed-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]