Update: I reported the deluge issues and added a new problem about the lack of click on tapping on the touchpad.

---

I know that installation reports and upgrade reports need to be submitted to the BTS, but I just want to point out some issues for people that might hit the same issue on upgrade from lenny to squeeze.

But before that I must say I like the new Debian site(s) look.

Issue number one: When upgrading from lenny's deluge to squeeze's deluge, the new version of the app is quite different from the prevoious version. Here are some things to take into account:

• when starting for the first time the new version it will take ages to check (and probably recalculate some checksums); make sure you don't mind the I/O activity when you start it; a torrent will not be available until this check is done
  
• the new version relies on a client-server model which is disabled if you use the "classic mode" (Edit->Preferences->Interface)
• some features available in the old version are not available in the new version (e.g.: graph for traffic and embedded search function)
• some features are availbale as modules, but there are just a few modules
• when starting the graphical interface in the new mode, don't use the "Start daemon" button, use the "Connect" button. If you start the daemon via the "Start daemon" button the "Connect" button will become "Disconnect" although the client is NOT connected. Using the "Connect" button directly solves the problem.
• There is an ugly side panel (on the left side) which, IMHO has no real function or use, except filtering in the view the active downloads or similar things
• when choosing the place to save a torrent and trying to set that place as the default location, deluge will not remember that setting
• closing now (with the daemon option) the app will close just the client, but the server/daemon will remain in the background, unless is explicitly closed (there is a dedicated menu entry)
  

Issue number 2: I seem to experience some weird glyph/graphic area reshuffling in GNOME (maybe X?) after recovering from hibernate. With a total (according to my current sloppy counting) 5 resumes, things get back to normal, but I suspect the next hibernate-resume cycle will restart the glyph reshuffling cycle.

By glyph/graphic area reshuffling I mean alterations of the shapes of the glyphs (and some areas on the background picture) in such a manner that it seems that within a set of 8/16/N (?) lines are shifted/rotated sideways with some undefined and different ammount each, but in a reproducible manner ("b" will always be doodled in the same way, no matter if is in the word "be" or if is in the word "absurd".

I'll try to provide some picture in the bug report, once I report this issue in BTS.

Update: I reported this in Debian's BTS and upstream (with screenshots, too). I am not convinced the problem is in the kernel since I tried an old kernel and saw the same issue. I suspect X is at fault.

Issue number 3: This is more like a convenience issue. In the past I was using "hibernate" with uswsusp which I understand is now broken beyond repair and replaced by pm-utils. The thing I miss in the hibernate process now is the ability to abort the hibernation process as it was possible in lenny's uswsusp by pressing the backspace key during the storing of the state on disk phase.


Issue number 4: The upgrade process was quite tedious because once I tried upgrading aptitude, python2.6 was pulled in and almost all apps ended up needing upgrading due to the chaining of necessary package upgrades.


Issue number 5: For some weird reason pulseaudio was initially installed making playback of any audio impossible (the apps wanting to emit noises would just freeze but they were TERM-inatable) and later I've seen a default null audio sink was defined for me. Killing pulseaudio and removing the ~/.pulse directory fixed the issue (but I should probably see why pulseaudio didn't work properly in the first place because I suspect the problem will reappear at the next restart - I usually use hibernate).

Issue number 6: Tapping the touchpad no longer results in a click. Maybe some packages got removed? And, no, it is the same when I remove the external mouse, so it is not because of some smart behaviour of that sort.

Otherwise I am quite satisfied with the result of the upgrade. A huge "thank you" to all people involved in the development of squeeze.

