[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] 3rd party libraries
From: |
Markus Wanner |
Subject: |
Re: [Monotone-devel] 3rd party libraries |
Date: |
Fri, 24 Oct 2008 11:19:21 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080916) |
Hi,
Zack Weinberg wrote:
> I'm all for dynamic linking of botan, too, and being able to use the
> accelerated engines.
Cool. I'm trying to keep up with the development of botan, test against
new releases and potentially adopt to its changes. I'm eagerly awaiting
1.8, though. :-)
> So I believe this is the one that started graydon on the "bundle
> everything" path, with specific point revs of sqlite 2.x working for
> us and others not, and over at my day job we've been having similar
> problems with more recent releases of it. So it may well be worth
> continuing to bundle a "known good" version of the amalgamation. If
> we do, though, we should be much more proactive about testing newer
> releases so we don't wind up where we are now (i.e. stuck multiple
> feature releases behind the curve) again.
Agreed. By now I know about enough to test and integrate new sqlite
releases as well. I'll try to keep monotone's sqlite integration code
up-to-date as well.
I plan to add an optional amalgamation variant to nvm.stripped.
> I think I mentioned this before, but if we're going to stop bundling
> lua we have to overhaul the error-handling interface between lua and
> our code, because we're currently relying on lua's ability to be
> compiled as C++ and use C++ exceptions to report errors. Of course we
> need to overhaul it *anyway* because right now lots of errors just
> silently get lost, but remember that this is on the critical path for
> unbundling it.
Okay, thanks for the reminder. To be compatible to system libraries,
compiling lua with plain C (instead of C++) makes sense, IMO. Thus I'll
look into proper lua error handling for C compiled lua.
> Regarding file size, are you sure you're not counting debug
> information? On my (also 64-bit - amd64) machine, the file is 129KB,
> but 'size' says it's only got about 7KB of actual code in it. That's
> a n.v.m build; I haven't built your .dates branch but I don't see
> anything in there that would bulk it up that much.
Oh, right, that was counting debug info as well. It's rather in the
order of 11 KiB.
> Improved date parsing certainly would be nice to have but I think if
> we're going to do anything there, it oughta be that we figure out how
> to use gnulib's getdate.y, which is the gold standard as far as
> user-supplied date parsing.
Okay, thanks for that hint. I won't have time to look into that anytime
soon, though. nvm.dates is currently sufficient for my needs WRT dates.
Regards
Markus Wanner
- Re: [Monotone-devel] 3rd party libraries, (continued)
- Re: [Monotone-devel] 3rd party libraries, Markus Wanner, 2008/10/24
- Re: [Monotone-devel] 3rd party libraries, Stephen Leake, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Markus Wanner, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Stephen Leake, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Zack Weinberg, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Stephen Leake, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Markus Wanner, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Zack Weinberg, 2008/10/25
- Re: [Monotone-devel] 3rd party libraries, Matthew Nicholson, 2008/10/26
- Re: [Monotone-devel] 3rd party libraries, Markus Wanner, 2008/10/27
Re: [Monotone-devel] 3rd party libraries,
Markus Wanner <=
Re: [Monotone-devel] 3rd party libraries, Florian Weimer, 2008/10/25
Re: [Monotone-devel] 3rd party libraries, Matthew Nicholson, 2008/10/23