peter.makholm.net

At work I have a dual-head setup with two screens. Previously it seemed to me that you had to choose:

• Either you could set the screens up as separate entities in xorg.conf, which means separate workspaces but not being able to move windows from one screen to the other
• or you set it up as one big virtual screen with you workspace spanning both screens.

I like workspaces and use them a lot on my primary screen, but on my secondary screen I mostly want my browser and my instant messaging (IRC). Some solves this by making the windows on the secondary screen sticky, so the appears on every workspace. That doesn’t work for me – I still want my worksapces on the secondary screen, I just want the workspaces to behave separately from the workspaces on the primary screen.

For a long time I thought this impossible, so I used the first option with separate entries in my xorg.conf. I havn’t really missed moving windows from screen to screen, but Firefox is a bother. I want to be able to have Firefox windows on both screen without having to keep two profiles in sync.

Awesome3 to the rescue. I finally upgraded my window manager to awesome3 and after using xrandr to configure my screes, awesome works out of the box as I need. X only provides one display, which means that I can move windows freely around and Firefox can open windows on both screens, but Awesome automatically gives me separated workspaces on the two screens.

Of course I had do make some changes in the standard configuration for awesome. Other menus, click to focus (remove the awful.hooks.mouse_enter.register call), enforce floating layout with a proper window placement (some changes in the awful.hooks.manage.register call). View my configuration on GitHub Gists.

At this years YAPC::EU I’m giving a talk about some of the more advanced features of regular expressions.

Slides are available at http://hacking.dk/talks/yapceu2009/ – There is a pretty regexp validating dates (including February 29th) in it!

Vel hjemvendt fra min første Blå Sommer (men med 4 grønne korpslejre i bagagen) er her en række af mine indtryk:

• Madudleveringen virkede perfekt. Fedt at man bare kunne hente hvad man havde brug for. Kun en enkelt dag missede det hvor vi fik frosne kyllingefiletter klokken helv fem.
• Rigtig god ide at bruge korpstes ungdomskurser som temadage, men dobbelt ufedt når det ender i kaos.
• Det kan godt være at de nye hvide toiletvogne virker mere rigtige og lugter bedre, men længe leve de grønne godik-toiletter og rodalon-spande. De virker sgu tilforskel fra de andre.
• Første halvdel af afslutningsshowet var for meget multimedieundervisningspræsentation og for lidt show.
  • De høje lejrbål var fede
  • Lad være med at bruge store hvide flader på storskærmene når der er folk på scenen man bør kunne se, hvad med at vise hvad der sker på scenen?
  • Øv-forbudt folk er stadigvæk latterlige. Om jeg sidder på min thermorest underlag eller i min thermorest-stol gør altså ingen
    forskel.
• Personligt synes jeg at der var for meget støj mellem midnat og halv to om natten, men ingen af vores børn beklagede sig. Måske lå vi for tæt på underlejrtorvet og Paradiset.
• Jeg skal lærre at lukke min tørsæk ordentligt når jeg ligger i bivuak!

Alt i alt en rigtig god uge.

Over the years I have collected a few shell snippets that have to be sourced or called as shell functions to work correctly. Having all these function definitions in a monolithic file sourced from my .bashrc isn’t cool, so for some time I’ve had the following in my .bashrc:

