Zero_Dogg’s blog

Day Planner 0.10 was released on the 25th of March! This release is, imho, a great step forward from 0.9. It fixes various minor bugs, cleans up parts of the UI, handles strange or broken iCalendar files better, enforces UTF-8 encoding on the calendar and adds a plugin system.

The largest new feature is the plugin system. Day Planner now comes with support for plugins, complete with a simple file format that allows users to easily install third party plugins. Its purpose is of course to make it easy for other people to alter the behaviour of Day Planner, or add features to it easily, without having to resort to patching the app itself, but also to make it easier for me to add optional features that perhaps not everyone wants (for instance, 0.10 comes with a tray icon plugin. It is disabled by default, but those that want to use it can do so quite easily). The API is simple, and somewhat inspired by the Gtk2-perl API, to make it feel somewhat familiar for people already used to signal-based programming.

The tarball comes with an example plugin, plugins/HelloWorld.pm that is well commented and explains how to do some of the basic things like hooking into signals, displaying simple dialog boxes and adding events to the calendar. The API itself is documented in DP::CoreModules::Plugin (access the documentation by running perldoc modules/DP-CoreModules/lib/DP/CoreModules/Plugin.pm from the base directory of the Day Planner tarball or git repo).

If you want to write a plugin, and need some help or pointers, feel free to join the Day Planner irc channel, #dayplanner on irc.freenode.net and I’ll be glad to help.

Git

As mentioned earlier, Day Planner is now using git instead of subversion. After I learned git I now greatly prefer it over subversion, and have thus moved all of my projects to it. Information on how to use the Day Planner git repo can be found at http://www.day-planner.org/index.php/development/git:

Last year, the 21st of December I had to send in my GF’s cellphone for repairs (bought online), incredibly enough the repairs went smoothly and fast, and on the 29th of December it was shipped back to us, using the Norwegian postal system. Little did we know that it wanted to go on a round trip around the southern part of Norway. This is its story.

29.12.08 - Sent from Drammen, Norway
29.12.08 - Arrived at a terminal in Oslo
30.12.08 - Arrived at a terminal in Stavanger
31.12.08 - Arrived at a terminal in Haugesund
02.01.09 - Beep! Still in Haugesund, and the post office realizes that we have moved and that we have bought a service to forward our mail to our new address
02.01.09 - Arrived in Stavanger. Gah! That’s the wrong way!
05.01.09 - Registered at a terminal in Bergen. Yay! It’s getting close!
06.01.09 - Arrived at our local post office in Bergen. Hurray.

…However, they never sent us any packing slip, and we didn’t have the tracking number so we didn’t know.

16.01.09 - Beep! Still in Bergen, and the post office realizes…something and decides to ship it somewhere else.
16.01.09 - Registered at a terminal in Bergen
19.01.09 - Registered at a terminal in Stavanger?!
20.01.09 - Arrived at a post office in Haugesund…again
31.01.09 - Beep! Still in Haugesund, and the post office realizes, once again that we have moved and that we STILL have purchased the service to forward it to our new address.
02.02.09 - Registered at a terminal in Stavanger…yet again
03.02.09 - Registered at a terminal in Bergen
04.02.09 - Arrived at our local post office in Bergen…again. Hurray!

…But they STILL hasn’t sent us any packing slip stating that the package has arrived and that we need to pick it up.
We contact the retailer, which contacts the repair shop, which provides the information that it is here! At our local post office!
So we go to our local post office, I present my ID and that there’s a package for me, aaand… they can’t find it. We go home and yet again mail the retailer, which contacts the repair shop which then gets hold of the tracking number.
Armed with this brand new information, we head to the post office again…

18.02.09 - We get the package.

And no, they still haven’t provided a packing slip.

This is true Norwegian efficiency.

I’ve just written my first blog post for Linux Game Publishing on the new LGP blog.

The post is about the LGP community. You can head over to the LGP blog to read it.

I’ve got some plans for SWEC in the future. One of its primary limitations at the time is that it can’t really do advanced tests using things like POST or specific pattern matching. So I’m planning a simple command-based file format where you can define advanced checks for sites, to compliment the already existing fully-automated checks.

The basic syntax will be something like this (any input is welcome):

URL http://...
GET
MATCH /regex/ or STRING
RUN_CHECKS

RUN_MAIN


