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
but for version 0.50 and below that always failed one or more tests, so I didn't install it.
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!
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:
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.
Ok, so it seems that the memory allocation errors on blogs.perl.org are finally behind us and we're working our way through the list of users who were semi-signed-up during the bad old times.
That means it's probably time to start looking ahead and discussing what improvements we can make to the system. The project team have an internal bug-tracking tool (er... ok... spreadsheet) which we'll make public very soon, but we're keen to have your ideas too.
We want to hear about two types of things. Firstly there's the actual bugs that you find - what's broken when you use the site. And secondly, what can we improve? What features are missing from blogs.perl.org? We want blogs.perl.org to be a first class blogging platform for the Perl community. What, in your opinion, does it need in order to reach that goal?
Please leave suggestions in the comments on this post.
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.
My fabulous new nook arrived today. The packaging was atrocious, as can be expected for any new electronic gizmo, but once I broke out the Jaws of Life and freed the nook from its captivity, I was very pleased indeed. The first thing I did was to load it up with my PDF copy of Mark Jason Dominus's Higher Order Perl, which is now available for free and which every Perl programmer should read once a year or so.
It looks like something didn't go quite as planned in the migration yesterday and now we seem to have lost some of the most recent posts. It looks like we're missing stuff from about midnight on 8th December to just before midday today.
Sorry about that. We now have a database back-up strategy in place that means we'll always have far more recent backups available. I'm sure this was a migration glitch and nothing more serious.
On all released 5.10.* versions of Perl to date, the smart match operator can segfault if passed recursive data structures (like arrays that contain a reference to themselves).
I fixed that. The fix was pretty trivial: basically, the C code in the implementation of smart match was creating two hashes, called seen_this and seen_other; however, a typo made it so only seen_this was actually created. Segfaults ensued if the code was trying to use seen_other.
Do you see the language problem here? The code to create seen_this was copied and pasted to the code to create seen_other, but not all occurrences of the variable were renamed. Because in C, it's difficult to factorize this code without much programming overhead. (In that case, pointers to pointers.)
But in Perl, we have foreach and aliasing to $_. That's a great tool to avoid cut and paste, and reducing cut and paste will always improve maintainability. And that's why I prefer writing stuff like
It's a lot of fun to contribute to other people's code (especially code you're using) and it's very fulfilling. Some people say it's a downer when your code isn't accepted, and I can understand that. However, the serious downer is when your code gets ignored.
When I go over a module, I go over the ticket list. When I see a ticket from over a year and it's still "new", it disappoints me and when I contribute to a project and it takes six months to get a reply, it disappoints me.
The following is ongoing on my private branch of the CPAN dist Net::RackSpace::CloudServers, in which I'm creating an App::Cmd interface to the module:
So I finally managed to attend a Perl workshop over the weekend and it was awesome! I saw some excellent talks and even got a goddie bag ... I was not expecting that. Some personal highlights:
Most entertaining talk
For me it was Piers Crawleys lightening talk/song "don't care how you young people talk to one another but don't take that tone with your mother". Can I have the lyrics please ;)
Most useful/relevant talk
Plack/PSGI by Miyagawa. It's great to see that folk much smarter than myself are solving issues that directly influence my work. More of stuff like this and I won't be forced to use Ruby any time soon ;)
Most "what the hell was he on about" talk
Definitely Matt Trout's BEGINing Perl talk. Something about compilation units, Moose, antlers, Damian Conway, black magic, e.t.c. I understood about 30% of that ... about 20% more than I anticipated ;)
I left with a satisfying feeling that I am somewhat better than I give myself credit for (mostly because I understood any of Matt Trout's talk). I missed most of the conference including the trip to the pub and did not socialize as much as I would have liked. Perhaps in my next conference I'll be more friendly :)
All in all a great experience that I would recommend to any one!
My editor of choice is Emacs. Like Perl, one of its strengths is its flexibility. (some would argue this a weakness. to each their own) Here's just one example I recently found... you can extend Emacs to change the cursor based on what mode you are in (normal, read-only, overwrite)
Rapidshare deletes illegal files, so instead of sharing Rapidshare links, sites nowadays apparently started sharing .dlc files (or so I've heard). DLC is an encrypted container format. It is very very stupid. I'll elaborate.
Let's break it down:
Only one server decrypts - single point of failure.
Disregarding the necessity for internet, this binds you to specific programs that have the keys hardcoded in them to be able to access the server.
The protocol is secret, the key is secret, the programs are closed source (at least the part that matters).
One program is for Windows only. The main one is written in Java. Stupid Java. I've gone over the parts of it that are open source and it's horrible (really really horrible).
I have not managed to get the program running on three different computers, and on Windows as well.
Apparently they change the key every once in a while so you always have to stay updated with the program.
So I have a module that exports some functions that each take a single hashref as an argument, and I want to be sure that:
I really have got a single hashref
The contents of the hashref conform to my specification
I'd never used Params::Validate before now, so this looked like an ideal opportunity.
Here's what I came up with:
sub _validate_me {
# Raise exception if we don't have exactly one hashref
validate_pos( @_
, sub { TYPE => HASHREF } );
# P::V only tests lists.
my(@test) = %{$_[0]};
# Now we have our validation specs for the hashref. We accept :
# keys foo,bar and baz, each with defined scalar values of length > 1
# keys qux and tla with defined scalars as values.
# Anything else is a fatal error.
validate( @test
, { foo => { type => SCALAR
, callbacks =>
{ 'foo set' => sub { length($_[0])>1 } } }
, bar => { type => SCALAR
, callbacks =>
{ 'bar set' => sub { length($_[0])>1 } } }
, baz => { type => SCALAR
, callbacks =>
{ 'baz set' => sub { length($_[0])>1 } } }
, qux => { type => SCALAR }
, tla => { type => SCALAR } } );
}
And in the calling code :
sub do_stuff {
_validate_me(@_);
# Invalid? BOOM
my($args) = shift;
#Continue processing.
#..
}
We could obviously push quite a lot of validation logic into the callbacks, which has the benefit of making the actual application code much cleaner.