Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Noah Slater wrote: > Just wondering how a client would use them. If there are three bind > addresses, how do you know which one to use? I'm not sure I understand the > use case here. Not that I don't think clients need to know how to speak to > the running CouchDB, just that I don't understand the circumstances around it > well enough. Would this use case make more sense? http://192.0.2.1:5984 http://[2001:db8:dead:beef::1]:5984
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Tue, Sep 28, 2010 at 12:51 AM, Chris Anderson wrote: > On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater wrote: >> >> On 28 Sep 2010, at 02:18, Paul Davis wrote: >> >>> Multiple public interfaces and binding ssl to a subset? What does it >>> matter why so much as "not obviously unpossible". In the land of "not >>> obviously unpossible" as long as we don't have different semantics on >>> what's served to any given port, then an idea of "the right one" is >>> rather unimportant and fairly client specific, ie, "the only public >>> interface I have access to." >> >> >> I'm not sure I see where the confusion is. >> >> I am not suggesting this feature is badly thought out. >> >> I'm just trying to clarify how it will work. >> >> There are four possibilities. >> >> A file with a single HTTP URL in it: >> >>> http://192.168.0.10:80/ >> >> A file with a single HTTPS URL in it: >> >>> http://192.168.0.20:443/ >> >> A file with a HTTP and HTTPS URL in it: >> >>> http://192.168.0.10:80/ >>> http://192.168.0.20:443/ >> >> A file with multiple URLs for each protocol in it: >> >>> http://192.168.0.10:80/ >>> http://192.168.0.11:80/ >>> http://192.168.0.12:80/ >>> http://192.168.0.20:443/ >>> http://192.168.0.21:443/ >> >> The first three are okay and I see no problem with them. >> >> For the last one, it boils down to the following two question: >> >> * Do the port 80 URLs *always* point to the same thing? >> * Do the port 443 URLs *always* point to the same thing? >> > > I guess I assumed they would always be the same. more realistically I > see the file could have these contents: > > http://192.168.0.10:80/ > http://192.168.0.10:5984/ > https://192.168.0.10:443/ > https://192.168.0.10:8889/ > > Does that make more sense? I think the protocol needs to be specified > because what if you want to run https on a non 443 port? > >> If the answer is yes to both of those questions, and WILL be yes forever, >> then I see no problem with adopting this format. If the answer is no, or >> might be no, then I suspect we need to rethink it. If they could point to >> different things, and we have no way of indicating what they point to, that >> would render the file almost useless. I know my question might come across >> as utterly stupid, but I want to make sure that whatever format we choose is >> going to be future proof. > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > More specifically, the URL scheme needs to reflect the protocol. Once that exists I think we've exhausted our duty because we can tell clients "these are the endpoints" and they'll figure out which ones are reachable and compatible.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater wrote: > > On 28 Sep 2010, at 02:18, Paul Davis wrote: > >> Multiple public interfaces and binding ssl to a subset? What does it >> matter why so much as "not obviously unpossible". In the land of "not >> obviously unpossible" as long as we don't have different semantics on >> what's served to any given port, then an idea of "the right one" is >> rather unimportant and fairly client specific, ie, "the only public >> interface I have access to." > > > I'm not sure I see where the confusion is. > > I am not suggesting this feature is badly thought out. > > I'm just trying to clarify how it will work. > > There are four possibilities. > > A file with a single HTTP URL in it: > >> http://192.168.0.10:80/ > > A file with a single HTTPS URL in it: > >> http://192.168.0.20:443/ > > A file with a HTTP and HTTPS URL in it: > >> http://192.168.0.10:80/ >> http://192.168.0.20:443/ > > A file with multiple URLs for each protocol in it: > >> http://192.168.0.10:80/ >> http://192.168.0.11:80/ >> http://192.168.0.12:80/ >> http://192.168.0.20:443/ >> http://192.168.0.21:443/ > > The first three are okay and I see no problem with them. > > For the last one, it boils down to the following two question: > > * Do the port 80 URLs *always* point to the same thing? > * Do the port 443 URLs *always* point to the same thing? > I guess I assumed they would always be the same. more realistically I see the file could have these contents: http://192.168.0.10:80/ http://192.168.0.10:5984/ https://192.168.0.10:443/ https://192.168.0.10:8889/ Does that make more sense? I think the protocol needs to be specified because what if you want to run https on a non 443 port? > If the answer is yes to both of those questions, and WILL be yes forever, > then I see no problem with adopting this format. If the answer is no, or > might be no, then I suspect we need to rethink it. If they could point to > different things, and we have no way of indicating what they point to, that > would render the file almost useless. I know my question might come across as > utterly stupid, but I want to make sure that whatever format we choose is > going to be future proof. -- Chris Anderson http://jchrisa.net http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On 28 Sep 2010, at 02:18, Paul Davis wrote: > Multiple public interfaces and binding ssl to a subset? What does it > matter why so much as "not obviously unpossible". In the land of "not > obviously unpossible" as long as we don't have different semantics on > what's served to any given port, then an idea of "the right one" is > rather unimportant and fairly client specific, ie, "the only public > interface I have access to." I'm not sure I see where the confusion is. I am not suggesting this feature is badly thought out. I'm just trying to clarify how it will work. There are four possibilities. A file with a single HTTP URL in it: > http://192.168.0.10:80/ A file with a single HTTPS URL in it: > http://192.168.0.20:443/ A file with a HTTP and HTTPS URL in it: > http://192.168.0.10:80/ > http://192.168.0.20:443/ A file with multiple URLs for each protocol in it: > http://192.168.0.10:80/ > http://192.168.0.11:80/ > http://192.168.0.12:80/ > http://192.168.0.20:443/ > http://192.168.0.21:443/ The first three are okay and I see no problem with them. For the last one, it boils down to the following two question: * Do the port 80 URLs *always* point to the same thing? * Do the port 443 URLs *always* point to the same thing? If the answer is yes to both of those questions, and WILL be yes forever, then I see no problem with adopting this format. If the answer is no, or might be no, then I suspect we need to rethink it. If they could point to different things, and we have no way of indicating what they point to, that would render the file almost useless. I know my question might come across as utterly stupid, but I want to make sure that whatever format we choose is going to be future proof.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Mon, Sep 27, 2010 at 8:33 PM, Noah Slater wrote: > > On 28 Sep 2010, at 00:50, Chris Anderson wrote: > >> On Mon, Sep 27, 2010 at 3:55 PM, Noah Slater wrote: >>> >>> On 27 Sep 2010, at 23:08, Chris Anderson wrote: >>> Hmm I don't see why multiple bind addresses matter. >>> >>> Just wondering how a client would use them. If there are three bind >>> addresses, how do you know which one to use? I'm not sure I understand the >>> use case here. Not that I don't think clients need to know how to speak to >>> the running CouchDB, just that I don't understand the circumstances around >>> it well enough. >> >> you might want to bind to :80 and :5984, for obvious reasons. now >> people do that with a proxy, but you could do it with Couch, too. > > I get that. :) > > Just wondering what the circumstance will be around having two non-SSL ports > open on the same CouchDB instance. Will this EVER happen? If so, how would > you figure out which line in the file was the correct one? Multiple public interfaces and binding ssl to a subset? What does it matter why so much as "not obviously unpossible". In the land of "not obviously unpossible" as long as we don't have different semantics on what's served to any given port, then an idea of "the right one" is rather unimportant and fairly client specific, ie, "the only public interface I have access to." Paul
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On 28 Sep 2010, at 00:50, Chris Anderson wrote: > On Mon, Sep 27, 2010 at 3:55 PM, Noah Slater wrote: >> >> On 27 Sep 2010, at 23:08, Chris Anderson wrote: >> >>> Hmm I don't see why multiple bind addresses matter. >> >> Just wondering how a client would use them. If there are three bind >> addresses, how do you know which one to use? I'm not sure I understand the >> use case here. Not that I don't think clients need to know how to speak to >> the running CouchDB, just that I don't understand the circumstances around >> it well enough. > > you might want to bind to :80 and :5984, for obvious reasons. now > people do that with a proxy, but you could do it with Couch, too. I get that. :) Just wondering what the circumstance will be around having two non-SSL ports open on the same CouchDB instance. Will this EVER happen? If so, how would you figure out which line in the file was the correct one?
[jira] Updated: (COUCHDB-896) window.name set stalls futon
[ https://issues.apache.org/jira/browse/COUCHDB-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-896: Attachment: couchdb-896.patch Updated patch, fixed for all access to window.name object > window.name set stalls futon > > > Key: COUCHDB-896 > URL: https://issues.apache.org/jira/browse/COUCHDB-896 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.2 > Environment: Firefox 3.6 on OSX Leapord >Reporter: Dale Harvey >Priority: Minor > Attachments: couchdb-896.patch > > Original Estimate: 0.03h > Remaining Estimate: 0.03h > > Occasionally firefox will set window.name to true which causes futon to stall > and not function in any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-896) window.name set stalls futon
[ https://issues.apache.org/jira/browse/COUCHDB-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-896: Attachment: (was: couchdb-896.patch) > window.name set stalls futon > > > Key: COUCHDB-896 > URL: https://issues.apache.org/jira/browse/COUCHDB-896 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.2 > Environment: Firefox 3.6 on OSX Leapord >Reporter: Dale Harvey >Priority: Minor > Original Estimate: 0.03h > Remaining Estimate: 0.03h > > Occasionally firefox will set window.name to true which causes futon to stall > and not function in any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-896) window.name set stalls futon
[ https://issues.apache.org/jira/browse/COUCHDB-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-896: Attachment: couchdb-896.patch Fix for reported issue, its pretty trivial > window.name set stalls futon > > > Key: COUCHDB-896 > URL: https://issues.apache.org/jira/browse/COUCHDB-896 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 1.2 > Environment: Firefox 3.6 on OSX Leapord >Reporter: Dale Harvey >Priority: Minor > Attachments: couchdb-896.patch > > Original Estimate: 0.03h > Remaining Estimate: 0.03h > > Occasionally firefox will set window.name to true which causes futon to stall > and not function in any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Mon, Sep 27, 2010 at 3:55 PM, Noah Slater wrote: > > On 27 Sep 2010, at 23:08, Chris Anderson wrote: > >> Hmm I don't see why multiple bind addresses matter. > > Just wondering how a client would use them. If there are three bind > addresses, how do you know which one to use? I'm not sure I understand the > use case here. Not that I don't think clients need to know how to speak to > the running CouchDB, just that I don't understand the circumstances around it > well enough. > > you might want to bind to :80 and :5984, for obvious reasons. now people do that with a proxy, but you could do it with Couch, too. -- Chris Anderson http://jchrisa.net http://couch.io
[jira] Created: (COUCHDB-896) window.name set stalls futon
window.name set stalls futon Key: COUCHDB-896 URL: https://issues.apache.org/jira/browse/COUCHDB-896 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.2 Environment: Firefox 3.6 on OSX Leapord Reporter: Dale Harvey Priority: Minor Occasionally firefox will set window.name to true which causes futon to stall and not function in any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-867) Add http handlers for root files with special meanings, such as crossdomain.xml.
[
https://issues.apache.org/jira/browse/COUCHDB-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915537#action_12915537
]
Eric Desgranges commented on COUCHDB-867:
-
Is there really a difficulty to add a special handler to access directly a file
like crossdomain.xml?
I don't see any progress on this issue... because you can't really use CouchDB
in a Flash or Silverlight application without being able to read a
crossdomain.xml / clientaccesspolicy.xml file.
> Add http handlers for root files with special meanings, such as
> crossdomain.xml.
>
>
> Key: COUCHDB-867
> URL: https://issues.apache.org/jira/browse/COUCHDB-867
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 1.0.1
>Reporter: Eric Desgranges
>
> Some files at the root level of a website have a special meaning, such as
> favicon.ico storing the favorite icon, which is processed correctly in the
> [httpd_global_handlers] section of the ini file with this instruction:
> favicon.ico = {couch_httpd_misc_handlers, handle_favicon_req,
> "../share/couchdb/www"}
> But this is the only one handled while other files, which are critical when
> to accessing the CouchDB server from Flash, Flex, Silverlight..., are missing
> - crossdomain.xml (this one should be a top priority fix!)
> - clientaccesspolicy.xml -- See
> http://msdn.microsoft.com/en-us/library/cc838250%28v=VS.95%29.aspx#crossdomain_communication
> And there's also 'robots.txt' to prevent search engines from accessing some
> files / directories.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On 27 Sep 2010, at 23:08, Chris Anderson wrote: > Hmm I don't see why multiple bind addresses matter. Just wondering how a client would use them. If there are three bind addresses, how do you know which one to use? I'm not sure I understand the use case here. Not that I don't think clients need to know how to speak to the running CouchDB, just that I don't understand the circumstances around it well enough.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
I think, at most, it's one http and one https line per file, though now I think on it, what use case would there be for dynamic port assignment for https anyway? B. On Mon, Sep 27, 2010 at 11:08 PM, Chris Anderson wrote: > On Mon, Sep 27, 2010 at 3:06 PM, Noah Slater wrote: >> >> On 27 Sep 2010, at 23:02, Chris Anderson wrote: >> >>> the https:// urls are SSL, and the http:// urls are regular >>> >>> Does that answer the question? >> >> Nope. :) >> >> My reading of your comment was that at some point, we might want to support >> multiple bind addresses per protocol. So you might have three HTTP URLs. Is >> that the case? Do we need to worry about it for the future? > > Hmm I don't see why multiple bind addresses matter. We'd just have 3 > http urls in the file. Or maybe I'm being "daft". This is starting to > feel like IRC. > > Chris > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io >
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
> Hmm I don't see why multiple bind addresses matter. We'd just have 3 > http urls in the file. Or maybe I'm being "daft". This is starting to > feel like IRC. > [18:10] My and now it might belong to jan since its mostly just a HARD SPOT)
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Mon, Sep 27, 2010 at 3:06 PM, Noah Slater wrote: > > On 27 Sep 2010, at 23:02, Chris Anderson wrote: > >> the https:// urls are SSL, and the http:// urls are regular >> >> Does that answer the question? > > Nope. :) > > My reading of your comment was that at some point, we might want to support > multiple bind addresses per protocol. So you might have three HTTP URLs. Is > that the case? Do we need to worry about it for the future? Hmm I don't see why multiple bind addresses matter. We'd just have 3 http urls in the file. Or maybe I'm being "daft". This is starting to feel like IRC. Chris -- Chris Anderson http://jchrisa.net http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On 27 Sep 2010, at 23:02, Chris Anderson wrote: > the https:// urls are SSL, and the http:// urls are regular > > Does that answer the question? Nope. :) My reading of your comment was that at some point, we might want to support multiple bind addresses per protocol. So you might have three HTTP URLs. Is that the case? Do we need to worry about it for the future?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Mon, Sep 27, 2010 at 3:01 PM, Noah Slater wrote: > > On 27 Sep 2010, at 22:53, Chris Anderson wrote: > >> we need to specify the protocol in the file, as you could potentially >> have a single couchdb server listening on multiple ports with multiple >> protocols. (or even on a non-standard port, like https on or >> something) >> >> so the file could have multiple lines corresponding the the addresses >> the server is listening on. >> >> does that make sense? > > Yes, but how do you know which matches up to what? > the https:// urls are SSL, and the http:// urls are regular Does that answer the question? Chris -- Chris Anderson http://jchrisa.net http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On 27 Sep 2010, at 22:53, Chris Anderson wrote: > we need to specify the protocol in the file, as you could potentially > have a single couchdb server listening on multiple ports with multiple > protocols. (or even on a non-standard port, like https on or > something) > > so the file could have multiple lines corresponding the the addresses > the server is listening on. > > does that make sense? Yes, but how do you know which matches up to what?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
I didn't figure out to do it but when ssl is enabled the file should probably contain two lines. On Mon, Sep 27, 2010 at 10:53 PM, Chris Anderson wrote: > On Mon, Sep 27, 2010 at 1:58 PM, Noah Slater wrote: >> >> On 26 Sep 2010, at 00:18, Chris Anderson wrote: >> >>> On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana >>> wrote: On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau wrote: > data info shouldn't be in run . anyway too late now. Could have been > waiting a little more ... We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on var/run/couchdb instead of var/lib/couchdb that I rushed into committing it to trunk. Sorry, should have waited for more opinions yes, I'll revert if needed. > >>> >>> I see the http URL as being much more like a PID file than a database >>> file. Is there something I'm missing? >> >> It is fine as it is: >> >> http://www.pathname.com/fhs/2.2/fhs-5.13.html >> >> We should rethink the filename though. My original suggestion was to call it >> "couch.addr" and only include the network address and port number. But we >> can't do this until we have a separate port number for SSL connections - >> because you wouldn't be able to tell what the protocol was from this file. >> Not sure that's a huge issue though. Feedback welcome. >> >> > > we need to specify the protocol in the file, as you could potentially > have a single couchdb server listening on multiple ports with multiple > protocols. (or even on a non-standard port, like https on or > something) > > so the file could have multiple lines corresponding the the addresses > the server is listening on. > > does that make sense? > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io >
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On Mon, Sep 27, 2010 at 1:58 PM, Noah Slater wrote: > > On 26 Sep 2010, at 00:18, Chris Anderson wrote: > >> On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana >> wrote: >>> On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau >>> wrote: data info shouldn't be in run . anyway too late now. Could have been waiting a little more ... >>> >>> We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on >>> var/run/couchdb instead of var/lib/couchdb that I rushed into >>> committing it to trunk. >>> Sorry, should have waited for more opinions yes, I'll revert if needed. >>> >> >> I see the http URL as being much more like a PID file than a database >> file. Is there something I'm missing? > > It is fine as it is: > > http://www.pathname.com/fhs/2.2/fhs-5.13.html > > We should rethink the filename though. My original suggestion was to call it > "couch.addr" and only include the network address and port number. But we > can't do this until we have a separate port number for SSL connections - > because you wouldn't be able to tell what the protocol was from this file. > Not sure that's a huge issue though. Feedback welcome. > > we need to specify the protocol in the file, as you could potentially have a single couchdb server listening on multiple ports with multiple protocols. (or even on a non-standard port, like https on or something) so the file could have multiple lines corresponding the the addresses the server is listening on. does that make sense? -- Chris Anderson http://jchrisa.net http://couch.io
Re: [jira] Updated: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
On 25 Sep 2010, at 18:54, Benoit Chesneau wrote: > I need to check what is the bsd way. Main reason i put it /var/lib/couchdb > wa because it was the home of couchdb user. I don't understand how this makes a difference either way. :)
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
On 26 Sep 2010, at 00:18, Chris Anderson wrote: > On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana > wrote: >> On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau wrote: >>> data info shouldn't be in run . anyway too late now. Could have been >>> waiting a little more ... >> >> We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on >> var/run/couchdb instead of var/lib/couchdb that I rushed into >> committing it to trunk. >> Sorry, should have waited for more opinions yes, I'll revert if needed. >> >>> > > I see the http URL as being much more like a PID file than a database > file. Is there something I'm missing? It is fine as it is: http://www.pathname.com/fhs/2.2/fhs-5.13.html We should rethink the filename though. My original suggestion was to call it "couch.addr" and only include the network address and port number. But we can't do this until we have a separate port number for SSL connections - because you wouldn't be able to tell what the protocol was from this file. Not sure that's a huge issue though. Feedback welcome.
[jira] Updated: (COUCHDB-895) Improved log() function to handle "undefined" as well as object's of type "xml"
[
https://issues.apache.org/jira/browse/COUCHDB-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Young updated COUCHDB-895:
---
Attachment: log_improvements.diff
> Improved log() function to handle "undefined" as well as object's of type
> "xml"
> ---
>
> Key: COUCHDB-895
> URL: https://issues.apache.org/jira/browse/COUCHDB-895
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
>Affects Versions: 0.11.1, 0.11.2, 1.0, 1.0.1
>Reporter: Benjamin Young
>Priority: Minor
> Fix For: 1.0.2
>
> Attachments: log_improvements.diff
>
>
> Currently (1.0.1 and below), if you try log(undefined) in a map/reduce or
> other JS function in CouchDB, you'll get a rather verbose stack trace. This
> patch casts the message var as a String to avoid that stack trace and output
> the text representation of "undefined".
> Additionally, this patch includes outputting XML objects (build with E4X: new
> XML('')) as string representations of the entire XML (using
> toXMLString()).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-895) Improved log() function to handle "undefined" as well as object's of type "xml"
Improved log() function to handle "undefined" as well as object's of type "xml"
---
Key: COUCHDB-895
URL: https://issues.apache.org/jira/browse/COUCHDB-895
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.0.1, 1.0, 0.11.2, 0.11.1
Reporter: Benjamin Young
Priority: Minor
Fix For: 1.0.2
Currently (1.0.1 and below), if you try log(undefined) in a map/reduce or other
JS function in CouchDB, you'll get a rather verbose stack trace. This patch
casts the message var as a String to avoid that stack trace and output the text
representation of "undefined".
Additionally, this patch includes outputting XML objects (build with E4X: new
XML('')) as string representations of the entire XML (using
toXMLString()).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: adding new macro to couch_db.hrl
On Mon, Sep 27, 2010 at 7:46 PM, Damien Katz wrote: > I wouldn't mind it being ?get(...) as required by a macro. Also, I think it > could be an import statement in couch_db.hrl, so it's automatic for all > including files. couch_util includes couch_db.hrl so we get a compile error. > > -Damien > > > On Sep 27, 2010, at 11:06 AM, Filipe David Manana wrote: > >> On Mon, Sep 27, 2010 at 7:04 PM, Adam Kocoloski wrote: >>> I don't like "get" because it clashes with the auto-imported erlang:get >>> (for the process dictionary). >>> >>> Any reason to prefer a macro over an -import statement? >> >> Just to avoid doing the import everywhere and I still consider >> get_value too long :P >> >>> >>> Adam >>> >>> On Sep 27, 2010, at 1:47 PM, Filipe David Manana wrote: >>> Hi, I'm getting tired of typing couch_util:get_value(..). It also consumes too much horizontal space. It's probably the most used function from couch_util. I'm thinking of adding a new macro in couch_db.hrl, like: -define(value(Key, List), couch_util:get_value(Key, List)). -define(value(Key, List, Default), couch_util:get_value(Key, List, Default)). Or maybe naming the macro just "get". Anyone against it? cheers -- 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." >>> >>> >> >> >> >> -- >> 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." > > -- 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-800) Problem when writing larger than 4kb file headers
[
https://issues.apache.org/jira/browse/COUCHDB-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915431#action_12915431
]
Paul Joseph Davis commented on COUCHDB-800:
---
I'm an idiot. I managed to fix the bug by doing an `svn up`. Happened to be
looking at an old copy that was out of date.
> Problem when writing larger than 4kb file headers
> -
>
> Key: COUCHDB-800
> URL: https://issues.apache.org/jira/browse/COUCHDB-800
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
>Reporter: Damien Katz
>Assignee: Damien Katz
> Fix For: 0.11.1, 0.12
>
>
> From Andrey Somov:
> Hi,
> while reading the CouchDB source I found a question in couch_file.erl,
> I am not sure whether it is a bug or not.
> Lines 297-311:
> handle_call({write_header, Bin}, _From, #file{fd=Fd, eof=Pos}=File) ->
>BinSize = size(Bin),
>case Pos rem ?SIZE_BLOCK of
>0 ->
>Padding = <<>>;
>BlockOffset ->
>Padding = <<0:(8*(?SIZE_BLOCK-BlockOffset))>>
>end,
>FinalBin = [Padding, <<1, BinSize:32/integer>> | make_blocks(1, [Bin])],
>case file:write(Fd, FinalBin) of
>ok ->
>{reply, ok, File#file{eof=Pos+iolist_size(FinalBin)}};
>Error ->
>{reply, Error, File}
>end;
> Because <<1, BinSize:32/integer>> occupies 5 bytes make_blocks() shall
> use offset=5, but the offset is only 1.
> (it should be make_blocks(5, [Bin]))
> Since the header is smaller then 4k there is no difference and it
> works (the tests succeed with both 1 and 5). But it makes it more
> difficult to understand the code for those who study the source to
> understand how it works.
> -
> Thank you,
> Andrey
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: adding new macro to couch_db.hrl
I wouldn't mind it being ?get(...) as required by a macro. Also, I think it could be an import statement in couch_db.hrl, so it's automatic for all including files. -Damien On Sep 27, 2010, at 11:06 AM, Filipe David Manana wrote: > On Mon, Sep 27, 2010 at 7:04 PM, Adam Kocoloski wrote: >> I don't like "get" because it clashes with the auto-imported erlang:get (for >> the process dictionary). >> >> Any reason to prefer a macro over an -import statement? > > Just to avoid doing the import everywhere and I still consider > get_value too long :P > >> >> Adam >> >> On Sep 27, 2010, at 1:47 PM, Filipe David Manana wrote: >> >>> Hi, >>> >>> I'm getting tired of typing couch_util:get_value(..). It also >>> consumes too much horizontal space. It's probably the most used >>> function from couch_util. >>> I'm thinking of adding a new macro in couch_db.hrl, like: >>> >>> -define(value(Key, List), couch_util:get_value(Key, List)). >>> >>> -define(value(Key, List, Default), couch_util:get_value(Key, List, >>> Default)). >>> >>> Or maybe naming the macro just "get". >>> >>> Anyone against it? >>> >>> >>> cheers >>> >>> -- >>> 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." >> >> > > > > -- > 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."
Re: escript tests
On Mon, Sep 27, 2010 at 9:37 AM, Andrey Somov wrote: > Thank you Chris. I have updated xulrunner (I am on Ubuntu) and all the > tests pass. > > Unfortunately I cannot use FreeNode because I am behind a firewall. > is this blocked also? http://webchat.freenode.net/ -- Chris Anderson http://jchrisa.net http://couch.io
Re: adding new macro to couch_db.hrl
?getv is what the cool kids would do. On Mon, Sep 27, 2010 at 7:11 PM, Paul Davis wrote: > On Mon, Sep 27, 2010 at 2:06 PM, Filipe David Manana > wrote: >> On Mon, Sep 27, 2010 at 7:04 PM, Adam Kocoloski wrote: >>> I don't like "get" because it clashes with the auto-imported erlang:get >>> (for the process dictionary). >>> >>> Any reason to prefer a macro over an -import statement? >> >> Just to avoid doing the import everywhere and I still consider >> get_value too long :P >> >>> >>> Adam >>> >>> On Sep 27, 2010, at 1:47 PM, Filipe David Manana wrote: >>> Hi, I'm getting tired of typing couch_util:get_value(..). It also consumes too much horizontal space. It's probably the most used function from couch_util. I'm thinking of adding a new macro in couch_db.hrl, like: -define(value(Key, List), couch_util:get_value(Key, List)). -define(value(Key, List, Default), couch_util:get_value(Key, List, Default)). Or maybe naming the macro just "get". Anyone against it? cheers -- 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." >>> >>> >> >> >> >> -- >> 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." >> > > I'd have to agree with Filipe that I'd probably rather see a macro > than an import. For some reason or another imports tend to annoy me > because its a layer of indirection between what's being called. > Granted, in some of those cases its probably more of a sign that we > need to break some of the various files into sub modules and what not. > More at 10. >
Re: adding new macro to couch_db.hrl
On Mon, Sep 27, 2010 at 2:06 PM, Filipe David Manana wrote: > On Mon, Sep 27, 2010 at 7:04 PM, Adam Kocoloski wrote: >> I don't like "get" because it clashes with the auto-imported erlang:get (for >> the process dictionary). >> >> Any reason to prefer a macro over an -import statement? > > Just to avoid doing the import everywhere and I still consider > get_value too long :P > >> >> Adam >> >> On Sep 27, 2010, at 1:47 PM, Filipe David Manana wrote: >> >>> Hi, >>> >>> I'm getting tired of typing couch_util:get_value(..). It also >>> consumes too much horizontal space. It's probably the most used >>> function from couch_util. >>> I'm thinking of adding a new macro in couch_db.hrl, like: >>> >>> -define(value(Key, List), couch_util:get_value(Key, List)). >>> >>> -define(value(Key, List, Default), couch_util:get_value(Key, List, >>> Default)). >>> >>> Or maybe naming the macro just "get". >>> >>> Anyone against it? >>> >>> >>> cheers >>> >>> -- >>> 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." >> >> > > > > -- > 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." > I'd have to agree with Filipe that I'd probably rather see a macro than an import. For some reason or another imports tend to annoy me because its a layer of indirection between what's being called. Granted, in some of those cases its probably more of a sign that we need to break some of the various files into sub modules and what not. More at 10.
Re: adding new macro to couch_db.hrl
On Mon, Sep 27, 2010 at 7:04 PM, Adam Kocoloski wrote: > I don't like "get" because it clashes with the auto-imported erlang:get (for > the process dictionary). > > Any reason to prefer a macro over an -import statement? Just to avoid doing the import everywhere and I still consider get_value too long :P > > Adam > > On Sep 27, 2010, at 1:47 PM, Filipe David Manana wrote: > >> Hi, >> >> I'm getting tired of typing couch_util:get_value(..). It also >> consumes too much horizontal space. It's probably the most used >> function from couch_util. >> I'm thinking of adding a new macro in couch_db.hrl, like: >> >> -define(value(Key, List), couch_util:get_value(Key, List)). >> >> -define(value(Key, List, Default), couch_util:get_value(Key, List, Default)). >> >> Or maybe naming the macro just "get". >> >> Anyone against it? >> >> >> cheers >> >> -- >> 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." > > -- 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-800) Problem when writing larger than 4kb file headers
[
https://issues.apache.org/jira/browse/COUCHDB-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915401#action_12915401
]
Paul Joseph Davis commented on COUCHDB-800:
---
Odd. When I checked this morning it was still in couch_file as a 1 byte offset
instead of 5. I didn't spend too much time reading though so maybe its a
subtlety somewhere else. The test itself would be as easy as writing a header
larger than 4K and checking the byte boundary position.
> Problem when writing larger than 4kb file headers
> -
>
> Key: COUCHDB-800
> URL: https://issues.apache.org/jira/browse/COUCHDB-800
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
>Reporter: Damien Katz
>Assignee: Damien Katz
> Fix For: 0.11.1, 0.12
>
>
> From Andrey Somov:
> Hi,
> while reading the CouchDB source I found a question in couch_file.erl,
> I am not sure whether it is a bug or not.
> Lines 297-311:
> handle_call({write_header, Bin}, _From, #file{fd=Fd, eof=Pos}=File) ->
>BinSize = size(Bin),
>case Pos rem ?SIZE_BLOCK of
>0 ->
>Padding = <<>>;
>BlockOffset ->
>Padding = <<0:(8*(?SIZE_BLOCK-BlockOffset))>>
>end,
>FinalBin = [Padding, <<1, BinSize:32/integer>> | make_blocks(1, [Bin])],
>case file:write(Fd, FinalBin) of
>ok ->
>{reply, ok, File#file{eof=Pos+iolist_size(FinalBin)}};
>Error ->
>{reply, Error, File}
>end;
> Because <<1, BinSize:32/integer>> occupies 5 bytes make_blocks() shall
> use offset=5, but the offset is only 1.
> (it should be make_blocks(5, [Bin]))
> Since the header is smaller then 4k there is no difference and it
> works (the tests succeed with both 1 and 5). But it makes it more
> difficult to understand the code for those who study the source to
> understand how it works.
> -
> Thank you,
> Andrey
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: adding new macro to couch_db.hrl
I don't like "get" because it clashes with the auto-imported erlang:get (for the process dictionary). Any reason to prefer a macro over an -import statement? Adam On Sep 27, 2010, at 1:47 PM, Filipe David Manana wrote: > Hi, > > I'm getting tired of typing couch_util:get_value(..). It also > consumes too much horizontal space. It's probably the most used > function from couch_util. > I'm thinking of adding a new macro in couch_db.hrl, like: > > -define(value(Key, List), couch_util:get_value(Key, List)). > > -define(value(Key, List, Default), couch_util:get_value(Key, List, Default)). > > Or maybe naming the macro just "get". > > Anyone against it? > > > cheers > > -- > 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."
Re: adding new macro to couch_db.hrl
On Mon, Sep 27, 2010 at 1:47 PM, Filipe David Manana wrote: > Hi, > > I'm getting tired of typing couch_util:get_value(..). It also > consumes too much horizontal space. It's probably the most used > function from couch_util. > I'm thinking of adding a new macro in couch_db.hrl, like: > > -define(value(Key, List), couch_util:get_value(Key, List)). > > -define(value(Key, List, Default), couch_util:get_value(Key, List, Default)). > > Or maybe naming the macro just "get". > > Anyone against it? > > > cheers > > -- > 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." > I'd vote for value or getval. I'm a bit hesitant about get because of the overloading of the get bif. Paul
adding new macro to couch_db.hrl
Hi, I'm getting tired of typing couch_util:get_value(..). It also consumes too much horizontal space. It's probably the most used function from couch_util. I'm thinking of adding a new macro in couch_db.hrl, like: -define(value(Key, List), couch_util:get_value(Key, List)). -define(value(Key, List, Default), couch_util:get_value(Key, List, Default)). Or maybe naming the macro just "get". Anyone against it? cheers -- 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."
Re: escript tests
> They're maintained, but they're not widely run outside the main > committers. If you have issues or patches for them we'd be glad to > have them so they run everywhere. > It was a problem with my setup. >> 2. '020-btree-bacisc.t' test only works with big lists. When the >> rows() method returns less then 40 then the test fail. Does it mean >> that the BTree does not work with small portions of data ? May the >> test be changed (or added) to be able to process 3-5 values because it >> would be much more convenient to follow the execution with the >> debugger ? >> > > That's unintentional. I can't say I've ever tried running with a small > number of rows. If its a simple change I'd be willing to add it. If it > becomes a big change I'd probably ask you to add another test to > exercise things with smaller numbers of rows. > I checked the test, but I could not locate the problem. If I can identify the cause I will report it. >... the best place to report them is in JIRA and not here. No problem. Thank you. Andrey
[jira] Commented: (COUCHDB-800) Problem when writing larger than 4kb file headers
[
https://issues.apache.org/jira/browse/COUCHDB-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915356#action_12915356
]
Andrey Somov commented on COUCHDB-800:
--
But the issue has been fixed by Damian 3 months ago. I think I can try to
deliver patches once I learn more about CouchDB internals.
> Problem when writing larger than 4kb file headers
> -
>
> Key: COUCHDB-800
> URL: https://issues.apache.org/jira/browse/COUCHDB-800
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
>Reporter: Damien Katz
>Assignee: Damien Katz
> Fix For: 0.11.1, 0.12
>
>
> From Andrey Somov:
> Hi,
> while reading the CouchDB source I found a question in couch_file.erl,
> I am not sure whether it is a bug or not.
> Lines 297-311:
> handle_call({write_header, Bin}, _From, #file{fd=Fd, eof=Pos}=File) ->
>BinSize = size(Bin),
>case Pos rem ?SIZE_BLOCK of
>0 ->
>Padding = <<>>;
>BlockOffset ->
>Padding = <<0:(8*(?SIZE_BLOCK-BlockOffset))>>
>end,
>FinalBin = [Padding, <<1, BinSize:32/integer>> | make_blocks(1, [Bin])],
>case file:write(Fd, FinalBin) of
>ok ->
>{reply, ok, File#file{eof=Pos+iolist_size(FinalBin)}};
>Error ->
>{reply, Error, File}
>end;
> Because <<1, BinSize:32/integer>> occupies 5 bytes make_blocks() shall
> use offset=5, but the offset is only 1.
> (it should be make_blocks(5, [Bin]))
> Since the header is smaller then 4k there is no difference and it
> works (the tests succeed with both 1 and 5). But it makes it more
> difficult to understand the code for those who study the source to
> understand how it works.
> -
> Thank you,
> Andrey
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: escript tests
Thank you Chris. I have updated xulrunner (I am on Ubuntu) and all the tests pass. Unfortunately I cannot use FreeNode because I am behind a firewall.
Re: svn commit: r1001196 - /couchdb/trunk/src/couchdb/couch_file.erl
On Mon, Sep 27, 2010 at 3:34 PM, Adam Kocoloski wrote:
> Hi Filipe, I'm quite certain that the file_descriptor is closed when
> couch_file dies. I believe what the man page means by that statement is that
> if you don't supply the 'raw' option, Erlang will spawn a process to handle
> IO for the file. That is, couch_file will send a message to another process
> which owns the port, rather than couch_file owning the port itself. Regards,
Right.
Digging into OTP's code (R14B actually, but I guess it didn't change
much from R13), when the option 'raw' is not given, file.erl (
lib/kernel/src/file.erl) will use a process (the gen_server defined in
lib/kernel/src/file_server.erl) to access the file. This server will
handle process EXIT messages and do the necessary cleanups.
When using the 'raw' flag, file.erl will do the file operations
through a port (erts/preloaded/src/prim_file.erl) - this is why I have
a hunch that in this case we need to explicitely close the file, which
will send the 'close' command to the port and close the port. From
prim_file.erl:
close(#file_descriptor{module = ?MODULE, data = {Port, _}}) ->
case drv_command(Port, <>) of
ok ->
drv_close(Port);
Error ->
Error
end;
I'm not 100% sure of course, but anyway, it doesn't hurt to
explicitely close the file.
cheers
>
> Adam
>
> On Sep 25, 2010, at 7:26 AM, fdman...@apache.org wrote:
>
>> Author: fdmanana
>> Date: Sat Sep 25 11:26:39 2010
>> New Revision: 1001196
>>
>> URL: http://svn.apache.org/viewvc?rev=1001196&view=rev
>> Log:
>> Explicitely close the file descriptor. It doesn't hurt.
>> Also, since we open the file in 'raw' mode, I suspect the file descriptor is
>> not closed when the couch_file server dies.
>>
>> From erl -man file:
>>
>> "The raw option allows faster access to a file, because no Erlang process is
>> needed to handle the file."
>>
>> For me, no Erlang process handling the file means that it's likely the file
>> is not closed by any other process.
>>
>>
>>
>> Modified:
>> couchdb/trunk/src/couchdb/couch_file.erl
>>
>> Modified: couchdb/trunk/src/couchdb/couch_file.erl
>> URL:
>> http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/couch_file.erl?rev=1001196&r1=1001195&r2=1001196&view=diff
>> ==
>> --- couchdb/trunk/src/couchdb/couch_file.erl (original)
>> +++ couchdb/trunk/src/couchdb/couch_file.erl Sat Sep 25 11:26:39 2010
>> @@ -278,8 +278,8 @@ maybe_track_open_os_files(FileOptions) -
>> couch_stats_collector:track_process_count({couchdb, open_os_files})
>> end.
>>
>> -terminate(_Reason, _Fd) ->
>> - ok.
>> +terminate(_Reason, #file{fd = Fd}) ->
>> + ok = file:close(Fd).
>>
>>
>> handle_call({pread_iolist, Pos}, _From, File) ->
>>
>>
>
>
--
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-800) Problem when writing larger than 4kb file headers
[
https://issues.apache.org/jira/browse/COUCHDB-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915336#action_12915336
]
Paul Joseph Davis commented on COUCHDB-800:
---
I do believe you're correct. Think you could make a failing test case and/or
patch to show the behaviour?
> Problem when writing larger than 4kb file headers
> -
>
> Key: COUCHDB-800
> URL: https://issues.apache.org/jira/browse/COUCHDB-800
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 0.11
>Reporter: Damien Katz
>Assignee: Damien Katz
> Fix For: 0.11.1, 0.12
>
>
> From Andrey Somov:
> Hi,
> while reading the CouchDB source I found a question in couch_file.erl,
> I am not sure whether it is a bug or not.
> Lines 297-311:
> handle_call({write_header, Bin}, _From, #file{fd=Fd, eof=Pos}=File) ->
>BinSize = size(Bin),
>case Pos rem ?SIZE_BLOCK of
>0 ->
>Padding = <<>>;
>BlockOffset ->
>Padding = <<0:(8*(?SIZE_BLOCK-BlockOffset))>>
>end,
>FinalBin = [Padding, <<1, BinSize:32/integer>> | make_blocks(1, [Bin])],
>case file:write(Fd, FinalBin) of
>ok ->
>{reply, ok, File#file{eof=Pos+iolist_size(FinalBin)}};
>Error ->
>{reply, Error, File}
>end;
> Because <<1, BinSize:32/integer>> occupies 5 bytes make_blocks() shall
> use offset=5, but the offset is only 1.
> (it should be make_blocks(5, [Bin]))
> Since the header is smaller then 4k there is no difference and it
> works (the tests succeed with both 1 and 5). But it makes it more
> difficult to understand the code for those who study the source to
> understand how it works.
> -
> Thank you,
> Andrey
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: escript tests
On Mon, Sep 27, 2010 at 5:17 AM, Andrey Somov wrote: > Hi all, > I like CouchDB and I would like to read its source to understand it better. > While reading the code I have already discovered places where it can > be improved (https://issues.apache.org/jira/browse/COUCHDB-800) > > I find it very helpful to run and debug tests. > > 1. Some test fail - I get endless loop. Are the escript tests > maintained ? (If yes I will try to find out what is wrong with my > setup) They're maintained, but they're not widely run outside the main committers. If you have issues or patches for them we'd be glad to have them so they run everywhere. > 2. '020-btree-bacisc.t' test only works with big lists. When the > rows() method returns less then 40 then the test fail. Does it mean > that the BTree does not work with small portions of data ? May the > test be changed (or added) to be able to process 3-5 values because it > would be much more convenient to follow the execution with the > debugger ? > That's unintentional. I can't say I've ever tried running with a small number of rows. If its a simple change I'd be willing to add it. If it becomes a big change I'd probably ask you to add another test to exercise things with smaller numbers of rows. > 3. If I find a place where the code may be improved shall I first > raise a question in this list or should I create an issue with a patch > and an explanation ? > > -- > Andrey > Either or really. Feel free to ask here or in IRC before you do too much coding on something. If you've already have patches or find obvious things, the best place to report them is in JIRA and not here. All patches from non-committers must go through JIRA and JIRA automatically sends this list an email. HTH, Paul Davis
Re: svn commit: r1001196 - /couchdb/trunk/src/couchdb/couch_file.erl
Hi Filipe, I'm quite certain that the file_descriptor is closed when couch_file
dies. I believe what the man page means by that statement is that if you don't
supply the 'raw' option, Erlang will spawn a process to handle IO for the file.
That is, couch_file will send a message to another process which owns the
port, rather than couch_file owning the port itself. Regards,
Adam
On Sep 25, 2010, at 7:26 AM, fdman...@apache.org wrote:
> Author: fdmanana
> Date: Sat Sep 25 11:26:39 2010
> New Revision: 1001196
>
> URL: http://svn.apache.org/viewvc?rev=1001196&view=rev
> Log:
> Explicitely close the file descriptor. It doesn't hurt.
> Also, since we open the file in 'raw' mode, I suspect the file descriptor is
> not closed when the couch_file server dies.
>
> From erl -man file:
>
> "The raw option allows faster access to a file, because no Erlang process is
> needed to handle the file."
>
> For me, no Erlang process handling the file means that it's likely the file
> is not closed by any other process.
>
>
>
> Modified:
>couchdb/trunk/src/couchdb/couch_file.erl
>
> Modified: couchdb/trunk/src/couchdb/couch_file.erl
> URL:
> http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/couch_file.erl?rev=1001196&r1=1001195&r2=1001196&view=diff
> ==
> --- couchdb/trunk/src/couchdb/couch_file.erl (original)
> +++ couchdb/trunk/src/couchdb/couch_file.erl Sat Sep 25 11:26:39 2010
> @@ -278,8 +278,8 @@ maybe_track_open_os_files(FileOptions) -
> couch_stats_collector:track_process_count({couchdb, open_os_files})
> end.
>
> -terminate(_Reason, _Fd) ->
> -ok.
> +terminate(_Reason, #file{fd = Fd}) ->
> +ok = file:close(Fd).
>
>
> handle_call({pread_iolist, Pos}, _From, File) ->
>
>
Re: escript tests
On Mon, Sep 27, 2010 at 2:17 AM, Andrey Somov wrote: > Hi all, > I like CouchDB and I would like to read its source to understand it better. > While reading the code I have already discovered places where it can > be improved (https://issues.apache.org/jira/browse/COUCHDB-800) > thanks for this. > I find it very helpful to run and debug tests. > the tests pass for me, i run them like this from the source directory (make sure couchdb is not running) `make check` There is also a way to run them individually. I don't recall it from the top of my head. Another resource you should look into is the #couchdb room on irc.freenode.net It is a great place to get answers to development questions Chris > 1. Some test fail - I get endless loop. Are the escript tests > maintained ? (If yes I will try to find out what is wrong with my > setup) > > 2. '020-btree-bacisc.t' test only works with big lists. When the > rows() method returns less then 40 then the test fail. Does it mean > that the BTree does not work with small portions of data ? May the > test be changed (or added) to be able to process 3-5 values because it > would be much more convenient to follow the execution with the > debugger ? > > 3. If I find a place where the code may be improved shall I first > raise a question in this list or should I create an issue with a patch > and an explanation ? > > -- > Andrey > -- Chris Anderson http://jchrisa.net http://couch.io
escript tests
Hi all, I like CouchDB and I would like to read its source to understand it better. While reading the code I have already discovered places where it can be improved (https://issues.apache.org/jira/browse/COUCHDB-800) I find it very helpful to run and debug tests. 1. Some test fail - I get endless loop. Are the escript tests maintained ? (If yes I will try to find out what is wrong with my setup) 2. '020-btree-bacisc.t' test only works with big lists. When the rows() method returns less then 40 then the test fail. Does it mean that the BTree does not work with small portions of data ? May the test be changed (or added) to be able to process 3-5 values because it would be much more convenient to follow the execution with the debugger ? 3. If I find a place where the code may be improved shall I first raise a question in this list or should I create an issue with a patch and an explanation ? -- Andrey
Re: CouchDb not releasing files
Filipe, Thanks very much for looking at this, I'll get one of our guys to check out the code and put it on one of our servers, we can normally tell pretty quickly if its working or not. Will let you know the results Stephen On 25 September 2010 17:15, Filipe David Manana wrote: > On Sat, Sep 25, 2010 at 5:12 PM, Robert Dionne > wrote: > > I see, cool. I just saw the patch, was wondering how all these terminate > functions were being called, and started refreshing my memory on these bits. > They aren't all that intuitive. > > True. > > > > > Well it's a good idea to try it, as it's harmless and might fix the > problem. > > > > Thanks Filipe, Randall, and Paul, for the schooling > > you're welcome :) > > > > > > > On Sep 25, 2010, at 11:57 AM, Paul Davis wrote: > > > >> Bob, > >> > >> If memory serves, this thread doesn't have anything to do with the > >> couch_db_updater not functioning properly. I thought all the > >> "unlreased files" were related to views, and more specifically, view > >> compaction. Ie, its quite possible that calling couch_file:stop in the > >> proper place would've fixed this. So, my thought was perhaps with > >> Filipe's spotting this and adding the patch, it might fix the view > >> compaction leaking file descriptors issue. > >> > >> HTH, > >> Paul Davis > >> > >> On Sat, Sep 25, 2010 at 11:47 AM, Robert Dionne > >> wrote: > >>> > >>> > >>> > >>> On Sep 25, 2010, at 11:15 AM, Randall Leeds wrote: > >>> > On Sat, Sep 25, 2010 at 17:07, Robert Dionne > wrote: > > couch_file has a close function which presumably does the right > thing, but it's only called from couch_db_update:terminate > > > > It just shuts down the process. > >>> > >>> right, I'm just wondering how couch_db_update:terminate is ever called? > Does it receive an EXIT message? > >>> > >>> > The question on the table is whether > that will close the raw file opened by the process as well. Stephen, > can you reproduce the issue with .couch files if you set max_open_dbs > really low (like 2) and repeatedly access three or four databases? If > not, then I suspect it's a ref counting issue with the view index and > not directly related to couch_file at all. > > -Randall > >>> > >>> > > > > > > > > -- > 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." >