Here any URL statement defines a new check, where all previous data is dropped. Each section can have a POST or GET statement, and then any number of MATCH statements, as well as a RUN_CHECKS statement. If any MATCH statement fails (ie. the regex doesn’t match, or the result isn’t equal to STRING) then it will skip the remaining tests and skip ahead to the next URL or RUN_MAIN statement.

MATCH is obvious, it runs a test on the entire content to see if it matches a regex, or equals a string.
RUN_CHECKS would start the standard (SDF-based) SWEC checks on the returned data.
RUN_MAIN would start the main SWEC mode
[SOMETHING] MATCH would create a named match, so the content within [ ] would be the returned error if it doesn’t match, instead of something generic like “failed to match /regex/”.

Other commands I’ve thought of that I might or might not want to do include one to clean the cookiejar, so that tests can be performed on how a page acts when cookies are missing, and a way to add custom skip filters based upon for instance the URL.

THese are just random ideas and plans that I’ve got at the moment, I haven’t begone coding it yet, but it’s definetely something I’m going to do at some point. I’ll welcome any input if you have any.

I’ve been doing some web development lately, and the old question of testing has of course come up (and some might say, of course I had to roll my own solution).

I wanted a simple way to sanity check a site, to ensure that my article changes didn’t suddenly break comments on images (lagacy apps are strange beasts). So I ended up writing SWEC, the simple web error checker. It’s a basic app that goes through all links in a site (or “webapp”) as long as those are present in the HTML (ie. it doesn’t run any JS, so its use in JS/AJAX/AJAJ-heavy webapps can be somewhat limited). It parses all pages it downloads, looking for known errors and then reports those. For instance, if you run it on a site based on Catalyst (perl) and catalyst crashes with its standard backtrace, SWEC will return which page it happened on, which page referenced it and a quick line about what happened. Ie. if it’s an exception it’ll say “Exception in Catalyst controller”.

It uses a very simple file format for writing tests (which is well documented in SWEC’s manpage). It has several different types of tests, but the most common one looks something like this:
[SWEC_CATALYST_CONTROLLER_EXCEPTION]
type = regexs
check = Caught exception in.*Controller.*Request.*Catalyst
error = Exception in Catalyst controller
sortindex = 11
What’s between the brackets [ ] is the name of the test. All tests that are shiped with SWEC are prefixed with SWEC_.
The type defines which “type” of test it is. This one is “regexs” which is a ’smart’ regex, a standard perl regex that swec modifies during runtime to easier match HTML. The check is in this case a normal perl regex that is applied to the entire html document. As the type is regexs, swec will modify the regex to this during runtime: Caught(\\s+|&nbsp;|<[^>]+>)+exception(\\s+|&nbsp;|<[^>]+>)+in.*Request.*Catalyst

The error is the string that will be returned, and the sortindex is used for prioritizing tests, the lower the better (bundled tests will always be positive, so one only needs to give tests a negative index to ensure they will be run before bundled ones).

By default the bundled tests (default.sdf) and the user-specific rc file ~/.swecrc will be loaded. The user-specific one can disable bundled ones easily, and you can disable them on the command line on an individual basis.

SWEC supports sessions, where SWEC remembers previously checked URLs, and previous errors and can then either check pages that used to have errors before the others, or only report ‘new’ errors that did not exist before. This will also remember all settings that you set so you don’t have to type it every time (although it’ll allow you to do that as well). It has cookie support so it will run just fine as a logged-in user, though you probably don’t want to run it on a live database, but rather a test one, as it’ll click on any link it sees (with a few exceptions, it tries to avoid ‘logout’ and ‘delete’ links, additions to the exceptions list is welcome).

It’s GPLv3, so feel free to hack your own things into it. I’ll accept patches for the app itself, as well as new tests to be bundled. As long as they are either specific to a language, web server or framework, I’ll happily add more bundled checks (or fixes to existing ones), however I will try to avoid app-specific checks as that might just get a bit too much.

Happy hacking

The new Linux game turned out to be Sacred: Gold an action-RPG similar to Blizzard’s Diablo 2. The package includes the original Sacred, a free (official) expansion pack called Sacred Plus and the Sacred: Underworld expansion pack.

I for one can’t wait for this port to be released.

Linux Game Publishing has announced a competition where one can win the first copy of their new unnannounced game for Linux.

The winner will be the first person to guess which game it is, based upon the slowly revealing image on http://competition.linuxgamepublishing.com/.

The chance to know what new game is coming out for Linux and the chance to win the first copy of it produced. Yay :).

