blogs.perl.org

Currently I'm located at the Dutch Eth0 Summer 2010 event, which is a camp-with-tents-and-attend-talks-and-workshops event. My younger brother who studies IT went with a bunch of classmates, and I decided to tag along.

So far it has been fun - I've done some Perl evangelising and handed out Round Tuits to random people (thanks for those Tuits, Wendy).

The overall view of Perl is the same ol' "Perl is line noise and the language hasn't seen changes in 10 years lol". While a rebuttal is easy, it's somewhat disheartening but not unexpected.

Other than that, not a bad tech festival.

I'm back from YAPC::EU::2010 in Pisa, Italy.

My 13th YAPC.

And it's still awesome.

I mostly enjoyed the lightning talks, as usual. They're funny and they're usually the bit of the conference during which I'm not busy writing slides.

Can't wait for the next one, in Riga, Lithu^WLatvia.

In the meantime, I decided to write on blogs.perl.org for a bit.

I was never much of a prolific blogger - and since I was out of action nearly a year back for an extended period, I have not managed to resume at all...

So I'm aiming to do a little perl blogging here, as opposed to on my other (mostly abandoned) blog. Hopefully this should manage to keep going for a while.

So... I've got this set of modules I've been going to opensource for more than a year now. Strangely, main obstacle is a choice of namespace.

Internally, they are called Stream::*. It is multi-layered set of classes with common interfaces, from low-level Stream::File / Stream::Log / Stream::MemoryStorage, to more complex Stream::Queue (local file-based queue supporting multiple parallel clients). Also, there are functional-style filters, catalog which can construct stream objects by their name, pumpers connecting input and output streams, multiplexing, and a lot of abstractions, base classes and roles...
Together, they assist in implementing complex asyncrohous, realtime and possibly distributed data processing.
By now, i think the paradigm I'm trying to implement is called a Flow-based programming, but until recently, I've mostly been thinking in terms of this image:

Anyway. I'll have a chance to talk about it later when this code will become public.

Any hints about namespace?
I don't like Stream::* that much, and there is a Stream-Reader in that namespace already.

mst's State of the Velociraptor talk at YAPC::EU inspired me to start a blog here, although this first post has nothing to do with Perl...

After reading Chisel's post on highlighting useful words like TODO in Vim, I decided to see if TextMate could do the same. After a bit of trial-and-error and a brief glance at the documentation, the following worked for me:

