Estimated read time: 1 minutes
Estimated read time: 1 minutes
So we decided to upgrade from 1.35.0 to 1.37.0 in Frugalware-current. As usual, there is a WIP repo since this won't be finished in one day. Most of the trivial rebuilds are done, but still need to fix up miro, pdfedit and bmpx. Ah and I needed to upgrade libtorrent as well which resulted some problem in btg and qtorrent, though both have some support for the new 0.14.x libtorrent in SVN so most of the work was just to backport those patches.
A user on #frugalware asks when will we have python-2.6. Not before boost-1.37, I'm sure.
Side note: It seems I managed not to waste the whole day just because I met and old friend (and drinking beer). It turns out that if I drink 2 beers and sleep 2 hours then I can code without the usual "go to bed early, sleep a lot, then you can work" procedure.
Estimated read time: 1 minutes
Estimated read time: 1 minutes
Today evening gitte collected a summary of his tailor problems, which I would call a nice collection.
He says:
01:31 < gitte> vmiklos: tailor was limited in many ways. 01:31 < gitte> vmiklos: one, basically branch per branch. 01:32 < gitte> vmiklos: two, it was written in Python 01:33 < gitte> vmiklos: three, it did not define a language, but a class interface 01:33 < gitte> vmiklos: four, it made assumptions about the internal organization of SCMs 01:33 < gitte> vmiklos: five, it is maintained in a darcs repository, which tailor cannot even convert to Git. 01:35 < gitte> vmiklos: oh, and it did not help that the configuration is awkward and badly documented, not to mention inconsistent with regard to the types of input/output repositories.
Estimated read time: 1 minutes
Estimated read time: 1 minutes
So today I had a test at the uni with a lot of formula and given that it was boring to learn, I created a cheat sheet using asciidoc. The fun part is that the just released asciidoc 8.3 not only supports inline tex expressions but (using -a latexmath) supports rendering most of them to html as well.
I bookmarked a few related useful howtos on delicios, and my 14-page-length doc is available here (source, pdf, html).
I also like the new table format. The only buggy thing seems that I always have to scale images down, 100% results in a size about 200% somehow. Ah and the url escaping stuff I just reported, but that's not a problem here.
I hit it while building Git v1.6.1-rc1, released today. The toplist of that is interesting:
$ git shortlog -s -n v1.6.0..v1.6.1-rc1|head 351 Junio C Hamano 61 Alexander Gavrilov 54 Shawn O. Pearce 48 Miklos Vajna 43 Jeff King 38 Brandon Casey 29 Nanako Shiraishi 28 Nicolas Pitre 25 Alex Riesen 24 Petr Baudis
Heh, heh.
Estimated read time: 1 minutes
OK, I gave up converting darcs' darcs with tailor, opened a ticket for it. Once that is resolve, I hope I can do a comparision.
Snip. I like the new asciidoc-8.3.0, now math expressions can be defined using the latexmath :: [] macro inline. ;-)
Snip. I like how people can say the usual "if you need it, send a patch" sentence. Today's version:
"It's not very high on my list of priorities, but I assume fixing the problem is probably not hard if you decide to get your editor dirty." :-)
Estimated read time: 1 minutes
I just sent this patch, because I hated I had to look up the source about what -b does.
BTW, I did the d-f-e benchmark for the ghc repo as well, the results are here. I hope I can get tailor to somehow convert the darcs and ghc darcs repo as well, then I can draw some nice chart about how fast d-f-e is. ;-)
Currently it can't convert darcs.darcs because I specified latin2 as input/output charset and it considered that as invalid. Given that d-f-e detected ISO-8859-2, I wonder WTF is this, I unspecified the output charset and changed latin2 to ISO-8859-2 on the input side, we'll see if that helps or not.
Estimated read time: 1 minutes
I got to implement the direct patch technique for darcs2 repos in darcs-fast-export, and it seems to be a dramatic speedup.
The benchmark was done using darcs' darcs.
real 786m16.035s
real 29m39.458s
I plan to do a similar benchmark with ghc's darcs repo as well (it contains about 19k patches).
Estimated read time: 1 minutes
So today I did what I have in my TODO for some time: make darcs-fast-export produce the fast-import stream on the fly, without a tmp working dir (that's how tailor and darcs2git works, and I think that's just ugly).
And the result? I thought this will be the trick that makes it a lot faster, compared to tailor and at the end it turns out that it slows it down about 3 times. :-(
Not counting speed issues, it's a huge cleanup:
12 files changed, 34 insertions(+), 106 deletions(-)
Dunno what to do with it now. I'll try to poke the darcs devs, maybe they can optimize it a bit.
The sad fact is the comparision to git:
$ time darcs show contents --match "hash 20040523231834-97f81-2bca6242bec169bd01079378524a33e0310e0b65.gz" tailor.py >/dev/nullreal 0m2.780s $ time git show 451ae1176d56a579d3d7bd236fe7d7dd9df59326:tailor.py >/dev/null
real 0m0.004s