Most probably haven't noticed yet but I finished the Mono 2.10.1 debian packaging effort of the past 3 months and uploaded it to Debian/Experimental. With Mono 2.10 I had to make the biggest changes in Mono packaging since the big Mono 2.0 upload. The runtime no longer supports the 1.0 and 2.0 runtime profile, instead it now supports the 2.0 and 4.0 runtime profile. This meant I had to drop all libmono*1.0-cil packages and add libmono*4.0-cil packages. This sounds like a lot of s/1.0/4.0/ work but it actually wasn't. Mono 2.10 ships a lot of new libraries over 2.6 and I had again to decide where they should go. "Where should this $library go?" I have been playing this game for the past 7 years maintaining Mono and I finally gave up on it... What, where, when, why? I could give now a 2 hours talk of the issues behind the current packaging approach (keeping the number of library packages low) but instead I will do something else. Please, just take a look at this picture for a second: If your browser crashed, your eyes hurt or your brain simply melted, I think you have got the idea. The Big Split The cure? cli-common-dev! This is a package that contains 2 extremely important debhelper packaging tools for packaging Mono/CLI related packages called dh_makeclilibs and dh_clideps. If you don't know these, they do exact the same thing as dh_makeshlibs and dh_shlibdeps do. dh_makeclilibs generates library dependency tracking information and dh_clideps consumes that information to automatically generate the package dependencies for you. So each library of the 4.0 runtime profile has now it's own package, simple as that, the rest does cli-common-dev for me and you. "Hey, that Mono packaging bastard is polluting the Debian archive because of his laziness!" No, I am not. This packaging change not only has the advantage of simplifying the packaging and with that bringing new Mono versions faster to you but also reduces the typical install size for applications as they will only pull in the really used libraries of Mono instead of groups of them. I don't have any numbers handy right now as none of the applications are built against Mono 2.10 (yet), but when the transition starts we will get numbers. New Features There is also a new SGen flavor of Mono available called mono-runtime-sgen which is no longer using the conservative non-generational Boehm's garbage collector but SGen which is a simple generational garbage collector with promising advantages. And here some more Mono 2.8/2.10 news from /usr/share/doc/mono-runtime/NEWS.Debian.gz:

• SGen Precise Stack Scanning
• Enhanced SIMD with new methods for Vector data type conversions and swapping elements in vectors
• ASP.NET MVC 3.0 (not included, only supported)
• The C# Interactive Shell can now be used as shebang: #!/usr/bin/csharp
• .NET 4.0 runtime
• C# 4.0 compiler
• ASP.NET 4.0
• Managed Extensibility Framework (MEF)
• System.Data.Services.Client (OData)
• glib was replaced with eglib
• Removed .NET 1.1 runtime

Architecture Regressions With the initial upload of Mono 2.10.1 to Debian/Experimental the architecture world broke apart and it regressed on all Mono architectures except for i386 and amd64 There is a reason it's called experimental isn't there? In mono 2.10.1-3 I could solve all regressions except for kfreebsd-* and armel. Jo Shields fixed the remaining regressions and the world started to look good again in mono 2.10.1-4! He also took care of mono-basic, mod-mono and xsp, but mod-mono and xsp are still waiting for the translation call deadline to pass by so they can also be uploaded to Debian/Experimental. Planned Transition As mentioned above, there will be a Mono 2.10 transition needed when the packages hit Debian/Unstable. There is no ETA yet on this when it will happen as I have to coordinate this with debian-release first. But as things are not showtime ready in experimental anyhow, this will not happen too soonish. The Mono 2.10 transition plan will be covered in a following post. GIVMENOWPLX OMG, all this rumbling about Mono 2.10 and I still haven't said a word on how to obtain it, sorry about this, just do this and I will shut up now:

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get install -t experimental mono-complete

(this is the easiest way of getting only mono 2.10.1 from experimental)

I stumbled across this file whilst sorting through some old backups. It's a "sortpaper": a wallpaper designed to aid people with sorting out files on their desktops. I thought I would share it in case anybody thought the concept was interesting: The size/aspect of the picture probably make it less practically useful today than whenever I first made it.

This is old actually old news, but I suspect some people have forgotten or maybe do not understand to what extend. We decided to break overrides in 2.5.0~rc1[1], as explained in Raphael s email to d-d-a@l.d.o. As the email mentions there were two breakages the tag merges and the file prefix change. Especially the latter seem to be causing confusion (or at least pings/questions/emails for me). The long story short:

All overrides listing files with a prefix of ./ or / will not work as of 2.5.0~rc1

If you are curious as to why, please have a look at #534940. Fixing the override is simply a matter of removing the ./ or / prefix(es). If you discover a tag that still uses ./ or / as file name prefix, please file a bug (assuming someone did not beat you to it). I am not entirely sure if the FTP-masters have updated the copy of Lintian that handles auto-rejects[2], so you may have keep the old/broken override if it is for a non-fatal auto-reject tag. This is especially true for the embedded-zlib tag that were merged into embedded-library. [1] On a related note, this is why this is 2.5.0~rc1 and not 2.4.4. [2] I also do not know when they plan to do it if they have not already done so, but Tolimar has informed me that 2.5.0~rc2 is in squeeze-backports. >.>

