Avian’s Blog

I was surprised to find these little pieces of pixel art made with small stone tiles all over Provence. In fact there were so many that it stopped being fun looking for them.

I counted 10 in Avignon alone, positioned from old stone arches, street corners to the old papal palace of Avignon.

Speaking of French engineering achievements, here's another one: Aiguille du Midi is an inaccessible tower of rock in the middle of snow, ice and granite. With buildings and walkways on the top. And a cable car that brings you to them from the valley below in some 15 minutes.

This is even more impressive when you get to know that the first version was built before helicopters and that the heavy steel cable was brought up on foot. You can see and feel the huge difference in height from the cable car when it rises almost vertically at the top end of the catenary.

Going to 3800 m above the sea level was an interesting experience by itself. This is most likely far the highest place on Earth I'll ever stand on. Before going on the cable car I did question the safety of making an altitude gain of 2800 m in a couple of minutes without leaving some time for the body to accommodate. Then I saw hordes of other tourists going in and coming back without any doubts in their minds.

While the experience is obviously survivable, the thin air on the top does make climbing 10 steps feel like you're going 10 floors up. It certainly makes you respect people that come this far on their own feet.

And question the sanity of bringing that many tourists there.

Traveling to France I drove under the Mont Blanc last Friday.

When you're focusing on keeping a safe distance from the car in front of you using the lines of blue LEDs as a guide, 11 kilometers don't seem that long.

Only after a day or so I realized that at the deepest point I was under 3.5 km of rocks. In a car, no less.

With all the glaciers and mountains around it it's easy to overlook what an engineering feat this tunnel is.

Video recordings of all sessions at Wikimania 2008 appeared at the Bibliotheca Alexandrina site a few days ago. Among others was also the video of my talk about the technology behind Wikitag, the in-text link generation system I developed at Zemanta.

Unfortunately the videos are only provided in form of pretty large MPEG-2 files and the site seems pretty slow. So I've uploaded my video to YouTube for more convenient viewing. It's split into three parts and a small part of the recording is missing for some reason (which may be for the best, because now you can't see my futile attempt at pitching Zemanta service to Wikipedians).

Here's the first part of it:

(If you can't see the embedded player: part 1, part 2, part 3)

I was looking at the input and output voltage history of my server's UPS the other day and I noticed this line voltage drop or around 10 volts that occurred sometime in July:

Digging some more into logs I found out that this drop coincides with an hour long black-out in the morning of 14 July. Being a bit suspicious about the quality of the voltmeter built into a cheap UPS I also checked the current UPS input voltage reading against a multimeter and they matched to within 1 V.

It looks like this is still well within the allowed limits though. According to my electrical engineering handbook Slovenian distribution network complies with IEC 60038 standard, which permits tolerances of +6% and -10% from the nominal 230 V. So as long as the there is more than around 200 V in the sockets, I can't complain.

Still it's interesting why this happened. I find it hard to believe that such a consistent drop would be caused by a large load being connected to the network. This is a residential area and people don't tend to run large machinery in their basements. The time of the blackout (from 11 to 12 am) suggests that it was because of planned maintenance (they don't usually tell you about those).

It's possible that the ratio of the local transformer got changed for some reason. Someone closer to it could have complained that they're receiving voltage that is too high. Or perhaps the cause is somewhere further upstream. Maybe a transmission line is out somewhere and they are providing power to our neighborhood through some new route that is has a higher load.

If you think Python readline() function works like the C fgets(), you're in for a nasty surprise the first time you'll be using it to read line-oriented files containing Unicode text (like FreeBase data dumps for example).

Check this example:

import codecs

one_line = u"Hello\u2028world!\n"
print one_line

f = codecs.open("tmp", "w", "utf-8")
f.write(one_line)
f.close()

f = codecs.open("tmp", "r", "utf-8")
for line in f:
        # How many lines are read here?
        print line
f.close()

The loop at the end prints out two lines: one with "Hello", and other with "world!". Of course, once you look into it the reason for this behavior becomes obvious. Unicode character 2028 is a line separator and readline() seems to be smart enough to know this.

This is my first time that I encountered a function that reads a line from a file and has intimate knowledge of Unicode. Since most other such functions only know "\n" (or "\r" or "\r\n" on line-ending challenged systems) it would be nice if this oddity would at least be mentioned in Python documentation.

On the other hand, maybe it's time to put Tab Separated Values file format to rest and bravely step into the bright Unicode-encoded XML-formatted future?

Russell Coker gives some good reasons why you want to avoid using single character names for variables in your code.

I also occasionally find myself searching for uses of a variable i, only to find that half of the source code matches. A simple regular expression like \Wi\W usually works fine for me. But that already requires three times as many key presses as a fast / i search in vi.

The policy I try to stick to is to use single letter names only for loops that have an obvious purpose and are no longer than say ten lines or so. This usually removes the need to search for such variable names. Any variable that lives longer than that should have a descriptive name anyway. I'm pretty much against using index or similar generalized, verbose names for a simple loop counter. They don't tell you a lot more about the meaning than a single letter name and they make code harder to read. If it's a long loop or it's not obvious what it counts, then you should give it a proper name like pixel_cnt or something similar.

Russell also mentions that the most common loop counter names start with i because of the way variable types worked in FORTRAN. Interesting, because I usually start with n. I got used to that when I learned programming on Sinclair Spectrum. There the next BASIC keyword was entered by pressing the letter n. So n was most convenient as a for loop variable, because you could close the loop simply by hitting n twice. In nested loops letters near n had the priority, starting with m, b and so on.

This is old news (dated June 2006), but I just stumbled upon it and it may be interesting to some Skype users I know.

Vanilla Skype is a title of a talk given by Fabrice Desclaux and Kostya Kortchinsky at RECON 2006. You can get slides from the net (part 1, part 2) and they tell a pretty fascinating story about how far Skype will got to prevent you from messing with their software and their P2P network.

With the recent talks of backdoors in this particular piece of software, I can't help but think that with all that obfuscation and protection against reverse engineering they must have something to hide.

Last week I uploaded my first contribution to CPAN, the Comprehensive Perl Archive Network: Net::Zemanta, an object oriented Perl binding for Zemanta services.

This means that you can now start experimenting with Zemanta in your language of choice after a simple shell one-liner like this:

$ perl -MCPAN -e "install Net::Zemanta::Suggest"

Before operating the unit carefully read the user's manual and keep it for future reference:

$ perldoc Net::Zemanta::Suggest

For the impatient, here is an example that shows how easy it is to get a list of related articles for some text:

use Net::Zemanta::Suggest;

my $zemanta = Net::Zemanta::Suggest->new(
		APIKEY => 'your-API-key' 
	);

my $suggestions = $zemanta->suggest(
		"Cozy lummox gives smart squid who asks for job pen."
	);

for $article (@{$suggestions->{articles}}) { 
	print $article->{title}, "(", $article->{url}, ")\n";
}

Surprisingly uploading this module didn't involve much dark magic at all.

I would like to notify users of z80dasm, my version of a disassembler for Zilog Z80, that I've released a new version. It contains a one-line change compared to version 1.1.0 that fixes a minor bug causing labels to be sometimes created without a good reason.

In detail, it was a typo in an if statement that was inherited from dz80, on which z80dasm is based. It caused every instruction that started with 0xDD or 0xFD to be recognized as a LD (nn),IX (only as far as label generation was concerned - actual instruction was decoded correctly). This created some random labels if bytes following the instruction decoded to a valid address within the binary block you were disassembling.

So, unless you're reverse engineering large chunks of code where extra labels may get in your way, there's no real hurry to upgrade.

Source and Debian packages are at the usual place.