Re: libseed-list js extensions for native modules

["Alan Knowles" <alan akbkhome com>]

This is a bit strange, My portable (Ubuntu 10.4) managed to do this fine this morning, however, pretty much every other box I've got shows the same errors that you get..

I've just reverted the get_global_object stuff, as it's not needed (.global was already there)

Testing on a fresh build to see if I can get it to work.

Regards
Alan

 --- On 29/Jun/2010, Jonatan Liljedahl wrote: 
> 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
> >