If you want Linux games already released, head to TuxGames. (Yes that’s my referral link ;)

Day Planner 0.9 has been released. It is available for download as a Mandriva RPM, Ubuntu deb, Debian deb, generic installer and source tarball.

The release focused primarily on fixes and cleanups. A bunch of minor bugs were fixed, and I rewrote most of the iCalendar back-end. It should be faster now and preserves files better than it used to.

This release includes a dummy maemo interface. It can currently fully display a Day Planner calendar, and has a UI quite similar to the desktop edition. However, it can not edit or add any events, and is as such not as useful as it might have been. The plan is for the maemo port to be ready for 0.11.

0.10 will (among other things) feature a new HTML exporting module (which has been in the works for quite a while), a cleaner, object-oriented version of the add/edit event windows (to simplify their use and maintainance. The current code that handles it is a bit ugly).

The major user-facing change will be the addition of a GUI for calendar subscriptions. 0.9 includes support for them (though it isn’t really announced because the feature isn’t ready), but one has to manually edit the config file.

(Re: Proprietary Webcam driver wonders).

I recently discovered a free driver for my GF’s builtin Microdia webcam. It works very nicely (better than the crappy proprietary one did when I tested the “trial”). So if you’ve got a Microdia webcam, at least the 0c45:624f one, now you can have it working properly, with good quality without paying a load of money for a one-time one-kernel one-arch license for a proprietary one.

git clone http://repo.or.cz/r/microdia.git
cd microdia
make
sudo insmod ./microdia.ko

Then just launch Cheese or your favourite webcam program and off you go.

Thanks a lot to those that took the time to develop a proper driver. If you’ve got a paypal account, I’ll donate some money for your hard work.

Update: the module is now named sn9c20x.ko, so the last line becomes sudo insmod ./sn9c20x.ko

I’ve added automatic development snapshots of Day Planner to the Day Planner homepage. There are currently three different branches (trunk, next stable, current stable) being built, in two flavours (tarball and installer). The snapshots are updated twice each day and are available at http://www.day-planner.org/index.php/download/snapshot. Feel free to take them for a spin.

An e-mail dumped into my inbox today, from the CEO of the MP3Tunes service, that I use for backing up my music collection. It stated that EMI claimed that this use was illegal and had sued MP3Tunes (this happened a while ago, I know). This isn’t even a case of so-called “piracy” that you claim is so evil, it’s me backing up my music. You’ve screwed up with all of your RIAA blunders already, one might think that you would realize that suing customers (or in this case, a company providing a useful service to your customers) is generally a bad idea.

Oh well, add me to the growing list of people boycotting you (and don’t think for a second that this is an empty statement).

Some articles on the subject: http://michaelrobertson.com/archive.php?minute_id=251, http://michaelrobertson.com/archive.php?minute_id=259, http://consumerist.com/382824/emi-says-you-cant-store-your-music-files-online and http://www.exchangemagazine.com/morningpost/2008/week13/Tuesday/032501.html. (note that I do not agree with, nor endorse all of the statements on these websites, they are provided as a source of information on the subject only).

Today is the second anniversary of the Day Planner project. So hurray for Day Planner, and here’s to all the great releases to come.

In other related news, I’ve just released a development snapshot of Day Planner 0.9.
It is available at http://www.day-planner.org/index.php/download/devsnapshot. It contains all of the developed features for 0.9 (including the unfinished maemo port), but is not yet stable enough to be labelled stable, so If you’ve got time and feel like it, give it a spin and report any bugs you find. The whole iCalendar back-end has been almost completely re-written for this version, which is why I want some additional testing before I release a stable version.

Please do not package this release or submit it to news sites, it’s just a svn snapshot.

Everyone else is doing it!

[0 zerodogg@firefly ~]$ history | awk ‘{a[$2]++}END{for(i in a){print a[i] ” ” i}}’ | sort -rn | head
279 cd
185 vim
117 ssh
75 screen
74 svn
66 wget
64 ls
60 perldoc
59 rm
58 cget

Today (6th of April) is my birthday, and my GF, being rather artistic, decided to go a different route when it came to the gift certificates she gave me.

This one is for TuxGames (well, this was /really/ from the cat (Junior) and the hamster (Tuxine)):

This one was for Aetolian credits (Aetolia being a MUD):

And the final one was for Wii points in the wii shop channel:

