I had to do some hackery to get this building on 10.6 with Homebrew. I
mostly hacked together a fake nspr.pc and dropped it in [1] so that
the pkgconfig stuff in setup.py would work. There's a copy of this
file in the "extra" directory in this repo. I also added a patch
for the va_copy like MacPorts does.

If anyone would like to tear out the embedded copy of Spidermonkey
that this package ships with and update the build system to use
either what Homebrew installs or is found in the xulrunner package
on Ubuntu, that would be awesome.

[1] /usr/local/lib/pkgconfig/nspr.c

This should not only make tracebacks better, but also allow Python
to open the JavaScript file so as to show the correct line (of
course, given the filename can be found.)

Fixed MANIFEST.in with a pointer from Roberto.

Turns out that I had an error in my logic about how to reference count
the python context object. I removed references to it from Python
objects that are wrapped in the JavaScript VM. I'm more than 50% certain that
this is correct as when the Python context dies, it'll destroy the
JSContext* and along with it all references to Python objects that need
refernces to the Context.

[#21 state:resolved]

JavaScript requests for data from the Python VM can now be filtered by
specifying an access callback function on the Context instance. See the
README or test-access.py tests for API usage.

Thanks to Richard Boulton for the initial patch.

Keiji Costantini reported the test as failing on Gentoo on amd64. I imagine the
64 bit might've had something to do with memory requirements for start up as it
seems just enough to get a working context on my 32 bit machine. I upped the
limit and memory usage of the test. Thanks Keiji.

Thanks to Spahl for the report, patch, and test, and general awesomeness
at being so thorough.

[#17 state:resolved]

    >>> rt = spidermonkey.Runtime()
    >>> cx = rt.new_context()
    >>> cx.add_global("bang", [2, "got me!"])
    >>> assert cx.execute("bang[1];") == "got me!"

Thanks to spahl for the report and fix.

[#16 state:resolved]

JavaScript acts a bit odd in this case in that the body of 'foo' is passed to
JS_Class.add_property but not JS_Class.set_property. For now I added an add_prop
method that special cases when the passed in value is a function and delegates
to set_prop.

While I was at it, I went ahead and added support for deleting global properties
as well. If your global handler has __delitem__ defined, it will now get called
for the JavaScript statement "delete foo;"

Thanks to Riccardo Pelizzi for the bug report.

Thanks to Mike West

[#5]

The root bug I think has to do with conversions between integral types. I
changed the Context.max_time method to be a bit less clever which will hopefully
fix things. I also updated the test_exceeds_time to fail more gracefully as per
suggestion.

Thanks to Mike West

[#15 state:open]

I added a test that catches the JSError generated by invalid octal. Ricardo, can
you confirm whether this test passes or fails? You can run the tests like such:

    $ python setup.py test

[#12 state:open]

[#12]

Linking against the library works, but importing spidermonkey kills the Python
VM because of an unresolved symbol. Can't figure out if this is just OS X's
build of libmozjs or if I'm missing a flag.

[#12]

Forgot to comment out a hack for OS X.
Missed a pointer cast to avoid compiler warnings.
Thanks to spahl for both.

Out of memory is now signaled by a MemoryError
Too much CPU time is reported as a SystemError

I'm going to punt on the issue with specifying memory usage limits on contexts
when it really refernces the runtime. I don't see a good way to implement it
without quite a bit of work. It'll never be specifiable per context, only the
api might change to avoid confusion.

[#12 state:resolved]

You can now enforce crude resource usage limits for scripts executing in the JS
VM. Its not overly granular and has some caveats, but it appears to work.

To limit the time a script can run:

    >>> rt = spidermonkey.Runtime()
    >>> cx = rt.new_context()
    >>> cx.max_time(5) # Specified in seconds, returns the previous value.
    0
    >>> cx.execute("while(true) {}")
    ...
    RuntimeError

To limit the amount of memory is similar:

    >>> rt = spidermonkey.Runtime()
    >>> cx = rt.new_context()
    >>> cx.max_memory(10000) # Specified in bytes, returns the previous value.
    0
    >>> cx.execute("var f = []; var b = 100000; while(b-- > 0) f.push(b*0.9)")
    ...
    RuntimeError

At the moment this looks like its limiting resources per context when in reality
its per runtime. So if you limit to usage on a context, and some other script in
the context is running above that limit, the limited context will fail.

You can also get the current values without setting:

    >>> cx.max_time(10)
    ...
    >>> cx.max_time()
    10
    >>> cx.max_memory(10000)
    ...
    >>> cx.max_memory()
    10000

Some minor tweaks to make the memory limit specified on the Runtime and to
improve the reported errors to follow shortly.

[#12]

If you want to be able to global properties using some sort of active logic you
can now pass an object that has __getitem__ and __setitem__ defined to
Runtime.new_context(). Something like:

    >>> rt = spidermonkey.Runtime()
    >>> cx = rt.new_context({"foo": "bar"})
    >>> cx.execute("foo;")
    'bar'

[#9 state:resolved]

This should wrap entries into the JS VM in JS_BeginRequest/JS_EndRequest calls.
I've added a setup.py debug flag to build spidermonkey in debug mode so that
calls into the VM requiring a request fail on an assert. To build in debug mode
you can do:

    python setup.py --debug $(ACTION)

I basically went through and added the calls where I thought they should go and
then turned on the debug build to get the ones I missed. Its quite possible I
still have some edge cases missing their required calls.

[#2 state:resolved]

Added the 'for each(var v in obj)' semantics to iteration.

[#1 state:resolved]

Thanks sk89q for the patch.

[#13 state:resolved]

Conflicts:
	tests/test-iterate.py

You can now do the 'for val in obj' syntax when obj is a wrapped JavaScript
object.

Thanks Mark Lee for the patch showing how to do this for arrays.

[#10 state:resolved]

This passes the basic tests. I need to add a check to detect if we're doing 'for
v in obj' vs 'for each (v in obj)' iteration as they behave differently in
JavaScript.