March 2012 Archives

Alien::Base Perl Foundation Grant Report Month 1

Once again I would like the thank the Perl Foundation for supporting me in my effort to provide a mechanism to ease the creation of Alien:: modules. Further I’d like to thank the many Perlers who have commented in various places that this project is of interest and that they are looking forward to providing that Alien:: module that they have always meant to write. This is exactly the response that I had hoped to receive.

Down to the details. This month I did a lot of work on Alien::Base; partially do the excitement about the grant and partially because our scientific camera was out for repairs, thus not much science going on in the lab. I hope to keep the pace high, but looking over the git log I’m not sure that they can be this productive! I’ll list some high points:

  • A::B now relies on M::B to handle most of the attributes. Originally I was pulling out my hash keys before creating the object. The few that I still do parse manually I do because there are states that M::B expects prior to the object being created, and I must ensure that those states exist.
  • A::B now includes a simple pkgconfig file parser and storage/munging engine. This allows for A::B to know what cflags and libs to provide and which -L directories to include even after M::B moves the files to their final location. I am considering using mnunberg’s new PkgConfig module to do the parsing, but in truth, the spec doesn’t seem very difficult (famous last words? let me know in the comments)
  • Removed an awkward system for supplying defaults for all repositories and building repository objects from them. The new engine for this is much simpler and allows for true constructors for the repository objects. This is necessary if my goal of presenting a fully subclassable module
  • Possibly the most important item: use Alien::MyModule; now provides the location of the library to the Perl’s run-time loader via LD_RUN_PATH (or PATH on windows). I may need to expand this for other platforms; I’m not familiar with this stuff on any platform but Linux, though my goal has always been to be as x-platform as possible
  • Wrote lots of documentation and tests. Of course there is plenty more to go, but I think that a reasonably competent CPAN author could write an Alien:: module using only these documents. See especially: A::B::Authoring and A::B::ModuleBuild::API.
  • Created an initial dev release, 0.000_001 and given the testers results, two further releases; now at 0.000_003.

Still on my list:

  • Fix a recurring bug that the testers see. It seems to always happen on Solaris, but also appears occasionally on other platforms.
  • Provide a few inheritable tests so that Alien:: authors can have a backbone test provided for them. I expect this will be something in a Test::Class kind of implementation. However the abstractions make this test hard to test, so I’m working on it.

Finally I want to share a little story. At just the right time, I happened to notice that Richard Simões had started an Alien::Nettle project on his GitHub account. Just for fun, I decided to see how easy it would be to write my own Alien::Nettle for this nettle library that I had never heard of, but which seemed to meet my mental image of a good candidate for the Alien::Base system. The project to me all of about 5 minutes and worked successfully! I contacted Richard to mention it and he was quite excited.

This has been added to the examples directory (in his name). There are other examples too, including my own pet Alien::GSL. Take a look to see how easy this can be.

Do you have an Alien:: project that you wish you could write? Once I knock out this bug, I will release an alpha version, probably 0.001 and I will issue a call-to-arms. The reason for this is two-fold.

  1. I want to hear what problems you have in writing your Alien:: module. Where is the framework not flexible enough? How is it confusing to you? Alien::Base has no purpose without users, I want to have you involved sooner rather than later.
  2. I want my actual release (1.000) to be accompanied by a host of other releases of YOUR Alien:: projects. Hopefully coordinated on the same day. What could be a better demonstration of a new easy mechanism for library support?

Finally, just wanted to mention that the project is available on GitHub - including those examples :-) Please, take a peek and comment either there or here, email me at joel dot a dot berger at gmail, or even chat me up on #alien, which I have created to support the authors after my call-to-arms.


A Little Light(?) Reading

Courtesy of the Hacker News Twitter feed, I read a really interesting piece from slate.

Where's _why? by Annie Lowrey

Ostensibly, the article is about the former Ruby developer, enthusiast, mascot and resident oddball named "_why". He dramatically disappeared from the open-source world dramatically one day, taking all of his software and writings with him. But that's not the only theme of t…

Alien::Base is almost ready

Not too long ago I mentioned on this blog that Alien::Base had reached a milestone, well today I’m announcing that its getting even closer.

Before I get there lets recap. The Alien namespace contains modules which provide external libraries to Perl modules. Alien:: modules typically can detect the presence of a library on your system or if not, install it. Then they can provide the locations and other information to the Perl modules that need them. Alien::Base aims to make these modules easier to write by providing most of this functionality in a configurable way.

Alien::Base, once it has decided that a computer does not have the library, will try to install it. One of my biggest concepts in designing Alien::Base is where it installs the library to. In contrast to attempting to install it to the system-at-large, it puts it in a static data location relative to the Alien:: module in question; it does this via File::ShareDir. Why is this important? Several reasons:

  1. It can be done without root privileges
  2. It respects perlbrew/local::lib
  3. It doesn’t unexpectedly change your system

For me number 3 is the most important. When installing a Perl module I don’t expect that there will be effects to the system outside of the Perl directory. This does bring a few drawbacks:

  1. Counter to #2 above, each installed Perl will need a separate copy of the library
  2. While satisfying the compile-time dependency is easy, satisfying the run-time dependency is hard

Yes #1 can be annoying if a large library is needed for multiple Perls. A workaround would be to manually install the library system-wide (via apt for example). Another that is planned is to add support for the new local::c project which brings local::lib-like functionality for C libraries.

Today’s news is that #2 has been fixed! Alien::Base now accomplishes this by appending to your $ENV{LD_RUN_PATH} just in time to load the library. This will mean a slight change to the mechanism of use of the Alien:: module. The dependent module will now need to explicitly import the Alien:: module.

package Some::Module::UsesMyLibrary;
use strict;
use warnings;

# this line now required for Alien::Base based modules
use Alien::MyLibrary;

require XSLoader;

# your code

In the past Alien:: modules have relied on system-installation, static libraries or rpath to do this work, but this mechanism seems to be simple and effective.

This was the last big hurdle to Alien::Base, so now I can (pretty) safely say, “Alien::Base is coming!” I had hoped to announce this when I first released Alien::Base, but some other functionality if taking longer than anticipated.

I expect a pre-alpha release to come soon, perhaps even this week. When I see that CPANtesters approves, I will then release the alpha version, at which point I will make a call for libraries which need wrapping, so keep that in mind; start thinking of those unwritten Alien:: modules you have always wished for; Alien::Base is going to empower YOU to create them!

Mojolicious + Bootstrap = Awesome

I have some news coming soon about Alien::Base but to avoid burnout, I’ve spent some time in the last few days playing with some things that are new to me. I enjoy doing this any time I’ve spent too much time on one project.

While I have spent some time using Mojolicious it has always been to hack together a quick UI for some code, rather than pulling out Tk. I never have really taken the time for pretty-fication, nor for any kind of interface logic.

I have a friend who thinks highly of my programming abilities and has recommended me to another of his friends to put together a website for a startup company. While I could put together a Joomla or Drupal site in no time, I thought I would investigate a Perl solution. I know that there are a few Perl CMSes out there (WebGUI 8 sounds interesting), but I wondered if I could hack something together myself.

Here’s the problem, I know Perl, thats about it. I don’t know much JavaScript, CSS or even HTML for that matter. Forget about DOM, and I’m no graphic designer.

However, surprisingly, Mojolicious, along with Twitter’s Bootstrap for building page elements, has made this really easy. I don’t know if I can sell it to a client yet. But maybe by the next client, or the one after that, I can offer a website as a Perl/Mojolicious/Bootstrap/PSGI app!

I love open source!

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.