1. Bundles / Bundle Editor / Edit Languages (and choose Perl if not already selected)
2. Find this section in the language grammar definition:

   
   	repository = {
                  ...
   		line_comment = {
   			patterns = (
   				{	name = 'meta.comment.full-line.perl';
   					match = '^((#).*$\n?)';
   					captures = {
   						1 = { name = 'comment.line.number-sign.perl'; };
   						2 = { name = 'punctuation.definition.comment.perl'; };
   					};
   				},
   				{	name = 'comment.line.number-sign.perl';
   					match = '(#).*$\n?';
   					captures = { 1 = { name = 'punctuation.definition.comment.perl'; }; };
   				},
   			);
   		};
   

3. Change it to:

   
   	repository = {
                  ...
   		line_comment = {
   			patterns = (
   				{	name = 'meta.comment.full-line.perl';
   					match = '^((#)\s?((TODO|FIXME|BUG|XXX):?)?.*$\n?)';
   					captures = {
   						1 = { name = 'comment.line.number-sign.perl'; };
   						2 = { name = 'punctuation.definition.comment.perl'; };
   						3 = { name = 'comment.keyword.string.perl'; };
   					};
   				},
   				{	name = 'comment.line.number-sign.perl';
   					match = '(#)\s?((TODO|FIXME|BUG|XXX):?)?.*$\n?';
   					captures = {
   						1 = { name = 'punctuation.definition.comment.perl'; };
   						2 = { name = 'comment.keyword.string.perl'; };
   					};
   				},
   			);
   		};
   

   and click 'Test'
4. Now open TextMate / Preferences... and open the Fonts & Colours tab
5. Create a new element, set Scope Selector to 'comment.keyword', and choose foreground and background colours as appropriate - I picked yellow background and red text too, but if you don't have a black background then something else may be more appropriate
6. Done!

The TextMate Perl language grammar defines two comment items - a comment line and a comment string (i.e. a partial line) - to both we've added an optional section to the regex and an extra capture. It could be further improved by matching the keyword anywhere within the comment if required, and unlike the Vim syntax highlighting, this only matches within comments, which I think is probably preferable.

This module dates back to 1999, but as of late 2009 it had only been patched twice over a 5 year period. The RT queue was full of very good (but unapplied) patches. The world of browsers had also changed considerably over this 10 year period, making the module helpful but missing a lot of coverage. Since I didn't feel like rewriting this module,I took the time to contact the author about seeing if he'd allow me to apply the patches. I'm happy to say that he was very responsive. He added me as a co-maintainer immediately and I set about working through the queue.

Since that time, the test suite has been improved, more UserAgents have been added and it really is, once again, a tool which you can use with confidence when detecting browsers. I'd also like to note that once I started moving through the available patches and made the repo available on GitHub, I started getting lots of very helpful pull requests from interested developers which have improved this module even more.

As of yesterday, the RT queue is officially empty for the first time in many years. So, if you've avoided this module in the past because it looked unloved, I invite you to give it another chance. Additionally, if you'd like to send me a pull request with your improvements, I'd be more than happy to incorporate them.

Over the last few years, I've come to rely on tools that summarize information for me: Being on a mailing list in digest mode and receiving a summary of activity once or twice a day is a great example -- and it's also the specific challenge that I'm struggling with.

As my information consumption habits change, I find that I also want to customize how that information is delivered, and when, more than simply changing to digest mode allows. And, frankly, even in digest mode, I receive too many individual e-mails.

To resolve this, I end up setting my list subscriptions to "no mail" and fooling myself into thinking I'll peruse them on the Web from time-to-time. However, for those mailing lists, I'd actually would like to see what's happening regularly. So, last week I started brainstorming a tool that would send me a daily summary of all activity across a variety of different lists -- combining, say, all lists about security into one daily e-mail summary with links to the individual posts.

So, here's the challenge: half the lists are Mailman lists, the other half are Google Groups; half of them are public, the other half private.

After I'd sketched out the initial requirements, I thought to myself "I probably don't need to start from scratch, I'm pretty sure that my old friend Plagger -- the Perl-based "UNIX pipe programming for Web 2.0" -- can do most of this." Thus, I updated my Plagger source from Github and started digging...

Turns out that Plagger can handle two requirements already: consuming a Mailman archive and outputting it in a variety of ways, and -- obviously -- consuming the XML feed that's provided for a public Google Group. In the Plagger world, that would be as simple as this:

So, that part is surprisingly simple. The bigger challenge is dealing with private mailing lists, where:

• If it's a Google Group, I need to authenticate to Google first (though, I only need to authenticate once for all lists, thankfully);
• If it's Mailmain, I need to authenticate to each list with a different password.

So -- drumroll please -- here's the actual question: Should I simple develop a couple of new plugins for Plagger to handle Google Groups and private Mailman lists? Or should I develop something smaller that is focused on my specific set of requirements?

I think the question is really about the status of the Plagger project and community. I've developed a couple of plugins for Plagger already -- one that integrates bit.ly and another that fixes problem in the existing Publish::MT plugin -- but there are a couple things that bother me about going down this road again. Specifically:

• It's difficult to get help for Plagger: the IRC channel is not really active, and the Plagger Google Group is full of spam.
• The Plagger documentation is woefully incomplete and -- in some cases -- just plain wrong.
• The existing Plagger Web site is terribly unhelpful, and more-often-than-not, contradictory (where do I get the latest Plagger source? From Subversion, or from Github?)

Lately, some folks have told me they looked at Plagger and then decided to develop their own aggregation tool instead of using it. So, What am I missing? Should I be heading down the "roll my own" path also?

There seems to be some recent activity on Plagger's github page -- a few forks anyway -- so the project is not entirely abandoned, it appears. However, it would be really comforting to see some efforts at making it easy for those of us who are working with Plagger to share configuration files, new plugins, and so on. Or maybe none of this should be a concern at all?

What do you think? What would you do?

It's over a year since I released Devel-CheckLib-0.699_001 which introduced a Useful and Shiny new feature, but it's still not had a proper release because it doesn't work on Windows. I don't have access to Windows, and even if I did I wouldn't know what to do, and, to be blunt, I don't care to learn.

So I'd like to find someone to take over maintenance, fix the bugs, be able to test it on both Windows (Cygwin, MSVC and ideally Borland too) and Unix, and get a release out. If you know VMS (for which it has no support at all) then all the better!

Any volunteers? Please email me if you'd like to do this.