kafsemo.org

“His first book was about cats, it was not very good”

Hullo!

New releases and old perls

Friday, 27 January 2012 (#)

CPAN Testers lets Perl developers know how their modules are building and testing on a variety of operating systems and Perl versions. XML::Writer is a (very!) stable module, so when I got email telling me the latest release was failing on an older Perl than I’d tested with I was concerned.

The failure was with Perl 5.6.2, released November 2003. That’s an old version, but I claim to support back to 5.6.0 (March 2000). Thanks to David Golden’s maint branches in his Perl repository I could quickly build that specific version on a current Ubuntu release. (Easily mixing history from different repositories is just another great DVCS feature.)

Although XML::Writer supports Perl 5.6.0 it only tests Unicode support after v5.8.1. The new test I added for this release would therefore be skipped under an old Perl. However, I labelled the test with ‘TEST:’ rather than ‘SKIP:’, so an attempt to skip it failed. That’s easy to fix.

(Music: Distillers, “Hall of Mirrors”)

replicate in R

Wednesday, 14 December 2011 (#)

I learned a new trick in R — replicate to repeat random number generation. I also learned that it’s not necessary to understand R to use it.

This was prompted by discussion of queueing theory, with code in R (“queue“). For a simpler case, suppose we’re investigating random distributions and seeing how many sixes we get when we roll a die ten times.

Function parameters in R are passed by value. This means that, while sum(sample(1:6, 10, replace='T') == 6) will give a random number, rep(sum(sample(1:6, 10, replace='T') == 6), 10) will take a sequence of ten rolls and then repeat it ten times — not what we want:

 [1] 2 2 2 2 2 2 2 2 2 2

I’d been using this technique to make each repetition pick a new number:

> sapply(1:10, function(x){sum(sample(seq(1,6), 10, replace='T') == 6)})
 [1] 1 0 1 0 1 1 0 1 2 0

Here, for each item in the initial list, the function is evaluated. R is also lazy — the expressions used as parameters aren’t evaluated until they’re used. To demonstrate:

> sideEffect <- function(s) {print(paste("Evaluated for", s)); s;}

> f <- function(x, y) {x}
> dummy <- f(sideEffect("First"), sideEffect("Second"))
[1] "Evaluated for First"

> f <- function(x, y) {c(x,y)}
> dummy <- f(sideEffect("First"), sideEffect("Second"))
[1] "Evaluated for First"
[1] "Evaluated for Second"

Here, the first function call only uses its first argument, so the second sideEffect is never called.

Together, that doesn’t help to write a function that evaluates its argument repeatedly. However, R is also flexible enough to allow redefining the arguments before evaluating them:

> replicate
function (n, expr, simplify = "array") 
sapply(integer(n), eval.parent(substitute(function(...) expr)), 
    simplify = simplify)
<environment: namespace:base>

Now, the expr argument is evaluated once each time it’s used. So, replicate(10, sum(sample(seq(1,6), 10, replace='T') == 6)) gives me exactly what I want.

(Music: AFI, “Fall Children”)

Gnome 3 dimmer setting

Wednesday, 9 November 2011 (#)

Ubuntu’s Unity is fun and all, but I’m giving Gnome Shell (apt-get install gnome-shell) a try. A new desktop environment is a great excuse for the Gnome developers to implement a new settings framework and simplify what’s shown in the UI. I was running into the screen dimming delay, which was too quick by default.

It’s an easy change:

gsettings set org.gnome.settings-daemon.plugins.power idle-dim-time 30

Behind the scenes, gsettings uses dconf as a backend. Both clients can monitor changes. In one window, run dconf watch /. In another, gsettings monitor org.gnome.settings-daemon.plugins.power. dconf lets you monitor the whole namespace - gsettings requires a schema, which maps to a subtree in the dconf space.

Now, try that gsettings line again and see the changes monitored at both levels. Changes through the GUI will also show.

It’s great when a system either chooses the exact same defaults that I’d use or lets me tune the difference, but hitting that exact spot for everyone isn’t really an option. Like Firefox’s about:config, that balance between making the most common settings visible and the rest tweakable for people who care seems like a nice compromise.

(Music: They Might Be Giants, “2082”)
Joseph Walton <joe@kafsemo.org>