It seems that Project Harmony has finally taken itself public. From the website:

Project Harmony is a community-centered group focused on contributor agreements for free and open source software (FOSS).

In reality, this seems to be a closed group that in no way represents the community in general and mainly acts in the interest of various corporations. Their goal is to create a bunch of templates for contracts to make participating in free software projects even more complicated than it already is. Look, we have a bunch of copyright licenses. They're not always easy to understand, and there's enough details and corner cases and interactions with the real world to make your head hurt. My head as well. (They're still easier, and more standardized, than contracts for proprietary software.) Contributing to a free software project is easy enough, in most cases. You make a patch, and if the project accepts it, yay. Your patch will be licensed the same way as all the other code. These Harmony agreements aim at making you give up your copyright to someone else, usually a corporate sponsor of the project. That's a bad thing. If the corporation owns the copyright, or you give them a license to do anything they wish with the project, they can do all sorts of evil things with it. For example, they can release it under a non-free license, or enter into complicated patent agreement with someone else that will require you to pay protection money later on, or something else. There is no end to the evil corporations invent, when given the chance. If, however, you refuse to give the corporation any ownership, or special powers, then their ability to do evil lessens, or at least you aren't helping them do that. It might be possible to use the Harmony agreements, as they are currently written, in ways that do not directly allow evil. However, why bother? By sticking to well-known, court-tested free software free software licenses, there is no need for the Harmony licenses. You get to keep the corporations honest, without having to read piles more legalese. Another way of looking at this: here's a bunch of corporations that want you to start using complicated legal documents for their benefit. Ask yourself, in what scenario is this going to be a good idea for you? Just say no to copyright assignments.

I'm participating in the MeeGo Summit FI that starts tomorrow, and I'm already in Tampere now, as you can see. The summit is at an interesting time, given that there is a huge amount of stuff happening around MeeGo while at the same time Nokia is balancing on what do both in the far future and what to do to ship the MeeGo device they've already promised. The summit is fully and overly booked for >300 attendees. There is also Finhack free software event happening alongside on Saturday at the same venue.


The company I work for, Nomovok's CEO illustrated the MeeGo situation extraordinarily well a little less than two months ago. I think it's one of the best insights you can get from anywhere in public at the moment. Now things are starting to really heat up. Of course the Big thing is the MeeGo Conference in San Francisco in the end of May, but it takes nothing away from this being the major event both in the country formerly known as NokiaLandia, and also globally given the amount of MeeGo related talent here. Nomovok is teasing people with the SteelRat - a launchpad for MeeGo tablet creation and an UX, based on latest MeeGo Core - a beta of which will be available now in Tampere and first version in San Fransisco. Meanwhile we and others are investing in also the MeeGo IVI and MeeGo TV platforms, not forgetting about the handset industry that is more visible to many tech savvy consumers.


At the same time there is a lot of exciting stuff going on in the Ubuntu project (Ubuntu 11.04 upcoming, I'm already using it and reporting bugs), together with Linaro and other ARM players. As a founder of Ubuntu Finland I'm always eager to see if I can work there also on work time, not only on free time. And regarding ARM, Nomovok is the key player in having ARM on MeeGo as well.

Then on the completely other end of spectrum, I'm eagerly waiting for the GTA04 project to have my Neo FreeRunner(s) bumped up to modern specs. At the end of the day I'm still using over 2,5 year old phone myself, since I want to run the software that is both free and completely selected (and if I want, done) by me. With GTA04, I could choose between MeeGo armv7hl port, Debian armhf port or Ubuntu as the base distribution to use my software.

It seems I'll be at the Lua workshop at Fabelier/tmplab on April 28th 2011, where I'll try to present and talk about Lua, how to use it, and why you should probably not use it. ;-)

We're heading to release candidates for phpMyAdmin 3.4.0 (probably once GSoC application/evaluation rush period is over), so the translators have less time to make the translations better. There is no new complete translation, so we still have 14 translations at 100%:

• Catalan
• Chinese (China)
• Czech
• Dutch
• English (United Kingdom)
• French
• German
• Greek
• Italian
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are still lot of translations which would need some love, for example:

• Finnish
• Norvegian
• Polish

Recently two of our prospective GSoC students started to contribute to translations, so there is great progress in Sinhala and Hindi translations. Looking forward to have these completed soon :-). You can also help make translation to your language better! If your language is missing just let me know (either in comments or by email).

