I own my MacBook now for a year, having been convinced by a friend. He - like me - had become tired of fiddling around with kismet and iwconfig just to make networking work at this conference, or at that meeting.

This weekend I delivered on my threat to post RDF::SKOS onto CPAN.

It is a developer version, as I still have to fathom out a proper API to deal with this.

Recently the Perl TM package has started to experience some problems with smoke testing together with some Perl releases.

As I do not have the time to track this down properly, I simply take this opportunity to remove the complete TMQL support, just to factor this into my private implementation.

Version 1.46 is on its way into CPAN.

This weekend I have commenced work on RDF::SKOS.

As most of you know, many have observed this before and larsbot has blogged about it in the past, SKOS is strikingly similar to Topic Maps, although in detail its semantics is much more limited. Interesting from a standards-political point of view.

There is yet no Perl coverage on CPAN. That has to change.

Before I submit a bug report , has anyone observed the memory usage pattern of Storable?

What Happens?

First I create a hash with 30 megs of memory:

having afterwards a process (virtual) size of ~50 MB.

Then I use Storable to freeze that:

Even though

On CPAN there are few options for reactive, event-driven programming, POE being just the most prominent one.

One hidden gem in this category is IO::Lambda. Given that it uses strongly a functional paradigm and continuations it will probably alienate most procedurally wired brains. The documentation and the examples are rich, but that itself presents a high entrance barrier.

I am now in the process to move a number of CPU intensive jobs into Gearman workers.

What Is

Unfortuntely, the required boilerplate code for that is quite crufty:

First, inside your workers you are supposed to do this:

That object is not what it appears to be. It is not a worker, but actually the handle to the job server.

Ok, here is my new MO (method of operation):

Whenever I see an awful piece of Perl (even if only a 0.01 version and especially if it is on CPAN), then I analyze it thoroughly, write the developer an email with my findings. And wait for a response.

After 3 emails without response, I rat out the module to the Perl Police. Even if it is a 0.01 version and especially if it is on CPAN.

One of the problems I have to solve for my infrastructure is to compute semantic landscapes ("SemScapes" if you were so marketing-ish inclined) with an efficient computation model.

If, for instance, a user has added a new document to the document corpus, then new feature vectors, after that new vector spaces, new convergence models, new landscapes and new maps (as images) have to be generated.

There is a dependency graph, quite similar to one you are used with tools like make.

Every now and then you come across other people's code. Perl being Perl this means that it can range from brilliantly obscure over brilliantly clear to brilliantly hillarious.

The first kind you ignore, the second kind you nod off and the encounter of the third kind you normally mock.

But not today. Today we look at addition of numbers.

This is only a bugfix release.

I am playing with the thought to remove the experimental CTM support. I had a look at the current CTM draft and simply do not understand it. Or, to be more precise, I do not understand the consequences for my implementation. Maybe I look at it in another year or so.

Instead I would love to see JTM support.

One of the many pieces in my puzzle are surfaces of topic maps. When computed these are simply PNG files. There will be different resolutions of these surface (maps), depending on how much content is involved.

As I want to integrate this into my TM::IP landscape, the best is to follow the pattern I used with TM::IP::Documents and have another Catalyst controller doing the work.

Ideally, one would expect that this works the orthodox way using MacPorts:

The first problem here is ImageMagick itself, as it depends on xorg-libX11 and that expects xproto which I do not have.

Perl XTM, the most ancient Perl implementation of Topic Maps has now retired. Or should I say: has been forcefully retired by me as I deleted it from CPAN.

I had started it 2001 when Topic Maps were young and promising, and of course I followed the only thing which was known at that time: the XTM format. Needless to say that this was not very effective.

Last year I extended my Topic Maps implementation into several directions. One was to host also documents as part of a topic map. With such a construct you can do a number of things: Have a fulltext search over the map, have text-to-map transformations, or build graphical map representations.

Now this is all good and well when working with an API and having all local on a box.