I have a version of env.js ported to johnson(ruby gem, based on  
tracemonkey) working, passing the env.js tests, and a slighty higher  
number of jquery tests than rhino.

I don't know what stage you would call it. POC/alpha/.... It runs the  
tests and seems reasonably stable, but it's not integrated with the  
java version yet. The multi-window support has to be reconciled  
between the two and the mutli-platform stuff cleaned up a little now  
that we actually have multiple platforms.

It's in my repo at git://github.com/smparkes/env-js.git, on the  
envjsrb branch (not the default). It requires my copy of johnson  
(tracemonkey port), which will get pulled in if you do a "git  
submodule update --init". Then all you have to do is a rake in vendor/
johnson and then a rake at the root of the repo.

Alternately, you can just do a "gem install smparkes.envjs" (you'll  
need to add gemcutter if you haven't yet). That will install both  
envjs and johnson (my version, smparkes.johnson). It takes a while to  
install Johnson because it includes all of tracemonkey (and, actually,  
the older spidermonkey).

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"

js> prompts are javascript; rb> prompts are ruby.

I wanted to show "window.frames.map(&:document).map(&:title)" but we  
don't implement frames() yet ...

This is great news Steven, congratulations and thanks for your contributions
back to the community!  I'm working on a 1.1 release and might have it ready
by as early as tonight, can we use the Johnson logo along with a link to
your project and a little blurb in the news section of our site?

Thatcher

On Tue, Oct 27, 2009 at 11:28 PM, Steven Parkes <smpar...@smparkes.net>wrote:

--
Christopher Thatcher

On Oct 28, 2009, at Oct 28,8:01 AM , chris thatcher wrote:

Seems like good timing. Then we can work through the integration  
issues post-release without holding up things.

Did you want to include the timer stuff in the release? Since it  
hasn't been in the main repo, I could see going either way. I have one  
fairly trivial patch to it that I made on the envjsrb branch which I  
haven't pushed to my timer branch.

Fine by me. I don't know of any logo for Johnson, though. Of for  
spidermonkey/tracemonkey, for that matter.

I should probably make my default branch the envjsrb branch at that  
point, but was waiting till we resolved the timing of the timer branch  
(so to speak.). Though it's easy enough to install it as a gem.

On Oct 27, 2009, at Oct 27,8:28 PM , Steven Parkes wrote:

Small tweak to these instructions: Johnson uses a submodule for  
tracemonkey, so you need to do a "git submodule update --init" in  
vendor/johnson before using rake to build johnson. (Thanks, Glen).

I don't suppose anyone but Glen has tried this yet, but Johnson wasn't  
actually submoduled last night; that's fixed now.

On Oct 28, 2009, at Oct 28,9:04 AM , Steven Parkes wrote:

Pushed to the timer branch.

I also fixed the test factoring that I broke. Sorry about that; I  
think this was bleed over from the envjsrb branch, which needs more  
factoring of the tests so they don's assume java. Anyway, the changes  
are clean and run all the tests against both jars.

I've been toying with a similar idea involving Python and V8:

http://code.google.com/p/pyv8/

It took me a bit to get V8/Python bindings built, but using what
you've done with Ruby and johnson as a guide, it should be possible to
get similar functionality using Python and V8. I'll post again if/when
I get anywhere with it :P Any idea how performance compares between
tracemonkey and v8?

cheers,

~john

Cool.

Only what I've seen on the web, which I don't even remember well. As I  
recall, each had things it was better at, but both are under heavy  
development, so I suspect that changes day by day.

I use env.js for development/test so for me, at least so far,  
performance isn't really a huge deal.

One thing that is fairly subtle and tricky is the handling of the  
window global object. In the browser environment, the global object  
behaves somewhat schizophrenically, which is necessary to make window  
references survive window reloads. SM actually has native support for  
this, which env.js uses. The Rhino port has it's own version of a  
proxy and handles scope management its own way. Unifying the two  
approaches  is being looked at right now, but it's unclear how it's  
going to turn out.

The window proxy and scoping issues are likely to be the biggest  
you'll come across ... everything else is pretty pedestrian.

Hi Steven,

Sorry for the "noob" question, but I seem to be missing something. As
I understand it there are 2 versions of env-js; "env.rhino.js", which
has some rhino-specific parts to it, and then there's "env.js" which
should be loadable in any JS runtime, be it V8, tracemonkey, etc etc,
right? Well, this is where whatever link I'm missing comes in, because
when I do a `load("env.js")`, I get errors like 'Envjs is not
defined'.

In fact loading the plain env.js gives the same errors in rhino, too,
so I'm really confused...where does the "magic" happen that I'm not
seeing? Looking at dist/env.js, it starts right off the bat assuming
there's an `Envjs` object defined. Where does / should that get
defined?

thanks,

~John

On Nov 6, 1:20 pm, Steven Parkes <smpar...@smparkes.net> wrote:

That's not the way thing stand right now. The env.js file has no  
platform-specific code, but it's not usable on its own. Standard  
javascript doesn't have enough functionality to be able to do anything  
with it, e.g., it has no I/O. All the javascript shells add these  
functions and the env.js platform code ties into these for each  
interpreter port.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi John.  Actually not a noob question at all.  This has been the state
of things since before I started working on/with env.js several months
ago.  The conclusion I've come to is that the non-Rhino version of
env.js has actually never been run by anyone.  It is essentially a
best-effort at packaging up the env.js code without any of the Rhino
dependencies.

When I first started working with the code, I kind of assumed that there
was some other JavaScript interpreting platform somewhere that I didn't
know about that pre-defined an object called Envjs.  Now I realize that
there's just no way to define it in a platform-independent way.

So, the work that Steven's been doing lately is essentially
reimplementing all of the Rhino-specific functionality env.js contained
before (no small feat).  And I for one have concluded that there's going
to be a fair amount of work required to get env.js to run within
virtually an JavaScript interpreter, simply because of the fact that a
browser emulation needs to be able to spawn new, independent JavaScript
execution environments.  And, between Rhino and SM/TM, we're
zero-for-two with being able to do this in pure JavaScript.

What interpreter(s) are you trying to run env.js in?

Hope this helped,
    glen

- --
gleneivey on Skype, Y!IM, AIM, Twitter, Facebook, GitHub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr1zB8ACgkQkocwxK1irU2sUwCgo4UA57u7O4indYVuQdPjh7h1
hzgAnjKBGK3AH5avSH8ALesfEUKyQ/F5
=HyH9
-----END PGP SIGNATURE-----

I was starting to realize that must be the case...

I've been playing with google's V8 engine for a few days. There are
Python bindings for it, so I've been working trying to get env.js to
work using Python+V8.

So, looking at the API docs, all the Envjs.* methods need to be
implemented somehow, either in Python in my case, or javascript where
possible?

thanks,

~john

Hi John sorry for chiming in so late. In env source there are two files in
src/platform right now.  One is core.js, the other is rhino.js.  Although I
noticed one or two files that have leaked a java specific line into the
source, the general design is that core.js describes all interfaces that a
new platform has to define for envjs to work correctly and then each new
platform would implement this, for example like we do in rhino.js.  So you
would add a src/platform/v8.js or something and we'ld add a build target for
env.v8.js.

The goal to isolate what is pure js from what is platform specific has been
in place for a long time, so the amount of platform specific code has been
generally minimized to make ports as painless as possible.

Does that help?

Thatcher

--
Christopher Thatcher