these days I was encountering a problem, when I was going through 2 veeeeeeery big hashes to find out which of them have similar keys (not really same keys, just slightly different). I thought, that the easiest way would be to go through both hashes in 2 for-loops and check them out one by one. Unfortunately, this approach took about 2 minutes to go through (2 minutes seem like an eternity if you are staring at a terminal).

My first approach looked like this:

for my $a (keys %b) {
    for my $c (keys %d) {
        if ($c =~ m/^$a.+$/) {
            print "bingo!\n";
        }
    }
}

You see, the keys in the second hash (%d) always look like the keys in the first hash (%b) with the only difference, that they contain the key plus some other stuff. So if $a looks like “abc”, $c looks like “abc123″. Now, if you have 2 hashes with – let’s say – 5000 keys and values, you can easily calculate how long this could take…. (5000 x 5000 = 25.000.000) … as I already said: it takes FOREVER!

Now, after some searching around I found a very nice solution on the Linux and Unix Forums from a guy called “pludi”. He recommended a grep-approach. Here is now my remodelled version:

for my $a (keys %b) {
    for my $c (grep { /^$a.+$/ } keys %d) {
        print "bingo!\n";
    }
}

Voila. Instead of taking 2 minutes, the loop now runs through in 15 seconds. I love Perl

You can get it on their website.

I guess I will write some programs soon to see what’s possible. The only thing that sucks on the milestone is, that the dollar sign is only available via touchpad. That’s REALLY annoying. :/

you call the script like this:

$ ./oebbquery "Innsbruck Hbf" "Wörgl Hbf"
Connections from Innsbruck Hbf to Wörgl Hbf:
 
Departure  Arrival  Duration  Changes  Train(s)
15:13      15:59     0:46     0        rex 
15:28      16:24     0:56     0        s 
15:54      16:28     0:34     0        oec

Please be sure to use the correct names of the stations. for example: “wörgl” doesn’t work, but “Wörgl Hbf” works. You have to use the names provided by the oebb-website.

the output looks now like this:

have fun!

I just spent 2 hours on a little project here. With this little script written in Perl by using LWP you now have the possibility to view train-connections from A to B in your terminal. You can then use this output to process it with conky or just any application you want. Here is a screenshot:

As you can see, i used it to display it with conky by executing it once every 600 seconds.

As soon as I have cleaned up the code to make it easier to read, you can download it here.

example: bash

#!/bin/bash
# usage text
usage() {
    echo ""
    echo "This is the usage of blabla"
    echo "Parameters:"
    echo " -f ... Parameter 1 blabla"
    echo " -g ... Parameter 2 blablubb"
    echo ""
}

Well, here you can see that there are a lot of echo-calls (often there are MUCH more … :-/). Now, we learn about an exciting new way to shorten this. We use “cat”:

example: bash better

#!/bin/bash
# usage text
usage() {
    cat << EOUSAGE
 
This is the usage of blabla
Parameters:
 -f ... Parameter 1 blabla
 -g ... Parameter 2 blablubb
 
EOUSAGE
}

So, instead of using tons of calls, just do it with one “cat”. Maybe it seems a bit pedantic of me, but this example makes more sense if you encounter more text (like HTML-output) which is printed out to a document with thousands of “echo”-s.

You can do this in Perl similarly:

#!/usr/bin/perl
# usage text
sub usage() {
    print <<"EOUSAGE";
 
This is the usage of blabla
Parameters:
 -f ... Parameter 1 blabla
 -g ... Parameter 2 blablubb
 
EOUSAGE
}

or in Ruby:

#!/usr/bin/ruby
# usage text
def usage
    print <<EOUSAGE
 
    This is the usage of blabla
    Parameters:
     -f ... Parameter 1 blabla
     -g ... Parameter 2 blablubb
 
EOUSAGE
end

I guess you can do something like that or similarly in nearly every language. So PLEASE, if you have much text to display in your scripts, use Here-Documents.

just wanted to give you a small update about how things are going with the current kernel (2.6.31.1 so far) on the 901 model from Asus.

Graphics:
The intel chipset ( Intel Corporation Mobile 945GME Express Integrated Graphics Controller ) works very well and even KMS works like expected. There were some minor issues that required to build a initial ramdisk in the past, but now that’s not necessary anymore. I don’t know if that’s because of a bugfix or just some lucky configuration of my kernel.

Wireless:
WiFi works with the rt2860 module from /staging.

Bluetooth:
I managed to use my cell phone as a modem device. It wasn’t very difficult. I’ll write a small article soon how to get this done. wvdial and rfcomm do the dirty work anyway …

I also bought a very nice little IBM thinkpad some days ago which I am currently tweaking to fit my needs. Screenshots will follow. Here is one from my eeePC:

Here are the steps for 2.6.31:

# create initrd
mkinitrd -c -k 2.6.31 -m intel-agp
OK: /lib/modules/2.6.31/kernel/drivers/char/agp/agpgart.ko added.
OK: /lib/modules/2.6.31/kernel/drivers/char/agp/intel-agp.ko added.
3224 blocks
# this now created a file named initrd.gz under /boot

Next, you have to include this line to you lilo.conf, under your “root = blabla” line:
initrd = /boot/initrd.gz

and run lilo to update. You have to comment out the “vga = xxx” line too by the way.

I hope this helps some of you. Enjoy!

Config for kernel 2.6.31:

Device Drivers --->
    Graphics Support --->
        Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->
            <*> Intel 830M, 845G, 852GM, 855GM, 856G
            [*]    Enable modesetting on intel by default

Here is the link to the website:
calcurse

I’m using it as my primary calendar application to get an overview of my daily tasks and events.

Here a screenshot of me entering my university lessons :

entering stuff in calcurse

I recently found out how to make your MySQL-Service listen to the entire world instead of working explicitly with the socket-connection.

At first I took a look into the configuration-file, which is /etc/my.cnf in my case and found out, that it should already work. But it didn’t. After some searching I found out that the start script /etc/rc.d/rc.mysqld contained the following line:

SKIP="--skip-networking"

After commenting out that line and restarting the daemon everything worked as expected and the daemon listens at port 3306. I hope that the next guy trying to configure MySQL doesn’t have to search for a solution anymore now.