From: Dominic Mitchell Date: 22:52 on 29 May 2006 Subject: JavaScript Implementations JavaScript -- the new respectable face of the web. Until you want to do anything with it outside of a browser. There's apparently lots of choice: * Rhino -- except that loading a full JVM to run a few lines of JavaScript code is living using a JCB to swat a fly. * SpiderMonkey -- Mozilla's JavaScript engine, ripped out and zombie-like. * njs -- so dormant it's like Rip van Winkle. * WSH -- yep, that'll work really well on my mac. All I wanted to do was run JSLint at the command line. Surely it can't be that hard? Yet SpiderMonkey has no I/O capabilities at all. Rhino has ReadFile(), but it's Java and slow. njs couldn't even parse the bloody jslint source, let alone try providing some input to it. That's OK, I'll work around this by using JavaScript::SpiderMonkey and a small bit of Perl. Except that appears to hang completely when run against the simplest function(). What a steaming pile of donkey turds.
From: Yoz Grahame Date: 01:33 on 30 May 2006 Subject: Re: JavaScript Implementations On 5/29/06, Dominic Mitchell <dom@xxxxxxxxxxxx.xxx> wrote: > JavaScript -- the new respectable face of the web. Until you want to do > anything with it outside of a browser. There's apparently lots of choice: > > * Rhino -- except that loading a full JVM to run a few lines of > JavaScript code is living using a JCB to swat a fly. > * SpiderMonkey -- Mozilla's JavaScript engine, ripped out and zombie-like. > * njs -- so dormant it's like Rip van Winkle. > * WSH -- yep, that'll work really well on my mac. > > All I wanted to do was run JSLint at the command line. Surely it can't > be that hard? Yet SpiderMonkey has no I/O capabilities at all. Rhino > has ReadFile(), but it's Java and slow. njs couldn't even parse the > bloody jslint source, let alone try providing some input to it. > > That's OK, I'll work around this by using JavaScript::SpiderMonkey and a > small bit of Perl. Except that appears to hang completely when run > against the simplest function(). What a steaming pile of donkey turds. A couple of alternatives for you: XPCShell is Spidermonkey with a command prompt and print() function http://www.mozilla.org/scriptable/XPCShell.html A different Spidermonkey module for Perl http://search.cpan.org/~claesjac/JavaScript-0.55/ -- Yoz
From: Stephen Deken Date: 19:44 on 30 May 2006 Subject: Re: JavaScript Implementations > > All I wanted to do was run JSLint at the command line. Surely it can't > > be that hard? Yet SpiderMonkey has no I/O capabilities at all. Maybe try compiling with -DJS_HAS_FILE_OBJECT and using the File object? --sjd;
From: Dominic Mitchell Date: 07:49 on 31 May 2006 Subject: Re: JavaScript Implementations Stephen Deken wrote: >> > All I wanted to do was run JSLint at the command line. Surely it can't >> > be that hard? Yet SpiderMonkey has no I/O capabilities at all. > > Maybe try compiling with -DJS_HAS_FILE_OBJECT and using the File object? Yep, works great -- if you've got a full mozilla source tree and not just spidermonkey. Oh, and the patience to build mozilla. -Dom
From: Chris Nandor
Date: 21:11 on 30 May 2006
Subject: Re: JavaScript Implementations
At 22:52 +0100 2006.05.29, Dominic Mitchell wrote:
>JavaScript -- the new respectable face of the web. Until you want to do
>anything with it outside of a browser. There's apparently lots of choice:
>
>* Rhino -- except that loading a full JVM to run a few lines of
>JavaScript code is living using a JCB to swat a fly.
>* SpiderMonkey -- Mozilla's JavaScript engine, ripped out and zombie-like.
>* njs -- so dormant it's like Rip van Winkle.
>* WSH -- yep, that'll work really well on my mac.
>
>All I wanted to do was run JSLint at the command line. Surely it can't
>be that hard? Yet SpiderMonkey has no I/O capabilities at all. Rhino
>has ReadFile(), but it's Java and slow. njs couldn't even parse the
>bloody jslint source, let alone try providing some input to it.
>
>That's OK, I'll work around this by using JavaScript::SpiderMonkey and a
>small bit of Perl. Except that appears to hang completely when run
>against the simplest function(). What a steaming pile of donkey turds.
[pudge@bourque js]$ cd /usr/local/src/js/src/Darwin_DBG.OBJ
[pudge@bourque js]$ cat > test.js
var x = { a: 1, b: 26 };
print(x.b + x.a);
[pudge@bourque js]$ ./js test.js
27
[pudge@bourque js]$ ./js
js> var x = { a: 1, b: 26 };
js> x.b + x.a;
27
Dunno if this helps you ... but I was able to compile SpiderMonkey for Mac
and run it on the command line without much difficulty.
From: Dominic Mitchell
Date: 07:51 on 31 May 2006
Subject: Re: JavaScript Implementations
Chris Nandor wrote:
> At 22:52 +0100 2006.05.29, Dominic Mitchell wrote:
>> JavaScript -- the new respectable face of the web. Until you want to do
>> anything with it outside of a browser. There's apparently lots of choice:
>>
>> * Rhino -- except that loading a full JVM to run a few lines of
>> JavaScript code is living using a JCB to swat a fly.
>> * SpiderMonkey -- Mozilla's JavaScript engine, ripped out and zombie-like.
>> * njs -- so dormant it's like Rip van Winkle.
>> * WSH -- yep, that'll work really well on my mac.
>>
>> All I wanted to do was run JSLint at the command line. Surely it can't
>> be that hard? Yet SpiderMonkey has no I/O capabilities at all. Rhino
>> has ReadFile(), but it's Java and slow. njs couldn't even parse the
>> bloody jslint source, let alone try providing some input to it.
>>
>> That's OK, I'll work around this by using JavaScript::SpiderMonkey and a
>> small bit of Perl. Except that appears to hang completely when run
>> against the simplest function(). What a steaming pile of donkey turds.
>
> [pudge@bourque js]$ cd /usr/local/src/js/src/Darwin_DBG.OBJ
> [pudge@bourque js]$ cat > test.js
> var x = { a: 1, b: 26 };
> print(x.b + x.a);
> [pudge@bourque js]$ ./js test.js
> 27
> [pudge@bourque js]$ ./js
> js> var x = { a: 1, b: 26 };
> js> x.b + x.a;
> 27
>
> Dunno if this helps you ... but I was able to compile SpiderMonkey for Mac
> and run it on the command line without much difficulty.
Spidermonkey works fine on it's own. It's trying to access it via the
Perl bindings that breaks so badly. Why should I care about that?
Because I want to do something more useful than the built in extremely
limited environment allows (I/O).
-Dom
Generated at 12:25 on 07 Jun 2007 by mariachi