root@fic-gta01:~$ python hangul.py
Python 2.5.1 (OpenEmbedded build) sitecustomize.py active.

KA-WA-SEY- NA-SSU-NA-(川瀬夏菜,9WEL- 8IL-SAYNG-)NUN- IL-PON-YI- MAN-HWA-KA-I-TA-. HI-LO-SI-MA-HYEN- CHWUL-SIN-, OHYENG-. 'MI-A-YI- HAYNG-PANG-(迷子の行方)' (「LaLa DX」2000NYEN- 11WEL-HO-)U-LO- TEY-PWI-HA-YESS-TA-. TA-NEY-MWU-LA- A-LI-NA-YI- E-SI-SU-THEN-THU-LO- IL-HAN- KYENG-LYEK-I- ISS-TA-KO- HAN-TA-.

Doesn’t look like much, but this is some Python code I wrote for someone, running *on* my Neo1973. Sweet…

At one point I thought I hated programming because I was just so sick it… It turns out I don’t hate programming, I just hate programming in Java.

Russell Beattie

ㅋㅋㅋ.

The reason people are looking at Erlang is not because its beautiful syntax, great documentation, or up-to-date libraries. Trust me. It’s because the Erlang VM can run for long periods of time, scaling linearly across cores or processors filling the same niche that Java does right now on the server.

This is less ㅋㅋㅋish. First off, why should I trust Russ on this? Is he Joe Armstrong? Kenneth Lundin? Robert Virding? Or the hordes of contributors on the Erlang mailing list? Nope. He is welcome to his opinion about Erlang’s syntax, but as a recovering Java programmer, what can you expect? The documentation is great, and the community vibrant and knowledgeable. Erlang’s faults are more with the lack of things that’d make it a great all-purpose language, like string manipulations, graphic libraries, and good GUI tools.

I have been cooperating on and off with the good people from Dot.Tunes, based in Australia. I have coded bits of the application, notably the iTunes Library XML file import engine. Back when they integrated my engine, D-T saw huge improvements while importing the XML database, especially with large files. If memory serves, the previous import engine stalled on some files. With the first two or three version of my code, large files took some time to import, but at least D-T didn’t fail. When I mean large, I mean real large. Like 50,000 record-large. 35MB+ of XML to digest and convert to sqlite. Gulp.

50K records took, give or take, 20 minutes. Note the use of past tense. Took. Now, it takes 3 minutes. Yessir. On the same machine. But to achieve that I had to break out the big guns. The real big ‘uns. I had been playing for a while with the idea of writing some iTunes/mp3/etc related code in Erlang and possibly Yaws. So one of the things I started writing is a new engine for the iTunes Library XML format, using message passing, concurrency and gazillions of lightweight threads.

The result is astounding. 2,000 records take 2 seconds on my MacBook, and/or a late-model PowerMac G5. 50,000 records take three minutes on that same PowerMac G5 – I don’t have yet the file to make the tests, and I am quite curious to see how the MacBook will fare. To be fair, there’s extra overhead then to inject the .sql file into an sqlite database, but it’s minimal. The only problem is that we’ll need to ship CEAN, a stand-alone version of Erlang. That adds +/-12MB to the package, but I think it’s well worth it.

We’re still in the testing stages, and Jeff over at D-T will certainly make announcements when we’re ready, but I am already quite excited by the progress we’ve made….

I have written over the last two days RB bindings for libgd, in the continous search for a replacement to the Picture object, which is missing in console apps. As long as the promised-and-long-forgotten SwordFish project won’t be released, there’ll be little need, I think, or more accurately little clamoring for a Picture object – but once people start writing web apps in RB, you bet your ass they’ll want to produce images on the fly, like everybody else…

So. GD’s one option I had been thinking about – while still thinking I could build my own. And fPic works well enough, albeit with quirks. And it covers lots of ground – including PDFs, thanks to CoreGraphics. But it’s not very portable – my attempts to make it work on Linux, sans PDF and vImage.framework, failed so far. Since gd works on all platforms, I thought I could try it out. And sure enough it was easy to write bindings to the library, with very few quirks – I am having problems with saving to wbmp format, but who cares about that format anyway?

One format that’s missing in GD is TIFF – which fPic handles very well, na na na – so I re-read fPics Tiff code [a wrapper to libtiff really] and converted that to RB. Which means I ended up writing bindings to libgd *and* libtiff, oh so much fun! It only reads TIFF files for the moment, as I haven’t worked out how to get access to the int **tpixels array from RB, in order to save as Tiff. Might have to write a small dylib to go with it – or use fPic’s very own manip.dylib!

Like in fPic, when using freetype2 to draw text, one has to pass the path to a .ttf font file. It’s not exactly user-friendly, so I am trying to find a way to provide for a better interface into that. Maybe a Font class that’ll take care of the nitty gritty work. I found a good code sample to retrieve the name of a ttf font. Could be useful…

I am adding my entry to identicon third party implementations. I followed more or less Don’s algorithm, and, using the PIL, I have now a functioning identicon lib in Python. The results are not as good as the originals, but it should give you an idea. If you perfect it, I’ll welcome back changes.

Download the source code.

identicon Python