blogs.perl.org

Hello there!

Being a cautious type (usually), I kept on to my recently created use.perl.org journal despite the justified acclaim this new platform gained when it was annouced.

It was worth the wait, seems like all the early illnesses have been cured, and it's safe to join this much improved perl blogging sphere!

Glad to join, and happy to use these great new blogging tools. Thanks to all those involved in the creation and maintenance of blogs.perl.org!

It has been another month since the last time I posted a Plumage work log, back on the old u.p.o blog. Mostly this was because I was getting actual work done on Plumage, so I hope you'll forgive me.

Just like last time so much time had passed, I'm just going to post the (mildly edited) #parrotsketch reports here; the format is a bit terse, but it should give you an idea of the pace of development:

just to say hi to my new blogs.perl blog :)

Good news! The Dataphor relational database is now open source under a modified BSD license.

Bad news! It's written in C#. C# is lovely, but this will likely limit its adoption in the non-Windows world. I'm curious to know if it will compile and run under Mono. More important, how would we write a Perl interface for it? True relational databases seem to eliminate the object-relational issues which ORMs traditionally have. It would be nice to see how well it translates in practice.

Quite often I read about whether Perl is "legacy" or "modern". It all comes down to "is Perl dead or alive?"
Here is an example to show how well it's sanity status is and why it might need marketing:
I try to "do email". :-)
I read myself through modules on cpan. There are a lot. Now, where to begin, which modules to choose? Instructions for beginners are rare or I am too stupid..
I find emailproject.perl.org
Same here. Plus most of the pages are a little older in date.
Few days later, emailproject.perl.org has shrunk down to one page.

So I finally do what I should have done at the very beginning.
I ask my questions on #email. Some minutes later I'm chatting with the authors of the modules I try to use. They expect me to ask clever questions but help anyway as I fail to do so. ;-)
My questions are promptly answered, I'm helped through the initial steps and my first "hello_email.pl" is working in no time.

Stability seems to be coming to these shores, so I guess it's about time I created an account here and started posting. For a while at least, most of my posts will be about Plumage, for which I am the current lead developer.

Plumage is a cross-language module ecosystem, designed to work with CPAN, LuaRocks, RubyGems, Rake, distutils, and so on. Plumage itself is implemented in NQP (Not Quite Perl 6), which is part of the PCT toolset used to implement languages and modules for Parrot.

The original design document for Plumage is available on the Parrot wiki, and the source repository is hosted on Gitorious. You can check it out by doing the following:

(Note: this is a repost due to some of the beta-ness of the site).

BioPerl is a commonly-used toolkit for bioinformatics, but it does have it's share of problems. As educated_foo has pointed out, it can be slow, documentation is spotty for some modules, classes can be overly complex in some cases, and there are interface issues. And, for simple formats like FASTA it's probably overkill if you are just parsing data. Not to mention the monolithic nature of the beast; I think it's over 1000 modules now.

We in the BioPerl community haven't heard much about these issues from users. What (specifically) bugs you about BioPerl? What could be improved? In other words, what are it's weaknesses? Specifics would be nice.

(Just for some balance, I'll blog about some of BioPerl's strengths at a later point)

Rattling off a couple, from educated_foo and myself:

• Make it less monolithic. Break up 'core' into more manageable bits.
• Simplify classes.
• Better tests?
• Maybe a BioPerl Manual? (we do have HOWTOs that could work as starter material...)
• Moose? Some of those interfaces fit nicely into Roles...
• Allow parsers to return simple data structures (hash refs?) as well as objects.
• Re-evaluate interface? educated_foo mentioned problems, but specifics would be nice.

Others?

Monty Widenius, the creator of MySQL, needs your help to save MySQL from Oracle. In short, Sun bought MySQL. Oracle wants to buy Sun. Get the picture? Oracle has already let InnoDB languish after acquiring it. There's no doubt that they would like to do the same thing with MySQL. After all, many companies look at the price of Oracle versus the price of MySQL and Oracle loses another sale. Oracle does not want MySQL to succeed.

Frankly, this might be a strange blessing in disguise as it could increase adoption rates for PostgreSQL. That being said, I support open source software, even if it's software which represents the Platonic ideal of a "love/hate relationship."

use Blog::Perl::Org;

my $blog = Blog::Perl::Org -> new ("Have appropriate amount of fun");
$blog -> thankCreators ("very much");

$blog -> release ();

Hello World,

Trying to reverse my I/O.

Module::Starter 1.54 was recently released. I felt like blogging a bit about it.

