I like this feature. It's pretty useful now when I have a homework at the uni where the whole solution should be a single C file. So I just do a texture in Gimp, export it to C, copy&paste it to "the" file, and stop wasting my time trying to create some texture by hand. Yay! :)

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.

It has not been updated for a long time, but today a fix appeared. It seem to be kernel.org-specific though, so don't worry.

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.

OK, given that I want to build the Git User Manual 1.6.1-rc1 with Asciidoc 8.3.0, I continue the story started yesterday. The new bug seem to have something with attribute handling, whitespaces in references and quotes, pick your favorite one.

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.

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." :-)

(full message)

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.

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.

Before:

real    786m16.035s

After:

real       29m39.458s

I plan to do a similar benchmark with ghc's darcs repo as well (it contains about 19k patches).

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/null
real    0m2.780s
$ time git show 451ae1176d56a579d3d7bd236fe7d7dd9df59326:tailor.py >/dev/null
real    0m0.004s