Got plenty of great presents (not going to list them all here, just wanted to note the cool gift certificates), its been a good day.

I’ve finally taken the time to prepare a website for all the various programs and scripts I’ve got in use here that the world might also find some use for. The address, right now, is http://random.zerodogg.org, though once I find some more imaginative name I’ll probably move it, but for now it’s random.
Everything mentioned is either GPLv3 (most of it) or GPLv2 (some of it).

I’ll write a quick word on the various new projects, and note those that I have moved from older websites to random.

New stuff:

Audio Utils
This is just a collection of scripts I’ve had in use (and had uploaded for the world to download previoulsy, but never together nor on a proper website) that assists in various audio-related tasks. These are:
aac2ogg - a quick and dirty aac to ogg converter, using mplayer, faad and oggenc
wma2ogg - the same for wma, using mplayer and oggenc
reencode - a quick and dirty bash script that lets you re-encode an mp3 file to another bitrate. Useful for clearing up space on “mp3 players”, especially if you’re into audio-books, which can often have their bitrates drastically reduced and still be in a fairly decent quality.

GRandomWallpaper
This is a wallpaper randomizer for GNOME/Nautilus. It takes a list of wallpapers (a directory) and selects a random one. This can be done on a timer, or just once. It keeps a hitlist for how many times a wallpaper has been shown, and is more likely to pick those that have not been shown as often. It also lets you ban wallpapers, which will cause it to always ignore the wallpaper in question.

LatexB
This is a quick script that assists in building LaTeX files. It can call latex or pdflatex, automatically spawn xdvi(k) or evince after building, and detect bibtex. It’s merely a utility script so that I can do “latexb file.tex” to build the LaTeX file properly in one go (it calls latex multiple times to ensure that everything is referenced properly).

MonitorGrowth
This is a simple perl program that lets you monitor how fast a file is growing, displays information similar to that of download utilities like wget.

mussort
This program sorts your music collection. It puts them into nice directories (artist/album) and renames the files, so that everything is consistent. It can also let you delete dupes. It works on MP3, and OGG Vorbis-files.

SPGal
This is my first python project. It builds a static XHTML-gallery from a set of images. It can work as a drop-in replacement of iGal and jGal.

Old stuff, new website:

MagicPO
This is a program that helps you translate PO-files from one similar language to another. Right now it can do automatic translation of for instance Norwegian Bokmål to Norwegian Nynorsk (you only have to read through them afterwards).

PDFtoPNG
This is a quick program that lets you convert PDFs into a set of PNG files. It can also build HTML-files to go with the PNGs, for easy reading in a browser.

SLX-Dict
This is a simple command-line program that lets you look up words in the Norwegian computer translation dictionary. It’s useful if you don’t want to open firefox and search for words there all the time.

SSHMan
SSHMan is a simple ssh agent helper, along the lines of keychain. It does persistant management of ssh agents, will only ever prompt you for adding keys to the agent once, does not slow down logging into X and does not start when you’re logging in via ssh.

Okay, I gave up on the point of getting the perl bindings for gtk2 going.
It was just too much work, and would not only require getting the gtk2 bindings going, but also writing bindings for hildon, the maemo-specific stuff.

So I went to plan B, which was to reimplement a maemo-specific GUI in python that just talks to a perl back-end which takes care of all of the actual data processing. This is now well under way. A working prototype of the GUI in python is now in SVN, it can read and display calendar data, but has no edit capabilities yet. The back-end portion is just about finished, it is a mixture of code from the dayplanner perl client and the dayplanner-daemon, what’s missing there is more configuration file handling (which can’t be done yet, because I’m not quite sure what config options the maemo UI actually needs) and synchronization code.

This has helped make Day Planner even more modular. I split out some code that is useful elsewhere into a DP::CoreModules module. That module now has code that for instance handles the configuration files, parses date strings, creates config dirs, runtime module loading, summary string wrappers and localtime() wrappers. All code that can be shared (and doesn’t merit having their own module) will be put there.

I expect the maemo port to have initial editing capabilities within 1-2 weeks, depending on my workload.

It’s finally here, and I’m loving it so far :).
Tried some basic stuff, installed ssh+scp and tried ScummVM on it. All running nicely.
Now I’m about to move to the hard part, getting Day Planner actually ported to the thing.