Filed under: English Phpmyadmin 0 comments Flattr this!

Yes, it's that time of the year: I am blogging. I was using Jaws as my blogging tool and CMS for the past few years more or less and I am finally switching to something new. I was running a SVN snapshot of Jaws and haven't updated nor maintained that one for about 3 years. This reduced my abilility to blog a lot as I had to look after bugs and jumping through the hoops to make a post. At some point I wanted to replace Jaws with something better that fits my needs but didn't find anything. I have been keeping an eye on Joey Hess' ikiwiki for quite some time, but never felt the desire to blog something important and thus postponed solving my website mess. For those who don't know ikiwiki yet, it is a wiki compiler based on a version control system like git which generates the website when you push your commits to the git repository. The wiki uses the markdown syntax but also supports other engines. ikiwiki is written in Perl which is not my favourite language, but I have seen worse. When I wrote the Debian packaging tools for the Common Language Infrastructure, which are based on debhelper, I had to study code written by Joey Hess. Putting the syntax aside (I mean it's Perl, it can't be beautiful because of that) he does well designed and implemented software and this is the reason ikiwiki is a great candidate despite the used language. Jo Shields suggested dogfeeding myself with a .NET based blog, but ASP.NET is just junk, but with Manos de Mono I am actually considering it! Manos is written in beautiful C# without any ASP.NET close to it, but is extremely new and has no blogging or wiki engine written for it yet. I was involved in Jaws's development and I didn't want to run into the same issue again for now (more hacking the tools, less using them). So last night I finally made the decision, installed ikiwiki and made my first post with it, yay! The markdown syntax feels very naturaly to me. I usually end up searching for the syntax documentation every 2nd paragraph, but not on this one...

A brand new 0.9.4 release of Rcpp is now on CRAN and Debian. This version contains an improvement to loading and initialization of Rcpp modules, a bug fix for vectors of factors, another build issue fix as well as (per common practice with JSS) citation information for the article Rcpp: Seamless R and C++ Integration which is now Volume 40, Issue 8 in the Journal of Statistical Software (or JSS for short). The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.4   2011-04-12
    o   New R function "loadRcppModules" to load Rcpp modules automatically
        from a package. This function must be called from the .onLoad function
        and works with the "RcppModules" field of the package's DESCRIPTION file
    o   The Modules example wrapped the STL std::vector received some editing
        to disambiguate some symbols the newer compilers did not like
    o   Coercing of vectors of factors is now done with an explicit callback
        to R's "as.character()" as Rf_coerceVector no longer plays along
    o   A CITATION file for the published JSS paper has been added, and 
        references were added to Rcpp-package.Rd and the different vignettes

Thanks to CRANberries, there is also a diff to the previous release 0.9.3:

