tracemonkey port ...
Steven Parkes
soon.
I've implemented it beside the spidermonkey port so as not to disturb
the working C code. The build infrastructure is extended to build and
run tests for both interpreters.
Semantically it's not a big change. TM is the evolution of SM.
However, syntactically there's a fair number of small changes: TM is
converting to C++ and while a lot of the API remains C compatible,
there's enough C++ in there to make it incompatible (which can
apparently be expected to become more, not less ... the parser is a C+
+ class and has no C API.)
So I've made the Johnson TM runtime basically the SM runtime with the
minimum necessary changes to make it valid C++. No semantic changes.
Basically all the changes are to make C++ strong typing work. There
are places where that's less than straightforward because of the
macros. I made minimal if inelegant changes to make the compiler
happy. I figure it can be improved once the code works.
It looks like the parse tree/ops have changed a little bit
semantically, so some of the tests fail. I hope to have those fixed
tomorrow.
Aside from wanting to be on the active Moz codebase and, perhaps, gain
speedups, I started this because the current SM that Johnson uses has
a bug that I didn't want to try to fix.
John Barnette
> For what it's worth, I expect to have a tracemonkey port done fairly soon.
That's great! I'd definitely like to get this into the Johnson
mainline when it stabilizes.
> I've implemented it beside the spidermonkey port so as not to disturb the
> working C code. The build infrastructure is extended to build and run tests
> for both interpreters.
Because SpiderMonkey availability varies wildly per platform, we've
vendored (and statically link) it when we build the SM extension.
IIRC, The newer Moz builds use autotools, but require a specific
autoconf version (ugh). Are you vendoring the TM codes as well, or
linking dynamically against an installed lib on your system?
> It looks like the parse tree/ops have changed a little bit semantically, so
> some of the tests fail. I hope to have those fixed tomorrow.
Yeah, they're intentionally not stable API, but we (Aaron) wanted to
get parse trees out badly enough that it's worth it. :)
> Aside from wanting to be on the active Moz codebase and, perhaps, gain
> speedups, I started this because the current SM that Johnson uses has a bug
> that I didn't want to try to fix.
I'd like to hear from Matthew, but I think in general we're in favor
of tracking Mozilla's latest stable releases. The version of SM we're
on is definitely not what's released in FF 3.5.
Where's your fork? GitHub?
~ j.
Steven Parkes
Yeah. I created a snapshot of the current TM in the moz hg. It's
buried deep in their repo, so I pulled it out and made a git repo of
just js/src (with tests). (I haven't seen any hg bridges that would
seem to work like, say git-svn does, especially since I don't want the
whole moz tree, which is huge. If anyone knows otherwise ...)
http://github.com/smparkes/spidermonkey
Note that this is from the main moz repo. There is a separate TM repo
at moz that gets merged into the main moz repo periodically. Based on http://tinyurl.com/yhcoby6
, I chose the main repo rather than the TM repo. (I have no ideas if/
what plans they have for independent TM releases).
I pull the TM repo into the Johnson repo as submodule. While my git
repo is called spidermonkey (which is what moz calls it) I bring it in
as vendor/tracemonkey so it doesn't displace spidermonkey immediately.
I went ahead and finished the multi-runtime support code in lib/
johnson, e.g., took out the hardcoded spidermonkey defaults. Should be
able to have multiple runtimes now (though that _won't_ work for SM/TM
because they use the same symbols since they're basically different
versions of the same code). How to select the runtime is up in the
air ...
I'm building statically, just as the SM build does. The current TM
Makefile.ref doesn't work on OS X (for me, anyway), so I go ahead and
run autoconf (the right version, which I have). My idea was to check
in the configure script created by running autoconf before building
the gem, so people don't have to have autoconf to install the gem. In
theory, that should work, right? In reality, not so sure. In any case,
the Rakefile only tries to run autoconf if the configure script isn't
there. I have no idea if the versioned autoconf has the same name
everywhere it's installed.
> Yeah, they're intentionally not stable API, but we (Aaron) wanted to
> get parse trees out badly enough that it's worth it. :)
Yeah, I agree. I wanted to fix it, rather than ditch it.
> I'd like to hear from Matthew, but I think in general we're in favor
> of tracking Mozilla's latest stable releases.
Ah, track the TM version by the FF version. That makes perfect sense.
I'll just add the appropriate branch to the TM gh repo. Then it's easy
enough to try different versions simply by checking out the
appropriate branch of the repo as the submodule.
Of course, it'd be nice to have the git repo auto-updated from the moz
repo, but unless someone knows of tools to make that easy, I'm not
going to bite it off now.
> Where's your fork? GitHub?
Yeah, git://github.com/smparkes/johnson.git, but I haven't pushed this
stuff yet.
Matthew Draper
> tracemonkey
!!
> I went ahead and finished the multi-runtime support code in lib/
> johnson, e.g., took out the hardcoded spidermonkey defaults. Should be
> able to have multiple runtimes now (though that _won't_ work for SM/TM
> because they use the same symbols since they're basically different
> versions of the same code). How to select the runtime is up in the
> air ...
My current plan was to eventually split into a 'johnson', that just
contains some abstract classes (with public API documentation), generic
(pure ruby/JS) type-conversion code, etc, and a 'johnson-spidermonkey'
that contains subclasses (J::SM::Runtime, etc)... so you can just
require 'johnson/spidermonkey' if that's the runtime you want... or,
ideally, just require 'johnson' and have it guess(?) which runtime to
use the first time you call J::Runtime.new.
Said plan hasn't really been thought through, though. :)
> > I'd like to hear from Matthew, but I think in general we're in favor
> > of tracking Mozilla's latest stable releases.
>
> Ah, track the TM version by the FF version. That makes perfect sense.
> I'll just add the appropriate branch to the TM gh repo. Then it's easy
> enough to try different versions simply by checking out the
> appropriate branch of the repo as the submodule.
Sounds good... I certainly have no particular interest in stagnating on
an older version. :)
Matthew
Steven Parkes
On Oct 13, 2009, at Oct 13,7:21 AM , Matthew Draper wrote:
> generic
> (pure ruby/JS) type-conversion code, etc, and a 'johnson-spidermonkey'
> that contains subclasses (J::SM::Runtime, etc)... so you can just
> require 'johnson/spidermonkey' if that's the runtime you want... or,
> ideally, just require 'johnson' and have it guess(?) which runtime to
> use the first time you call J::Runtime.new.
Yeah, I've cleaned up that split, at least enough to let two runtimes
coexist (as long as they don't conflict at the shared lib level, which
spidermonkey and tracemonkey do.)
I figure the most controversial part is how to select the default
runtime, in particular when using the johnson cli, but for other
cases, too.
I'm not crazy about env variables and command switches have to be
integrated with every app. So I took the arguably too cute method of
adding a inherited callback and using the first inherited subclass
(hmmm ... could use the last, too ...) as the default, e.g., "ruby -S -
rjohnson/tracemonkey johnson". Maybe not a good general solution, but
convenient for testing.
Steven Parkes
objects: outer/inner objects that are used to implement the window
object in browser environments (so that window.location = "...."
works). Mostly a copy of the stuff in the TM shell.
I added the option of passing a global to the compiler and a scope to
the evaluator.
I ended up adding a conditional around the call to the compiler: SM/TM
sometimes return null: in particular when there's an out-of-memory.
This was confusing me (thought it was something deeper). This was
partially because I thought, reading the API docs, that the amount of
memory given when init'ing SM/TM was just the initial size of the
memory pool (used to decide when to do the first GC). This doesn't
appear to be the case: it's a hard limit. Which probably means we need
a way to set it. I bumped the fixed number by adding a zero.
It's in my repo at git://github.com/smparkes/johnson.git, on the envjs
(default) branch. Also installable via "gem install smparkes.johnson"
from gemcutter.
For those interested, there's an early copy of envjs ported to Johnson
and packaged as a gem in my repo at git://github.com/smparkes/env-
js.git. It's on the envjsrb branch (which is not the default). Or you
can "gem install smparkes.envjs". After that you can do things like:
smparkes@barronpark ~/env.js $ envjsrb
INFO: [Tue Oct 27 2009 18:33:54 GMT-0700 (PST)] {ENVJS} Initializing
Core Platform Env
js> window.location = "test/index.html"
INFO: [Tue Oct 27 2009 18:34:16 GMT-0700 (PST)] {ENVJS} adding value
to history: file:///home/barronpark/smparkes/env.js/test/index.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Initializing
Core Platform Env
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} adding value
to history: file:///home/barronpark/smparkes/env.js/test/html/iframe1.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Sucessfully
loaded document at file:///home/barronpark/smparkes/env.js/test/html/iframe1.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Initializing
Core Platform Env
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} adding value
to history: file:///home/barronpark/smparkes/env.js/test/html/events.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Sucessfully
loaded document at file:///home/barronpark/smparkes/env.js/test/html/events.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Initializing
Core Platform Env
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} adding value
to history: file:///home/barronpark/smparkes/env.js/test/html/scope.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Sucessfully
loaded document at file:///home/barronpark/smparkes/env.js/test/html/scope.html
INFO: [Tue Oct 27 2009 18:34:17 GMT-0700 (PST)] {ENVJS} Sucessfully
loaded document at file:///home/barronpark/smparkes/env.js/test/index.html
=> "test/index.html"
js> rb
rb> window = js["this"]
=> [object Window 0]
rb> window.document.title
=> "jQuery Test Suite"
I wanted to show "window.frames.map(&:document).map(&:title)" but
envjs doesn't implement frames() yet ...
The Johnson/TM version runs all the envjs and jquery tests the rhino
port does, but the differences between the two haven't been resolved
yet, so while the API shouldn't change, the code will ...