Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1.1, 1.2, 1.3
    • Fix Version/s: None
    • Component/s: JavaScript View Server
    • Labels:
      None
    • Skill Level:
      Dont Know

      Description

      Figure out why some spidermonkeys have an error when doing: eval("function(){}")

        Activity

        Hide
        Paul Joseph Davis added a comment -

        So I sat down today to try and figure out this SpiderMonkey issue. After a chat with the guys on #jsapi they specifically said "wrap it in parens" when I asked. Though the issue is that it gets a bit more tricky.

        The situation is basically that we've apparently been using invalid JavaScript for the last four years. Specifically, a script like such is invalid:

        "function(){}"

        Sadly, that's how all of our callbacks are expected to be defined.

        When I mentioned this, the suggestion was exactly to wrap it in parens which is what I'd discovered on my own. This works fine except for that people that have defined functions outside the callback scope then hit issues. Ie:

        var f = function() {};
        function()

        {f();};

        Breaks when wrapped in parens. And it even breaks when not in parens because the anonymous function still needs to be wrapped like such:

        var f = function() {};
        (function(){f();}

        )

        So, we're kinda up shit creek here. I'm still trying to figure out if there's anything we can do to save users pain, but the recommendation was basically, "It was fixed on purpose and its a hardcoded change that can't be configured."

        So, either we tell users "fix your functions" or we try and do some sort of source level analysis to wrap that last function, or something entirely different.

        Anyone else have Ideas?

        Show
        Paul Joseph Davis added a comment - So I sat down today to try and figure out this SpiderMonkey issue. After a chat with the guys on #jsapi they specifically said "wrap it in parens" when I asked. Though the issue is that it gets a bit more tricky. The situation is basically that we've apparently been using invalid JavaScript for the last four years. Specifically, a script like such is invalid: "function(){}" Sadly, that's how all of our callbacks are expected to be defined. When I mentioned this, the suggestion was exactly to wrap it in parens which is what I'd discovered on my own. This works fine except for that people that have defined functions outside the callback scope then hit issues. Ie: var f = function() {}; function() {f();}; Breaks when wrapped in parens. And it even breaks when not in parens because the anonymous function still needs to be wrapped like such: var f = function() {}; (function(){f();} ) So, we're kinda up shit creek here. I'm still trying to figure out if there's anything we can do to save users pain, but the recommendation was basically, "It was fixed on purpose and its a hardcoded change that can't be configured." So, either we tell users "fix your functions" or we try and do some sort of source level analysis to wrap that last function, or something entirely different. Anyone else have Ideas?
        Hide
        Paul Joseph Davis added a comment -

        I thought to ask the SpiderMonkey hackers how crazy it was to try and do source level analysis to automatically wrap that last anonymous function in parens. Jason Orendorff is on record as saying it would be hopeless to try and hack that outside of the SpiderMonkey engine.

        The only other thing I can think of would be to try and hack JSLint's parser to do this for us. Other than that, I think we really are up shit creek here.

        Show
        Paul Joseph Davis added a comment - I thought to ask the SpiderMonkey hackers how crazy it was to try and do source level analysis to automatically wrap that last anonymous function in parens. Jason Orendorff is on record as saying it would be hopeless to try and hack that outside of the SpiderMonkey engine. The only other thing I can think of would be to try and hack JSLint's parser to do this for us. Other than that, I think we really are up shit creek here.
        Hide
        Jason Smith added a comment -

        Couch Javascript are expressions, not statements. Everything is an implicit var map = eval(ddoc.views.by_name.map). You put function expressions in them. Helpers must go in inside. If helpers don't fit in new couchjs, that can't be helped. It is not a breaking change so much, except that couch permitted a convenient but severe syntax error and now it doesn't.

        One can also argue that the place for helper code is CommonJS modules.

        We discussed parsing JS with uglify.js and identifying the final function defined. This allows unmodified ddocs to work. But developers communicate to CouchDB extremely implicitly and through an invisible mechanism. It feels like "being an enabler."

        Assuming uglify.js can do it, how would you feel about a correction tool which converts bad code to good code? We could test it in the real world as a couchapp or web service that converts bad ddocs to good ddocs. If it works well, maybe even bundle it into couchjs and couch could be told to correct the errors. When asked, couch could feed the design doc to couchjs with the uglify fixer tool and update the ddoc with the correction. Maybe /_config/couchdb/fix_my_js = true. The fix could run when ddocs are read, or perhaps saved, or who knows! even during compaction.

        This is a crazy idea but IMO less crazy than permitting invalid Javascript that upstream code has sought to eliminate. To me the best trade-off is to mark it in the change log and provide third-party tools to correct ddocs.

        Show
        Jason Smith added a comment - Couch Javascript are expressions, not statements. Everything is an implicit var map = eval(ddoc.views.by_name.map). You put function expressions in them. Helpers must go in inside. If helpers don't fit in new couchjs, that can't be helped. It is not a breaking change so much, except that couch permitted a convenient but severe syntax error and now it doesn't. One can also argue that the place for helper code is CommonJS modules. We discussed parsing JS with uglify.js and identifying the final function defined. This allows unmodified ddocs to work. But developers communicate to CouchDB extremely implicitly and through an invisible mechanism. It feels like "being an enabler." Assuming uglify.js can do it, how would you feel about a correction tool which converts bad code to good code? We could test it in the real world as a couchapp or web service that converts bad ddocs to good ddocs. If it works well, maybe even bundle it into couchjs and couch could be told to correct the errors. When asked, couch could feed the design doc to couchjs with the uglify fixer tool and update the ddoc with the correction. Maybe /_config/couchdb/fix_my_js = true. The fix could run when ddocs are read, or perhaps saved, or who knows! even during compaction. This is a crazy idea but IMO less crazy than permitting invalid Javascript that upstream code has sought to eliminate. To me the best trade-off is to mark it in the change log and provide third-party tools to correct ddocs.
        Hide
        Paul Joseph Davis added a comment -

        From Benoit on the ML:

        > if we do that it would imply the release of a major version since the change
        > is major. I'm +1 to introduce correct behaviour in trunk rather than trying
        > to hack arouind our own insanity.

        I think its a good idea to revert this on 1.1.x as it could break user code for no good reason. Though 1.1.x will have the ability to use newer SpiderMonkey's, they'll have to deal with upgrading their JS code.

        What we do about 1.2.x and trunk I'm less certain. On the one hand, we could save some people some effort. On the other hand, we'd also be breaking things for people that use helper functions that haven't upgraded to 1.8.5 or w/e version of SM introduces this.

        Bottom line is that there's no good answer other than making sure we note it in our NEWS files, and on the website and also try and document it in error messages.

        Quite an unfortunate situation that I see no good answer to.

        Show
        Paul Joseph Davis added a comment - From Benoit on the ML: > if we do that it would imply the release of a major version since the change > is major. I'm +1 to introduce correct behaviour in trunk rather than trying > to hack arouind our own insanity. I think its a good idea to revert this on 1.1.x as it could break user code for no good reason. Though 1.1.x will have the ability to use newer SpiderMonkey's, they'll have to deal with upgrading their JS code. What we do about 1.2.x and trunk I'm less certain. On the one hand, we could save some people some effort. On the other hand, we'd also be breaking things for people that use helper functions that haven't upgraded to 1.8.5 or w/e version of SM introduces this. Bottom line is that there's no good answer other than making sure we note it in our NEWS files, and on the website and also try and document it in error messages. Quite an unfortunate situation that I see no good answer to.
        Hide
        Riyad Kalla added a comment -

        Now is the perfect opportunity to make this change, once 1.2/2.0 goes out the door it likely couldn't be safely addressed again until 3.0 and the uptake in CouchDB (from what I see at least) seems to be on the rapid rise.

        Making this change in 1.2/2.0 becomes an education issue, so maybe some questions around how to be really helpful explaining the situation to the user, e.g. errors in the server log when the problem is encountered and exactly how to work around it pointing at a Wiki page with clarification explaining why; maybe warnings during startup when the server does a quick scan for the issue (that can be disabled if the user knows they have a good setup);

        Sure it will be painful, but trying to monkey-patch this until 3.0 (or beyond) will be much more painful and have a lot more negative impact by that time.

        I like Jason's suggestion of some quick-patch tool that might ship with the install that attempts the fix automatically or at least gives the users enough tools and help/information so as to get them from Point A to B as quickly as possible.

        Show
        Riyad Kalla added a comment - Now is the perfect opportunity to make this change, once 1.2/2.0 goes out the door it likely couldn't be safely addressed again until 3.0 and the uptake in CouchDB (from what I see at least) seems to be on the rapid rise. Making this change in 1.2/2.0 becomes an education issue, so maybe some questions around how to be really helpful explaining the situation to the user, e.g. errors in the server log when the problem is encountered and exactly how to work around it pointing at a Wiki page with clarification explaining why; maybe warnings during startup when the server does a quick scan for the issue (that can be disabled if the user knows they have a good setup); Sure it will be painful, but trying to monkey-patch this until 3.0 (or beyond) will be much more painful and have a lot more negative impact by that time. I like Jason's suggestion of some quick-patch tool that might ship with the install that attempts the fix automatically or at least gives the users enough tools and help/information so as to get them from Point A to B as quickly as possible.
        Hide
        Paul Joseph Davis added a comment -

        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

        Show
        Paul Joseph Davis added a comment - 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
        Hide
        Adam Kocoloski added a comment -

        +1 from me on points 1,2,3. Thanks for tracking this down Paul.

        Show
        Adam Kocoloski added a comment - +1 from me on points 1,2,3. Thanks for tracking this down Paul.
        Hide
        Noah Slater added a comment -

        I am +0 on having an over-ride ./configure flag.

        The rest seem perfectly reasonable, so +1 on those.

        Even 4 sounds okay, TBH. Though I'd be open to seeing other suggestions too!

        Show
        Noah Slater added a comment - I am +0 on having an over-ride ./configure flag. The rest seem perfectly reasonable, so +1 on those. Even 4 sounds okay, TBH. Though I'd be open to seeing other suggestions too!
        Hide
        Benoit Chesneau added a comment -

        +1 on 1,2,3 . thanks

        Show
        Benoit Chesneau added a comment - +1 on 1,2,3 . thanks
        Hide
        Robert Newson added a comment -

        +1 on 1,2,3.

        Not keen on configure option in 1.1.1 but will go with the flow (though let's decide soon pls).

        for point 4, while that signature looks much nicer, is it too much of a break for 1.2? Feels like a 2.0 thing. If there's agreement, then the remaining question is what branch becomes 2.0. Oh, the joy.

        Show
        Robert Newson added a comment - +1 on 1,2,3. Not keen on configure option in 1.1.1 but will go with the flow (though let's decide soon pls). for point 4, while that signature looks much nicer, is it too much of a break for 1.2? Feels like a 2.0 thing. If there's agreement, then the remaining question is what branch becomes 2.0. Oh, the joy.
        Hide
        Randall Leeds added a comment -

        +1 on 1 and 2.
        +1 for 3. I'll write this up for 1.1.x if Paul doesn't beat me to it. 1.2/2.0 needs something different though.

        Paul discovered and mentioned in IRC that we can't actually look for the last function if people use named functions because eval('function map(...)

        {...}

        ') === undefined. In other words, we need to pull 'map' out of the global scope after the call to eval() so it needs to have a well-known name.

        So we're stuck opening up the 2.0 can of worms it seems. We should consider what the cleanest looking design document that makes this all look sane is and what effect any changes have on the way we index and optimize work for calculating design doc indexes.

        We should focus on 1.1.1 and then open the bikeshed floodgates.

        Show
        Randall Leeds added a comment - +1 on 1 and 2. +1 for 3. I'll write this up for 1.1.x if Paul doesn't beat me to it. 1.2/2.0 needs something different though. Paul discovered and mentioned in IRC that we can't actually look for the last function if people use named functions because eval('function map(...) {...} ') === undefined. In other words, we need to pull 'map' out of the global scope after the call to eval() so it needs to have a well-known name. So we're stuck opening up the 2.0 can of worms it seems. We should consider what the cleanest looking design document that makes this all look sane is and what effect any changes have on the way we index and optimize work for calculating design doc indexes. We should focus on 1.1.1 and then open the bikeshed floodgates.
        Hide
        Paul Joseph Davis added a comment -

        I agree with Randall. I think we have a plan for 1.1.1 that's sane. The 1.2 can of worms is going to be a big one so we should make sure and separate the issues there.

        Show
        Paul Joseph Davis added a comment - I agree with Randall. I think we have a plan for 1.1.1 that's sane. The 1.2 can of worms is going to be a big one so we should make sure and separate the issues there.
        Hide
        Benoit Chesneau added a comment -

        I was thinking this morning on this function naming. I'm not sure it's really needed. Why not considering map & other functions like code we just need to evaluate. Something like :

        { "map": "emit(doc._id, null);" }

        So we can eventually encapsulate it in our function. This pattern is commonly used. You can found it for example in last redis script feature or in elasticsearch. It would also simplify a lot the syntax and the way we can write and debug such functions. Thoughts ?

        Show
        Benoit Chesneau added a comment - I was thinking this morning on this function naming. I'm not sure it's really needed. Why not considering map & other functions like code we just need to evaluate. Something like : { "map": "emit(doc._id, null);" } So we can eventually encapsulate it in our function. This pattern is commonly used. You can found it for example in last redis script feature or in elasticsearch. It would also simplify a lot the syntax and the way we can write and debug such functions. Thoughts ?
        Hide
        Paul Joseph Davis added a comment -

        I'm not entirely sure what you mean about encapsulation, but just evaling code and hoping for the best doesn't seem like the best solution here.

        When you eval something, it runs. So this case means we'd have to eval the function once per doc per view.

        Plus, other things.

        Show
        Paul Joseph Davis added a comment - I'm not entirely sure what you mean about encapsulation, but just evaling code and hoping for the best doesn't seem like the best solution here. When you eval something, it runs. So this case means we'd have to eval the function once per doc per view. Plus, other things.
        Hide
        Benoit Chesneau added a comment -

        I don't follow.... Since you get a string from the json , you can then easily do eval("function map(doc)

        { " + themapstring + "}

        )

        map(doc) ....

        doesn't change anything. And you won't have to check that map is really called as map in the json string.

        Show
        Benoit Chesneau added a comment - I don't follow.... Since you get a string from the json , you can then easily do eval("function map(doc) { " + themapstring + "} ) map(doc) .... doesn't change anything. And you won't have to check that map is really called as map in the json string.
        Hide
        Paul Joseph Davis added a comment -

        Source manipulations worry me. That's basically what I tired doing with the paren hack before thinking better of it and that's turned out to be quite a bad idea. As far as I'm concerned, if it can't be implemented at the level of the JSAPI, then its nothing more than hack that is just going to lead to more pain down the road.

        I'm all for tools that we don't rely on directly to help users find incompatible code, but those sorts of things don't strike me as having a place in trunk.

        Show
        Paul Joseph Davis added a comment - Source manipulations worry me. That's basically what I tired doing with the paren hack before thinking better of it and that's turned out to be quite a bad idea. As far as I'm concerned, if it can't be implemented at the level of the JSAPI, then its nothing more than hack that is just going to lead to more pain down the road. I'm all for tools that we don't rely on directly to help users find incompatible code, but those sorts of things don't strike me as having a place in trunk.
        Hide
        Benoit Chesneau added a comment -

        We don't really need to wrap the script in a function. In fact we could just make the doc or any context global. Then the script will be simply evaluated. I personaly would prefer these idea since it open the door for more flexibility later.

        Show
        Benoit Chesneau added a comment - We don't really need to wrap the script in a function. In fact we could just make the doc or any context global . Then the script will be simply evaluated. I personaly would prefer these idea since it open the door for more flexibility later.
        Hide
        Paul Joseph Davis added a comment -

        On the face of it, I'm not a fan of this. It seems... wrong. But its late so maybe I'm just not seeing it.

        Show
        Paul Joseph Davis added a comment - On the face of it, I'm not a fan of this. It seems... wrong. But its late so maybe I'm just not seeing it.
        Hide
        Paul Joseph Davis added a comment -

        Here's the fix for configure.ac as well as a minor patch to actually link against SpiderMonkey trunk.

        Anyone care to review it before I commit?

        Show
        Paul Joseph Davis added a comment - Here's the fix for configure.ac as well as a minor patch to actually link against SpiderMonkey trunk. Anyone care to review it before I commit?
        Hide
        Damjan Georgievski added a comment -

        My proposal is for CouchDB functions to be treated as CommonJS modules (http://wiki.commonjs.org/wiki/Modules/1.1) i.e. they would look like:

        exports = function(doc)

        { emit bla bla }

        btw, this seems to work even today in 1.2.x + vanilla 1.8.5 spidermonkey

        Show
        Damjan Georgievski added a comment - My proposal is for CouchDB functions to be treated as CommonJS modules ( http://wiki.commonjs.org/wiki/Modules/1.1 ) i.e. they would look like: exports = function(doc) { emit bla bla } btw, this seems to work even today in 1.2.x + vanilla 1.8.5 spidermonkey
        Hide
        Randall Leeds added a comment -

        Paul: +1 on both patches.

        I might like Damjan's proposal. We should start that ticket for 1.2+.

        Show
        Randall Leeds added a comment - Paul: +1 on both patches. I might like Damjan's proposal. We should start that ticket for 1.2+.
        Hide
        Randall Leeds added a comment -

        Tested 1.1.x with Paul's patches applied. I checked it against a few spidermonkey versions including debian unstable from the iceweasel package, ubuntu's xulrunner-1.9.2.17-dev and libmozjs185-dev. Verified that the configure throws an error on the new one. Didn't check spidermonkey trunk, but I trust that patch 0002 is fine. I say commit it for 1.1.x and we can start the release process, then open a new ticket to talk about what to do about 1.2.

        Thanks, Paul!

        Show
        Randall Leeds added a comment - Tested 1.1.x with Paul's patches applied. I checked it against a few spidermonkey versions including debian unstable from the iceweasel package, ubuntu's xulrunner-1.9.2.17-dev and libmozjs185-dev. Verified that the configure throws an error on the new one. Didn't check spidermonkey trunk, but I trust that patch 0002 is fine. I say commit it for 1.1.x and we can start the release process, then open a new ticket to talk about what to do about 1.2. Thanks, Paul!
        Hide
        Jan Lehnardt added a comment -

        +1, what Randall said.

        Great job Paul!

        One caveat, thinking about how the comments are read over time, "recent" will not convey they same meaning as it does today, maybe we can make the messages more explicit and have them include version numbers of what works and what doesn't?

        Show
        Jan Lehnardt added a comment - +1, what Randall said. Great job Paul! One caveat, thinking about how the comments are read over time, "recent" will not convey they same meaning as it does today, maybe we can make the messages more explicit and have them include version numbers of what works and what doesn't?
        Hide
        Paul Joseph Davis added a comment -

        Applied to 1.1.x, 1.2.x, and trunk. We can open a new ticket to discuss further work on how to deal with trunk using SM trunk later.

        Show
        Paul Joseph Davis added a comment - Applied to 1.1.x, 1.2.x, and trunk. We can open a new ticket to discuss further work on how to deal with trunk using SM trunk later.
        Hide
        Jens Alfke added a comment -

        For what it's worth: I ran into the exact same issue last month while working on experimental support for using WebKit's JavaScriptCore instead of SpiderMonkey in emonk. JSC has never supported that anonymous-function hack. Good to know this is going to get resolved in couchdb going forward.

        Show
        Jens Alfke added a comment - For what it's worth: I ran into the exact same issue last month while working on experimental support for using WebKit's JavaScriptCore instead of SpiderMonkey in emonk. JSC has never supported that anonymous-function hack. Good to know this is going to get resolved in couchdb going forward.
        Hide
        afters added a comment -

        Not sure if it's relevant, but here's how I checked if a string is indeed an anonymous function:
        (https://github.com/afters/Couch-Incarnate/blob/master/lib/syncer.js#L38)

        var verifyMapStringIsFunction = function () {
        var basicFuncTemplate = new RegExp(
        '^' +
        '
        s*' +
        'function' +
        '
        s*' +
        '\\(([^\\)]*)
        )' +
        '
        s*' +
        '

        {([\\s\\S]*)}

        ' +
        '
        s*' +
        '$'
        );
        var match = basicFuncTemplate.exec(map.fn);
        if (!match) throw new Error();
        try

        { var argsStr = match[1]; var bodyStr = match[2]; new Function(argsStr, bodyStr); }

        catch (e)

        { throw new Error(); }

        }

        Show
        afters added a comment - Not sure if it's relevant, but here's how I checked if a string is indeed an anonymous function: ( https://github.com/afters/Couch-Incarnate/blob/master/lib/syncer.js#L38 ) var verifyMapStringIsFunction = function () { var basicFuncTemplate = new RegExp( '^' + ' s*' + 'function' + ' s*' + '\\(( [^\\)] *) )' + ' s*' + ' {([\\s\\S]*)} ' + ' s*' + '$' ); var match = basicFuncTemplate.exec(map.fn); if (!match) throw new Error(); try { var argsStr = match[1]; var bodyStr = match[2]; new Function(argsStr, bodyStr); } catch (e) { throw new Error(); } }
        Hide
        Jason Smith added a comment -

        This ticket is listed as a 1.2 blocker. But Randall asked to open a new ticket for 1.2; so where do we stand?

        Today I got CouchDB working against the Firefox 10 spidermonkey but I'd like to know the roadmap for this issue, plus a place to post patches.

        Thanks.

        Show
        Jason Smith added a comment - This ticket is listed as a 1.2 blocker. But Randall asked to open a new ticket for 1.2; so where do we stand? Today I got CouchDB working against the Firefox 10 spidermonkey but I'd like to know the roadmap for this issue, plus a place to post patches. Thanks.

          People

          • Assignee:
            Unassigned
            Reporter:
            Paul Joseph Davis
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development