Diff between Rcpp versions 0.9.3 dated 2011-04-05 and 0.9.4 dated 2011-04-12
 Rcpp-0.9.3/Rcpp/build                                              only
 Rcpp-0.9.3/Rcpp/inst/skeleton/yada.Rd                              only
 Rcpp-0.9.3/Rcpp/inst/unitTests/testRcppModule/R/Modules.R          only
 Rcpp-0.9.3/Rcpp/inst/unitTests/testRcppModule/man/yada.Rd          only
 Rcpp-0.9.4/Rcpp/ChangeLog                                             55 
 Rcpp-0.9.4/Rcpp/DESCRIPTION                                           10 
 Rcpp-0.9.4/Rcpp/NAMESPACE                                             29 
 Rcpp-0.9.4/Rcpp/R/Rcpp.package.skeleton.R                             11 
 Rcpp-0.9.4/Rcpp/R/loadRcppModules.R                                only
 Rcpp-0.9.4/Rcpp/inst/CITATION                                      only
 Rcpp-0.9.4/Rcpp/inst/NEWS                                             17 
 Rcpp-0.9.4/Rcpp/inst/doc/Makefile                                      2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-FAQ.pdf                              binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-FAQ/Rcpp-FAQ.Rnw                       153 +-
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-extending.pdf                        binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-extending/Rcpp-extending.Rnw             2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-introduction.Rnw                       734 ++++------
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-introduction.pdf                     binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-modules.pdf                          binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-modules/Rcpp-modules.Rnw                36 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-package.pdf                          binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-package/Rcpp-package.Rnw                 4 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-quickref.pdf                         binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-quickref/Rcpp-quickref.Rnw              34 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-sugar.pdf                            binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-sugar/Rcpp-sugar.Rnw                     2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-unitTests.pdf                        binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp.bib                                     73 
 Rcpp-0.9.4/Rcpp/inst/doc/unitTests-results/Rcpp-unitTests.html        18 
 Rcpp-0.9.4/Rcpp/inst/doc/unitTests-results/Rcpp-unitTests.txt         40 
 Rcpp-0.9.4/Rcpp/inst/include/Rcpp/config.h                             2 
 Rcpp-0.9.4/Rcpp/inst/skeleton/zzz.R                                   11 
 Rcpp-0.9.4/Rcpp/inst/unitTests/runit.Module.client.package.R          27 
 Rcpp-0.9.4/Rcpp/inst/unitTests/runit.Vector.R                         18 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/DESCRIPTION              2 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/NAMESPACE                3 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/R/zzz.R              only
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/src/rcpp_module.cpp      6 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/src/stdVector.cpp       18 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/tests/modules.R         21 
 Rcpp-0.9.4/Rcpp/man/Rcpp-package.Rd                                    6 
 Rcpp-0.9.4/Rcpp/man/loadRcppModules.Rd                             only
 Rcpp-0.9.4/Rcpp/src/r_cast.cpp                                         9 
 43 files changed, 647 insertions(+), 696 deletions(-)

As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

A maintenance release 0.2.3 of RProtoBuf is now on CRAN. RProtoBuf provides GNU R bindings for the Google Protobuf data encoding library used and released by Google. The NEWS file entry follows below:

0.2.3   2011-04-12
   o    Protect UINT64 and INT64 with '#ifdef RCPP_HAS_LONG_LONG' which
        itself is valid with either g++ <= 4.4, or newer versions if the 
        -std=c++0x is used
    o   The documentation Makefile now uses the $R_HOME environment variable
    o   The documentation Makefile no longer calls clean in the all target

And courtesy of CRANberries, here is the diff to the previous release 0.2.2:

Diff between RProtoBuf versions 0.2.2 dated 2011-01-12 and 0.2.3 dated 2011-04-13
 RProtoBuf-0.2.2/RProtoBuf/inst/doc/RProtoBuf-quickref.Rnw                      only
 RProtoBuf-0.2.3/RProtoBuf/ChangeLog                                               23 
 RProtoBuf-0.2.3/RProtoBuf/DESCRIPTION                                              8 
 RProtoBuf-0.2.3/RProtoBuf/R/with.R                                                12 
 RProtoBuf-0.2.3/RProtoBuf/cleanup                                                  3 
 RProtoBuf-0.2.3/RProtoBuf/inst/NEWS                                               10 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/Makefile                                       42 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf-quickref.pdf                      binary
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf-unitTests.pdf                     binary
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf.pdf                                1267 +++++-----
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/unitTests-results/RProtoBuf-unitTests.html     20 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/unitTests-results/RProtoBuf-unitTests.txt      14 
 RProtoBuf-0.2.3/RProtoBuf/src/extractors.cpp                                      44 
 RProtoBuf-0.2.3/RProtoBuf/src/mutators.cpp                                        55 
 RProtoBuf-0.2.3/RProtoBuf/src/wrapper_FieldDescriptor.cpp                         24 
 15 files changed, 819 insertions(+), 703 deletions(-)

As always, there is more information at the RProtoBuf page which has a draft package vignette, a 'quick' overview vignette and a unit test summary vignette. Questions, comments etc should go to the rprotobuf mailing list off the RProtoBuf page at R-Forge.

As I got some e-mails about this: if you're on amd64 and Wine complains that it couldn't find a 3D acceleration card, then this is no bug in my wine-unstable packages but #614805. The short-term workaround for you is to use LIBGL_DRIVERS_PATH=/usr/lib32/dri. You can either put it in front of every Wine invocation or you can export the variable in a specific shell session (don't export it globally), in which you'll run Wine or other programs needing the 32 bit libraries. #614805 should be fixed automatically by the next ia32-libs upload, if it contains a version of Mesa containing Git commit cdd1912f.

