Re: [Monotone-devel] comments on merging nvm.error-handling?
On Sat, Jan 17, 2009 at 10:04 AM, Timothy Brownawell wrote: > net.venge.monotone.error-handling is meant to clean up our E(), I(), N() > usage somewhat, so that for example receiving an invalid revision from > the network will be treated differently than internally generating an > invalid revision and won't crash the server. > > N() is gone, and E() takes an extra argument, E(condition, origin, > message). The origin is an origin::type enum (see origin_type.hh), and > indicates where the data causing the error is from. E(..., > origin::user, ...) is equivalent to what N() was. > > All vocab types and most other classes now track where their data came > from with a origin::type made_from member (which can be obtained by > inheriting from origin_aware), and this is required when making a vocab > type from a string (so "branch_name(arg())" won't work, but > "branch_name(arg(), origin::user)" or "typecast_vocab(arg)" > will work. > > This also removes informative_failure, and replaces it with > recoverable_failure and unrecoverable_failure. Which one is thrown by > E() depends on the origin, currently unrecoverable for internal and > database origins, and recoverable for others. I wanted to look through the code for this but I didn't have time. I like the concept, though, and we definitely need something along these lines. Go ahead and merge it :) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] comments on merging nvm.error-handling?
On Sat, 2009-01-17 at 18:04 +, Timothy Brownawell wrote: > net.venge.monotone.error-handling is meant to clean up our E(), I(), N() > usage somewhat, so that for example receiving an invalid revision from > the network will be treated differently than internally generating an > invalid revision and won't crash the server. [...] > Does anyone have problems with merging this? I guess I'll merge this in tomorrow, then. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: times to load various things from the database
Sorry... missed the reply all button... On Mon, Jan 19, 2009 at 1:22 AM, Markus Wanner wrote: > Hi, > > Derek Scherger wrote: > > I have run timings on a few different things, the testsuite, db check and > > full pulls > > These all don't represent use cases I'm eagerly awaiting optimization > for. I don't mind if db check or an initial pull takes a while. > > I'm much more interested in optimizations for log, annotate, diff and > other operations used daily. There's nvm.cbench which does at least some > of these tests. Have you tried using that instead? > All I'm trying to do with these tests is see if this change causes a slowdown somewhere. I've never looked at the cbench branch but it sounds interesting so I may have a look that way as well. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, I've just run through the testsuite with mtn compiled against an up to date sqlite 3.6.10 (released Jan 15th). All tests succeed. > monotone 0.43dev (base revision: 2d8426478d56750e764a5ce552ba3ce7c22acb0a) > Running on : Linux 2.6.26-1-686 #1 SMP Thu Jan 1 02:26:25 UTC 2009 > i686 > C++ compiler: GNU C++ version 4.3.2 > C++ standard library: GNU libstdc++ version 20080905 > Boost version : 1_34_1 > SQLite version : 3.6.10 (compiled against 3.6.10) > Lua version : Lua 5.1 > PCRE version: 7.6 2008-01-28 (compiled against 7.6) > Botan version : 1.8.1 (compiled against 1.8.1) However, I'm still having troubles with Solaris. Maybe mostly due to my lack of understanding of that system, though. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner writes: > Hi, > > Stephen Leake wrote: >> I have a patch for m4/pcre.m4 that fixes a similar problem on Win32 >> (it will show up on any system that doesn't have pkg-config). >> ac_link uses CPPFLAGS, _not_ CFLAGS. try specifying CPPFLAGS on the >> configure command line. > > Oh, yeah, thanks for that hint. Specifying CPPFLAGS on Solaris did the > trick. > > However, CFLAGS_LUA is certainly inappropriate within m4/pcre.m4. Hmm. I think you mean LUA_CFLAGS; yes, that is a cut-paste-forget-to-edit error. > I've read the autoconf manual and figured, that all our > AC_PREPROC_IFELSE and AC_LANG_PROGRAM calls use C++, as we set > AC_LANG([C++]). Thus all CFLAGS are simply ignored. I've cleaned up that > mess (rev 2d842647..), we now have: > > PCRE_CPPFLAGS > LUA_CPPFLAGS > IDNA_CPPFLAGS > SQLITE3_CPPFLAGS > > (and no more *_CFLAGS) That sounds good. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Stephen Leake wrote: > I have a patch for m4/pcre.m4 that fixes a similar problem on Win32 > (it will show up on any system that doesn't have pkg-config). > ac_link uses CPPFLAGS, _not_ CFLAGS. try specifying CPPFLAGS on the > configure command line. Oh, yeah, thanks for that hint. Specifying CPPFLAGS on Solaris did the trick. However, CFLAGS_LUA is certainly inappropriate within m4/pcre.m4. I've read the autoconf manual and figured, that all our AC_PREPROC_IFELSE and AC_LANG_PROGRAM calls use C++, as we set AC_LANG([C++]). Thus all CFLAGS are simply ignored. I've cleaned up that mess (rev 2d842647..), we now have: PCRE_CPPFLAGS LUA_CPPFLAGS IDNA_CPPFLAGS SQLITE3_CPPFLAGS (and no more *_CFLAGS) However, we do not currently respect BOTAN_CPPFLAGS or BOTAN_LIBS, it seems. m4/botan.m4 simply overrides them. Specifying global CPPFLAGS should work, though. > I was thinking we should split INSTALL into separate files > (INSTALL.windows_mingw, etc), but let's see how big it gets first. Yes, that's a good idea, IMO. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug in monotone / January Mini Summit
Philipp Gröschler wrote: > Anonymous write access? Uh, nope, you should send your key to Richard in order to be able to push revisions. > If noone objects then I could test the TechinfoML -> Wiki converter this > way. As long as these parts don't get linked from somewhere, nobody > should find them I guess. It's not overly difficult to have a local ikiwiki installation to test with… personally I'd use that =) -- Lapo Luchini - http://lapo.it/ “X-rays will prove to be a hoax.” (Lord Kelvin, 1883) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: bug in monotone / January Mini Summit
Lapo Luchini schrieb: > Just pull the branch net.venge.monotone.web and edit files under /wiki/, > when you push the changes to monotone.ca, the wiki will automatically > update. Anonymous write access? If noone objects then I could test the TechinfoML -> Wiki converter this way. As long as these parts don't get linked from somewhere, nobody should find them I guess. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: bug in monotone / January Mini Summit
In message on Mon, 19 Jan 2009 10:44:05 +0100, Lapo Luchini said: lapo> Philipp Gröschler wrote: lapo> > Therefore, two (possibly stupid) questions: lapo> > - Is there some kind of search function in the new wiki? lapo> lapo> Not yet, though one can be installed via CGI, AFAIK. Thanks for the reminder, that needs experimenting with... (I'll take any help I can get :-)) Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Moschny wrote: > Zack Weinberg wrote: >> I'd prefer not to drop the minimum version below the most recent point >> at which an exploitable crasher bug was fixed, which (according to >> pcre's NEWS file) was 7.6. There probably isn't an attack vector with >> our usage but I can't prove it so I'd rather be safe. >> >> (Can you find out if FC9 backported those fixes?) > > The pcre package in F9 has a backported fix for CVE-2008-0674, and also > a fix for the more recent CVE-2008-2371 problem. Hm.. so.. what's the way to go here? I'd propose leaving our own minimum requirement at 7.6 and advice to Fedora 9 packagers to drop it to 7.3 on their own (simply by patching pcrewrapper.hh). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: bug in monotone / January Mini Summit
Philipp Gröschler wrote: > Therefore, two (possibly stupid) questions: > - Is there some kind of search function in the new wiki? Not yet, though one can be installed via CGI, AFAIK. > - How do I make changes? I already guessed that the wiki files are > edited directly and then checked in, so, how do I sign up? Just pull the branch net.venge.monotone.web and edit files under /wiki/, when you push the changes to monotone.ca, the wiki will automatically update. -- Lapo Luchini - http://lapo.it/ “C is quirky, flawed, and an enormous success.” (Dennis M. Ritchie) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Moschny wrote: > A Fedora botan package is on the way, see > https://bugzilla.redhat.com/show_bug.cgi?id=480528. Also very nice, thank you. Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Keller wrote: > A small note here: There is a botan package in MP, but it is currently > unusable since botan-config --libs behaves wrongly. I've created a > ticket for that [0] and hope that it is resolved until we release 0.43. As a work-around, you can provide BOTAN_LIBS and BOTAN_CPPFLAGS to monotone's configure. > Anyways, this was the past, I now plan to take over the maintenance of > the package now that there are a couple of dependencies which will > probably make it a bit harder to quickly create (static) builds. Very cool, thanks! Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; Botan
Hi, Stephen Leake wrote: > I believe I compiled against 1.7.8-3, since that's what is in my > Debian distribution. I guess I should redo that and check with ldd? Yeah, ldd certainly tells for sure. Another very interesting output would be that of 'mtn version --full'. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: times to load various things from the database
Hi, Derek Scherger wrote: > I have run timings on a few different things, the testsuite, db check and > full pulls These all don't represent use cases I'm eagerly awaiting optimization for. I don't mind if db check or an initial pull takes a while. I'm much more interested in optimizations for log, annotate, diff and other operations used daily. There's nvm.cbench which does at least some of these tests. Have you tried using that instead? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Zack Weinberg wrote: > I'd prefer not to drop the minimum version below the most recent point > at which an exploitable crasher bug was fixed, which (according to > pcre's NEWS file) was 7.6. There probably isn't an attack vector with > our usage but I can't prove it so I'd rather be safe. > > (Can you find out if FC9 backported those fixes?) The pcre package in F9 has a backported fix for CVE-2008-0674, and also a fix for the more recent CVE-2008-2371 problem. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, thanks for your efforts on the MinGW build, very nice. Stephen Leake wrote: > Instructions for MinGW for monotone bundled are in > monotone.web/wiki/Building/Windows/MinGW.mdwn; 137 lines. Adding the > info for stripped at a similar level of detail will take about another > 50 lines. > > Does that make it worth a separate file? Hm.. I'd even strip down the explanation in the INSTALL file. Splitting the MinGW page on the wiki doesn't make much sense to me, because landing nvm.stripped will supersede the 'old' variant. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
