Re: SpiderMonkey 1.8.5 upgrades
+1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards. Leave couchjs as is on 1.0.x and 1.1.x B. On 2 April 2011 02:59, Adam Kocoloski kocol...@apache.org wrote: On Apr 1, 2011, at 7:26 PM, Paul Davis wrote: Hey, Mozilla released a SM 1.8.5 source distribution this morning [1]. We've been getting requests from various places to upgrade our couchjs to use this newer version for a couple weeks and now that its available, there's no better time to act. As can be expected, this new SpiderMonkey has a fairly significant API change from what we've been using in couchjs. Up until now we've been able to get away with supporting 1.7 and the 1.8.0rc1 tarballs without much hassle. The new API makes this much more difficult. Chris C Coulson from Ubuntu has been working on a patch that'll allow us to work with 1.8.5 and (IIRC) should work with the 1.8.0rc1 but it includes some extra gnarly ifdef magic to make things work. So my question is what versions of SM should we support? I would probably vote to drop everything in favor of 1.8.5 and no longer support the older APIs. There is a possibility of just having two versions of couchjs that we choose at compile time. But from what I've heard and seen, we're basically not going to be able to have a single compile time ifdef decision on versions without some super screw code. Thoughts? [1] http://ftp.mozilla.org/pub/mozilla.org/js/ Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it. For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is. Trunk can drop support for SM 1.7. Adam
[jira] [Updated] (COUCHDB-1116) Documentation for jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-1116: - Attachment: jquery.couch.js-docs.patch Documentation for jquery.couch.js - Key: COUCHDB-1116 URL: https://issues.apache.org/jira/browse/COUCHDB-1116 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Dale Harvey Priority: Minor Attachments: jquery.couch.js-docs.patch, jquery.couch.js-docs.patch Creating documentation for jquery.couch.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SpiderMonkey 1.8.5 upgrades
Adam, I'm with Bob on this one. 1.1 and 1.0 are forked so they stay the same. This should only concern trunk. Also, just rewriting couchjs and letting configure choose for 1.2 might be doable. On Apr 2, 2011, at 6:09 AM, Robert Newson robert.new...@gmail.com wrote: +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards. Leave couchjs as is on 1.0.x and 1.1.x B. On 2 April 2011 02:59, Adam Kocoloski kocol...@apache.org wrote: On Apr 1, 2011, at 7:26 PM, Paul Davis wrote: Hey, Mozilla released a SM 1.8.5 source distribution this morning [1]. We've been getting requests from various places to upgrade our couchjs to use this newer version for a couple weeks and now that its available, there's no better time to act. As can be expected, this new SpiderMonkey has a fairly significant API change from what we've been using in couchjs. Up until now we've been able to get away with supporting 1.7 and the 1.8.0rc1 tarballs without much hassle. The new API makes this much more difficult. Chris C Coulson from Ubuntu has been working on a patch that'll allow us to work with 1.8.5 and (IIRC) should work with the 1.8.0rc1 but it includes some extra gnarly ifdef magic to make things work. So my question is what versions of SM should we support? I would probably vote to drop everything in favor of 1.8.5 and no longer support the older APIs. There is a possibility of just having two versions of couchjs that we choose at compile time. But from what I've heard and seen, we're basically not going to be able to have a single compile time ifdef decision on versions without some super screw code. Thoughts? [1] http://ftp.mozilla.org/pub/mozilla.org/js/ Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it. For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is. Trunk can drop support for SM 1.7. Adam
[jira] [Created] (COUCHDB-1117) Querying view with group parameter after group_level parameter is ignoring group_level parameter
Querying view with group parameter after group_level parameter is ignoring
group_level parameter
Key: COUCHDB-1117
URL: https://issues.apache.org/jira/browse/COUCHDB-1117
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1
Environment: {couchdb:Welcome,version:1.1.0a771dd47-git}
Reporter: Sameer Babu KK
Query with
http://localhost:5984/t24-pmdata/_design/pm/_view/report?startkey=[3,%22temperature%22,2011,2,1]endkey=[3,%22temperature%22,2011,2,29]group_level=3group=true
returns different results than
http://localhost:5984/t24-pmdata/_design/pm/_view/report?startkey=[3,%22temperature%22,2011,2,1]endkey=[3,%22temperature%22,2011,2,29]group=truegroup_level=3
or just
http://localhost:5984/t24-pmdata/_design/pm/_view/report?startkey=[3,%22temperature%22,2011,2,1]endkey=[3,%22temperature%22,2011,2,29]group_level=3
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1118) Adding a NIF based JSON decoding/encoding module
Adding a NIF based JSON decoding/encoding module Key: COUCHDB-1118 URL: https://issues.apache.org/jira/browse/COUCHDB-1118 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Filipe Manana Fix For: 1.2 Currently, all the Erlang based JSON encoders and decoders are very slow, and decoding and encoding JSON is something that we do basically everywhere. Via IRC, it recently discussed about adding a JSON NIF encoder/decoder. Damien also started a thread at the development mailing list about adding NIFs to trunk. The patch/branch at [1] adds such a JSON encoder/decoder. It is based on Paul Davis' eep0018 project [2]. Damien made some modifications [3] to it mostly to add support for big numbers (Paul's eep0018 limits the precision to 32/64 bits) and a few optimizations. I made a few corrections and minor enhancements on top of Damien's fork as well [4]. Finally Benoît identified some missing capabilities compared to mochijson2 (on encoding, allow atoms as strings and strings as object properties). Also, the version added in the patch at [1] uses mochijson2 when the C NIF is not loaded. Autotools configuration was adapted to compile the NIF only when we're using an OTP release = R13B04 (R13B03 NIF API is too limited and suffered many changes compared to R13B04 and R14) - therefore it should work on any OTP release R13B at least. I successfully tested this on R13B03, R13B04 and R14B02 in an Ubuntu environment. I'm not sure if it builds at all on Windows - would appreciate if someone could verify it. Also, I'm far from being good with the autotools, so I probably missed something important or I'm doing something in a not very standard way. This NIF encoder/decoder is about one order of magnitude faster compared to mochijson2 and other Erlang-only solutions such as jsx. A read and writes test with relaximation shows this has a very positive impact, specially on reads (the EJSON encoding is more expensive than JSON decoding) - http://graphs.mikeal.couchone.com/#/graph/698bf36b6c64dbd19aa2bef634052381 @Paul, since this is based on your eep0018 effort, do you think any other missing files should be added (README, etap tests, etc)? Also, should we put somewhere a note this is based on your project? [1] - https://github.com/fdmanana/couchdb/compare/json_nif [2] - https://github.com/davisp/eep0018 [3] - https://github.com/Damienkatz/eep0018/commits/master [4] - https://github.com/fdmanana/eep0018/commits/final_damien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SpiderMonkey 1.8.5 upgrades
I'm fine with trunk requiring 1.8.5+ and not being compatible with previous releases. On Sat, Apr 2, 2011 at 3:22 PM, Paul J. Davis paul.joseph.da...@gmail.com wrote: Adam, I'm with Bob on this one. 1.1 and 1.0 are forked so they stay the same. This should only concern trunk. Also, just rewriting couchjs and letting configure choose for 1.2 might be doable. On Apr 2, 2011, at 6:09 AM, Robert Newson robert.new...@gmail.com wrote: +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards. Leave couchjs as is on 1.0.x and 1.1.x B. On 2 April 2011 02:59, Adam Kocoloski kocol...@apache.org wrote: On Apr 1, 2011, at 7:26 PM, Paul Davis wrote: Hey, Mozilla released a SM 1.8.5 source distribution this morning [1]. We've been getting requests from various places to upgrade our couchjs to use this newer version for a couple weeks and now that its available, there's no better time to act. As can be expected, this new SpiderMonkey has a fairly significant API change from what we've been using in couchjs. Up until now we've been able to get away with supporting 1.7 and the 1.8.0rc1 tarballs without much hassle. The new API makes this much more difficult. Chris C Coulson from Ubuntu has been working on a patch that'll allow us to work with 1.8.5 and (IIRC) should work with the 1.8.0rc1 but it includes some extra gnarly ifdef magic to make things work. So my question is what versions of SM should we support? I would probably vote to drop everything in favor of 1.8.5 and no longer support the older APIs. There is a possibility of just having two versions of couchjs that we choose at compile time. But from what I've heard and seen, we're basically not going to be able to have a single compile time ifdef decision on versions without some super screw code. Thoughts? [1] http://ftp.mozilla.org/pub/mozilla.org/js/ Well, we need to continue to support SM 1.7 on the 1.0.x branch, and if that means 1.0.x doesn't work with SM 1.8.5 then so be it. For 1.1.0 I'd want to know what the availability of SM 1.8.5 in various package repositories looks like before dropping support for SM 1.7. Ideally I'd like to ship at least one version of CouchDB that works with both SM 1.7 and SM 1.8.5, but I've seen Chris' work in COUCHDB-1078 and I don't relish the thought of making that any more complicated than it already is. Trunk can drop support for SM 1.7. Adam -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
[jira] [Commented] (COUCHDB-1117) Querying view with group parameter after group_level parameter is ignoring group_level parameter
[
https://issues.apache.org/jira/browse/COUCHDB-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015050#comment-13015050
]
Jan Lehnardt commented on COUCHDB-1117:
---
I think the long-term solution here is to drop group=true and rename it ti
group_level=exact. Of course, that would break BC and can't be considered
before 2.0.0.
In the meantime, how about detecting that both group=true and group_level=N are
set and returning an error, regardless of which order they are specified in?
Querying view with group parameter after group_level parameter is ignoring
group_level parameter
Key: COUCHDB-1117
URL: https://issues.apache.org/jira/browse/COUCHDB-1117
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1
Environment: {couchdb:Welcome,version:1.1.0a771dd47-git}
Reporter: Sameer Babu KK
Query with
http://localhost:5984/t24-pmdata/_design/pm/_view/report?startkey=[3,%22temperature%22,2011,2,1]endkey=[3,%22temperature%22,2011,2,29]group_level=3group=true
returns different results than
http://localhost:5984/t24-pmdata/_design/pm/_view/report?startkey=[3,%22temperature%22,2011,2,1]endkey=[3,%22temperature%22,2011,2,29]group=truegroup_level=3
or just
http://localhost:5984/t24-pmdata/_design/pm/_view/report?startkey=[3,%22temperature%22,2011,2,1]endkey=[3,%22temperature%22,2011,2,29]group_level=3
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1116) Documentation for jquery.couch.js
[ https://issues.apache.org/jira/browse/COUCHDB-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015051#comment-13015051 ] Jan Lehnardt commented on COUCHDB-1116: --- Fuckin' A for effort! :) — Here's what this looks like rendered: http://arandomurl.com/2011/04/02/jquery-couch-js-documentation.html +1 for getting this merged. Documentation for jquery.couch.js - Key: COUCHDB-1116 URL: https://issues.apache.org/jira/browse/COUCHDB-1116 Project: CouchDB Issue Type: Improvement Components: Documentation Reporter: Dale Harvey Priority: Minor Attachments: jquery.couch.js-docs.patch, jquery.couch.js-docs.patch Creating documentation for jquery.couch.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1116) Documentation for jquery.couch.js
Great work. Documentation of everyones code is greatly needed and furthers usage of their code. Will upgrade Jans grade to an A+ -Pete
[jira] [Updated] (COUCHDB-1078) Port couchjs to newest libmozjs
[ https://issues.apache.org/jira/browse/COUCHDB-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-1078: - Attachment: couchjs_ff185.patch Patch from Jasper Lievisse Adriaanse done for the openbsd port. Port couchjs to newest libmozjs --- Key: COUCHDB-1078 URL: https://issues.apache.org/jira/browse/COUCHDB-1078 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Affects Versions: 1.0.2 Reporter: Chris Coulson Priority: Minor Attachments: couchjs_ff185.patch, mozjs2.0.patch In the libmozjs shipped with Firefox 4 / xulrunner 2.0, jsapi has changed a fair bit. It would be nice to add support to couchjs for the latest libmozjs so Linux distro's don't have to support old versions of it. I already have a WIP patch for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SpiderMonkey 1.8.5 upgrades
On Sat, Apr 2, 2011 at 1:26 AM, Paul Davis paul.joseph.da...@gmail.com wrote: Hey, Mozilla released a SM 1.8.5 source distribution this morning [1]. We've been getting requests from various places to upgrade our couchjs to use this newer version for a couple weeks and now that its available, there's no better time to act. As can be expected, this new SpiderMonkey has a fairly significant API change from what we've been using in couchjs. Up until now we've been able to get away with supporting 1.7 and the 1.8.0rc1 tarballs without much hassle. The new API makes this much more difficult. Chris C Coulson from Ubuntu has been working on a patch that'll allow us to work with 1.8.5 and (IIRC) should work with the 1.8.0rc1 but it includes some extra gnarly ifdef magic to make things work. So my question is what versions of SM should we support? I would probably vote to drop everything in favor of 1.8.5 and no longer support the older APIs. There is a possibility of just having two versions of couchjs that we choose at compile time. But from what I've heard and seen, we're basically not going to be able to have a single compile time ifdef decision on versions without some super screw code. Thoughts? [1] http://ftp.mozilla.org/pub/mozilla.org/js/ +1 to just keep support for 1.8.5 it make the code easier to read. - benoit
[jira] [Commented] (COUCHDB-1118) Adding a NIF based JSON decoding/encoding module
[ https://issues.apache.org/jira/browse/COUCHDB-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015085#comment-13015085 ] Damien Katz commented on COUCHDB-1118: -- Looks good to me. Check it in! Adding a NIF based JSON decoding/encoding module Key: COUCHDB-1118 URL: https://issues.apache.org/jira/browse/COUCHDB-1118 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Filipe Manana Fix For: 1.2 Currently, all the Erlang based JSON encoders and decoders are very slow, and decoding and encoding JSON is something that we do basically everywhere. Via IRC, it recently discussed about adding a JSON NIF encoder/decoder. Damien also started a thread at the development mailing list about adding NIFs to trunk. The patch/branch at [1] adds such a JSON encoder/decoder. It is based on Paul Davis' eep0018 project [2]. Damien made some modifications [3] to it mostly to add support for big numbers (Paul's eep0018 limits the precision to 32/64 bits) and a few optimizations. I made a few corrections and minor enhancements on top of Damien's fork as well [4]. Finally Benoît identified some missing capabilities compared to mochijson2 (on encoding, allow atoms as strings and strings as object properties). Also, the version added in the patch at [1] uses mochijson2 when the C NIF is not loaded. Autotools configuration was adapted to compile the NIF only when we're using an OTP release = R13B04 (R13B03 NIF API is too limited and suffered many changes compared to R13B04 and R14) - therefore it should work on any OTP release R13B at least. I successfully tested this on R13B03, R13B04 and R14B02 in an Ubuntu environment. I'm not sure if it builds at all on Windows - would appreciate if someone could verify it. Also, I'm far from being good with the autotools, so I probably missed something important or I'm doing something in a not very standard way. This NIF encoder/decoder is about one order of magnitude faster compared to mochijson2 and other Erlang-only solutions such as jsx. A read and writes test with relaximation shows this has a very positive impact, specially on reads (the EJSON encoding is more expensive than JSON decoding) - http://graphs.mikeal.couchone.com/#/graph/698bf36b6c64dbd19aa2bef634052381 @Paul, since this is based on your eep0018 effort, do you think any other missing files should be added (README, etap tests, etc)? Also, should we put somewhere a note this is based on your project? [1] - https://github.com/fdmanana/couchdb/compare/json_nif [2] - https://github.com/davisp/eep0018 [3] - https://github.com/Damienkatz/eep0018/commits/master [4] - https://github.com/fdmanana/eep0018/commits/final_damien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SpiderMonkey 1.8.5 upgrades
On 2 April 2011 23:09, Robert Newson robert.new...@gmail.com wrote: +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards. Leave couchjs as is on 1.0.x and 1.1.x B. Makes sense; +1. From a release perspective I would like to be clear why we are upgrading or not depending on the branch. Is it simply speed that folks are interested in, or is there new functionality that people need in 1.8.5? A+ Dave
Re: SpiderMonkey 1.8.5 upgrades
On Sat, Apr 2, 2011 at 7:28 PM, Dave Cottlehuber d...@muse.net.nz wrote: On 2 April 2011 23:09, Robert Newson robert.new...@gmail.com wrote: +1 for supporting 1.8.5 exclusively from trunk (i.e, 1.2) upwards. Leave couchjs as is on 1.0.x and 1.1.x B. Makes sense; +1. From a release perspective I would like to be clear why we are upgrading or not depending on the branch. Is it simply speed that folks are interested in, or is there new functionality that people need in 1.8.5? A+ Dave Mostly, because the last 'official' version of SM is 1.7 which we've been required to support because there's nothing 'officially' released since then. (1.7 was released in 2007). Recently most people have either been using a 1.8.0rc1 tarball (which is in a bit of a wonky position between 1.7 and 1.8.1+ where it has a weird intermediary API) or a hash from the mozilla-central mercurial repository. Basically, we've been floating this upgrade because there was nothing to latch onto. Now that 1.8.5 is out as a tarball, I reckon we'll see most SM related projects making the jump pretty quickly. I know all of my other projects will do so as well as soon as I find some free time.
[jira] [Commented] (COUCHDB-1078) Port couchjs to newest libmozjs
[ https://issues.apache.org/jira/browse/COUCHDB-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015092#comment-13015092 ] Paul Joseph Davis commented on COUCHDB-1078: @Benoit Is it just me or is that a patch of a patch? Port couchjs to newest libmozjs --- Key: COUCHDB-1078 URL: https://issues.apache.org/jira/browse/COUCHDB-1078 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Affects Versions: 1.0.2 Reporter: Chris Coulson Priority: Minor Attachments: couchjs_ff185.patch, mozjs2.0.patch In the libmozjs shipped with Firefox 4 / xulrunner 2.0, jsapi has changed a fair bit. It would be nice to add support to couchjs for the latest libmozjs so Linux distro's don't have to support old versions of it. I already have a WIP patch for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