I've been running at capacity for a while now, and something went "snap" recently, so I decided to take a few days off to clear my head a bit. One of the things that came to mind is that I have too many 'side project' things. I have had lots of fun (and a few flame wars) over the years with LangPop.com but I decided that it's another thing that should probably go, in order to simplify my life some. It's a fairly popular site amongst programmers, as I think it's the best of the bunch in terms of guaging an admittedly tricky subject like language popularity, but there's lots of room to add to it. I've got various ideas for whoever ends up buying it! About money: it doesn't earn a lot. Programmers, I think, are fairly blind to advertisements. In the right hands I think it could do better, but most likely, it would work best as a bit of branding/advertising for your own business, much as TIOBE's index has spread their name far and wide. For the time being, I'll accept private bids, and depending on how well that does or doesn't go, may consider using something like Flippa.com later. Write me at davidw@dedasys.com if you're interested. I'd be happy to share some numbers and information with you. Perhaps I'll update this posting with them too. What you get: everything! Historicaly data, code, scripts to manage it, the domain. It could use some cleaning up and love, but it does get the job done. Running it just takes a few minutes a month, so I could hold on to it with no trouble, but I've decided that I want one less thing to think about. Update: Some Numbers In the last year, according to Google Analytics, the site had: 174,645 visits. In the last month, it had 17,047 visits. Revenue? Think of it as zero and you won't be too far off. You would have to rework things significantly to make money from ads on it, I think. Hosting costs? Not sure, particularly, it's on my Linode. It utilizes Ruby on Rails, but creates static HTML pages, so it's fairly cheap.

My brother was so kind to improve the looks of the Pornyness Calculator which I recently presented here a small web application that tells you how porny a given word is, by comparing the filtered and the non-filtered Google Image search results. The new look is slightly unsuitable for work, so the plain old version is still available.

This went out to d-d-a a couple of days ago already but I figured that this might be of interest here too: The fourth Debian Groupware Meeting was held in the LinuxHotel, Essen, Germany. This is a short summary of what happened during the weekend:

• We pushed new versions of icedove and iceowl to unstable fixing several issues with gnome-shell in the later. Unstable now ships packages based on Thunderbird's current 3.1 branch.
• The iceowl-l10n language package got resurrected (currently sitting in NEW) providing translations for iceowl-extension and (in a yet incomplete way) for iceowl. (Update: it's already in unstable now)
• We've done Citadel ice dove,owl interop testing and bug fixing.
• Work was done on Citadel's event driven SMTP client and IPv6 compatibility
• The z-push package got updated to 1.5.1. The patent restrictions are resolved now and we're closer to resolving the trademark issues. So hopefully an upload to main can happen real soon now.
• SOGo packaging made nice progress. Remaining issues involve linking against GNUTLS to resolve the OpenSSL GPL license incompatibility, and handling of the embedded copies of JavaScript libraries.
• We updated the groupware overview page.
• We were invited by the FrOSCon organizers to join their barbecue. Many thanks for that!

As a followup action to my recent Talk about PyGI I now re-used my notes to provide some real wiki documentation. It would be great if you could add package name info for Fedora/SUSE/etc., and perhaps add more example links for porting different kinds of software! Please also let me know if you have suggestions how to improve the structure of the page.

Today I uploaded bash-completion 1:1.3-2 to the experimental branch of Debian. This package uses dpkg triggers to achieve an overdue goal: speedup shell loading by not even looking into completions for unavailable commands. The mechanism is simple: a trigger is activated when a package installs something in one of the usual $PATH directories, and it creates symlinks for the appropriate completions. This upload also features a change in the layout: completions were moved out of /etc/, so you won't be annoyed anymore during upgrades (and, let's say it, they shouldn't have been there since the beginning). However /etc/bash_completion.d/ is still around for compatibility reasons. If you want to enable a completion, just symlink it there from /usr/share/bash-completion/completions/. If there are enough requests, I might do a simple compenable/compdisable script to create them. I'd appreciate if adventurous people could test it, and report bugs (if any, hopefully). And don't be scared by the tons of messages about removed conffiles Please beware that the "detection mechanism" of appropriate completions is not entirely foolproof: it might need some hacking upstream (adding meta-headers to completion files?), so I'll try to improve it in future.

R 2.13.0 will be released tomorrow. It contains a new package by R Core member Luke Tierney: compiler. What a simple and straightforward name, and something that Luke has been working on for several years. The NEWS file says

    o Package compiler is now provided as a standard package.  See
      ?compiler::compile for information on how to use the compiler.
      This package implements a byte code compiler for R: by default
      the compiler is not used in this release.  See the 'R
      Installation and Administration Manual' for how to compile the
      base and recommended packages.

so the compiler is not yet used for R's own base and recommended packages. While working on my slides for the upcoming Rcpp workshop preceding R/Finance 2011, I thought of a nice test example to illustrate the compiler. Last summer and fall, Radford Neal had sent a very nice, long and detailed list of possible patches for R performance improvements to the development list. Some patches were integrated and some more discussion ensued. One strand was on the difference in parsing between normal parens and curly braces. In isolation, these seem too large, but (as I recall) this is due some things 'deep down' in the parser. However, some folks really harped on this topic. And it just doesn't die as a post from last week demonstrated once more. Last year, Christian Robert had whittled it down to a set of functions, and I made a somewhat sarcastic post argueing that I'd rather use Rcpp to get 80-fold speed increase than spend my time argueing over ten percent changes in code that could be made faster so easily. So let us now examine what the compiler package can do for us. The starting point is the same as last year: five variants of computing 1/(1+x) for a scalar x inside an explicit for loop. Real code would never do it this way as vectorisation comes to the rescue. But for (Christian's) argument's sake, it is useful to highlight differences in the parser. We once again use the nice rbenchmark package to run, time and summarise alternatives:

