Closed cefn closed 4 years ago
@cefn Hey Cefn, thanks for the request.
FYI CouchDB 3.0.0 now ships with SM60 support. We no longer build SM60 ourselves, except for Windows, relying on the version provided by the distribution (Linux). I believe we use a brew recipe on macOS. You'll need to take it up with the packagers (e.g., Debian, RedHat, Ubuntu, etc.) if you want them to provide a SpiderMonkey REPL in their packages. It looks like, right now, you can get that from libmozjs-60-dev
via /usr/bin/js60
.
As we don't intend to put any more effort into SM 1.8.5 at this point, I'm going to close this as a wontfix.
Thanks @wohali.
Unfortunately I've maintained a fallback to targeting Cloudant for my project if and when I need scale, (effectively compatibility with couchdb 2.x.x and Spidermonkey 1.8.5 ?). Also my dev machine is stretch currently so even when I'm running 3.0.0 I'm still in a 1.8.5 hinterland as sm60 is not distributed and linked for couchdb on stretch.
I totally understand the team should focus on active supported versions, and it's best for the community for you to be able to get features out rather than fighting with long-dead builds for a minority. I'll be following along soon as buster is rolled out to my desktop, and perhaps as Cloudant starts targeting newer versions. Looking forward to performance improvements when I can get an SM60 interpreter to do the indexing work!
In the meantime I guess I can rely on getting SM60 via the docker packaging for local development ( https://github.com/apache/couchdb-docker/issues/163 ) and may in practice be deploying against Pouchdb lambdas over a DynamoDB or S3 leveldown when I finally go for a 'cloud' store alternative and that will basically mean node12 as a m/r interpreter anyway.
I'm having way too much fun with Couchdb and its cousins so thanks for all your impressive work!
@wohali is there a way to tell if I'm successfully running a couchdb server that's running with sm60 support?
Couldn't see any performance difference between docker versions couchdb:3.0.0
vs the original case I was testing couchdb:2.3.1
It may be because I haven't loaded in the sm60 support to the couchdb buster container I made from the official image but I am not sure how I would be able to tell one way or the other. Tried /opt/bin/couchjs -V
from the docker exec -it
console against the couchdb:3.0.0
, but that only reports the couchdb version.
Perhaps based on http://mail-archives.apache.org/mod_mbox/couchdb-commits/202002.mbox/%3C20200228163259.36ECB8DACC@gitbox.apache.org%3E I should assume that if it's 3.0.0 on an official couchdb docker image (therefore buster) then it's sm60...
CouchDB's convenience binaries only link against SM 60 on debian buster CouchDB's convenience binaries only link against SM 60 on the
x86_64
andppc64le
architectures. This includes the Docker image for these architectures. All other packages and Docker images link against SM 1.8.5
Sorry for the noise. Dug out some long-lost memories of c programming and did this, which settles it I believe...
root@562e9ec9f19f:/# ldd /opt/couchdb/bin/couchjs
linux-vdso.so.1 (0x00007fff685e3000)
libmozjs-60.so.0 => /usr/lib/x86_64-linux-gnu/libmozjs-60.so.0 (0x00007d9608c2a000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007d9608b99000)
...
Correct, that's the acid test.
To interrogate CouchDB's JavaScript support, you can just use the Dev Tools REPL in Firefox vN, where N is the version of SpiderMonkey bundled with CouchDB (available via GET /_node/_local/_versions
).
Summary
It would be great if Couchdb would either distribute a libmoz185
js
interactive shell build or offer guidance how and where this can be achieved.In this way, I could see my map,reduce,update code running in Spidermonkey 1.8.5, see it fail if there are compatibility problems, and iterate rapidly.
I hope I am not wasting everyone's time if there's an obvious way to run this from couchdb binaries but I can't find it documented anywhere and my attempts to achieve it myself through exploring couchdb distributed files and Spidermonkey legacy source tarballs have failed.
Background
It is important prove whether the javascript primitives in my map, reduce, update function code are compliant for the target environment. To help with this, I would like to be able to run the Spidermonkey REPL and check for the use of particular javascript syntax and global objects. However, I am struggling to achieve this for Spidermonkey 1.8.5 against a modern (linux) desktop build.
The couchjs binary doesn't appear to have an interactive shell mode. I guess its build is dedicated to the hosting of the monolithic main.js which acts as the query server.
I have made an attempt to build the Spidermonkey js (javascript shell) repl but I have failed, (I think owing to changes in c-compiler conformance and modern architectural targets). All links point to the CouchDB source as the most maintained version of Spidermonkey 1.8.5, but from what I can see in the couchdb packages, an interactive shell is not shipped with this build.
Ironically many attempts to get a debian package to install the
js
Spidermonkey REPL binary forces the uninstallation of couchdb because of its conflicting libmoz185 version. This incompatibility further emphasises the value of distributing a blessed version of thejs
interactive shell with couchdb. However, even after agreeing to uninstall couchdb to explore this option I wasn't able to find an interactive shell within any libmoz185xxx or libmoz185xxx-dev.deb
packages.Desired Behaviour
Once couchdb is installed, it should be possible to identify and run a
js
interactive shell from the console which runs the same version of Javascript as used in the evaluation of couchdb indexing functions.Possible Solution
There are legacy instructions for building the Spidermonkey 1.8.5 interactive shell which I found non-functional (or no longer current) at Mozilla. I believe there is a build chain for doing this from the same codebase which has been vendored-in to couchdb but I can't find any example of the binary being built.