incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1302) Fix couchjs
Date Thu, 06 Oct 2011 20:05:31 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122206#comment-13122206
] 

Paul Joseph Davis commented on COUCHDB-1302:
--------------------------------------------

Ok. Here's the situation:

First, an anonymous function at the root of a scope is invalid JavaScript. Ie, the following
is invalid:

    "function(doc) {emit(doc._id, 1);}"

Is broken JavaScript.

But, SpiderMonkey has had an option for years [1] that allowed this. SpiderMonkey happened
to be the only interpreter that has had this. The setting JSOPTION_ANONFUNFIX existed to enforce
the error mechanism. The thing is, it was off by default (ie, the error was not triggered
by default) in older js shells.

Recently, this appears to have caused an error for SpiderMonkey passing the JavaScript test
suite [2]. Along with this patch, the js shell from SM 1.8.5 enables JSOPTION_ANONFUNFIX so
all of the js shell tests we were doing were misleading. couchjs works with the 1.8.5 tarball
from Mozilla. It does not work starting when [2] was applied to trunk (after the 1.8.5 tarball
was created).

So bottom line, this isn't an issue for all of the tarballs from Mozilla's official FTP site,
but it will be an issue moving forward.

So the plan I'm proposing is this:

1. Re-enable support for 1.8.5 on 1.1.x for 1.1.1

2. Revert the paren hack across the board.

3. Add a configure check for JSOPTION_ANONFUNFIX so we can detect if
   user code will break (and perhaps add an option to override it)

4. Update 1.2.x with some new behavior that will force people to upgrade
   all of their function definitions to be correct moving forward. Also note that
   this would be backwards compatible if the named function is the last statement
   as we currently require which should be enforceable in the future (if we so
   desire).

I think 1, 2, and 3 are relatively uncontroversial at this point. We now know how to detect
exactly when old code will break and can warn about it (ie, by refusing to build, (the option
to override I'm less certain about, I'd be +0.5 at this point)).

As to 4, the behavior I would propose at this point is that all of our JS definitions would
require a name in the future. For instance:

     "function(doc) {emit(doc._id, 1);}"

becomes:

    "function map(doc) {emit(doc._id, 1);}"

And then couchjs+main.js gets modified to look for these specific names. I'm thinking we'd
end up with "map", "reduce", "filter", "validate", "show", "list", and "update" given our
current set of user definable functions. For users we'd also need to make our error messages
better. Currently, the error without these names would be something generic like "expression
does not evaluate to a function" or similar which could be change to something like "No function
named 'map'" or similar (though, that obviously needs work cause it could be a real syntax
error as well).

So, 1, 2, and 3 have my +1. I think 4 is probably best going forward, but we can open a new
ticket about how to deal with the it for 1.2.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=377433
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=665835
                
> Fix couchjs
> -----------
>
>                 Key: COUCHDB-1302
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1302
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: JavaScript View Server
>    Affects Versions: 1.1.1, 1.2, 1.3
>            Reporter: Paul Joseph Davis
>            Priority: Blocker
>
> Figure out why some spidermonkeys have an error when doing: eval("function(){}")

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message