Re: [jira] [Commented] (COUCHDB-1302) Fix couchjs
Randall asked that I note for posterity that uglify.js may help. It seems to be 100% Javascript, CommonJS (not just a Node), BSD license. It gives you the Javascript abstract syntax tree. I was thinking of using it for input validation. Perhaps, instead of all sorts of new ideas, just make the breaking change that you *must* stick to the normal CouchDB way, one function in a string. Here is how you can confirm a standard map function. That could be in the view server, just before you eval() it. http://friendpaste.com/7LdkWzEfGgrLTKYdo7JENm // Confirm a valid old-school CouchDB map function. var uglify = require('uglify-js') , assert = require('assert'); var old_map = "function(doc) { emit(doc._id, 1) }" var code, ast; code = old_map; try { ast = uglify.parser.parse('(' + code + ')'); assert.equal(ast[0], 'toplevel'); var statements = ast[1]; assert.equal(statements.length, 1); var func_expr = statements[0]; assert.equal(func_expr.length, 2); assert.equal(func_expr[0], 'stat'); var func_def = func_expr[1]; assert.equal(func_def[0], 'function'); if(process.env.require_name) assert.equal(func_def[1], 'map'); var formals = func_def[2]; assert.ok(formals.length <= 1); console.log('Good code:\n' + code); } catch(e) { console.log('Bad code:\n' + code); if(ast) console.log('\nAST:\n' + JSON.stringify(ast)); } On Fri, Oct 7, 2011 at 10:58 AM, Paul Joseph Davis (Commented) (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122519#comment-13122519 > ] > > Paul Joseph Davis commented on COUCHDB-1302: > > > 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. > >> 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 > > > -- Iris Couch
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122562#comment-13122562 ] Benoit Chesneau commented on COUCHDB-1302: -- 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 ? > 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122519#comment-13122519 ] Paul Joseph Davis commented on COUCHDB-1302: 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. > 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
[jira] [Assigned] (COUCHDB-642) Support rev in PUT URL
[ https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds reassigned COUCHDB-642: - Assignee: Randall Leeds > Support rev in PUT URL > -- > > Key: COUCHDB-642 > URL: https://issues.apache.org/jira/browse/COUCHDB-642 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Environment: trunk 08 Feb 2010 >Reporter: Brian Candler >Assignee: Randall Leeds >Priority: Minor > Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch > > > A DELETE request lets you append ?rev= to the URL. But this doesn't work > with a PUT request; you have to put the _rev in the body instead (even though > the _id is taken from the URL path) > $ curl -X PUT -d "{}" > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"} > $ curl -X PUT -d "{}" > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d > {"error":"conflict","reason":"Document update conflict."} > $ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}' > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"} > Allowing ?rev in the URL would make PUT and DELETE more consistent, and would > allow you to replace an existing JSON doc with another one without having to > merge the _rev into it first. -- 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
[jira] [Commented] (COUCHDB-642) Support rev in PUT URL
[ https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122491#comment-13122491 ] Randall Leeds commented on COUCHDB-642: --- Oh. I have this work already done. I'll double check that the preference ordering makes sense. I don't have any philosophical objection to allowing it in the URL and the way I've written it already asserts that if it's present in more than one place it has to match everywhere or it's a bad request. > Support rev in PUT URL > -- > > Key: COUCHDB-642 > URL: https://issues.apache.org/jira/browse/COUCHDB-642 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Environment: trunk 08 Feb 2010 >Reporter: Brian Candler >Priority: Minor > Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch > > > A DELETE request lets you append ?rev= to the URL. But this doesn't work > with a PUT request; you have to put the _rev in the body instead (even though > the _id is taken from the URL path) > $ curl -X PUT -d "{}" > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"} > $ curl -X PUT -d "{}" > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d > {"error":"conflict","reason":"Document update conflict."} > $ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}' > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"} > Allowing ?rev in the URL would make PUT and DELETE more consistent, and would > allow you to replace an existing JSON doc with another one without having to > merge the _rev into it first. -- 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122427#comment-13122427 ] Randall Leeds commented on COUCHDB-1302: +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. > 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122280#comment-13122280 ] Robert Newson commented on COUCHDB-1302: +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. > 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
[jira] [Commented] (COUCHDB-642) Support rev in PUT URL
[ https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122275#comment-13122275 ] Benjamin Young commented on COUCHDB-642: >From a REST perspective nothing in the query string or header should take >precedence over the content body. Meaning, the "rev" query parameter value >really shouldn't override the "_rev" keys value in the document. Updating the >_rev in the JSON object seems like a very small "cost" in exchange for the >cumbersome "order of preference" given to various query parameters or headers. >The content body is the canonical source for the document--especially in >regards to a PUT. The DELETE case doesn't require a content body, so issuing it with a "rev" is mandatory as it semantically specifies the resource your deleting. You can delete documents via POST, but in that case the _rev is included in the content body (as it should be)--which matches the PUT use case. -1 as it's just not worth the "confusion cost" for a nice-to-have. > Support rev in PUT URL > -- > > Key: COUCHDB-642 > URL: https://issues.apache.org/jira/browse/COUCHDB-642 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Environment: trunk 08 Feb 2010 >Reporter: Brian Candler >Priority: Minor > Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch > > > A DELETE request lets you append ?rev= to the URL. But this doesn't work > with a PUT request; you have to put the _rev in the body instead (even though > the _id is taken from the URL path) > $ curl -X PUT -d "{}" > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"} > $ curl -X PUT -d "{}" > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d > {"error":"conflict","reason":"Document update conflict."} > $ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}' > http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo > {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"} > Allowing ?rev in the URL would make PUT and DELETE more consistent, and would > allow you to replace an existing JSON doc with another one without having to > merge the _rev into it first. -- 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122274#comment-13122274 ] Benoit Chesneau commented on COUCHDB-1302: -- +1 on 1,2,3 . thanks :) > 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122252#comment-13122252 ] Noah Slater commented on COUCHDB-1302: -- 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! > 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122217#comment-13122217 ] Adam Kocoloski commented on COUCHDB-1302: - +1 from me on points 1,2,3. Thanks for tracking this down Paul. > 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ 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
Re: Getting to start!
Thanks for you email Amir. You'll have better results on the general user list for now: http://couchdb.apache.org/community/lists.html Thanks! N On 6 Oct 2011, at 20:10, Amir Almasi wrote: > Dear all, > > I am new to CouchDB. Already, I know Erlang programming language, and now, I > want to connect to couchDB in Erlang programming language. > Currently, I am using windows! and Erlang/OTP (R14B04) > > I appreciate, if you leave me any sources or documents to start. > I was confused, I should Install CouchDB as an Erlang Library? And also to > connect Erlang processes to couchDB to read and write on the local computer, > I should install any additional software? > > Best regards, > /Amir > > > * > *
Getting to start!
Dear all, I am new to CouchDB. Already, I know Erlang programming language, and now, I want to connect to couchDB in Erlang programming language. Currently, I am using windows! and Erlang/OTP (R14B04) I appreciate, if you leave me any sources or documents to start. I was confused, I should Install CouchDB as an Erlang Library? And also to connect Erlang processes to couchDB to read and write on the local computer, I should install any additional software? Best regards, /Amir * *
Re: CouchDB 1.1.1
Oh, and did anyone mention that the workaround is to make your JS functions actually contain code? I think it's worth pointing out that this might not really be a serious problem, per se. On Thu, Oct 6, 2011 at 11:41, Randall Leeds wrote: > On Thu, Oct 6, 2011 at 11:37, Robert Newson wrote: > >> 1.1.1 contains many important fixes, holding it up to get 1.8.5 >> support in seems odd to me. The breakage also seems dramatic for a bug >> fix release and there was wide agreement on that point. >> >> Putting all of that aside, what should we do? Make it configurable at >> build time? Introduce all this breakage in 1.1.1 and slap a big >> warning on it? >> > > It's already configurable at build time via --with-js-* > And again, I don't think there was a problem with any official release, > just some not official version some distros yanked out of a xulrunner > tarball. > If you must keep the support reverted, do so. I'll say I'm -0 on it. Just a > bit of a bummer. > > >> >> I'm still voting for the current state of 1.1.x, which doesn't include >> 1.8.5 support or the paren change. >> >> B. >> >> On 6 October 2011 19:34, Noah Slater wrote: >> > >> > On 6 Oct 2011, at 19:31, Paul Davis wrote: >> > >> >> That was awfully quick. :/ >> > >> > Agreed. >> > >> >> I would prefer to make this a social >> >> contract by doing something along the lines of requiring people to run >> >> ./configure --yes-really-give-me-1.8.5 >> > >> > -1 >> > >> > >> > >
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:37, Robert Newson wrote: > 1.1.1 contains many important fixes, holding it up to get 1.8.5 > support in seems odd to me. The breakage also seems dramatic for a bug > fix release and there was wide agreement on that point. > > Putting all of that aside, what should we do? Make it configurable at > build time? Introduce all this breakage in 1.1.1 and slap a big > warning on it? > It's already configurable at build time via --with-js-* And again, I don't think there was a problem with any official release, just some not official version some distros yanked out of a xulrunner tarball. If you must keep the support reverted, do so. I'll say I'm -0 on it. Just a bit of a bummer. > > I'm still voting for the current state of 1.1.x, which doesn't include > 1.8.5 support or the paren change. > > B. > > On 6 October 2011 19:34, Noah Slater wrote: > > > > On 6 Oct 2011, at 19:31, Paul Davis wrote: > > > >> That was awfully quick. :/ > > > > Agreed. > > > >> I would prefer to make this a social > >> contract by doing something along the lines of requiring people to run > >> ./configure --yes-really-give-me-1.8.5 > > > > -1 > > > > >
Re: CouchDB 1.1.1
1.1.1 contains many important fixes, holding it up to get 1.8.5 support in seems odd to me. The breakage also seems dramatic for a bug fix release and there was wide agreement on that point. Putting all of that aside, what should we do? Make it configurable at build time? Introduce all this breakage in 1.1.1 and slap a big warning on it? I'm still voting for the current state of 1.1.x, which doesn't include 1.8.5 support or the paren change. B. On 6 October 2011 19:34, Noah Slater wrote: > > On 6 Oct 2011, at 19:31, Paul Davis wrote: > >> That was awfully quick. :/ > > Agreed. > >> I would prefer to make this a social >> contract by doing something along the lines of requiring people to run >> ./configure --yes-really-give-me-1.8.5 > > -1 > >
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:31, Paul Davis wrote: > On Thu, Oct 6, 2011 at 6:05 AM, Robert Newson wrote: > > Thanks all, I've pushed the change to 1.1.x. make check and futon all > > pass; review would still be nice. :) I simply reverted the two > > commits. > > > > B. > > > > That was awfully quick. :/ I would prefer to make this a social > contract by doing something along the lines of requiring people to run > ./configure --yes-really-give-me-1.8.5 > > Removing support completely seems awfully counter productive. > Especially given that it works fine for me on Ubuntu 11.04 and with the 1.8.5 tarball download without the paren thing. The only place I've seen the paren hack be necessary is when I tried with the js bundled in Debian unstable's iceweasel, which purports to be some form of version 185 according to jsversion.h. If there's no _official_ release of a separate tarball of SpiderMonkey 1.8.5 which doesn't work with Paul's paren commit reverted then I say we keep it in 1.1.1. If distributions are still packaging the spidermonkey from inside an iceweasel/xulrunner build for 1.8.5 it's on them. Mozilla released that thing officially and it works here. -R
Re: CouchDB 1.1.1
On 6 Oct 2011, at 19:35, Robert Newson wrote: > This change came *after* discussion and +1's from multiple developers. > We can certainly change direction on this but it's not like I've > jumped the gun. We talked it out. I think a single day might be too short a time span for something like this. People may be away from their email for days at a time. Don't want to make people feel like they have to check the list every single day in case important decisions are made with out them.
Re: CouchDB 1.1.1
This change came *after* discussion and +1's from multiple developers. We can certainly change direction on this but it's not like I've jumped the gun. We talked it out. B. On 6 October 2011 19:31, Paul Davis wrote: > On Thu, Oct 6, 2011 at 6:05 AM, Robert Newson wrote: >> Thanks all, I've pushed the change to 1.1.x. make check and futon all >> pass; review would still be nice. :) I simply reverted the two >> commits. >> >> B. >> > > That was awfully quick. :/ I would prefer to make this a social > contract by doing something along the lines of requiring people to run > ./configure --yes-really-give-me-1.8.5 > > Removing support completely seems awfully counter productive. >
Re: CouchDB 1.1.1
On 6 Oct 2011, at 19:31, Paul Davis wrote: > That was awfully quick. :/ Agreed. > I would prefer to make this a social > contract by doing something along the lines of requiring people to run > ./configure --yes-really-give-me-1.8.5 -1
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 6:05 AM, Robert Newson wrote: > Thanks all, I've pushed the change to 1.1.x. make check and futon all > pass; review would still be nice. :) I simply reverted the two > commits. > > B. > That was awfully quick. :/ I would prefer to make this a social contract by doing something along the lines of requiring people to run ./configure --yes-really-give-me-1.8.5 Removing support completely seems awfully counter productive.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 6:59 PM, Robert Newson wrote: > does the newer erlang-oauth break anything? Not that I know of. > > On 6 October 2011 18:52, Filipe David Manana wrote: >> On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson wrote: >>> If there are no objections, I'm going to build the first 1.1.1 >>> candidate in the morning and start a new thread for the release. >> >> As pointed out in 2 other related threads, we have some compilation >> warnings about functions that will no longer exist in OTP R15 (to be >> released by the end of this year): >> >> /opt/r14b03/bin/erlc +debug_info oauth_http.erl >> ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be >> removed in R15B; use httpc:request/4 >> /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl >> /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl >> ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated >> (will be removed in R15A); use file:read_file/1 and >> public_key:pem_decode/1 >> ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is >> deprecated and will be removed in R15A; use >> public_key:pem_entry_decode/1 >> ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated >> (will be removed in R15A); use file:read_file/1 and >> public_key:pem_decode/1 >> /opt/r14b03/bin/erlc +debug_info oauth_unix.erl >> >> The ones regarding public_key concern me, as it will break the OAuth >> authentication handler. >> I see 2 solutions: >> >> 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x >> (doesn't produce these warnings) >> >> 2) modify the erlang-oauth in 1.1.x and use try catches where the >> catch would call the equivalent versions in R14/R15 (these new >> functions don't exist in R13B03 for example) >> >> Naturally, I would prefer 1) >> >> The warnings about http:request can be ignored I think, as in Couch we >> don't use any codepath that will execute the deprecated function >> >>> >>> B. >>> >>> On 6 October 2011 12:05, Robert Newson wrote: Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt wrote: > > On Oct 6, 2011, at 10:30 , Robert Newson wrote: > >> There is no build of 1.1.1 on Ubuntu 11.x that will work as well as >> 1.1.0, so I think it's correct that it cannot build under those >> conditions. >> >> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and >> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING >> CHANGES"). >> >> I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. > > +1 > > Cheers > Jan > -- > > >> >> B. >> >> On 6 October 2011 09:25, Paul Davis wrote: >>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson >>> wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. >>> >>> +1 on removing the paren hack for sure. >>> >>> Not sure about removing 1.8.5 support completely. On the one hand, it >>> would prevent breakage because people couldn't link against the >>> breaking SM. On the other hand, it prevents people from linking >>> against 1.8.5 which means it won't build on Ubuntu 11.x. >>> >>> Unless someone comes up with a magic option I'd say put it to an >>> informal vote so that I can blame someone else. >>> On 5 October 2011 18:25, Paul Davis wrote: > Yes, its release blocking. > > On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson > wrote: >> All, >> >> I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to >> include everything that was missing (Sidenote: Can we all keep this >> file up to date when commit bugfixes or add features?). I'd >> appreciate >> everyone giving it a look over before I start to build the release >> artifact. >> >> I believe there's an outstanding issue (not present in JIRA) around >> javascript function evaluation? Can someone confirm that it's release >> blocking? >> >> Thanks, >> B. >> > >>> > > >>> >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the wo
Re: CouchDB 1.1.1
does the newer erlang-oauth break anything? On 6 October 2011 18:52, Filipe David Manana wrote: > On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson wrote: >> If there are no objections, I'm going to build the first 1.1.1 >> candidate in the morning and start a new thread for the release. > > As pointed out in 2 other related threads, we have some compilation > warnings about functions that will no longer exist in OTP R15 (to be > released by the end of this year): > > /opt/r14b03/bin/erlc +debug_info oauth_http.erl > ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be > removed in R15B; use httpc:request/4 > /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl > /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl > ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated > (will be removed in R15A); use file:read_file/1 and > public_key:pem_decode/1 > ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is > deprecated and will be removed in R15A; use > public_key:pem_entry_decode/1 > ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated > (will be removed in R15A); use file:read_file/1 and > public_key:pem_decode/1 > /opt/r14b03/bin/erlc +debug_info oauth_unix.erl > > The ones regarding public_key concern me, as it will break the OAuth > authentication handler. > I see 2 solutions: > > 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x > (doesn't produce these warnings) > > 2) modify the erlang-oauth in 1.1.x and use try catches where the > catch would call the equivalent versions in R14/R15 (these new > functions don't exist in R13B03 for example) > > Naturally, I would prefer 1) > > The warnings about http:request can be ignored I think, as in Couch we > don't use any codepath that will execute the deprecated function > >> >> B. >> >> On 6 October 2011 12:05, Robert Newson wrote: >>> Thanks all, I've pushed the change to 1.1.x. make check and futon all >>> pass; review would still be nice. :) I simply reverted the two >>> commits. >>> >>> B. >>> >>> On 6 October 2011 12:02, Jan Lehnardt wrote: On Oct 6, 2011, at 10:30 , Robert Newson wrote: > There is no build of 1.1.1 on Ubuntu 11.x that will work as well as > 1.1.0, so I think it's correct that it cannot build under those > conditions. > > Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and > then focus on getting 1.2 out with 1.8.5 support (and "BREAKING > CHANGES"). > > I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- > > B. > > On 6 October 2011 09:25, Paul Davis wrote: >> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >>> All, >>> >>> Paul Davis has researched the issue and it seems intractable. >>> >>> I would like to remove 1.8.5 support from 1.1.1. It was not present in >>> 1.1.0 so will not be (officially) missed. >>> >>> The place for a breaking change of this magnitude is 1.2, not a minor >>> bug fix release. >>> >>> Thoughts? >>> B. >>> >> >> +1 on removing the paren hack for sure. >> >> Not sure about removing 1.8.5 support completely. On the one hand, it >> would prevent breakage because people couldn't link against the >> breaking SM. On the other hand, it prevents people from linking >> against 1.8.5 which means it won't build on Ubuntu 11.x. >> >> Unless someone comes up with a magic option I'd say put it to an >> informal vote so that I can blame someone else. >> >>> On 5 October 2011 18:25, Paul Davis wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: > All, > > I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to > include everything that was missing (Sidenote: Can we all keep this > file up to date when commit bugfixes or add features?). I'd appreciate > everyone giving it a look over before I start to build the release > artifact. > > I believe there's an outstanding issue (not present in JIRA) around > javascript function evaluation? Can someone confirm that it's release > blocking? > > Thanks, > B. > >>> >> >>> >> > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." >
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson wrote: > If there are no objections, I'm going to build the first 1.1.1 > candidate in the morning and start a new thread for the release. As pointed out in 2 other related threads, we have some compilation warnings about functions that will no longer exist in OTP R15 (to be released by the end of this year): /opt/r14b03/bin/erlc +debug_info oauth_http.erl ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be removed in R15B; use httpc:request/4 /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is deprecated and will be removed in R15A; use public_key:pem_entry_decode/1 ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated (will be removed in R15A); use file:read_file/1 and public_key:pem_decode/1 /opt/r14b03/bin/erlc +debug_info oauth_unix.erl The ones regarding public_key concern me, as it will break the OAuth authentication handler. I see 2 solutions: 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x (doesn't produce these warnings) 2) modify the erlang-oauth in 1.1.x and use try catches where the catch would call the equivalent versions in R14/R15 (these new functions don't exist in R13B03 for example) Naturally, I would prefer 1) The warnings about http:request can be ignored I think, as in Couch we don't use any codepath that will execute the deprecated function > > B. > > On 6 October 2011 12:05, Robert Newson wrote: >> Thanks all, I've pushed the change to 1.1.x. make check and futon all >> pass; review would still be nice. :) I simply reverted the two >> commits. >> >> B. >> >> On 6 October 2011 12:02, Jan Lehnardt wrote: >>> >>> On Oct 6, 2011, at 10:30 , Robert Newson wrote: >>> There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and "BREAKING CHANGES"). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. >>> >>> +1 >>> >>> Cheers >>> Jan >>> -- >>> >>> B. On 6 October 2011 09:25, Paul Davis wrote: > On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >> All, >> >> Paul Davis has researched the issue and it seems intractable. >> >> I would like to remove 1.8.5 support from 1.1.1. It was not present in >> 1.1.0 so will not be (officially) missed. >> >> The place for a breaking change of this magnitude is 1.2, not a minor >> bug fix release. >> >> Thoughts? >> B. >> > > +1 on removing the paren hack for sure. > > Not sure about removing 1.8.5 support completely. On the one hand, it > would prevent breakage because people couldn't link against the > breaking SM. On the other hand, it prevents people from linking > against 1.8.5 which means it won't build on Ubuntu 11.x. > > Unless someone comes up with a magic option I'd say put it to an > informal vote so that I can blame someone else. > >> On 5 October 2011 18:25, Paul Davis wrote: >>> Yes, its release blocking. >>> >>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson >>> wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B. >>> >> > >>> >>> >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Re: CouchDB 1.1.1
If there are no objections, I'm going to build the first 1.1.1 candidate in the morning and start a new thread for the release. B. On 6 October 2011 12:05, Robert Newson wrote: > Thanks all, I've pushed the change to 1.1.x. make check and futon all > pass; review would still be nice. :) I simply reverted the two > commits. > > B. > > On 6 October 2011 12:02, Jan Lehnardt wrote: >> >> On Oct 6, 2011, at 10:30 , Robert Newson wrote: >> >>> There is no build of 1.1.1 on Ubuntu 11.x that will work as well as >>> 1.1.0, so I think it's correct that it cannot build under those >>> conditions. >>> >>> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and >>> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING >>> CHANGES"). >>> >>> I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. >> >> +1 >> >> Cheers >> Jan >> -- >> >> >>> >>> B. >>> >>> On 6 October 2011 09:25, Paul Davis wrote: On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: > All, > > Paul Davis has researched the issue and it seems intractable. > > I would like to remove 1.8.5 support from 1.1.1. It was not present in > 1.1.0 so will not be (officially) missed. > > The place for a breaking change of this magnitude is 1.2, not a minor > bug fix release. > > Thoughts? > B. > +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. > On 5 October 2011 18:25, Paul Davis wrote: >> Yes, its release blocking. >> >> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: >>> All, >>> >>> I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to >>> include everything that was missing (Sidenote: Can we all keep this >>> file up to date when commit bugfixes or add features?). I'd appreciate >>> everyone giving it a look over before I start to build the release >>> artifact. >>> >>> I believe there's an outstanding issue (not present in JIRA) around >>> javascript function evaluation? Can someone confirm that it's release >>> blocking? >>> >>> Thanks, >>> B. >>> >> > >> >> >
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[ https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122013#comment-13122013 ] Benjamin Young commented on COUCHDB-1303: - I do agree that the more the more "RESTful" thing to do would actually be allowed to POST to the /db/ URL with a specific mimetype that designated that one was sending a representation containing several documents to be added (which of course could use it's own ticket). However, as we allow end users to extend CouchDB's functionality with "CouchApp" additions (which is fabulous!), we need to offer them as much power as possible so this can move out of being a "toy" (for some) into being a viable "stack." The develoepr generated additions (such as _update handlers) can live wherever they need to in the CouchDB URL space (all of them are currently under _design/{app}), as long as they are wrap-able by the URL rewriter, the developer can make their own API's and vhost them wherever they'd like. That's the goal of this request. I agree that the whole CouchApp approach/concept could use a fresh approach, but I'm not sure it's a good reason to stall what we have moving now. I look forward to seeing your CouchApp-related proposals, but I'd prefer this (and any other) idea be measured on its merits relative to the current code--not potential rewrites. There are likely other reasons this might be bad, but "because we should start over" isn't one of them. :) > Add a _bulk_update handler similar to _update but for bulk document changes > --- > > Key: COUCHDB-1303 > URL: https://issues.apache.org/jira/browse/COUCHDB-1303 > Project: CouchDB > Issue Type: New Feature >Reporter: Benjamin Young > Labels: api, update_request_handler > > _update handlers are great (and getting better!) for building RESTful API's > inside CouchDB. One limitation I found tonight is that _update can only do a > single document at a time. If the API I'm building needs to update multiple > docs (in a similar fashion to _bulk_docs), then an outside "proxy" script is > required. It would be ideal to have a _bulk_update handler to allow for the > same functionality as _update, but with the ability to insert multiple > documents at once. > Perhaps the current _update handler API could be extended to support multiple > IDs/documents, but a separate API endpoint would be seem reasonable if needed. > Thanks for considering this idea. -- 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
[jira] [Commented] (COUCHDB-1303) Add a _bulk_update handler similar to _update but for bulk document changes
[ https://issues.apache.org/jira/browse/COUCHDB-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121989#comment-13121989 ] Benoit Chesneau commented on COUCHDB-1303: -- posted on dev@ , copied here. I would really prefer to sit down a little and start to rethink the couchapp engine. Restful means imo that on a particular resource we could react on each actions (here HTTP verbs). Instead we did the same error Rails did by having a resource per actions or so. Bulk updates would be another hack around this so I'm -1 on such features. New ticket about what i would like to design is coming along. > Add a _bulk_update handler similar to _update but for bulk document changes > --- > > Key: COUCHDB-1303 > URL: https://issues.apache.org/jira/browse/COUCHDB-1303 > Project: CouchDB > Issue Type: New Feature >Reporter: Benjamin Young > Labels: api, update_request_handler > > _update handlers are great (and getting better!) for building RESTful API's > inside CouchDB. One limitation I found tonight is that _update can only do a > single document at a time. If the API I'm building needs to update multiple > docs (in a similar fashion to _bulk_docs), then an outside "proxy" script is > required. It would be ideal to have a _bulk_update handler to allow for the > same functionality as _update, but with the ability to insert multiple > documents at once. > Perhaps the current _update handler API could be extended to support multiple > IDs/documents, but a separate API endpoint would be seem reasonable if needed. > Thanks for considering this idea. -- 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
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[ https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121871#comment-13121871 ] Riyad Kalla commented on COUCHDB-1302: -- 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. > 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
Re: CouchDB 1.1.1
Thanks all, I've pushed the change to 1.1.x. make check and futon all pass; review would still be nice. :) I simply reverted the two commits. B. On 6 October 2011 12:02, Jan Lehnardt wrote: > > On Oct 6, 2011, at 10:30 , Robert Newson wrote: > >> There is no build of 1.1.1 on Ubuntu 11.x that will work as well as >> 1.1.0, so I think it's correct that it cannot build under those >> conditions. >> >> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and >> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING >> CHANGES"). >> >> I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. > > +1 > > Cheers > Jan > -- > > >> >> B. >> >> On 6 October 2011 09:25, Paul Davis wrote: >>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. >>> >>> +1 on removing the paren hack for sure. >>> >>> Not sure about removing 1.8.5 support completely. On the one hand, it >>> would prevent breakage because people couldn't link against the >>> breaking SM. On the other hand, it prevents people from linking >>> against 1.8.5 which means it won't build on Ubuntu 11.x. >>> >>> Unless someone comes up with a magic option I'd say put it to an >>> informal vote so that I can blame someone else. >>> On 5 October 2011 18:25, Paul Davis wrote: > Yes, its release blocking. > > On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: >> All, >> >> I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to >> include everything that was missing (Sidenote: Can we all keep this >> file up to date when commit bugfixes or add features?). I'd appreciate >> everyone giving it a look over before I start to build the release >> artifact. >> >> I believe there's an outstanding issue (not present in JIRA) around >> javascript function evaluation? Can someone confirm that it's release >> blocking? >> >> Thanks, >> B. >> > >>> > >
Re: CouchDB 1.1.1
On Oct 6, 2011, at 10:30 , Robert Newson wrote: > There is no build of 1.1.1 on Ubuntu 11.x that will work as well as > 1.1.0, so I think it's correct that it cannot build under those > conditions. > > Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and > then focus on getting 1.2 out with 1.8.5 support (and "BREAKING > CHANGES"). > > I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. +1 Cheers Jan -- > > B. > > On 6 October 2011 09:25, Paul Davis wrote: >> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >>> All, >>> >>> Paul Davis has researched the issue and it seems intractable. >>> >>> I would like to remove 1.8.5 support from 1.1.1. It was not present in >>> 1.1.0 so will not be (officially) missed. >>> >>> The place for a breaking change of this magnitude is 1.2, not a minor >>> bug fix release. >>> >>> Thoughts? >>> B. >>> >> >> +1 on removing the paren hack for sure. >> >> Not sure about removing 1.8.5 support completely. On the one hand, it >> would prevent breakage because people couldn't link against the >> breaking SM. On the other hand, it prevents people from linking >> against 1.8.5 which means it won't build on Ubuntu 11.x. >> >> Unless someone comes up with a magic option I'd say put it to an >> informal vote so that I can blame someone else. >> >>> On 5 October 2011 18:25, Paul Davis wrote: Yes, its release blocking. On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: > All, > > I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to > include everything that was missing (Sidenote: Can we all keep this > file up to date when commit bugfixes or add features?). I'd appreciate > everyone giving it a look over before I start to build the release > artifact. > > I believe there's an outstanding issue (not present in JIRA) around > javascript function evaluation? Can someone confirm that it's release > blocking? > > Thanks, > B. > >>> >>
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:06 AM, Paul Davis wrote: > On Thu, Oct 6, 2011 at 3:51 AM, Benoit Chesneau wrote: >> On Thu, Oct 6, 2011 at 10:25 AM, Paul Davis >> wrote: >>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. >>> >>> +1 on removing the paren hack for sure. >>> >>> Not sure about removing 1.8.5 support completely. On the one hand, it >>> would prevent breakage because people couldn't link against the >>> breaking SM. On the other hand, it prevents people from linking >>> against 1.8.5 which means it won't build on Ubuntu 11.x. >> >> >> Is this really a problem with 1.8.5 ? How do you explain then that I >> have to remove this changes to have refuge working with it then? >> >> https://github.com/refuge/refuge/commit/481bd6623ccfc8895eacf8a1528bffa5efa4ad47#apps/couch/share/server/util.js >> >> Refuge is only working with 1.8.5. >> >> >> - benoît >> > > Things I know for certain: > > This fails in the js shell from the 1.8.5 tarball: > > eval("function(){}") > > It also fails on the package in Debian that is supposed to be > SpiderMonkey 1.8.5. It also fails on a checkout of the mercurial > repository with hash 959c1e6bdb11. > > Fact of the matter, SpiderMonkey distribution is notorious in its > avoidance of anything resembling a versioning scheme that we can use > to refer to API/ABI compatibility across platforms. Not that it > matters as it's apparently a fix, so at the end of the day "new > SpiderMonkey breaks code that has worked for years." > > By enabling the linkage (for which, if code were proper, things would > work) we introduce a non-obvious new behavior error. > > If we *intentionally disable* 1.8.5 linking, then we avoid introducing > errors subtly into code that has always worked if someone tries to > upgrade SpiderMonkey to a version that breaks old code. That said, we > also limit the ability of CouchDB to run easily on OS's that include > newer SpiderMonkeys. > The odd thing is that refuge is using the archive downloadable on mozilla website. Anyway that doesn't change anything to the fact that we should correct our js I agree. I would be for a 2.0 then, like noah. - benoit
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 11:42 AM, Robert Newson wrote: > While I agree on the sentiment, I don't think it's part of the > decision. Even if 1.2 is months away, I don't think we can introduce > such a break in a minor point release. > > I'm working on the patch to remove this, can some other devs please > chime in soon with their opinions/votes? > > B. > already said but +1 for that. - benoit
Re: CouchDB 1.1.1
On 6 Oct 2011, at 10:42, Robert Newson wrote: > While I agree on the sentiment, I don't think it's part of the > decision. Even if 1.2 is months away, I don't think we can introduce > such a break in a minor point release. Let's not be afraid to use 2.x if we need to. Ultimately, these numbers are meant to communicate useful information. The marketing aspect of them ("Ooh, CouchDB hit 2.0!") is a, usually, pleasant side-effect.
Re: CouchDB 1.1.1
While I agree on the sentiment, I don't think it's part of the decision. Even if 1.2 is months away, I don't think we can introduce such a break in a minor point release. I'm working on the patch to remove this, can some other devs please chime in soon with their opinions/votes? B. On 6 October 2011 10:34, Dirkjan Ochtman wrote: > On Thu, Oct 6, 2011 at 10:30, Robert Newson wrote: >> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and >> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING >> CHANGES"). > > If we're optimistic about getting 1.2 out soonish, getting 1.1.1 out > without 1.8.5 support seems fine. > > Cheers, > > Dirkjan >
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 10:30, Robert Newson wrote: > Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and > then focus on getting 1.2 out with 1.8.5 support (and "BREAKING > CHANGES"). If we're optimistic about getting 1.2 out soonish, getting 1.1.1 out without 1.8.5 support seems fine. Cheers, Dirkjan
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 3:51 AM, Benoit Chesneau wrote: > On Thu, Oct 6, 2011 at 10:25 AM, Paul Davis > wrote: >> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >>> All, >>> >>> Paul Davis has researched the issue and it seems intractable. >>> >>> I would like to remove 1.8.5 support from 1.1.1. It was not present in >>> 1.1.0 so will not be (officially) missed. >>> >>> The place for a breaking change of this magnitude is 1.2, not a minor >>> bug fix release. >>> >>> Thoughts? >>> B. >>> >> >> +1 on removing the paren hack for sure. >> >> Not sure about removing 1.8.5 support completely. On the one hand, it >> would prevent breakage because people couldn't link against the >> breaking SM. On the other hand, it prevents people from linking >> against 1.8.5 which means it won't build on Ubuntu 11.x. > > > Is this really a problem with 1.8.5 ? How do you explain then that I > have to remove this changes to have refuge working with it then? > > https://github.com/refuge/refuge/commit/481bd6623ccfc8895eacf8a1528bffa5efa4ad47#apps/couch/share/server/util.js > > Refuge is only working with 1.8.5. > > > - benoît > Things I know for certain: This fails in the js shell from the 1.8.5 tarball: eval("function(){}") It also fails on the package in Debian that is supposed to be SpiderMonkey 1.8.5. It also fails on a checkout of the mercurial repository with hash 959c1e6bdb11. Fact of the matter, SpiderMonkey distribution is notorious in its avoidance of anything resembling a versioning scheme that we can use to refer to API/ABI compatibility across platforms. Not that it matters as it's apparently a fix, so at the end of the day "new SpiderMonkey breaks code that has worked for years." By enabling the linkage (for which, if code were proper, things would work) we introduce a non-obvious new behavior error. If we *intentionally disable* 1.8.5 linking, then we avoid introducing errors subtly into code that has always worked if someone tries to upgrade SpiderMonkey to a version that breaks old code. That said, we also limit the ability of CouchDB to run easily on OS's that include newer SpiderMonkeys.
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 3:29 AM, Dirkjan Ochtman wrote: > On Thu, Oct 6, 2011 at 10:25, Paul Davis wrote: >> +1 on removing the paren hack for sure. > > Can you elaborate on what the paren hack is? Unfotunately, SM 1.8.5 breaks the ability to evaluate anonymous functions at global scope. So all CouchDB code examples are effectively broken. The "fix" is to wrap the function in parentheses to trick the parser into returning the anonymous function. Ie, Given a standard CouchDB map function like: function(doc) { if(doc.my_type) emit(doc.my_type, 1); } The "fix" is to do: (function(doc) { if(doc.my_type) emit(doc.my_type, 1); }) However, if people are using helper functions at global scope, it turns into this: (var f = function() {return 2;}; function(doc) { if(doc.my_type) emit(doc.my_type, f()); }) Which is an error on all versions of SpiderMonkey. Basically, SpiderMonkey got stricter about following the spec by hard coding a check for the exact type of anonymous function declarations that CouchDB has relied on (unknowingly in my case) for years. > >> Not sure about removing 1.8.5 support completely. On the one hand, it >> would prevent breakage because people couldn't link against the >> breaking SM. On the other hand, it prevents people from linking >> against 1.8.5 which means it won't build on Ubuntu 11.x. > > That seems problematic. With my packager hat on, I would also prefer > if 1.8.5 support came sooner rather than later. > > Cheers, > > Dirkjan >
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 10:25 AM, Paul Davis wrote: > On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >> All, >> >> Paul Davis has researched the issue and it seems intractable. >> >> I would like to remove 1.8.5 support from 1.1.1. It was not present in >> 1.1.0 so will not be (officially) missed. >> >> The place for a breaking change of this magnitude is 1.2, not a minor >> bug fix release. >> >> Thoughts? >> B. >> > > +1 on removing the paren hack for sure. > > Not sure about removing 1.8.5 support completely. On the one hand, it > would prevent breakage because people couldn't link against the > breaking SM. On the other hand, it prevents people from linking > against 1.8.5 which means it won't build on Ubuntu 11.x. Is this really a problem with 1.8.5 ? How do you explain then that I have to remove this changes to have refuge working with it then? https://github.com/refuge/refuge/commit/481bd6623ccfc8895eacf8a1528bffa5efa4ad47#apps/couch/share/server/util.js Refuge is only working with 1.8.5. - benoît
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 10:25, Paul Davis wrote: > +1 on removing the paren hack for sure. Can you elaborate on what the paren hack is? > Not sure about removing 1.8.5 support completely. On the one hand, it > would prevent breakage because people couldn't link against the > breaking SM. On the other hand, it prevents people from linking > against 1.8.5 which means it won't build on Ubuntu 11.x. That seems problematic. With my packager hat on, I would also prefer if 1.8.5 support came sooner rather than later. Cheers, Dirkjan
Re: CouchDB 1.1.1
There is no build of 1.1.1 on Ubuntu 11.x that will work as well as 1.1.0, so I think it's correct that it cannot build under those conditions. Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and then focus on getting 1.2 out with 1.8.5 support (and "BREAKING CHANGES"). I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x. B. On 6 October 2011 09:25, Paul Davis wrote: > On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >> All, >> >> Paul Davis has researched the issue and it seems intractable. >> >> I would like to remove 1.8.5 support from 1.1.1. It was not present in >> 1.1.0 so will not be (officially) missed. >> >> The place for a breaking change of this magnitude is 1.2, not a minor >> bug fix release. >> >> Thoughts? >> B. >> > > +1 on removing the paren hack for sure. > > Not sure about removing 1.8.5 support completely. On the one hand, it > would prevent breakage because people couldn't link against the > breaking SM. On the other hand, it prevents people from linking > against 1.8.5 which means it won't build on Ubuntu 11.x. > > Unless someone comes up with a magic option I'd say put it to an > informal vote so that I can blame someone else. > >> On 5 October 2011 18:25, Paul Davis wrote: >>> Yes, its release blocking. >>> >>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: All, I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to include everything that was missing (Sidenote: Can we all keep this file up to date when commit bugfixes or add features?). I'd appreciate everyone giving it a look over before I start to build the release artifact. I believe there's an outstanding issue (not present in JIRA) around javascript function evaluation? Can someone confirm that it's release blocking? Thanks, B. >>> >> >
Re: CouchDB 1.1.1
On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: > All, > > Paul Davis has researched the issue and it seems intractable. > > I would like to remove 1.8.5 support from 1.1.1. It was not present in > 1.1.0 so will not be (officially) missed. > > The place for a breaking change of this magnitude is 1.2, not a minor > bug fix release. > > Thoughts? > B. > +1 on removing the paren hack for sure. Not sure about removing 1.8.5 support completely. On the one hand, it would prevent breakage because people couldn't link against the breaking SM. On the other hand, it prevents people from linking against 1.8.5 which means it won't build on Ubuntu 11.x. Unless someone comes up with a magic option I'd say put it to an informal vote so that I can blame someone else. > On 5 October 2011 18:25, Paul Davis wrote: >> Yes, its release blocking. >> >> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: >>> All, >>> >>> I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to >>> include everything that was missing (Sidenote: Can we all keep this >>> file up to date when commit bugfixes or add features?). I'd appreciate >>> everyone giving it a look over before I start to build the release >>> artifact. >>> >>> I believe there's an outstanding issue (not present in JIRA) around >>> javascript function evaluation? Can someone confirm that it's release >>> blocking? >>> >>> Thanks, >>> B. >>> >> >
Re: CouchDB 1.1.1
All, Paul Davis has researched the issue and it seems intractable. I would like to remove 1.8.5 support from 1.1.1. It was not present in 1.1.0 so will not be (officially) missed. The place for a breaking change of this magnitude is 1.2, not a minor bug fix release. Thoughts? B. On 5 October 2011 18:25, Paul Davis wrote: > Yes, its release blocking. > > On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: >> All, >> >> I went through JIRA and updated CHANGES and NEWS on origin/1.1.x to >> include everything that was missing (Sidenote: Can we all keep this >> file up to date when commit bugfixes or add features?). I'd appreciate >> everyone giving it a look over before I start to build the release >> artifact. >> >> I believe there's an outstanding issue (not present in JIRA) around >> javascript function evaluation? Can someone confirm that it's release >> blocking? >> >> Thanks, >> B. >> >