Re: [Monotone-devel] time for a release?
Am 18.05.2010 07:03, schrieb Derek Scherger: On Mon, May 17, 2010 at 2:33 AM, Thomas Keller m...@thomaskeller.biz wrote: \2) I'd like to get my nvm.experiment.database-management branch ready and merged in as well, so the change I did earlier to mtn setup (which now creates a database if none is given) is changed to create a database in the default location or use the default database there. The code compiles already and partially works, but I had to do a couple of non-related changes to make database objects easier constructable and other things, which make mtn currently crash badly. I'll commit my current state tonight, so others have time to look at it. Maybe I'm on a wrong path there. I had a quick look over your changes and they seem fairly reasonable. A few minor things: We seem to be using lots of redundant std:: prefixes in various .cc files (not just in your changes) where we also have using std::foo declarations to avoid needing the std:: prefixes throughout the implementation. Do people have a general preference for explicit prefixes? Personally I much prefer a using declaration and less cluttered sources, iterators are already bad enough, sprinkling them with std:: makes them worse! ;) I'm almost everytime use the std:: prefixes to make it explicit, but you are right it makes everything even more hard to read. I'll change that accordingly. Some of your changelog comments use very long lines and are somewhat hard to read without a tool that does automatic, but careful, wrapping (viewing these in emacs diff-mode is not particularly pleasant). Can you try and wrap these at some reasonable length please? Of course, totally my fault. I'm too used to this style for guitone and guitone properly wraps lines... :) On the other hand one could see that as a feature request for the log output - wrap long lines with an \ at the end if f.e. some --wrap option is given. Based on all the shenanigans with .mtn extensions it seems like maybe the path handling code could use a more formal concept of extension. Hrm... I'd see this a bit out of scope for this branch, but if you're in the mood, go on, I won't hold you off :) A shared_ptr for the lazy_rng would probably be better than a raw pointer. I will change that - it was a raw pointer before and I haven't thought about changing that. We should probably have a :memory: constant somewhere, rather than multiple string instances. Good catch, will change that as well. I don't think you want to set the foo_given flags when reading options from the options file do you? Isn't the point of these to know whether the user specified such an option on the command line? In this context it actually means if the particular stanza is written out at all in _MTN/options, i.e. not empty. This may not make sense much for the current options there, but I thought it is stringent to how the command line options parser works. Since we use a options structure to fill in the options from _MTN/options there, I aimed for 100% compatibility with the command line parser. Thanks for the review! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: new restrictions branch for including required parents
Am 18.05.2010 04:56, schrieb Derek Scherger: On Mon, May 17, 2010 at 2:26 AM, Thomas Keller m...@thomaskeller.biz wrote: Ok, as long as you have documented that for the revert command, everything should be fine. A short note in NEWS shouldn't hurt as well. Done and ready to merge. Any objections? Sorry, I forgot to review it last night - give me one more day :) Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.experiment.database-management
I've looked thru the log of nvm.experiment.database-management, and the changes make sense, although I'm not clear how they all relate to the issue of searching for a database on a path. It's currently crashing in the database-impl deconstructor. Part of the point of Boost is you're not supposed to be able to get a crash from a deconstructor; congratulations :). Compiling with -O0 gives a better stack trace; the actual crash is in Botan. I suspect something is being deconstructed twice, which is often a bad idea, although deconstructors should be designed to handle that. But I don't see a double invocation in the debugger. Perhaps this is one reason the dbcache was a member of the application class? I'm off to work now; I'll look at this some more later. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.database-management
Am 18.05.2010 13:46, schrieb Stephen Leake: I've looked thru the log of nvm.experiment.database-management, and the changes make sense, although I'm not clear how they all relate to the issue of searching for a database on a path. The problem was that I stumbled across many limitations during the implementation and fixed them on the way - f.e. I needed to retrieve the branch option from _MTN/options, but there was only a get_database_option() in work.cc. Adding another get_branch_option() looked too stupid, so I changed the code overall... :) Pretty much the same with the database code; I wanted to be able to create a local, throw-away database instance without giving it a sense of app_state, but to achieve that the random number generator and the db implementation cache had to be moved. I thought this was a good change because we have the long-term goal of getting rid of app_state anyways. It's currently crashing in the database-impl deconstructor. Part of the point of Boost is you're not supposed to be able to get a crash from a deconstructor; congratulations :). Hehe, yes. Compiling with -O0 gives a better stack trace; the actual crash is in Botan. I suspect something is being deconstructed twice, which is often a bad idea, although deconstructors should be designed to handle that. But I don't see a double invocation in the debugger. Yeah, I saw the crash in botan as well - maybe this is related to the rng change I did on my way. Derek proposed to wrap the instance in a shared pointer, but I'm unsure if this helps at all, because we have to explicitely give the raw pointer away to Botan later anyways. Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. Thanks for looking! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.database-management
Am 18.05.2010 14:07, schrieb Thomas Keller: Am 18.05.2010 13:46, schrieb Stephen Leake: Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. This is the problem when I just copy over the existing code and don't think for myself - the issue was the reference to the shared_ptr in the database constructor which rendered the reference counting of shared_ptr useless. I changed that in 35cfbc0b277b7c0a5e3a401688078cee11dc20ad and mtn no longer crashes for me. Can you confirm that? Thanks, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.database-management
Am 18.05.2010 14:41, schrieb Thomas Keller: Am 18.05.2010 14:07, schrieb Thomas Keller: Am 18.05.2010 13:46, schrieb Stephen Leake: Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. This is the problem when I just copy over the existing code and don't think for myself - the issue was the reference to the shared_ptr in the database constructor which rendered the reference counting of shared_ptr useless. I changed that in 35cfbc0b277b7c0a5e3a401688078cee11dc20ad and mtn no longer crashes for me. Can you confirm that? Forget this fix - it won't cache database_impl instances at all. I'll look further into the issue tonight. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] strptime not in MinGW time.h
I'm getting a compilation error on Windows MinGW: ../monotone/dates.cc: In static member function `static date_t date_t::from_formatted_localtime(const std::string, const std::string)': ../monotone/dates.cc:446: error: `strptime' was not declared in this scope On Debian, 'strptime' is in time.h; on MinGW, it is not; it isn't anywhere in c:/MinGW/include Upgrading to the latest MinGW 5.1.6 didn't help. A web search turned up this reference: which identifies 'strptime' as an XSI; X/Open System Interfaces Extension. So apparently MinGW doesn't support that. Annotate says 'strptime' was added recently, as part of the changelog-editor work: f67e1dea.. by derek 2010-03-14 Can this be rewritten using more standard libraries? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Tue, May 18, 2010 at 2:49 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: which identifies 'strptime' as an XSI; X/Open System Interfaces Extension. So apparently MinGW doesn't support that. Annotate says 'strptime' was added recently, as part of the changelog-editor work: Uh oh. Can this be rewritten using more standard libraries? Do you have any in mind? Date formatting and parsing seems to be quite a ghetto. Boost maybe? This sounds like maybe mingw missed it. Maybe it will appear in a future release? http://www.mail-archive.com/bug-gnu...@gnu.org/msg17739.html We could possibly copy an strptime implementation into our win32 directory I suppose. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: new restrictions branch for including required parents
Am 18.05.10 09:26, schrieb Thomas Keller:
Am 18.05.2010 04:56, schrieb Derek Scherger:
On Mon, May 17, 2010 at 2:26 AM, Thomas Keller m...@thomaskeller.biz wrote:
Ok, as long as you have documented that for the revert command,
everything should be fine. A short note in NEWS shouldn't hurt as well.
Done and ready to merge. Any objections?
Sorry, I forgot to review it last night - give me one more day :)
Ok here we go - code looks very good overall, some minor questions:
1)
+case restricted_path::required:
+case restricted_path::excluded_required:
+ if (path_depth == 0)
+{
+ L(FL(implicit include of nid %d path '%s') %
current % fp);
+ return true;
+}
+ else
+{
+ return false;
+}
+ return true;
If I followed the code correctly this logic is basically there to avoid
the exclusion of the root directory '', right? Would it make sense to
give this special node the correct node / path status right from the
start and therefor move this logic upwards? Also, the last return true
can never be reached, it should probably be
+case restricted_path::required:
+case restricted_path::excluded_required:
+ if (path_depth == 0)
+{
+ L(FL(implicit include of nid %d path '%s') %
current % fp);
+ return true;
+}
+ return false;
2) The test case restricted_diff_bug should get a better name, its no
longer a bug :)
Other than that I think its ready to get merged - I suspect Stephe has
to make his undrop command equally use explicit_includes, just like
revert, right?
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #8916] Default database location
Update of bug #8916 (project monotone): Status: Fixed = None Assigned to: stephen_leake = tommyd Open/Closed: Closed = Open ___ Follow-up Comment #3: I'm working on a separate feature in nvm.experiment.database-management which should address the original feature request much better. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?8916 ___ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
Am 15.05.10 08:56, schrieb J Decker: Monotone has no ipv6 support? It's something I've been implementing, and I had some firewall issues otherwise, I can ping the IPV6 address, but monotone claims mtn.EXE: network error: name resolution failure for 2001:db8:d:231::12: The requested name is valid, but no data of the requested type was found. (11004) (address changed to documentation prefix, and is literally not valid, but, if the address was correct, it still fails to resolv.) Linux uses 'inet_pton' for this translation, and Windows uses 'getaddrinfo' which works to resolve names and return the correct address for literal addresses also. for DNS resolution under linux, gethostbyname2() can be used to resolve IPV6 and IPv4 addresses. Could anybody with a decent ipv6 setup please look into this issue? Thanks! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
The problem here is that we are using an ancient networking library (netxx) that hasn't been updated since 2005 or something like that, and has no IPv6 support. We need a new networking library. Unfortunately, I don't know if there *is* a good low-level async networking library that meets all our requirements. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
On Tue, May 18, 2010 at 03:59:06PM -0700, Zack Weinberg wrote: The problem here is that we are using an ancient networking library (netxx) that hasn't been updated since 2005 or something like that, and has no IPv6 support. We need a new networking library. Unfortunately, I don't know if there *is* a good low-level async networking library that meets all our requirements. Just out of curiosity, how does asio fall down in this context? -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
On Tue, May 18, 2010 at 4:47 PM, Jack Lloyd ll...@randombit.net wrote: On Tue, May 18, 2010 at 03:59:06PM -0700, Zack Weinberg wrote: The problem here is that we are using an ancient networking library (netxx) that hasn't been updated since 2005 or something like that, and has no IPv6 support. We need a new networking library. Unfortunately, I don't know if there *is* a good low-level async networking library that meets all our requirements. Just out of curiosity, how does asio fall down in this context? Well, it might not, tbh - it just exceeded my pain threshold :) The problem I was having was, in asio a network socket, a local domain socket, and an anonymous pipe are all different static types, but monotone wants to treat them identically, so a big dynamically typed wrapper was necessary and writing it was too much work. Also it may have reimplemented the DNS client rather than calling getaddrinfo, which is not sysadmin-friendly. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: new restrictions branch for including required parents
On Tue, May 18, 2010 at 3:40 PM, Thomas Keller m...@thomaskeller.biz wrote:
Ok here we go - code looks very good overall, some minor questions:
1)
+case restricted_path::required:
+case restricted_path::excluded_required:
+ if (path_depth == 0)
+{
+ L(FL(implicit include of nid %d path '%s') %
current % fp);
+ return true;
+}
+ else
+{
+ return false;
+}
+ return true;
If I followed the code correctly this logic is basically there to avoid
the exclusion of the root directory '', right? Would it make sense to
give this special node the correct node / path status right from the
start and therefor move this logic upwards? Also, the last return true
can never be reached, it should probably be
This is so that only the required parents are included but not all of their
contents. Another way to think of this is that for implicit includes the
depth is always 0 so that we don't end up inadvertently including more than
we want to.
The last stray return true; shouldn't be there. I've removed it.
2) The test case restricted_diff_bug should get a better name, its no
longer a bug :)
Done.
Other than that I think its ready to get merged - I suspect Stephe has
to make his undrop command equally use explicit_includes, just like
revert, right?
Yes that's probably correct. I haven't actually looked at that code to see
what it shares with revert, but it probably needs a similar restriction
change. Ideally there will be a test that fails (with too much getting
reverted) until it isn't including parents. It looks like undrop has not
been merged yet so we can fix it before it gets merged.
I've merged the restriction changes in so we can see what needs to be done
to undrop and I'll move on to the diff branch from the bugfest.
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
