Other than that I extended the command-line parser, so you can now say “swec example.com -s /test.html” where you would previously have had to do “swec --baseurl example.com -s /test.html“. Other than that it’s mostly a bunch of cleanups, some refactoring and a few minor bugfixes, in addition to a new test suite so the thing can be properly sanity-checked before release.

If you need to sanity check dynamic websites, give SWEC a go.

mussort is a simple command-line music sorting program. It recursively processes a directory tree, and then sorts whatever music files it finds there, renaming the files and putting them in a nice directory tree.

0.2 added a load of features designed to make mussort faster. It introduced optional caching of file tags, which has a major impact on the performance on subsequent runs on a directory tree. I optimized away an insane amount of readdir() calls that it kept doing over and over, even though nothing had actually changed since the last readdir(). It also only supported id3info and ogginfo as sources for information, which is problematic because ogginfo is very very slow at times. So in 0.2 it can use the Audio::File perl module if it is available. It provides redundancy (should Audio::File fail for an ogg file, it falls back to ogginfo, should id3info fail for an mp3 file it tries Audio::File) and a large speed increase for ogg vorbis files. It can also use id3v2 if it is available. Because of the caching however, even without Audio::File, any subsequent runs on ogg vorbis files will be a lot faster.

When it comes to actual features, the largest one is support for detection of compilation albums. It will locate an album that contains a lot of different artists and then put those into a single directory named after the album, rather than put them into separate artist/album dirs. For those that don’t want that, it is important to note that the feature is optional and must be explicitly requested (like case-insensitive sorting).

Other than that there’s a bunch of code cleanups, along with minor additions, such as selectable verbosity (–verbose, –quiet) and the option to keep all duplicate files around (–keepdupes). mussort is also now hosted on github, so if you are interested, fork the repository and let’s see what cool stuff you can come up with! Remember to prod me with a pull request so that any nice things you do get included upstream.

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 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 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.

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.

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.

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.

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!

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.

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.

Creating a deb was interesting, as I had never done that before – used to rpm packaging, though I got a lot of help by Morten Werner Olsen.

The packaging also uncovered quite a few limitations in both the default tarball and the Makefile, which should not only make the deb possible, but also improve the RPM.

I’m hoping to get Day Planner into Debian too, but I’ll have to write a proper deb for Date::HolidayParser first. Debian, like Mandriva, wants to have modules available as seperate packages, and as Date::HolidayParser isn’t *really* Day Planner-specific it makes sense distributing it seperately. The current debs has it bundled, and I might be inclined to continue to have the ones on the website bundle the module (the RPMs on the website does this, even though the package in Mandriva does not), so that there is only one package to install to get Day Planner installed.

In other (somewhat) related news, I’ve changed the URL structure on the Day Planner website. It previously used ugly looking index.php?page=foo&type=bar URLs. It now uses clean index.php/foo/bar URLs, which incidentally was rather simple to implement once I found which variables to parse and PHP functions to do it with.

If it’s been a while since you tried it, or if you haven’t tried it at all, go ahead and give it a download. It is available as a Mandriva Linux noarch RPM, generic .run installer and a source tarball, it also has only one single dependency except for perl and that is the gtk2 perl bindings, so it should run without having to install 20 dependencies.

Take the following config file:
RunMode = Inetd
AuthMode = Closed
Restricted = true

To create a simple configuration GUI for this I would write something like this:
filename is /etc/example.conf
setting RUNMODE can be (Inetd, Daemon)
setting AUTHMODE can be (Closed, Open)
option RunMode is RUNMODE with name "Run mode" and tooltip "Which mode to run in"
option AuthMode is AUTHMODE with name "Authentication mode" and tooltip "Which mode to use for authentication"
option Restricted is BOOLEAN with name "Enable restriction" and tooltip "Enable this if you want to enable restriction of user rights"

The initial filename option selects which file the config file is.
The first “setting” defines a type of entry in the config file that can be either of the value “Inetd” or “Daemon”. This would create a drop-down widget where you can select “Inetd” and “Daemon”.
The second setting defines the same for “Closed” and “Open”.
The first “option” defines that the option in the config file “RunMode” is of the type “RUNMODE” and the name of the option that is displayed in the GUI is “Run mode” and it has a tooltip saying “Which mode to run in”
The second is the same.
The third one defines that the option “Restricted” is of the predefined type “BOOLEAN” (which is predefined to be true/false, this creates a checkbox instead of a drop-down box).

Now begin your slaughtering. This is still just an idea. There is no code yet. What do you think of the concept of creating a whole configuration GUI for an app using a single file like this? I’m thinking it would be okay for daemons and such.
What do you think of the syntax? I just grabbed it out of my head today and thought it might work. I want the syntax to be simple and human-readable. The point is that you should be able to hack together a GUI for any program with a simple configuration file in a few minutes.

Flame me.

Here’s an abriged changelog:
A bug that caused the entire program to go insensitive if you clicked the edit button without having any event selected was fixed. Daemon errors are handled better. A bug where day planner would freeze if the daemon shut down while it was running was fixed. Localization was fixed. A Norwegian bokmål translation was added. The pop up dialogs is now placed on top of the main window. The notifier now gets the information from the daemon instead of getting it on the command-line, so that other users can’t see information about other users on the system.

I would still very much like any comments you might have, so please feel free to test and give feedback.

You can find a day planner RPM in cooker or on the day planner download page (along with numerous other options).

Please read the day planner TODO list before reporting issues. It’s not that long :).

You may also be interested in reading the day planner vision.

Then one day I thought about this and well, using a proprietary website to produce and manage a free software project makes…well…no sense. So then I started looking at the alternatives. I landed on Savannah. My first Savannah project was GoldenPod. Followed by the (mostly dead) GoldenBackup (no link due to no website nor release, it does have a CVS though). Then followed by the common configuration parser. Then I had my disagreements with Savannah (as some of you might remember).

Then I started looking at GNA! which I am now using for my most active project, Day planner. Now what does GNA! have to offer that Savannah doesn’t?
Well, it offers easier access to the downloads directory, I can simply rsync/scp stuff from my box to the GNA! download directory. It also has SVN which is imho MUCH better than CVS (I’ve never used Arch, so I won’t say anything about that). They also offer download/website statistics, something Savannah doesn’t. The only plus of Savannah I can find is some of their admins. I’ve spoken with a few of them and they where very nice, savannah also has an IRC channel (#savannah on freenode) which is rather nice. Though currently, I’ll take my GNA! without my Savannah if that is possible thank you very much.

CCP can be downloaded from http://ccp.nongnu.org/download.html