Re: [Monotone-devel] 3rd party libraries

[Markus Wanner]

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