Jester support in js.io

[J5]

Hey everyone,

I have written a JavaScript unit tester called Jester[1] using
GNOME's Gjs engine and in order to get it to work with js.io I had to
write a patch[2]. This is probably not the best way to add support
for other environments. I would suggest adding some initialization
code where other engines can register their own hooks so js.io works
in more cases than just node(v8) and inside the browser.

And just to preempt the inevitable, "why another JavaScript unit
testing library" question - I wrote it to learn the internals of Gjs
and to provide a library that Gjs desktop applications can include
directly which follows their module guidelines. Hopefully it will
lead to code that can be reused on the web and the desktop as well as
bring the two platform a bit closer together at some point. It just so
happens that my kamaloka-js project which uses js.io benefits from the
unit tester also. Hence the need for the patch.

Let me know if you will include the patch directly or if you want to
discuss ways we can have js.io load custom hooks. Thanks.

[1] http://live.gnome.org/Jester
[2] http://live.gnome.org/Jester?action=AttachFile&do=view&target=jsio-jester.patch

[Marcus Westin]

Hey John,

Cool stuff! Looking at http://github.com/mcarter/js.io/blob/master/packages/jsio.js
it seems like support is already there. Try:

jsio = import('jsio.js'); // or however you import code in jester
jsio.setEnv({
'global': GLOBAL,
'getCwd': function() {return __jester_cwd},
'getPath': function() {return __jester_path},
'eval': function(src, path) { return eval(src); },
'log': print,
'findModule': function(possibilities) {
for (var i = 0, possible; possible = possibilities[i]; ++i) {
var f = imports.gi.Gio.file_new_for_path(possible.filePath);
var t = f.query_file_type(0, null);
if(t == imports.gi.Gio.FileType.REGULAR) {
var [success, contents, len, etag] = f.load_contents(null);
possible.src = contents;
return possible;
}
}
}
})

I think that should work - if not, let's figure out why not! You
should not have to modify jsio.js in order to user a new environment.

Cheers!
Marcus

> [2]http://live.gnome.org/Jester?action=AttachFile&do=view&target=jsio-je...

[john palmieri]

That might work if js.io doesn't try to load the browser environment or node environment first.  The reason being, I don't export some of the symbols that might get executed in setting up the initial environment. This line in ENV_browser would do it:

var XHR = window.XMLHttpRequest || function() { return new ActiveXObject("Msxml2.XMLHTTP"); }

first it assumes window exists (it does in Gjs but may not in others) and then if XMLHttpRequest isn't available it trys to create an ActiveXObject which would throw an error unless I am missing some try catch code.

This code ensures that if this is not a Node environment ENV_browser always gets run:

jsio.setEnv(typeof node !== 'undefined' && typeof process !== 'undefined' && process.version ? 'node' : 'browser');

Since setEnv is already there and available, the best patch would be change the above code to check for browser identifiers and not call setEnv if they are not available.  The other possible better fix, since even a non-browser env might export XMLHttpRequest is to make sure that any code that might not exist, defers execution until the first use of the library (though that would necessitate checks in a number of places).  For example XHR is defined as null but only set when something goes to use it and sees that it is not yet initialized.

--
You received this message because you are subscribed to the Google Groups "js.io" group.
To post to this group, send email to js...@googlegroups.com.
To unsubscribe from this group, send email to jsio+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jsio?hl=en.

[john palmieri]

Actually looking at it again, it might be ok.  Let me run some quick tests.

[john palmieri]

Nope.  Gjs is a little more strict with its undefined errors.  It throws an error since window.location is not defined.  Most likely because of the way window is defined in the underlying SpiderMonkey engine.

[Marcus Westin]

Not setting the environment to browser unless (typeof XMLHttpRequest !- 'undefined' || typeof ActiveXObject != 'undefined') seems reasonable. 

Unless anyone disagrees I'll commit a patch tomorrow.

Thanks John!

[Marcus Westin]

just patched master with http://github.com/mcarter/js.io/commit/e5f9bc5316640d08525f569c3500b65d4e67e929

On Mar 23, 11:22 am, Marcus Westin <marcus.wes...@gmail.com> wrote:
> Not setting the environment to browser unless (typeof XMLHttpRequest !-
> 'undefined' || typeof ActiveXObject != 'undefined') seems reasonable.
>
> Unless anyone disagrees I'll commit a patch tomorrow.
>
> Thanks John!
>
> On Tue, Mar 23, 2010 at 11:14 AM, john palmieri

> <john.j5.palmi...@gmail.com>wrote:

>
>
>
> > Actually looking at it again, it might be ok.  Let me run some quick tests.
>

> > On Tue, Mar 23, 2010 at 2:12 PM, john palmieri <john.j5.palmi...@gmail.com

> > > wrote:
>
> >> That might work if js.io doesn't try to load the browser environment or
> >> node environment first.  The reason being, I don't export some of the
> >> symbols that might get executed in setting up the initial environment. This
> >> line in ENV_browser would do it:
>
> >> var XHR = window.XMLHttpRequest || function() { return new
> >> ActiveXObject("Msxml2.XMLHTTP"); }
>
> >> first it assumes window exists (it does in Gjs but may not in others) and
> >> then if XMLHttpRequest isn't available it trys to create an ActiveXObject
> >> which would throw an error unless I am missing some try catch code.
>
> >> This code ensures that if this is not a Node environment ENV_browser
> >> always gets run:
>
> >> jsio.setEnv(typeof node !== 'undefined' && typeof process !== 'undefined'
> >> && process.version ? 'node' : 'browser');
>
> >> Since setEnv is already there and available, the best patch would be
> >> change the above code to check for browser identifiers and not call setEnv
> >> if they are not available.  The other possible better fix, since even a
> >> non-browser env might export XMLHttpRequest is to make sure that any code
> >> that might not exist, defers execution until the first use of the library
> >> (though that would necessitate checks in a number of places).  For example
> >> XHR is defined as null but only set when something goes to use it and sees
> >> that it is not yet initialized.
>

> >>> jsio+uns...@googlegroups.com <jsio%2Bunsu...@googlegroups.com>.

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/jsio?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups "
> > js.io" group.
> > To post to this group, send email to js...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > jsio+uns...@googlegroups.com <jsio%2Bunsu...@googlegroups.com>.