couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: eep0018 and spidermonkey 1.8.1
Date Mon, 18 May 2009 02:50:50 GMT
I updated github to the following:

This is just the eep0018 integration. It shouldn't require any other
dependencies than what CouchDB currently requires.

This branch includes the upgrades to support spidermnkey 1.8.1 It
requires that 1.8.1 is installed which more than likely requires you
to download the mozilla repository and build it.

Let me know if you can find anything that breaks it or if you have any
speed comparisons. I'd be especially interested if anyone has a decent
size view they could compute using this branch. If not I'll have to go
generate some data.


On Sun, May 17, 2009 at 9:01 PM, Paul Davis <> wrote:
> Hey,
> I've got a CouchDB branch [1] on github that has eep0018 integrated
> into the build system as well as upgrades to make CouchDB work with
> Spidermonkey 1.8.1
> Before you go diving in, this requires building Spidermonkey 1.8.1
> form Mozilla's Mercurial repo. Its pretty cake but it can screw with
> your currently installed spidermonkey when compiling other software so
> be warned.
> To install spidermonkey 1.8.1 on OS X, the directions are like:
> $ sudo port install autoconf213
> $ sudo port install mercurial
> $ hg clone
> $ cd mozilla-central/js/src
> $ autoconf213
> $ sudo make install
> Anyway, I've gotten everything so that all but one test passes. The
> biggest issues came from some of the weirdness in the differences
> between our JSON.stringify and JSON.parse functions and the new C
> functions in SM 1.8.1. I ended up going and reading the docs, and they
> were in favor of spidermonkey's interpretation. The specific bits are
> that when you emit(undefined, undefined) it now actually works and the
> key/value pair null, null is emitted.
> Another point of weirdness is how it handles XML attributes. When
> passing XML to the JSON.stringify methods I had to call .toString() on
> the xml object first.
> So =>
> Its a bit tedious and I'm pretty sure I can override it by adding a
> XML.prototype.toJSON method to return a proper string but that's for
> another day.
> Actually, now that I consider it, I'll change the branches around so
> that eep0018 doesn't have the spidermonkey updates so people can at
> least test that. But first I need to do dishes and some other un fun
> cleaning chores.
> So in short, anyone feel like running this through some sort of
> benchmark script or some such? I haven't even tried to see if it's any
> faster yet.
> [1]

View raw message