Re: [feedback] mozjs17.0.0
Sound like more changes are needed. I will post a new patch with that. - benoit On Thu, Mar 28, 2013 at 6:05 PM, Randall Leeds wrote: > lgtm but I'll test it today > > On Thu, Mar 28, 2013 at 3:26 AM, Benoit Chesneau wrote: >> This patch seems to be enough but I will let Randall decide: >> >> diff --git a/configure.ac b/configure.ac >> index 91e2d3d..285ab03 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -241,6 +241,7 @@ Are the Mozilla SpiderMonkey headers installed?]) >> ]) >> ]) >> >> +AC_CHECK_LIB([mozjs-17.0], [JS_NewContext], [JS_LIB_BASE=mozjs-17.0], [ >>AC_CHECK_LIB([mozjs185], [JS_NewContext], [JS_LIB_BASE=mozjs185], [ >> AC_CHECK_LIB([mozjs185-1.0], [JS_NewContext], >> [JS_LIB_BASE=mozjs185-1.0], [ >> AC_CHECK_LIB([mozjs], [JS_NewContext], [JS_LIB_BASE=mozjs], [ >> @@ -256,6 +257,7 @@ Is the Mozilla SpiderMonkey library installed?]) >> ]) >> ]) >>]) >> +]) >> >> # Figure out what version of SpiderMonkey to use >> >> >> >> - benoît >> >> On Thu, Mar 28, 2013 at 4:54 AM, Wendall Cada wrote: >>> On 03/27/2013 07:36 PM, Benoit Chesneau wrote: Hi, As promised, I finally had time to test a build of Apache CouchDB using latest stable spidermonkey from Mozilla [1] . For this test I used rcouch which only use the spidermonkey 1.8.5 version of couchjs but the code is similar to the one in Apache CouchDB. All tests are green. It didn't imply any changes in the source code. Some important changes though: This version of spidermonkey can't be built with llvm gcc. It requires either clang or gcc. It also requires a new version of NSPR. I used latest (4.9.6) . Anyway that's good news. Now we need to update configure to handle this version. - benoīt. [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey/17 >>> >>> Fantastic news Benoit! Thanks for testing this. >>> >>> Wendall
Re: Google Summer of Code topics
On Fri, Mar 29, 2013 at 12:47 AM, Olafur Arason wrote: > 22. _changes feed for views on https://gist.github.com/rnewson/2387973 is > already supported. > http://comments.gmane.org/gmane.comp.db.couchdb.user/14891 > so /mydb/_changes?filter=_view&view=mydesign/my_view > > I only recently stumbled on this. > > This isn't the same feature: https://issues.apache.org/jira/browse/COUCHDB-1737?focusedCommentId=13615965&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615965 - benoît
Re: Google Summer of Code topics
22. _changes feed for views on https://gist.github.com/rnewson/2387973 is already supported. http://comments.gmane.org/gmane.comp.db.couchdb.user/14891 so /mydb/_changes?filter=_view&view=mydesign/my_view I only recently stumbled on this. Regards, Olafur Arason On Fri, Mar 22, 2013 at 7:13 AM, Dave Cottlehuber wrote: > Hi folks, > > GSOC[1][2] registration for ASF closes this weekend, and we'd like to > get some proposals into it, viz http://community.apache.org/gsoc.html > from last year. > > If you reply, please do so just to the dev@ list -- note I BCC'd > users@ for some ideas. > > I've got a few suggestions to get the ball rolling, with numbers where > taken from the future features list: > https://gist.github.com/rnewson/2387973 > > 6. implement a Domain-Specific Language to run within the Erlang VM, > to support native speed filtering, validation, and indexing in > addition to the current in-built JS and erlang ones. Maybe something > that includes http://jsonselect.org/ > > 8/9. Rewire CouchDB's HTTP layer to support websockets and spdy. I > think this implies switching to cowboy, this could be too messy. > > 12. Extend CouchDB's query model (e.g. > https://developers.google.com/chart/interactive/docs/querylanguage) to > support a richer syntax. > > 13/14. Implement partial reads and updates of documents, > > Make the javascript view engine faster. Could include v8 bindings, > different / parallel communication approaches between erlang and > javascript worlds, avoiding reparsing JSON roundtrips, and make it > faster than the current spidermonkey implementation. > > Implement external storage of attachments and appropriate HTTP API > hooks incl replication to allow hosting attachments outside the .couch > files, either on local storage, or in cloud blob storage (S3, azure > etc). > > Implement a view development sandbox, where you can easily prototype > with a sub-set of documents without long build times. > > Add an optional HTTP compression layer to CouchDB. It would be really > cool if you could do the compression during doc update (or view > creation or something) so that it can be served directly next time. > See https://github.com/lgerbarg/couchdb/tree/gzip-support for a prior > implementation or https://gist.github.com/archaelus/76455 for a > file-based approach, and > http://visualstart.blogspot.co.at/2012/02/mochiweb-erlang-and-gzip.html > for some other ideas. > > Develop a plugin API & rework the authentication layer to allow > plugging in ErLDAP, nodejs with EveryAuth or PassportJS or in fact > anything you like. > > Extend geocouch and/or couchdb with some of Volker's ideas (cue > Volker). Or stuff like quadtrees, geohashes or hilbert curves. > > Finally, if you are interested in being a mentor, please speak up! > > A+ > Dave > > [1]: http://www.google-melange.com/gsoc/homepage/google/gsoc2013 > [2]: > https://groups.google.com/forum/?fromgroups=#!topic/google-summer-of-code-discuss/yYM2ru4bTeo >
[jira] [Commented] (COUCHDB-1753) Erlang headers not found for RHEL/Fedora/Centos based distributions.
[ https://issues.apache.org/jira/browse/COUCHDB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616563#comment-13616563 ] Wendall Cada commented on COUCHDB-1753: --- I need to research this a little more. This is just a kitchen sink approach. I'll be creating a better patch on this branch. > Erlang headers not found for RHEL/Fedora/Centos based distributions. > > > Key: COUCHDB-1753 > URL: https://issues.apache.org/jira/browse/COUCHDB-1753 > Project: CouchDB > Issue Type: Bug > Components: Build System >Reporter: Wendall Cada >Assignee: Wendall Cada >Priority: Minor > > ./configure requires --with-erlang=/usr/lib/erlang/usr/include on all RHEL > based distributions, as this is the default install location for all Erlang > headers for any of these distributions or derivatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1753) Erlang headers not found for RHEL/Fedora/Centos based distributions.
[ https://issues.apache.org/jira/browse/COUCHDB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendall Cada updated COUCHDB-1753: -- Assignee: Wendall Cada > Erlang headers not found for RHEL/Fedora/Centos based distributions. > > > Key: COUCHDB-1753 > URL: https://issues.apache.org/jira/browse/COUCHDB-1753 > Project: CouchDB > Issue Type: Bug > Components: Build System >Reporter: Wendall Cada >Assignee: Wendall Cada > > ./configure requires --with-erlang=/usr/lib/erlang/usr/include on all RHEL > based distributions, as this is the default install location for all Erlang > headers for any of these distributions or derivatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1753) Erlang headers not found for RHEL/Fedora/Centos based distributions.
[ https://issues.apache.org/jira/browse/COUCHDB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendall Cada updated COUCHDB-1753: -- Priority: Minor (was: Major) > Erlang headers not found for RHEL/Fedora/Centos based distributions. > > > Key: COUCHDB-1753 > URL: https://issues.apache.org/jira/browse/COUCHDB-1753 > Project: CouchDB > Issue Type: Bug > Components: Build System >Reporter: Wendall Cada >Assignee: Wendall Cada >Priority: Minor > > ./configure requires --with-erlang=/usr/lib/erlang/usr/include on all RHEL > based distributions, as this is the default install location for all Erlang > headers for any of these distributions or derivatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1753) Erlang headers not found for RHEL/Fedora/Centos based distributions.
[ https://issues.apache.org/jira/browse/COUCHDB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616543#comment-13616543 ] ASF subversion and git services commented on COUCHDB-1753: -- Commit 535fe3f091fa5dbf463066f71af056155c630cc1 in branch refs/heads/1753-detect-non-standard-erlang-headers from [~wendall911] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=535fe3f ] COUCHDB-1753 Refactored erlang headers detection for non-standard locations. > Erlang headers not found for RHEL/Fedora/Centos based distributions. > > > Key: COUCHDB-1753 > URL: https://issues.apache.org/jira/browse/COUCHDB-1753 > Project: CouchDB > Issue Type: Bug > Components: Build System >Reporter: Wendall Cada > > ./configure requires --with-erlang=/usr/lib/erlang/usr/include on all RHEL > based distributions, as this is the default install location for all Erlang > headers for any of these distributions or derivatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Javascript Test Suite
+1s all around, this is much needed attention! Feel free to file JIRAs for individual issues/milestones and discuss details there. Jan -- On Mar 28, 2013, at 18:22 , Wendall Cada wrote: > On 03/27/2013 02:05 PM, Wendall Cada wrote: >> In 1.3.0, there is a new part of the test suite to run the javascript tests >> from the command line. I'm running into various issues on different >> hardware/OS configurations. Mostly, tests hanging or timing out and failing. >> These are really hard to troubleshoot, as they all pass just fine if run >> individually. >> >> What I'm experimenting with today is rewriting how the tests are implemented >> to be run one at a time from a loop in bash, versus a loop in javascript. I >> think the failures I'm running into are improper setup/teardown. There may >> be an issue with rapid delete and adding a db, or rapidly starting and >> stopping couchdb, but I think this is not what's happening in my failures. >> >> The nature of spidermonkey doesn't allow for spawning threads, or >> sandboxing, etc, so it's hard looking at the test suite to see how I can >> improve running all tests. I think it's far better to have the setup spawn a >> new interpreter for each test. Tear down will kill the interpreter. >> >> Wendall > An update here. I spent some time with this yesterday. > > There are two problems here I'd like to address. > > 1. When running `make check`, the entire javascript test suite runs in a > single interpreter thread. This means that if there are any broken tests, > then entire suite bails, as it can crash the interpreter. As I said, to > address this, I simply want to refactor the test suite to spawn a new > interpreter thread for every test. This is working well for me with my quick > work yesterday, and allows me to put a small delay in between tests to ensure > proper tear down from the previous test. > > 2. Some of the tests are written in a way that can cause a race condition in > the test itself. Quite a few places exist in the current javascript tests > where infinite loops can get generated. I simply want to re-factor several of > these tests to work as expected and avoid the race conditions entirely. > > One additional thought I had was to mimic the output of the etap tests a bit > more. Show the entire path to the test file being run, with a status at the > end of the line. Change the individual test run to include the full path to > the test to be run. Additionally, the run scripts would benefit from having > some help output. I'm in the process of gathering notes for the documentation > as well. > > My thinking is that if the test suites are similar, it will be helpful to new > developers in troubleshooting issues. > > If nobody has any objections, I'd like to get started on this work. I have a > local branch in progress for this already, but it's mostly just a scratch > space for testing so far. > > Wendall
Re: Javascript Test Suite
Sounds excellent! Very happy about this work! On 28 March 2013 17:22, Wendall Cada wrote: > On 03/27/2013 02:05 PM, Wendall Cada wrote: > >> In 1.3.0, there is a new part of the test suite to run the javascript >> tests from the command line. I'm running into various issues on different >> hardware/OS configurations. Mostly, tests hanging or timing out and >> failing. These are really hard to troubleshoot, as they all pass just fine >> if run individually. >> >> What I'm experimenting with today is rewriting how the tests are >> implemented to be run one at a time from a loop in bash, versus a loop in >> javascript. I think the failures I'm running into are improper >> setup/teardown. There may be an issue with rapid delete and adding a db, or >> rapidly starting and stopping couchdb, but I think this is not what's >> happening in my failures. >> >> The nature of spidermonkey doesn't allow for spawning threads, or >> sandboxing, etc, so it's hard looking at the test suite to see how I can >> improve running all tests. I think it's far better to have the setup spawn >> a new interpreter for each test. Tear down will kill the interpreter. >> >> Wendall >> > An update here. I spent some time with this yesterday. > > There are two problems here I'd like to address. > > 1. When running `make check`, the entire javascript test suite runs in a > single interpreter thread. This means that if there are any broken tests, > then entire suite bails, as it can crash the interpreter. As I said, to > address this, I simply want to refactor the test suite to spawn a new > interpreter thread for every test. This is working well for me with my > quick work yesterday, and allows me to put a small delay in between tests > to ensure proper tear down from the previous test. > > 2. Some of the tests are written in a way that can cause a race condition > in the test itself. Quite a few places exist in the current javascript > tests where infinite loops can get generated. I simply want to re-factor > several of these tests to work as expected and avoid the race conditions > entirely. > > One additional thought I had was to mimic the output of the etap tests a > bit more. Show the entire path to the test file being run, with a status at > the end of the line. Change the individual test run to include the full > path to the test to be run. Additionally, the run scripts would benefit > from having some help output. I'm in the process of gathering notes for the > documentation as well. > > My thinking is that if the test suites are similar, it will be helpful to > new developers in troubleshooting issues. > > If nobody has any objections, I'd like to get started on this work. I have > a local branch in progress for this already, but it's mostly just a scratch > space for testing so far. > > Wendall > -- NS
Re: Javascript Test Suite
On 03/27/2013 02:05 PM, Wendall Cada wrote: In 1.3.0, there is a new part of the test suite to run the javascript tests from the command line. I'm running into various issues on different hardware/OS configurations. Mostly, tests hanging or timing out and failing. These are really hard to troubleshoot, as they all pass just fine if run individually. What I'm experimenting with today is rewriting how the tests are implemented to be run one at a time from a loop in bash, versus a loop in javascript. I think the failures I'm running into are improper setup/teardown. There may be an issue with rapid delete and adding a db, or rapidly starting and stopping couchdb, but I think this is not what's happening in my failures. The nature of spidermonkey doesn't allow for spawning threads, or sandboxing, etc, so it's hard looking at the test suite to see how I can improve running all tests. I think it's far better to have the setup spawn a new interpreter for each test. Tear down will kill the interpreter. Wendall An update here. I spent some time with this yesterday. There are two problems here I'd like to address. 1. When running `make check`, the entire javascript test suite runs in a single interpreter thread. This means that if there are any broken tests, then entire suite bails, as it can crash the interpreter. As I said, to address this, I simply want to refactor the test suite to spawn a new interpreter thread for every test. This is working well for me with my quick work yesterday, and allows me to put a small delay in between tests to ensure proper tear down from the previous test. 2. Some of the tests are written in a way that can cause a race condition in the test itself. Quite a few places exist in the current javascript tests where infinite loops can get generated. I simply want to re-factor several of these tests to work as expected and avoid the race conditions entirely. One additional thought I had was to mimic the output of the etap tests a bit more. Show the entire path to the test file being run, with a status at the end of the line. Change the individual test run to include the full path to the test to be run. Additionally, the run scripts would benefit from having some help output. I'm in the process of gathering notes for the documentation as well. My thinking is that if the test suites are similar, it will be helpful to new developers in troubleshooting issues. If nobody has any objections, I'd like to get started on this work. I have a local branch in progress for this already, but it's mostly just a scratch space for testing so far. Wendall
Re: [feedback] mozjs17.0.0
lgtm but I'll test it today On Thu, Mar 28, 2013 at 3:26 AM, Benoit Chesneau wrote: > This patch seems to be enough but I will let Randall decide: > > diff --git a/configure.ac b/configure.ac > index 91e2d3d..285ab03 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -241,6 +241,7 @@ Are the Mozilla SpiderMonkey headers installed?]) > ]) > ]) > > +AC_CHECK_LIB([mozjs-17.0], [JS_NewContext], [JS_LIB_BASE=mozjs-17.0], [ >AC_CHECK_LIB([mozjs185], [JS_NewContext], [JS_LIB_BASE=mozjs185], [ > AC_CHECK_LIB([mozjs185-1.0], [JS_NewContext], > [JS_LIB_BASE=mozjs185-1.0], [ > AC_CHECK_LIB([mozjs], [JS_NewContext], [JS_LIB_BASE=mozjs], [ > @@ -256,6 +257,7 @@ Is the Mozilla SpiderMonkey library installed?]) > ]) > ]) >]) > +]) > > # Figure out what version of SpiderMonkey to use > > > > - benoît > > On Thu, Mar 28, 2013 at 4:54 AM, Wendall Cada wrote: >> On 03/27/2013 07:36 PM, Benoit Chesneau wrote: >>> >>> Hi, >>> >>> As promised, I finally had time to test a build of Apache CouchDB >>> using latest stable spidermonkey from Mozilla [1] . For this test I >>> used rcouch which only use the spidermonkey 1.8.5 version of couchjs >>> but the code is similar to the one in Apache CouchDB. >>> >>> All tests are green. It didn't imply any changes in the source code. >>> >>> Some important changes though: >>> >>> This version of spidermonkey can't be built with llvm gcc. It requires >>> either clang or gcc. It also requires a new version of NSPR. I used >>> latest (4.9.6) . >>> >>> Anyway that's good news. Now we need to update configure to handle this >>> version. >>> >>> - benoīt. >>> >>> [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey/17 >> >> Fantastic news Benoit! Thanks for testing this. >> >> Wendall
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616345#comment-13616345 ] Benoit Chesneau commented on COUCHDB-1754: -- [~paul.joseph.davis] I've also the same feeling about ubf. Still need to find some times to really try it. Hopefully Joe will also answer to my question about its use in browsers and such. > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [REQUEST] Release notes for 1.2.2-rc.1
Randall, the 1.2.2-rc.1 vote was successful. Are the release notes ready? Thanks, On 23 March 2013 22:48, Noah Slater wrote: > Dear community, > > This is a request to prepare the release notes for the 1.2.2-rc.1 release. > > Please follow the release procedure: > > > http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Release_Notes > > Everyone is welcome to prepare the release notes for this release. > > Thanks, > > > -- > NS > -- NS
Re: [REQUEST] Release notes for 1.3.0-rc.2
Closing down this thread, as the 1.3.0-rc.2 vote was aborted. On 25 March 2013 22:13, Randall Leeds wrote: > Sure. I'll move it there. > > On Mon, Mar 25, 2013 at 10:35 AM, Noah Slater wrote: > > Cool. Thanks Randall. Feel free to draft on the wiki if you like? > > > > (Also, are you able to help with 1.2.2?) > > > > > > On 25 March 2013 17:23, Randall Leeds wrote: > > > >> I've been slow (as has 1.3) but I've got this half written. I'll post a > >> link to this thread after I feel it's a full draft. Probably Wednesday. > >> On Mar 23, 2013 3:48 PM, "Noah Slater" wrote: > >> > >> > Dear community, > >> > > >> > This is a request to prepare the release notes for the 1.3.0-rc.2 > >> release. > >> > > >> > Please follow the release procedure: > >> > > >> > > >> > > >> > > >> > http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Release_Notes > >> > > >> > Everyone is welcome to prepare the release notes for this release. > >> > > >> > Thanks, > >> > > >> > -- > >> > NS > >> > > >> > > > > > > > > -- > > NS > -- NS
Re: [REQUEST] Binaries for 1.3.0-rc.2
Closing down this thread, as the 1.3.0-rc.2 vote was aborted. On 26 March 2013 12:57, Jan Lehnardt wrote: > On it, but blocked by https://github.com/iriscouch/build-couchdb/issues/71 > > cc Jason. > > Jan > -- > > On Mar 26, 2013, at 11:26 , Noah Slater wrote: > > > Nudging Dave and Jan. > > > > > > On 23 March 2013 22:46, Noah Slater wrote: > > Dear community, > > > > This is a request to prepare binaries for the 1.3.0-rc.2 release. > > > > Please follow the release procedure: > > > > > http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Binary_Packages > > > > Everyone is welcome to prepare binaries for this release. > > > > Thanks, > > > > -- > > NS > > > > > > > > -- > > NS > > -- NS
[RESULT] (Was: Re: [VOTE] Release Apache CouchDB 1.2.2-rc.1)
Dear community, The vote has now closed. The results are: +1 - 6 votes 0 - 0 votes -1 - 0 votes The vote is successful. Thanks, On 23 March 2013 20:47, Noah Slater wrote: > Dear community, > > I would like to call a vote on Apache CouchDB 1.2.2-rc.1. > > Changes since last round: > > * > https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.2.x > > We encourage the whole community to download and test these release > artefacts so that any critical issues can be resolved before the release is > made. Everyone is free to vote on this release, so get stuck in! > > The release artefacts we are voting on are available here: > > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.2.2/rc.1/apache-couchdb-1.2.2.tar.gz > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.2.2/rc.1/apache-couchdb-1.2.2.tar.gz.asc > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.2.2/rc.1/apache-couchdb-1.2.2.tar.gz.ish > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.2.2/rc.1/apache-couchdb-1.2.2.tar.gz.md5 > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.2.2/rc.1/apache-couchdb-1.2.2.tar.gz.sha > > Please follow the test procedure here: > > http://wiki.apache.org/couchdb/Test_procedure > > Please remember that "rc.1" is an annotation. If the vote passes, these > artefacts will be released as Apache CouchDB 1.2.2. > > Thanks, > > -- > NS > -- NS
Re: [VOTE] Release Apache CouchDB 1.3.0-rc.2
I am aborting this vote. Thanks to all who participated. On 23 March 2013 20:15, Noah Slater wrote: > Dear community, > > I would like to call a vote on Apache CouchDB 1.3.0-rc.2. > > Changes since last round: > > * > https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.3.x > > We encourage the whole community to download and test these release > artefacts so that any critical issues can be resolved before the release is > made. Everyone is free to vote on this release, so get stuck in! > > The release artefacts we are voting on are available here: > > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.3.0/rc.2/apache-couchdb-1.3.0.tar.gz > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.3.0/rc.2/apache-couchdb-1.3.0.tar.gz.asc > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.3.0/rc.2/apache-couchdb-1.3.0.tar.gz.ish > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.3.0/rc.2/apache-couchdb-1.3.0.tar.gz.md5 > wget > https://dist.apache.org/repos/dist/dev/couchdb/source/1.3.0/rc.2/apache-couchdb-1.3.0.tar.gz.sha > > Please follow the test procedure here: > > http://wiki.apache.org/couchdb/Test_procedure > > Please remember that "rc.2" is an annotation. If the vote passes, these > artefacts will be released as Apache CouchDB 1.3.0. > > Thanks, > > -- > NS > -- NS
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616242#comment-13616242 ] Riyad Kalla commented on COUCHDB-1754: -- Fair point; I think we could profile couch under load and find a rough idea of what the serialization costs (as far as a perf payoff), but certainly understand "if we are just going to be in there hacking up the world, let's fix it for everything instead of just this 1-off". Certainly agree with that. > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616236#comment-13616236 ] Paul Joseph Davis commented on COUCHDB-1754: The only issue with #2 is the amount of work that it would require for an unknown amount of payoff. If we wanted #2 I think I'd rather pay a GSOC person to rewrite some of the core bits to make #2 (and lots of other things easier) so that the focus is on the "make easier part" rather than just hack enough to get ubjson on disk. > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616229#comment-13616229 ] Riyad Kalla commented on COUCHDB-1754: -- There might be two interesting SOC projects in relation to UBJSON: 1. Supporting UBJSON over-the-wire (I assume that is what this ticket is for?) 2. Supporting UBJSON as the on-disk binary data format for the CouchDB DB file, allowing records to be streamed directly off of disk with no serialization step. At least this was the original intent of UBJSON. I know there are likely a boat load of details around #2 that I am not aware of that might make that an unlikely SOC project, but just wanted to throw it out there incase anyone was interested. I've always been curious to see what kind of performance water-level Couch could hit if we could remove the serialization/deserialization steps. > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616218#comment-13616218 ] Paul Joseph Davis commented on COUCHDB-1754: That's what reminded me of ubjson actually. I looked at UBF and it looks rather complicated for a data exchange. I wouldn't say no but I don't have any interest in supporting it. ubjson shouldn't be anything more than writing a parser (which should be ~trivial) and then adding the logic to switch (de)serializers based on content and accept types. I have no idea what UBF really even is under the hood but it sounded a lot more complicated. > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616213#comment-13616213 ] Benoit Chesneau commented on COUCHDB-1754: -- also what about ubf as well ? > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616211#comment-13616211 ] Paul Joseph Davis commented on COUCHDB-1754: Aha, found them now. I was looking in the edit dialog. Thanks [~benoitc] > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-1754: - Labels: gsoc2013, http (was: ) > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616205#comment-13616205 ] Benoit Chesneau commented on COUCHDB-1754: -- [~paul.joseph.davis] you need to tagged it. Just did it anyway. > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > Labels: gsoc2013,, http > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1754) Implement ubjson support
[ https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616182#comment-13616182 ] Paul Joseph Davis commented on COUCHDB-1754: I dunno how to make this a GSOC topic. Help [~dch] ? > Implement ubjson support > > > Key: COUCHDB-1754 > URL: https://issues.apache.org/jira/browse/COUCHDB-1754 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Paul Joseph Davis > > Just remembered this thing. For a GSOC project it might prove useful as a > "what would it take to support alternative data formats that are > representable as JSON" structures. > http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1754) Implement ubjson support
Paul Joseph Davis created COUCHDB-1754: -- Summary: Implement ubjson support Key: COUCHDB-1754 URL: https://issues.apache.org/jira/browse/COUCHDB-1754 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Paul Joseph Davis Just remembered this thing. For a GSOC project it might prove useful as a "what would it take to support alternative data formats that are representable as JSON" structures. http://ubjson.org/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [feedback] mozjs17.0.0
This patch seems to be enough but I will let Randall decide: diff --git a/configure.ac b/configure.ac index 91e2d3d..285ab03 100644 --- a/configure.ac +++ b/configure.ac @@ -241,6 +241,7 @@ Are the Mozilla SpiderMonkey headers installed?]) ]) ]) +AC_CHECK_LIB([mozjs-17.0], [JS_NewContext], [JS_LIB_BASE=mozjs-17.0], [ AC_CHECK_LIB([mozjs185], [JS_NewContext], [JS_LIB_BASE=mozjs185], [ AC_CHECK_LIB([mozjs185-1.0], [JS_NewContext], [JS_LIB_BASE=mozjs185-1.0], [ AC_CHECK_LIB([mozjs], [JS_NewContext], [JS_LIB_BASE=mozjs], [ @@ -256,6 +257,7 @@ Is the Mozilla SpiderMonkey library installed?]) ]) ]) ]) +]) # Figure out what version of SpiderMonkey to use - benoît On Thu, Mar 28, 2013 at 4:54 AM, Wendall Cada wrote: > On 03/27/2013 07:36 PM, Benoit Chesneau wrote: >> >> Hi, >> >> As promised, I finally had time to test a build of Apache CouchDB >> using latest stable spidermonkey from Mozilla [1] . For this test I >> used rcouch which only use the spidermonkey 1.8.5 version of couchjs >> but the code is similar to the one in Apache CouchDB. >> >> All tests are green. It didn't imply any changes in the source code. >> >> Some important changes though: >> >> This version of spidermonkey can't be built with llvm gcc. It requires >> either clang or gcc. It also requires a new version of NSPR. I used >> latest (4.9.6) . >> >> Anyway that's good news. Now we need to update configure to handle this >> version. >> >> - benoīt. >> >> [1] https://developer.mozilla.org/en-US/docs/SpiderMonkey/17 > > Fantastic news Benoit! Thanks for testing this. > > Wendall
[DISCUSS] a git workflow based on @dev
I should have posted it since a while but was side tracked by work and travel. Anyway here is a workflow I had in mind since a long time. It's not here to forbid the use of Github PR or system like one. On the contrary it is trying to find a way to work with them while keeping the @dev mailing-list as the first citizen. This is just a proposal. If there are any legal or technical constraints that seem to stop it then let me know in response to this thread as well. Git has been designed from the ground to work with email and many commands inside git are just here for that: git-format-patch(1), git-apply(1), git-am(1), git-send-email(1). It's really easy to send a patch via email and test it on any source code. I would like to use this feature as the core component of our workflow. Today we are using 2 main tools in the Apache CouchDB project: Jida and the mailing lists. We also have a github mirror. I didn't have the time to test the review tool we have, and if someone did I would be happy to have a feedback on its usage. So what I propose as main workflow is this one: - The main git repo centralize features & fixes which have a ticket in Jira, also master & release branches. We probably need a develop branch for C-I where fix/features branches should land before going in master or releases branches but that's another topic. - Patches should be sent and discussed on the mailing-list. So anyone susbcribed on the mailing-list can comment them and update the thread with new patches. - Once a patch has been reviewed or lazily reviewed (ie. after a time, noone responded), a developer commit it on a branch on the main repo. - After a final approval the patch will land in one of the main branches (release, master, develop). This workflow allows us to keep git decentralized and let small groups or individials to manage the code outside apache while keeping main discussions for patch integration on the ml. What about JIRA: - If a patch is answering to an issue in JIRA, it *must* link to it in using a syntax - Each response could be eventually appended to the JIRA ticket, but maybe we could just link the mailing list thread? What about GITHUB Pull Requests: Since we have a mirror on github, I'm kinda agree with Noah that we can't really forbid the use of PR. Especially since most want it. In my understanding and reading the Github API [1], PRs are some kind of patches. As a patch they could be hooked to the ML. The proposed workflow for PR is: 1. When creating a PR a thread is created on the ML 2. Each new patch to the PR is sent to the ML 3. Any new comment on the PR is sent to the ML 4. Any comment on the ML is sent to the PR. We could find a syntax as well to annotate a line just like github does. 5. Any patches sent to this ml thread is also added to the PR. In that case noone need to subscribe on Github and the dev ml is the first citizen. It can be extended to other systems if needed. I reckon this workflow imply some work to handle PR notifications or Jira integration, but at the end I think it's a win-win solution preserving our neutrality while opening ourself to others. I'm happy to help on that work. I will probably also need the help of @davisp since he knows more about the Apache Foundation internals than me. Anyway let me know what you think about it. - benoît [1] http://developer.github.com/v3/pulls/
Re: Summary of IRC meeting in #couchdb-meeting, Wed Mar 27 20:09:05 2013
On Wed, Mar 27, 2013 at 8:54 PM, ASF IRC Services < asf...@wilderness.apache.org> wrote: > 3. 1.2.2 > a. someone explain xylophone (Wohali, 3) > b. ship 1.2.2 (jan, 3) > "Xylophone" is single word, a compression, of a complex, subtle idea. The goal of xylophone is to return immediately to the original conversation without any social stigma or discomfort. "Xylophone" means, "With respect, this conversation has reached diminishing returns. While I acknowledge its importance, I propose that we table it and pop the conversation stack, back to the more urgent issue." The key to xylophone is, nobody loses face. Nobody is accusing anybody of any wrongdoing, of wasting time, of being unprofessional. Nothing like that. An individual may utter the word, but xylophone is a mantra the group tells itself. Nobody is keeping score. When somebody invokes "xylophone," proper etiquette is to **immediately** halt the conversation--mid sentence even--and return back to the main discussion. Remember, xylophone is not an accusation. There is no shame in being xylophoned. (Carrying on the less-urgent discussion, however--**that** is shameful.) There are regional dialects. People in the San Francisco Bay Area say "Styrofoam." -- Iris Couch
[jira] [Commented] (COUCHDB-1737) _changes feed for views
[ https://issues.apache.org/jira/browse/COUCHDB-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616119#comment-13616119 ] Benoit Chesneau commented on COUCHDB-1737: -- Right. Among these many things btw is the replication using view changes. > _changes feed for views > --- > > Key: COUCHDB-1737 > URL: https://issues.apache.org/jira/browse/COUCHDB-1737 > Project: CouchDB > Issue Type: Improvement >Reporter: Dave Cottlehuber >Assignee: Benoit Chesneau > Labels: couchdb, erlang > > It should be possible to subscribe to view changes the same way we can > subscribe to database changes. This will enable many useful things, > chained map-reduce being a notable one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1737) _changes feed for views
[ https://issues.apache.org/jira/browse/COUCHDB-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616118#comment-13616118 ] Klaus Trainer commented on COUCHDB-1737: Thanks Benoit for clarifying! It isn't clear from the above description that this is only about a performance improvement rather than developing a new feature. Maybe [~dch] can update the description accordingly ;) > _changes feed for views > --- > > Key: COUCHDB-1737 > URL: https://issues.apache.org/jira/browse/COUCHDB-1737 > Project: CouchDB > Issue Type: Improvement >Reporter: Dave Cottlehuber >Assignee: Benoit Chesneau > Labels: couchdb, erlang > > It should be possible to subscribe to view changes the same way we can > subscribe to database changes. This will enable many useful things, > chained map-reduce being a notable one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