> ## cf http://dirk.eddelbuettel.com/blog/2010/09/07#straight_curly_or_compiled
> f <- function(n, x=1) for (i in 1:n) x=1/(1+x)
> g <- function(n, x=1) for (i in 1:n) x=(1/(1+x))
> h <- function(n, x=1) for (i in 1:n) x=(1+x)^(-1)
> j <- function(n, x=1) for (i in 1:n) x= 1/ 1+x 
> k <- function(n, x=1) for (i in 1:n) x=1/ 1+x 
> ## now load some tools
> library(rbenchmark)
> ## now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
     test replications elapsed relative
5 k(N, 1)           10   9.764  1.00000
1 f(N, 1)           10   9.998  1.02397
4 j(N, 1)           10  11.019  1.12853
2 g(N, 1)           10  11.822  1.21077
3 h(N, 1)           10  14.560  1.49119

This replicates Christian's result. We find that function k() is the fastest using curlies, and that explicit exponentiation in function h() is the slowest with a relative penalty of 49%, or an absolute difference of almost five seconds between the 9.7 for the winner and 14.6 for the worst variant. On the other hand, function f(), the normal way of writing things, does pretty well. So what happens when we throw the compiler into the mix? Let's first create compiled variants using the new cmpfun() function and then try again:

> ## R 2.13.0 brings this toy
> library(compiler)
> lf <- cmpfun(f)
> lg <- cmpfun(g)
> lh <- cmpfun(h)
> lj <- cmpfun(j)
> lk <- cmpfun(k)
> # now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
9  lj(N, 1)           10   2.971  1.00000
10 lk(N, 1)           10   2.980  1.00303
6  lf(N, 1)           10   2.998  1.00909
7  lg(N, 1)           10   3.007  1.01212
8  lh(N, 1)           10   4.024  1.35443
1   f(N, 1)           10   9.479  3.19051
5   k(N, 1)           10   9.526  3.20633
4   j(N, 1)           10  10.775  3.62673
2   g(N, 1)           10  11.299  3.80310
3   h(N, 1)           10  14.049  4.72871

Now things have gotten interesting and substantially faster, for very little cost. Usage is straightforward: take your function and compile it, and reap more than a threefold speed gain. Not bad at all. Also of note, the difference between the different expressions essentially vanishes. The explicit exponentiation is still the loser, but there may be an additional explicit function call involved. So we do see the new compiler as a potentially very useful addition. I am sure more folks will jump on this and run more tests to find clearer corner cases. To finish, we have to of course once more go back to Rcpp for some <emph>real</emph> gains, and some comparison between compiled and byte code compiled code.

