After the public buyers-remorse that I (almost) had on the name of my latest module Tie::Select, I got to thinking about the filling of CPAN namespaces.

CPAN is awesome; many have said that it is Perl’s killer app. It has tons of modules to do many many things. The problem is that some of the obvious names are gone. Certain namespaces have implications. For Tie::Select I thought of IO::Select, which exists. I thought of going underneath an existing module’s namespace, for example IO::Handle::Select, but this implies, at least to me, that it is either a part of, or derivative of IO::Handle. Its not, and in fact it isn’t even OO as that module is.

I have settled on the current name for now, but I am not totally happy with it. I got to thinking about other naming problems I’ve had. (And note I am not complaining about any of this, just ruminating):

• Duke Leto’s SWIGing of the GSL library effectively took up the entire Math::GSL namespace. My Math::GSLx::ODEIV2 needed that little x to “clear things up”

• One might expect that my MooseX::Types::NumUnit uses MooseX::Types, but it doesn’t. Perhaps it should, or perhaps it should be in another namespace. Then again, this is the descriptive one.

• It seems like there are more that I am forgetting

Anyway, it begs the question, as CPAN continues to mature, what happens as the namespaces fill up? What happens to old dead modules Tie::CSV_File which aren’t really worth fixing, but will decrease the searching signal-to-noise?

Gasp! What happens when ACME:: fills up!

I know that some people’s answer will be to adopt the old modules. But what if I don’t plan to keep the API or the implementation. What if the functionality is different but the names should be similar (my Tie::Select vs IO::Select).

I know I’m rambling a bit now and I can’t say that I know what I want, but I know what I don’t want. I don’t want new CPAN modules to have to start picking odd names just to have their own namespaces. I’m sure many of us have see Miyagawa’s module’s funny names and their reasoning.

But there just aren’t enough descriptive names.

Have you ever forgotten to restore your original STDOUT (or other handle) when you want to select another one for a brief time? Does the usage

my $stdin = select *STDERR;
print "To STDERR";
select $stdin;

seem clunky?

I have always loved the interface provided by File::chdir. It gives you the $CWD variable. When you assign to it you change the working directory. Even better, if you do that with the local directive, you dynamically scope the change!

It struck me, while I was working on the test suite for another project, that I wished that I could have that same kind of interface to select. And why not, they both need changing and restoring of a global property? So I gave it a try, and lo and behold it was simple!

So here it goes, I present Tie::Select, which provides the $SELECT variable. Use it like this and I think you will wonder why you ever did it the other way!

 use Tie::Select;

 {
   local $SELECT = *STDERR;
   print "This goes to STDERR";
 }

 print "This goes to STDOUT";

The PDL community has been buzzing with activity as they prepare for the 2.4.10 release.

For those of you who are unaware, PDL is the Perl Data Language, which gives Perl numerical array processing power. Implemented in C these computations are very fast, and with its sublanguage PDL::PP you can easily write your own C implementations of numerical algorithms too.

One of the things coming in this release will be the companion PDL::Book. Its been entirely written by the developers specifically for this release. The source is all in POD of course.

While there aren’t too many formulas in the book, there will be a few. To that end I decided to look into LaTeX->”ASCII art” conversion and found that there is a nice utility called AsciiTeX, which has a command line and a GUI interface and is GPL. Since it was nicely modularized it was easy for me to pull the guts out, put an XS wrapper on it and Text::AsciiTeX was born. (N.B. updated example for version 0.03).

use Text::AsciiTeX;
say for render( <<'END' );
\int_0^W \frac{np}{n+p}dx = \int_0^W \frac{n_0}{
exp \left(\frac{E_0(x-x_0)}{kT} \right)
+exp \left( -\frac{E_0(x-x_0)}{kT}\right)
} dx
END

gives

   _                 _                       n                         
  /  W  np          /  W                      0                        
  |    -----dx  =   |    ------------------------------------------- dx
 _/  0 n + p       _/  0    / E (x - x ) \       /    E (x - x )\     
                            |  0      0  |       |     0      0 |     
                        exp | ---------- | + exp |  - ----------|     
                            \     kT     /       \        kT    /

(I apologize if that doesn’t display correctly in your browser, I assure you it looks right in my terminal)

It doesn’t do the whole world of LaTeX math, but it does a surprising amount. Of course this is only half the problem, now I have to figure out how to hook this into a POD renderer. Any thoughts?

Enjoy!

