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

OK, so I got this idea in the darcs-user mailing list that it would be nice to do some benchmarks on how fast and correct darcs-fast-export is. Actually I already have a TODO item about an idea that would make it faster, but doing a benchmark before doing the speedup is required in that case as well, so that I can show "hey, this is cool, it results in foo% speedup!11". ;-)

And if I'm already there, I plan to do it with tailor as well, I'm just curious about how fast it is. Ideally fast-import is much faster, but I guess the current darcs exporter does not make use of it, so I expect something like 1:1 for now.

The test repo is darcs' darcs, current status with darcs-fast-export is like:

progress [2008-11-25 16:02:28] getting list of patches
progress [2008-11-26 00:53:25] 4000/6548 patches

Yeah, darcs apply is slow.

I got this exercise at the uni, and I thought it's easier if I split the problem: first the logical one (implement the pseudocode from Wikipedia in Python) then the RTFM one (figure out the right Java API).

Of course I wasted the whole evening by not starting working on it, so it was 0:30 when I started. It took about 2 hours to do the Python implementation, and then again two hours to transform it to Java. And of course the code is two times longer. Guess what? One of the guy I talked today was surprised about how short my Java code is. :-P

BTW, the day before I finally got to write git-darcs. An old vision that is now reality. :-)

There is now a testcase that checks if the feature mentioned in the post title works.

Basically I hope I can write - based on this - a git-darcs wrapper that will make it easy to convert a darcs repo to a git one, work in git, then push the result back to the darcs repo, something I wish a long time ago. ;-)

I use Frugalware's mutt-ng package for e-mail, which is mutt-devel + a more-or-less small patchset, maintained by voroskoi. Given that he was quite inactive recently, I poked him regularly to update the package (+ the patches, of course) to 1.5.18. I just noticed today that he did so about a month ago. :-)

Two changes I noticed so far are: 1) when you open a large folder, not only the current/total value is printed for processed mails, but the percentage as well, and 2) the sidebar shows again the number of flagged mails, which feature disappeared IIRC after we switched from "mutt-ng as a fork" to "mutt-ng is mutt-devel + patches".

Snip. I bumped our kernel to 2.6.27.7 and it seems now I have to update the kernel config even for a new -stable release, which is quite annoying. :-/

Snip. This evening I got some time to work on this darcs-git stuff again and I tagged darcs-fast-export 0.5 + pushed an initial darcs-fast-import.

Of course it does not support incremental import, it does not import tags yet and such, but it works! ;-)

The project was linked on a news site today, but voroskoi already poked me about "hey, you should try it out with Frugalware", so I was aware of the project already. The reason I point it out is that now they create a sample for Git as well, and I seem to appear in it at 4m25s, heh.

The IPv6 tunnel I use changed its IPv4 address. This caused some great silence in my IRC client, basically none of the freenode people was able to poke me with random problems. ;-) But the party is over, since the tunnel guy was kind enough to mail the new IP.

i just recently got a mail about that 'bitlbee1.asnetinc.net' is a public server with my skype plugin installed. in other words, you no longer are forced to run your own bitlbee server if you want to use skype from bitlbee, yay! :)

note: actually if you are behind nat, then this is not something useful for you as the public server will want to connect to your skype instance, actually. :/

so, one of my friends called me a few days ago, saying 'hi, i got this eee pc, it's shipped with win xp, could you please install frugalware on it, making it dual-bootable?'.

today i got the gadget, i had about 3 hours to play with it, so i did not have much time.

first, there was an installer bug, but fortunately it was trivial to fix it up. second, the internal wifi card is not supported by 2.6.26, so i made a kernel package from 2.6.27-rc6 and made a custom usb installer using that kernel.

once that was ok, the installation went fairly easy. minor problems were that the netinstall by default wants to use ftp but we were behind a proxy, so we needed http. and other problem was that there were two ntfs partitions, the second was empty, i just formatted it as ext3, using it as /, but i did not set the partition type from ntfs to linux and grub refused to install because of my laziness.

i did not want to do a full install but i needed network, so i installed base+network. once that was fine, i installed some other packages/groups: acpi, mc, x11 and kdebase.

so far what i saw working:

• wireless, that was working in the netinstall as well after the kernel update
• touchpad
• xorg, using that 1024x600 custom resolution.
• acpi reported the correct battery status

unfortunately i had no more time to play with it, so i did not check how suspend, 3d acceleration, ethernet card and webcam works.

in short, i think it's nice it has no major problems, but probably it's hard for non-developers to install it as long as we don't have kernel-2.6.27 in current.

Probably most mobile users know the 'acpi' command, a simple command-line utility that shows the state of the battery on a PC.

The problem is that iBooks have PMU, not ACPI support, so that problem can hardly output anything useful. I searched for an equivalent for a while, but actually couldn't find such a utility, and quite frankly, it's not a big deal to write such a one, so I stopped wasting with searching alternatives, I just wrote one.

Sample outputs:

$ acpi
     Battery 1: discharging, 92%, 04:34:17 remaining

$ acpi
     Battery 1: charging, 99%, 00:10:53 until charged

$ acpi
     Battery 1: charged, 100%

The short script (54 lines) is available here.