> ## now with Rcpp and C++
> library(inline)
> ## and define our version in C++
> src <- 'int n = as<int>(ns);
+         double x = as<double>(xs);
+         for (int i=0; i<n; i++) x=1/(1+x);
+         return wrap(x); '
> l <- cxxfunction(signature(ns="integer",
+                            xs="numeric"),
+                  body=src, plugin="Rcpp")
> ## now run the benchmark again
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           l(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
6   l(N, 1)           10   0.120   1.0000
11 lk(N, 1)           10   2.961  24.6750
7  lf(N, 1)           10   3.128  26.0667
8  lg(N, 1)           10   3.140  26.1667
10 lj(N, 1)           10   3.161  26.3417
9  lh(N, 1)           10   4.212  35.1000
5   k(N, 1)           10   9.500  79.1667
1   f(N, 1)           10   9.621  80.1750
4   j(N, 1)           10  10.868  90.5667
2   g(N, 1)           10  11.409  95.0750
3   h(N, 1)           10  14.077 117.3083

Rcpp still shoots the lights out by a factor of 80 (or even almost 120 to the worst manual implementation) relative to interpreted code. Relative to the compiled byte code, the speed difference is about 25-fold. Now, these are of course entirely unrealistic code examples that are in no way, shape or form representative of real R work. Effective speed gains will be smaller for both the (pretty exciting new) compiler package and also for our C++ integration package Rcpp. Before I close, two more public service announcements. First, if you use Ubuntu see this post by Michael on r-sig-debian announcing his implementation of a suggestion of mine: we now have R alpha/beta/rc builds via his Launchpad PPA. Last Friday, I had the current R-rc snapshot of R 2.13.0 on my Ubuntu box only about six hours after I (as Debian maintainer for R) uploaded the underlying new R-rc package build to Debian unstable. This will be nice for testing of upcoming releases. Second, as I mentioned, the Rcpp workshop on April 28 preceding R/Finance 2011 on April 29 and 30 still has a few slots available, as has the conference itself.

All my notebooks till today have been ThinkPads from the T series, sadly Lenovo decided (or, maybe, were persuaded) to go with nVidia GPUs for their current designs (T5xx). That's sad, because nVidia doesn't cooperate with the FLOSS world. I still wanted a ThinkPad with up-to-date parts. That left me with the Edge series, which is designed to be the bridge between consumer and business models. After some searching I settled on the NVLJ6GE model (the last two letters just indicate, that this is the "German" variant). The key specs are Intel Core i5-480M, 4096 MB RAM, AMD Mobility Radeon HD 5145, Intel WLAN module and a non-glare display. Now to the part about running and installing Debian testing on this. Judging from the hardware I was pretty sure, that getting all hardware (i.e. all hardware I'd be using; e.g. I'm not using WiMax or the integrated web cam so far, which means I've dectivated them in the BIOS) up and running. and I'm happy to report, that this is true. The installation was really straight forward (netinstall CD in expert mode (64 bit), running through all steps and booting, that's it). I did the install over a wired network, mainly because this is faster for me, but with an USB stick and the firmware for the Intel Centrino module a installation over the wireless interface should work too. I'm now running a slightly customized setup (e.g. my own 2.6.38.2 kernel and Mesa 7.10.2, the X from experimental), but not because some serious problems with Wheezy. So far I can recommend this ThinkPad for usage with Debian (or Linux in general), though, if you don't want a "big" GPU, you might be happier with a T or L series model. They should run somewhat longer with the default battery (Lenovo 25+ with six cells). As for the service for this line I can't say anything yet, but as it's still a ThinkPad, I hope it'll be as for the other ThinkPad series.

A long list, and you want to process its items n at a time; easy, but how to split that list in sublists of n elements (except the last one, of course)?

I looked a bit into the stdlib but it doesn't seem to exist anything I could use (oh, did I say I'm still on 2.4?) so I directed my research to Google, and found a nice recipe at ActiveState, but it has the problem it discards the last list, if it has less than n items.

Searching again, I got more lucky with this article: it's a generator of tuples from a list, splitting every n elements and optionally return the last semi-full tuple. I slightly modified it to obtain:

def group_iter(iterator, n=2):
    """ Given an iterator, it returns sub-lists made of n items
    (except the last that can have len < n)
    inspired by http://countergram.com/python-group-iterator-list-function"""
    accumulator = []
    for item in iterator:
        accumulator.append(item)
        if len(accumulator) == n: # tested as fast as separate counter
            yield accumulator
            accumulator = [] # tested faster than accumulator[:] = []
            # and tested as fast as re-using one list object
    if len(accumulator) != 0:
        yield accumulator

How would you have done it?