(Fork Text::AsciiTeX at GitHub)

I don't want this blog to be political, so all I will post here is this: I have posted some views on SOPA on my non-Perl blog. If you would like to read them, click here. To paraphrase Wikipedia, although this blog is neutral, its existence is not. Thank you.

Today on StackOverflow, an old thread popped up that prompted me to answer. That answer became a slightly longer compendium of recent developments in Perl and Perl-for-web.

I will copy the text here, but I am asking you to vote it up so that it will show for future viewers. So that I will not be getting undue points, I have made it community wiki (also means you can amend if you want).

Vote here: http://stackoverflow.com/a/8828209/468327

== Post Content ==

This is an old question, but I thought I should update the readers. I am happy to report that in my opinion Perl is more viable for web development than ever! Along with old friends Catalyst and (recently revamped) Mason, there are some great new entries Mojolicious (or visit mojolicio.us) and Dancer. I’m sure there are others too.

Perhaps the biggest improvement is PSGI/Plack (or visit http://plackperl.org/).

PSGI is an interface between Perl web applications and web servers, and Plack is a Perl module and toolkit that contains PSGI middleware, helpers and adapters to web servers.

With these improvements have come more cloud hosting platforms: for a couple examples read more here.

Perl itself is experiencing a renaissance of sorts. Between Moose object framework (and lighter clones like Mouse) and the ideals of the Modern Perl movement (readability while using modern best practices), Perl seems to be growing and its users are excited and motivated.

Personally I have been enjoying Mojolicious. I like its built-in servers and templating engine. I also like that you can make a Mojolicious::Lite application in a single file! That said I really haven’t played with Dancer or other frameworks, so if you are coming back to Perl or new to Perl, I would encourage you to take a look at those too.

In closing Perl-for-web has come a long way since CGI.pm. If you’ve been away for a while, its worth another look.

What other language comes with a service like CPAN Testers?

I recently uploaded version 0.02 of Module::UseFrom and little did I know, but it had an odd bug. As hopefully you all know by now, since Perl 5.14 many functions that take hashes or arrays as arguments can now take references as well. This often makes for cleaner code, but I don’t use it (intentionally) on CPAN modules so that they are backwards compatible. However when you write keys $export but meant to write keys %$export and it works you never notice, the tests all pass for me. Release.

On most languages many users would attempt to install and would fail before a few would file bug reports. With CPAN testers however, an army of dedicated volunteers are out there keeping my back. So thanks guys! Bug caught, face saved, everyone wins.

Thank you CPAN Testers!!

A couple days ago I released Module::UseFrom and I asked Schwern for his comments since it was addressing an issue that I knew he was very familiar with.

In response to his concern that the interface is overly complicated and strays from the known use interface, I really had to examine what I was doing, why, and how best to accomplish it. Most importantly I followed his suggestion to create a separate use_if_available function (exported on request) rather than using flags to use_from.

In the end I needed tidier cleanup from a no-op use_if_available and I needed some way to inform the user whether or not the module had been loaded (without being able to tuck it into a hash). The former was accomplished by injecting a no-op subroutine to catch import parameters intended for the not-available module. The latter involved using the rarely seen dualvar to tuck the module version into the number slot of the original scalar (I thought that was rather cute).

I have released 0.02 which provides this greatly simplified interface and since I’m sure nobody jumped out to use 0.01 in a mission-critical way, I will remove it from CPAN as soon as 0.02 posts.

Special thanks to Schwern for his comments. I welcome yours if you have any.

So what do you do when you need to load a module from a string? Do you do eval "require $module"? Well as many of you may have read, that is How (not) to Load a Module. This mechanism is unsafe in certain situations, but sadly there hasn’t been a good answer for it.

What do you do when you want to load a module only if it is installed, or only if it is of a certain version or higher (without dieing). Of course there are eval ways around that too, but could they be easier?

This post announces Module::UseFrom, which lets you do all of these things. But it gets better! All of these actions are done using the much safer bareword form of use, accomplishes this at compile time, and does it without any evals[1]!

It does all this using Devel::Declare to inspect a package variable in your module and inject a bareword use statement. This means that it avoid most (all?) of the problems Schwern’s post (above); if it fails to create the right statement, perl (yes lowercase) dies on the use Bareword::Module statement.

Check it out, fork, comment etc. https://github.com/jberger/Module-UseFrom

Happy New Year everyone!

[1]: ok, there is a s///e, but its for convenience, and its safe.