Module::Starter is one of my favorite projects in the Perl community and on CPAN. I use it whenever I want to start a new module or program. It's very simple (read: beginner-friendly), modest and provides what I don't feel like doing myself. It has boilerplate files, text and tests and keeps updating those with habits that are considered "best practice", such as replacing the default licensing term we use.

Recently I've had the pleasure and honor of contributing to this project. I've made several changes mainly taking care of tickets and patches people submitted, making this release a fixer upper release. Following releases will contain some bigger and more exciting changes.

I want to take this chance to thank Andy Lester, Ricardo Signes, Shlomi Fish and anyone else involved with Module::Starter. Also, I want to thank some lesser-known contributors to Module::Starter, those that send bug reports, feature requests and patches (on my god, patches *drool*).

libnova is a Celestial Mechanics, Astrometry and Astrodynamics Library written in C. Just yesterday, I uploaded an inital, thin XS wrapper to CPAN as Astro::Nova, so we can use it from Perl.

Here's a simple example that calculates the current moon rise, transit and set times at my home in Karlsruhe using Astro::Nova. It's quite similar to the equivalent example of the C version.

I recently started working on my first CPAN module, Project::Euler. This is simply my effort of solving the problems posted on http://projecteuler.net using modern Perl strategies / modules. I will be making an effort to post about my thoughts that I have while coding as well as problems that I ran into and how I overcame them.

Being as this is my first module uploaded with PAUSE, I've already ran into many snags and continue to muck up some simple things that will no doubt disappear once I am fully comfortable with how CPAN works. I may post some entries about the issues I've encountered already but for now I will just be posting all future ones.

With any luck, I will help others who have been hesitant posting to CPAN see it through the eyes of a newbie and realize that it isn't all that bad!

I have been using Emacs for decades. I am totally happy with it (indeed, it keeps getting better and better!) and am not looking for another editor. Nonetheless I like to keep abreast of things, so when new tools become available, I like to check them out.

For a while now, I have been hearing about Padre, an IDE written in Perl. However, until recently, I wasn't able to get it to work. Granted, I never tried anything more than

PERL_MM_USE_DEFAULT=1 cpan Padre

I recently tried installing version 0.50 on a Windows machine with the fancy .msi installer (recommended!). It appeared to install okay, but when I ran it, nothing happened. Nothing. At all. So I tried to uninstall it, but that just hung the machine. Grr. After powering the thing off and back on again, I removed the C:\strawberry directory and then ran uninstall. Whew!

But today I ran

PERL_MM_USE_DEFAULT=1 cpan Padre

Working on rights modeling for programmes and one of the issues deals with the availability window of online content. It might be available for a day, a week, a month, etc. It looks like this in our XML:

<availability_window unit="days" value="1"/> <availability_window unit="days" value="7"/> <availability_window unit="days" value="30"/>

The availability window is an extremely important part of our rights model and if we get it wrong, we're violating contractual agreements with people who produce content for the BBC. In short: don't get this wrong.

As it turns out, there is some content which has what is called "endless availability". This is content which, when made public, is never removed. We represent this availability window with the following element:

<availability_window/>

It turns out that this was a mistake because people assumed it meant this:

<!-- not available --> <availability_window unit="days" value="0"/>

This is a stupid hack and you shouldn't do it. But it was one of those things where I wondered if it would work and had to try it.

One of the things that annoys me tremendously about HTML is that you can't write a self-closing script tag. E.g.

<script type="text/javascript" src="/foo.js" />

is invalid. The <script> element is not allowed to be empty because it may contain inline code, and HTML is not smart enough to turn that feature on or off based on the presence of an attribute. (And it probably shouldn't be.) So you have to do <script ... ></script> every time.

perl -e " print 'Hello,world.' "

I am in the process of writing Yet Another Job Queue, Cantella::JobQueue.

I decided from the beginning that I wanted a well-defined API for the storage layer, so that as different back ends would be easy to write and swap around. While writing the tests for the first one, I encountered a problem that’s been haunting me since: how to deal with locks.

Originally, I imagined a job would either be locked, or not locked and manager processes would be in charge of releasing locks if workers died / failed. Then I started thinking, what if a manager process dies? Who releases the locks? So I decided to add time-based automatic lock expiration. This introduced a new problem, a possible race condition. What if a job takes so long that it’s lock times out before the job is done? What do I do then?

A possibility is to have a manager process / thread that monitors its workers and updates the lock-expiry time, which is the route I am likely to take. I don’t particularly like it, but I can’t come up with anything better right now.

I’d love to hear from anyone that has any experience with this kind of problem.

# I had to say
# push my @entries,<<EOF;
# just to make it appear as:
# push my @entries,<<EOF;
EOE