On Fri, Jun 29, 2012 at 06:24:58PM +0100, Chris Young wrote: > On Fri, 29 Jun 2012 17:28:39 +0100, Vincent Sanders wrote: > > > A simple javascript abstraction has been added allowing for > > alternative javascript interpreters to be added in future. And an > > initial implementation added for the spidermonkey interpreter/jit > > (jsapi) this integration allows for javascript code to be correctly > > gathered and executed from script tags. > > That's good to hear. Spidermonkey is perhaps a bit "heavy", partly > due to being C++ (so the std C++ lib has to be loaded too), and
the spidermonkey versions i have been targetting are the c API versions of the 1.8 series so are simply heavy rather than obease > current versions are awkward to port due to the dependency on NSPR > (although there is a Bugzilla open to remove this dependency which I'm > keeping my eye on). Unfortunately it's probably our best option - I > don't know of any decent lighter Javascript engines. I tried v8 and looked at a couple of others but none are vaugely usable in our situation and really few of the larger js libs are usuable outside their parent browser projects. > > > What is now required is to add bindings to the javascript runtime for > > all the DOM operations including the so called DOM0 objects like the > > global window object and all the associated sub objects like > > navigator, console etc. > > Would that need to be done again if somebody decides to add support > for a different Javascript library? alas, yes, which is why I tried to work from the web IDL, turns out the IDL samples are incomplete and kinda assume a type system that does not exist within javascript and fits very badly, at which point working from them is pointless as you end up with special casing to make the "ideal" spec fit the real world. Oh and add in the IDL is simply missing for most of DOM0 > > > Although there is no explicit dependency on > > specific versions of spidermonkey I am primarily basing my efforts on > > the 1.8.5 releases as this are the most common version found in > > distributions. > > v1.50-2 (which is positively prehistoric, but the only working ported > version I have) unfortunately does not work, I fudged it with some > macros from newer Spidermonkey includes, and it is calling alert > (warn_user()) but with no text. Not sure if it is easy to get it > working, for such an old version it's probably not worth it. I have > a quick port of Spidermonkey 1.85 but having issues with it crashing; > I guess I have quite a while to fix this though. most probably because the JSAPI native calling function spec changed in an incompatible way! can you tell me what JS_VERSION is on your version of the library? I might be able to come up with something...but currently I am a bit stumped how to alter the native calling convention at compile time without some hedious macro magic > > I'd be interested to hear which versions of Spidermonkey are ported to > other operating systems we target (and any porting tips!) > > Chris > > - Debian squeeze has 1.8.0 - Debian wheezy has 1.8.5 - I have dev builds using 1.8.9 but they are not really representative of anything - Ubuntu 11.04 has 1.8.5 in the alternate include layout (thats why there are two pkgconfig names/paths sigh) - Ubuntu 11.10 and later seems to be 1.8.5 in various include layouts So I guess that answers the question about which API major version to pick, I think 1.8 series is still the right target -- Regards Vincent http://www.kyllikki.org/
