Re: libseed-list js extensions for native modules

["Alan Knowles" <alan akbkhome com>]

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
> >