for i in $HOME/.lib.sh/* ; do
    source $i
done

This has at least one obvious downside. Each time I change a function definition I have to reload the function i each and every open shell if I want a consistent work environment. Today I came up with a nifty solution. Each file in ~/.lib.sh which previously contained a function definition isedited to only contain the function body. The I add the following new function called load_functions:

FUNCTIONS=$HOME/.lib.sh

eval $(
    find $FUNCTIONS -type f | \
        while read file ; do echo function $(basename $file)\(\) { source $file\; }\; ; done
)

For each file under ~/.lib.sh a new function is automatically defined which just sources the real file. This means I can edit the files without having to reload the function in every open shell. ~/.lib.sh/load_files itself is just sourced from my .bashrc.

One of my functions wraps the wonderful Perl5 module local::lib. This module makes it easy to manage multiple sandboxes with locally installed Perl modules. It works by setting a couple of environment variables including $PERL5LIB. Instead of using local::lib directly I used a function called perllibs:

# Defaults:
PERL_LOCAL_LIB="home"
DIR=$HOME/.perl

if [ -n "$1" ]; then
    PERL_LOCAL_LIB=$1
fi

export PERL_LOCAL_LIB

case $PERL_LOCAL_LIB in
    alpha)
        DIR=$HOME/projects/alpha/ ;;
    mercury)
        DIR=$HOME/subversion/mercury/perl ;;
    tmp)
        mkdir -p /tmp/makholm/perl
        DIR=/tmp/makholm/perl ;;
esac

eval $( perl -Mlocal::lib=$DIR )

Adding new projects to this list would be a hassle if I had to reload the file in multiple shells each time.

I’m a happy vim-user and I don’t see that change any time soon. But recently I have been hacking around with Padre, an editor writen in Perl and for Perl programmers. And even though I like my non-GUI editor I think Padre has one advantage: It is quite hackable inPerl – my favourite language for hacking.

One thing I wanted to play with was debugging from my editor. It is probably posible to write in vim-perl scripts, but having easy access to all the internals without language barriers made the task of writing a debugger plugin much easier and more importantly, much more fun.

So if you have ever thought about nice features you wanted while editing Perl, then please join the Padre project and keep hacking perl while improving you tools.

I often write code like this:

    $_->store() for @objects;

and quite often it actually works. But suddenly a piece of code doing this in a loop broke with this error message: Can’t call method “store” without a package or object reference. And quite right, sometimes @objects would contain plain integers.

Unfortunately it wouldn’t be quite easy to track down the relevant change, so enter the perl debugger. Declaring a watch on ‘@objects’ isn’t useful as it triggers each time @objects enters or leaves scope. But saving a reference to @objects in $my::objects and the watching $my::objects->[0] worked.

I had reimplemented the store() method using Data::Walk for walking some structure instead of doing it by hand. And Data::Walk sets $_ to the current node. A due to the aliasing implied in the for-modifier each element in my @objects array was garbled.

Two solutions: The store() method can localize $_ by adding local $_; before using Data::Walk – this works in legacy perl interpreters. The routine looping through @objects can make $_ a lexical variable by adding my $_; before the loop – This is a new feature in Perl 5.10.

An even more robust solution would be to have Data::Walk localize $_ itself AND use a lexical $_ in code where $_ is aliased to important data. See RT #47309.

I’ve just uploaded a new version of Padre-Plugin-Debugger to CPAN. It has been stuck in github for a while as I meant to write some documentation and start calling it version 1.0. But as I haven’t written any documentation yet, it is still just a puny 0.3 version.

The major update is how the interpreter is called. Now it will actually find the modules you are using, if you add the correct directories to ‘Edit -> Preferences -> Run Paramerters’

First you have to optimize for correctness, then you can optimize for speed. At the moment I’m working on a project where I do a lot of serialization, and to ensure that I could debug the correctness I have chosen an easy readable serialization format: YAML.

But running Devel::NYTProf on my code showed that an awful lot of time was spend in the YAML code. Changing a few lines to use Storable instead showed an improvement in speed going from 1000s to 200s for my test data. This is a significant win even while developing, but of course I shouldn’t have used the old YAML-implementation to begin with.

Mentioning this to the local Perl Mongers group I got referred to a benchmark of different serialization modules by Christian Hansen (I think). I’ve updated the script and the interesting part is that JSON::XS outruns Storable on both tests.

Thank you Devel::NYTProf for showing me that 80% of my run time was spent in old pure perl serialization code.

When I wrote about exception handling in Perl I mentioned briefly that DESTROY() methods should localize $? too.

Try this script:

#!/usr/bin/perl

package Foo;

sub new {
    my $class = shift;
    open my $fh, "-|", "cat /dev/zero";
    return bless { fh => $fh }, $class;
}

sub DESTROY {
    my $self = shift;
    close $self->{fh}
}

package main;

my $foo = Foo->new();
exit 42;

You would expect it to return with status code 42, but when I run it the status code is 13. Localizing $? in the DESTROY() method gives the expected 42 status code.

The most common usage of $? is explained in the perlvar manual page:

The status returned by the last pipe close, backtick (”“”) command, successful call to wait() or waitpid(), or from the system() operator.

And the above destructor makes a ‘pipe close’ changing the value of $?. But the perlvar manual also mentions an secondary usage of $?:

Inside an “END” subroutine $? contains the value that is going to be given to “exit()”. You can modify $? in an “END” subroutine to change the exit status of your program.

But this doesn’t just holds for END block, it is true for any code run after the exit() invokation – including destructors.

And then to a mystery. Given the above Foo package it isn’t very surprising that this script have the status code 13:

use Foo;
my $foo = Foo->new();

But why does the following change make the script have the status code 0?

use Foo;
my $foo = Foo->new();
$? = 42;

Vi har alle vore egne små mærkesager. En af mine mærkesager at at jeg gerne vil være fri for reklameri min mail og i min papirspost. Desvære er holdninger ikke underlagt markedsføringslovens bestemmelser, så religiøst og politisk spam er slet ikke forbudt.

Men de politiske parier burde alligevel respektere at jeg på min dør har taget en klar tilkendegivelse af at jeg ikke ønsker reklamer. Men det kan i hvert fald Socialdemokraterne ikke finde ud af.

Derfor, stem nej til politisk spam, stem nej til Socialdemokraternes Claus Larsen-Jensen!