Re: Sphinx docs
On 4 August 2012 11:25, Hans J Schroeder wrote: > This is great, thanks. > > For those building on Mac OS X: > > When "make html" stops with: ValueError: unknown locale: UTF-8 > > set the following env vars: > > export LANG=en_US.UTF-8 > export LC_ALL=en_US.UTF-8 > > - Hans > > On Aug 3, 2012, at 7:01 PM, Dirkjan Ochtman wrote: > >> On Fri, Aug 3, 2012 at 4:00 PM, Noah Slater wrote: >>> Dirkjan, please just concentrate on getting the output targets of your >>> existing Makefile working. (The Makefile I saw when I checked out your >>> Github repo last.) Don't bother yourself with Autotools. Just get the docs >>> dir working as if it were a separate concern, and I will take care of >>> integration. >> >> Okay, I think this is done. You can still see the current result here: >> >> http://couchdb.readthedocs.org/en/latest/index.html >> >> I've tested the html and texinfo targets so far, both seem to be fine. >> I've also left a TODO.txt for everyone who'd like to help out >> improving the docs and just needs a little nudge in the right >> direction. >> >> I have not removed the DocBook-based docs yet, since they are used in >> the build system and I didn't feel like messing with Noah's baby. ;) >> (Also, listing each and every HTML file seems incredibly tedious.) You >> can get the good stuff from https://github.com/djco/couchdb/tree/docs. >> I'm not sure whether it should be merged to master first, then >> included with the build system, or the other way around. >> >> Basic workflow is this: >> >> - Install docutils, pygments and sphinx via your system package >> manager, easy_install or pip >> - Go to share/sphinx-docs >> - Edit any .rst files >> - make html >> - Lather, rinse, repeat >> >> Helpful docs for those new to dealing with reST/Sphinx: >> >> http://docutils.sourceforge.net/docs/user/rst/quickstart.html >> http://sphinx.pocoo.org/rest.html >> >> Also, I'm going on vacation for a bit. I'll be around a little bit >> this weekend if there's anything you need from me, then I'll be gone >> for a week without network. >> >> Cheers, >> >> Dirkjan > I am *so* stoked to see this moving! I've started documenting how to edit/generate the docs http://wiki.apache.org/couchdb/Documentation - thanks Wendall for python assistance. Can anybody confirm if the python steps work on linux? Next: - squash patches - confirm this all works nice on github for in-page editing & document that - finish proof reading Unless there's any objections from PMC, I'd like to push the original CB xml + Dirkjan's Sphinx Sauce into a new /docs branch based off current master. A+ Dave
[jira] [Commented] (COUCHDB-1521) multipart parser gets multiple attachments mixed up
[ https://issues.apache.org/jira/browse/COUCHDB-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431288#comment-13431288 ] Robert Newson commented on COUCHDB-1521: Upgrading this to blocker because a) it's very silly and b) I think worse things happen if the two attachments were the same length. > multipart parser gets multiple attachments mixed up > --- > > Key: COUCHDB-1521 > URL: https://issues.apache.org/jira/browse/COUCHDB-1521 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.2 >Reporter: Jens Alfke >Priority: Blocker > Fix For: 1.3 > > > When receiving a document PUT in multipart format, CouchDB gets the > attachments and MIME parts mixed up. Instead of looking at the headers of a > MIME part to identify which attachment it is (most likely by using the > 'filename' property of the 'Content-Disposition:' header), it processes the > attachments according to the order in which their metadata objects appear in > the JSON body's '_attachments:' object. > The problem with this is that JSON objects (dictionaries) are _not_ ordered > collections. I know that Erlang's implementation of them (as linked lists of > key/value pairs) happens to be ordered, and I think some JavaScript > implementations have the side effect of preserving order; but in many > languages these are implemented as hash tables and genuinely unordered. > This means that when a program written in such a language converts a native > object to JSON, it has no control over (and probably no knowledge of) the > order in which the keys of the JSON object are written out. This makes it > impossible to then write the attachments in the same order. > The only workaround seems to be for the program to implement its own custom > JSON encoder just so that it can write object keys in a known order (probably > sorted), which then enables it to write the attachment bodies in the same > order. > NOTE: This is the flip side of COUCHDB-1368 which I filed last year; that bug > has to do with the same ordering issue when CouchDB _generates_ multipart > responses (and presents similar problems for clients not written in Erlang.) -- 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] [Updated] (COUCHDB-1521) multipart parser gets multiple attachments mixed up
[ https://issues.apache.org/jira/browse/COUCHDB-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1521: --- Priority: Blocker (was: Major) Fix Version/s: 1.3 > multipart parser gets multiple attachments mixed up > --- > > Key: COUCHDB-1521 > URL: https://issues.apache.org/jira/browse/COUCHDB-1521 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.2 >Reporter: Jens Alfke >Priority: Blocker > Fix For: 1.3 > > > When receiving a document PUT in multipart format, CouchDB gets the > attachments and MIME parts mixed up. Instead of looking at the headers of a > MIME part to identify which attachment it is (most likely by using the > 'filename' property of the 'Content-Disposition:' header), it processes the > attachments according to the order in which their metadata objects appear in > the JSON body's '_attachments:' object. > The problem with this is that JSON objects (dictionaries) are _not_ ordered > collections. I know that Erlang's implementation of them (as linked lists of > key/value pairs) happens to be ordered, and I think some JavaScript > implementations have the side effect of preserving order; but in many > languages these are implemented as hash tables and genuinely unordered. > This means that when a program written in such a language converts a native > object to JSON, it has no control over (and probably no knowledge of) the > order in which the keys of the JSON object are written out. This makes it > impossible to then write the attachments in the same order. > The only workaround seems to be for the program to implement its own custom > JSON encoder just so that it can write object keys in a known order (probably > sorted), which then enables it to write the attachment bodies in the same > order. > NOTE: This is the flip side of COUCHDB-1368 which I filed last year; that bug > has to do with the same ordering issue when CouchDB _generates_ multipart > responses (and presents similar problems for clients not written in Erlang.) -- 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] [Created] (COUCHDB-1521) multipart parser gets multiple attachments mixed up
Jens Alfke created COUCHDB-1521: --- Summary: multipart parser gets multiple attachments mixed up Key: COUCHDB-1521 URL: https://issues.apache.org/jira/browse/COUCHDB-1521 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Jens Alfke When receiving a document PUT in multipart format, CouchDB gets the attachments and MIME parts mixed up. Instead of looking at the headers of a MIME part to identify which attachment it is (most likely by using the 'filename' property of the 'Content-Disposition:' header), it processes the attachments according to the order in which their metadata objects appear in the JSON body's '_attachments:' object. The problem with this is that JSON objects (dictionaries) are _not_ ordered collections. I know that Erlang's implementation of them (as linked lists of key/value pairs) happens to be ordered, and I think some JavaScript implementations have the side effect of preserving order; but in many languages these are implemented as hash tables and genuinely unordered. This means that when a program written in such a language converts a native object to JSON, it has no control over (and probably no knowledge of) the order in which the keys of the JSON object are written out. This makes it impossible to then write the attachments in the same order. The only workaround seems to be for the program to implement its own custom JSON encoder just so that it can write object keys in a known order (probably sorted), which then enables it to write the attachment bodies in the same order. NOTE: This is the flip side of COUCHDB-1368 which I filed last year; that bug has to do with the same ordering issue when CouchDB _generates_ multipart responses (and presents similar problems for clients not written in Erlang.) -- 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
auto start couchdb 1.2 on bootup- Problem
I installed couchdb 1.2 from https://onabai.wordpress.com/2012/05/10/installing-couchdb-1-2-in-ubuntu-12-04/. I changed the couchdb storage path in the file /usr/local/etc/couchdb/local.ini. I also did the other steps as mentioned in the above website to auto start couchdb on start up. However, the service is not starting on start up, but when I manually do sudo etc/init.d/couchdb; the service starts. On the other hand, if I add the following ppa and install couchdb the service starts during the system startup, but when I change the storage path in /etc/couchdb/local.ini file; the services does not start during the start up. I cannot figure out the problem. Any help will be greatly appreciated. sudo apt-add-repository ppa:longsleep/couchdb sudo apt-get update sudo apt-get install couchdb Thanks -- View this message in context: http://couchdb-development.1959287.n2.nabble.com/auto-start-couchdb-1-2-on-bootup-Problem-tp7580729.html Sent from the CouchDB Development mailing list archive at Nabble.com.
[jira] [Created] (COUCHDB-1520) Replicator does not close Socket in pull from HTTPS source
Simon Eisenmann created COUCHDB-1520:
Summary: Replicator does not close Socket in pull from HTTPS source
Key: COUCHDB-1520
URL: https://issues.apache.org/jira/browse/COUCHDB-1520
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Ubuntu 8.04, Erlang 14.b.4 64bit
Reporter: Simon Eisenmann
Priority: Critical
When replicating using pull replication from an HTTPS-CouchDB source, the
client socket does not go away, but stays in CLOSE_WAIT forever, This will
crash the whole CouchDB server, as it will run out of file descriptors.
This did not happen with CouchDB 1.1.
I experimented with changing the socket options for the replicator client,
though no luck. The only change i saw was then running with keepalive (which
was the default), also the server side (pull peer) leaks a connection. Now i am
running with socket_options = [{keepalive, false}, {send_timeout, 1},
{send_timeout_close, true}]
which does not change a thing other than on the client side is leaking
connections.
To test this, you need the PID of the couchdb's beam process (ps aux |grep beam)
Then you list all the open files of this PID with "lsof -p $PID"
First you will see the pull connections beeing in ESTABLISHED state for a wile
(even when the replication itself is long finished), Then at some point it
switches to CLOSE_WAIT. The client side socket needs to be closed by the
replicator to go away and release the resources (eg. file pointer).
--
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