The gtk2 perl bindings still don’t have a maemo port. I’m going to have a go at those first to see if I can get them running half-decently without too much work, if not I’ll have to look at other more dirty hacks. Though if I can get the bindings themselves running that would be much better and would make the port a lot easier to maintain. Here’s hoping!

Day Planner 0.8 was released on the 1st of January (2008).

The primary focus of this release was getting some new technology in there and cleaning up old stuff.
The daemon (or “reminder” as it is called in the user-facing UI) was rewritten from the ground up. The new one is a lot more flexible, and less error-prone than the old one. The new one can for instance notify users about events backwards in time (say you log in at 08:05 and you had a meeting had 08:00 - it’ll let you know). Along with this I’ve removed the “Day Planner commander”, which was a commandline interface that allowed one to talk directly to the daemon and issue commands. I used it mostly for debugging with the old daemon, it’s not needed at all with the new one. The notifier (the program that pops up friendly GUI dialog boxes with reminders) was also partly rewritten for the daemon change.

The other major change was the addition of DP::iCalendar::Manager. This module allows DP to have multiple DP::iCalendars (and other compatible objects) in one object, whose API is completely identical to DP::iCalendar (with the exception of a few additional methods). In 0.8 it is for instance possible to edit holiday-events. The Date::HolidayParser module now presents a DP::iCalendar-compatible interface when requested (the old API is still in there, and is still the default - that won’t change). As Date::HolidayParser (and for instance http calendar subscriptions) are essentially read-only data sources, DP::iCalendar::Manager handles this nicely. When a change request is made upon an event from a read-only source the manager copies the event over to the primary DP::iCalendar object and makes the change there. This preserves the UID and thus the changed event will show up in the UI, instead of the original one.

All DP::iCalendar calls in 0.8 go through the manager, even though the management part isn’t used much, the only two parts added to it in 0.8 are the primary user calendar and the holidays. This opens doors for what one might expect to see in 0.9. Day Planner 0.9 will. among other things, have support for subscriptions to http-calendars. The current DP SVN already has a crude implementation of this, and it appears to be working pretty well (though it is missing some essential things, like caching, at the moment).

Day Planner 0.8 is available for download as a Mandriva RPM, Ubuntu/Debian deb, generic installer and source tarball.
For the adventurous (read: people who like to not have their software in a working state all the time) there are instructions on how to get the svn version on the website.

My girlfriend has a builtin webcam on her new x86_64 laptop.
The webcam has no free drivers, but there is a proprietary one available on linux-projects.org.

Pay 10EUR and you get the driver. Okay, doesn’t sound /so/ bad. But the driver is only available for x86 ubuntu gutsy, no other arch, no other distro, no other kernel. If you want it for /your/ kernel you have to pay 100EUR. Wonderful. There’s no way I’m paying 100EUR for a proprietary webcam driver. Buying a new, working, webcam would even be cheaper! She runs x86_64 so there’s no way to get that driver working there, without paying that 100EUR. The camera is Bus 005 Device 002: ID 0c45:624f Microdia.

If someone does decide to write a free GPLd driver for it, I’ll donate some money to that person (I don’t have 100EUR to give away, but I can do at least 30-50EUR).

This again goes to show the pain of proprietary drivers. I don’t mind *paying* for drivers, but when the drivers cost more than the device did, and a device working equally well would be cheaper than buying the drivers it has gone too far. I would have easily donated money if the page said “here’s the driver, it’s GPL so do what you want, but please donate 10EUR if you can” (and I have donated to FOSS projects before).

Update, see: http://blog.zerodogg.org/2008/04/27/microdia-0c45624f-webcam-on-linux/

Yay!

I’ve been picked as one of the lucky 500 that will recieve a Nokia N810 at a heavily discounted price.

My initial plans will be to investigate ways of porting Day Planner to maemo. Because there are no Gtk2 perl bindings for Maemo at the moment, as far as I know. I’m going to have a look at how hard it would be to port the current Gtk2 perl bindings to Maemo, and if it’s rather simple I’ll just bundle them along with Day Planner., or create a package for them. They might even run with little effort, who knows (heres hoping). Even if they don’t work 100%, as long as the methods DP uses work adequately I will be able to use them. If not, well, then I’ll have to look at other options, which include writing a dumb UI in python that talks to a perl-backend.

In any case I will need to figure out how to best integrate the daemon+notifier functionality. The platform probably needs its own notifier, if it is to have such a thing at all, though I’m hoping the daemon can work without major changes.

And now I just need to wait for it to be released so I can get it.