Are feature-addition patches for the js.c shell welcome?
Peter Michaux
I've been experimenting with JavaScript for a server-side web
framework. I've long wondered why JavaScript hasn't caught on as a
general-purpose scripting language and now I think I know why: the
Spidermonkey shell (i.e. js.c) doesn't have many facilities to deal
with the outside world of the system.
It seems that js.c isn't far from matching the capabilities of Ruby,
for example, but js.c is missing some important bits. File, Dir, and
Process classes to interact with the system would all be important
additions. The nspr project can help here apparently. The feature I am
most interested in is a require() function that enables dynamically
linked libraries. This would allow for user-specific extensions in C
without recompiling js.c and even a standard library. Then the sky
would be the limit.
There are projects on the web by some JavaScript enthusiasts that are
extending js.c; however, is the Mozilla team interested in patches for
js.c to add some of the features I've listed. If the central
Spidermonkey project was the focus for enhancements then I think there
would be more success in advancing JavaScript as general-purpose
scripting language. Would patches be welcome?
The Mozilla CVS tree has js/ which is C, js2/ which is C++ and the
tamarin project is C++. Will the currrent js/src/js.c shell die when
JavaScript 2.0 appears? Will a new shell in C++ replace it?
Thank you,
Peter
bre...@mozilla.org
> Hi,
>
> I've been experimenting with JavaScript for a server-side web
> framework. I've long wondered why JavaScript hasn't caught on as a
> general-purpose scripting language and now I think I know why: the
> Spidermonkey shell (i.e. js.c) doesn't have many facilities to deal
> with the outside world of the system.
Too true. But it would be sad if we had to write a bunch of glue for
handy library functionality by hand.
The truth is that js.c is really a REPL for testing, both interactive
and testsuite-automated (js/tests/jsDriver.pl, Bob Clary's web browser
harness for the same suite).
> The nspr project can help here apparently. The feature I am
> most interested in is a require() function that enables dynamically
> linked libraries. This would allow for user-specific extensions in C
> without recompiling js.c and even a standard library. Then the sky
> would be the limit.
Don't forget better garbage collection scheduling. Right now js.c does
nothing but set a 64MB limit on nominal heap size and JS_malloc
cumulative bytecount. Both are crude measures of memory pressure, or
something even less clear. More work could be done using the existing
API, with help from benchmarking (see my cross-posted reply to John
Resig's JS benchmark post).
> There are projects on the web by some JavaScript enthusiasts that are
> extending js.c; however, is the Mozilla team interested in patches for
> js.c to add some of the features I've listed. If the central
> Spidermonkey project was the focus for enhancements then I think there
> would be more success in advancing JavaScript as general-purpose
> scripting language. Would patches be welcome?
Yes, we would entertain patches, although we'll have to be ready for
Tamarin integration (ActionMonkey is at stage 0, see
http://wiki.mozilla.org/JavaScript:Action_Monkey) and be flexible
about how things evolve then.
> The Mozilla CVS tree has js/ which is C, js2/ which is C++ and the
> tamarin project is C++. Will the current js/src/js.c shell die when
> JavaScript 2.0 appears? Will a new shell in C++ replace it?
js2 is dead. The ActionMonkey work and all Tamarin development are
taking place in http://hg.mozilla.org/. There will be a testing REPL
at least, but what you propose would be welcome in any case. Right
now, Tamarin lacks a fully-integrated self-hosted compiler, so you
have to run an ABC compiler (ASC from http://flex.org/, MTASC, etc.)
to compile source to bytecode. Before this is fixed, extending js.c
would help you get more joy, and help us know where a "js shell"
worthy of the name should go. So I say hack on js.c for now.
/be
Peter Michaux
Thanks for the info.
On Jul 16, 3:00 pm, "bren...@mozilla.org" <bren...@mozilla.org> wrote:
> The truth is that js.c is really a REPL for testing, both interactive
> and testsuite-automated (js/tests/jsDriver.pl, Bob Clary's web browser
> harness for the same suite).
I ripped js.c apart and did really get the sense that it was for
experimentation and testing.
Thanks for the pointer to garbage collection issues.
> The ActionMonkey work and all Tamarin development are
> taking place inhttp://hg.mozilla.org/. There will be a testing REPL
> at least, but what you propose would be welcome in any case.
I figure the API could really change when Tamarin is fully integrated.
Will the jsapi.h file stay mostly intact or is the whole API going to
change? Will the API be C or C++?
> Before this is fixed, extending js.c
> would help you get more joy, and help us know where a "js shell"
> worthy of the name should go. So I say hack on js.c for now.
My JavaScript runtime now only has a vanilla global object and a
single function require() which can be used to dynamically load
extensions written in C or JavaScript. This is modeled after Ruby's
require() with a user modifiable require.path array of directories to
be searched for extensions. Even in a shell this is enough. The first
thing the user does could be require('shellFunctions') where
shellFunctions is a C extionsion with help(), quit() etc; however, it
may make sense for the shell to auto-include these. I believe there is
a nice purity in this extension-based design.
I really think that an extensible Actionmonkey and a "official" js
shell intended for real use could be successful if it was in the
Mozilla tree when Actionmonkey and JavaScript2/ECMAScript4 are
released.
Thanks again,
Peter