On behalf of the PDL Porters, and especially our tireless leader Chris Marshall, I am very happy to share the news that PDL 2.006 has been released, I’m reposting the announcement here, find the full message including release notes on the mailing list. It even includes my first contributions to the PDL core :-) Enjoy!

The PDL development team is pleased to announce the official release of PDL-2.006 and an updated draft of the PDL Book to accompany its release.

Of specific note:

• PDL VERSION numbers now use single decimal format. This will be the standard going forward.

• PDL now has three graphics options that build on all supported PDL platforms (thanks to work by Craig DeForest and David Mertens and a host of others):

  • PDL::Graphics::Gnuplot using the gnuplot program

  • PDL::Graphics::Prima based on the Prima toolkit

  and

  • PDL::Graphics::Simple a basic 2-D graphics layer that can use many of the existing PDL graphics modules with a uniform syntax.

• ASPerl build issues have been resolved thanks to relentless testing, verification and fixes by Rob/sisyphus and other win32 PDL users.

As always, go to http://pdl.perl.org for information about all things PDL and how to get PDL for your platform.

Enjoy!

Chris Marshall

PDL-2.006 Release Manager

Just a little note to announce the release of Galileo version 0.023. Galileo is my CMS that aims to be 100% CPAN installable, all you have to do is this:

$ cpanm Galileo
$ galileo setup
$ galileo daemon

This release makes installing even better, because now when you run galileo setup you get a web interface to configure your CMS and then install the database!

Ok that image is just slightly ahead of what is now on CPAN, but its close :-)

A few days ago, I announced the release of Mojolicious::Plugin::ModuleBuild. After some thinking I realized that without much (any?) changes it would work more generally, even with the ExtUtils::MakeMaker toolchain. Therefore I am now announcing the availability of Mojolicious::Plugin::InstallablePaths.

The general concept is that Mojolicious applications assume a certain directory structure for use locally. To make a CPAN-installable distribution out of that application one must move some directories. Further, if packaging using Module::Build, even more changes had to be applied.

Mojolicious::Plugin::InstallablePaths allows a consistent usage in all phases of development and with either build tool (EUMM or Module::Build). Hopefully this helps encourage people to think of their Mojolicious apps as candidates for CPAN and makes it easier for them to share them with the world that way!

The old module will be marked for deletion and the old blog entry will be removed as well, so don’t try to use it, its going away.

Not too long ago, I asked for input on a new module: Module::Build::CleanInstall.

TL;DR its out there, go use it!

I am happy to announce that Alien::Base (GitHub) has seen a beta release, version 0.001. It seems that my design change that I previously blogged about has indeed fixed (well avoided) the problems that I was having supporting Mac.

This is not to say that Alien::Base is quite completed. While I have released two testing modules which are an Alien:: module (Acme::Alien::DontPanic) and a dependent module (Acme::Ford::Prefect) these are very simple modules. To be sure that the API is flexible enough and that the loader mechanisms are robust enough Alien::Base needs to be used in the wild.

This week’s Chicago/WindyCity.pm meeting, our monthly Project Night, will feature (though not exclusively) creating these modules. I personally will work on porting Alien::GSL to the Alien::Base system. I hope that if you are in the area you will consider attending or if not please attempt to wrap your favorite C library using Alien::Base and let me know how it goes.

Also, please try installing Alien::Base, Acme::Alien::DontPanic and Acme::Ford::Prefect (in that order, though installing Ford should just work), and let me know how that works on your system. I have been developing on Linux and have run some tests on Mac obviously. I have seen some conflicting reports on different Windows/Perl combinations, so this remains to be seen.

I am very happy to have reached this point, and I want to thank the Perl Foundation and my grant manager Makoto Nozaki for their patience with me. This was supposed to be a short project and it has become a much longer one than originally proposed. Hopefully the community will find it useful.

I am happy to announce that Galileo CMS is now available from CPAN! This project has been my on-train side-project, but its come a long way in a short time. The most exciting thing for me is that its entirely installable from CPAN. To try it out, simply do

$ cpanm Galileo
$ galileo setup
$ galileo daemon

of course, you can also run it using the servers provided by Mojolicious, or using your favorite psgi-compliant server (as long as they support websockets).

Authorized users edit pages using markdown with a live-preview. All updates to pages, menus and users are sent via websockets. Styling is courtesy of Twitter’s Bootstrap library.

By default it uses an SQLite database, and indeed this is all its been tested on, but in principle it can use anything that DBIx::Class supports. All other dependencies are available from CPAN, with the exception of the javascript libraries, which are bundled with the distribution.

Some things that are still on the list:

• Other than the database, it is not tremendously configurable yet, but I don’t think that should be hard to do. With a few changes it might be decently themable by overloading the styles defined by Bootstrap.
• Images cannot be uploaded yet, but they can be linked to from external sources, or at least that should work :-)

Unfortunately I missed the deadline for Perl Weekly, but I did get it out before I go on vacation tomorrow, and I’m excited that I made that goal. So please, try it out; though probably not for anything mission-critical yet.

Let me know what you think!

This week has been an exciting week for the small but dedicated group of scientists in the Perl community. This is because this week we saw the roll-out of two science related Perl sites:

• perl4science.github.com - a site for (mostly) one-way communication about Perl and Science
• The Quantified Onion a Google Group for two-way communication about Perl and Science

As gizmo_mathboy has already announced his group, I though I should make my site official too!

I wish we could say we had a big roll-out plan, but not so. We had discussed these things, decided we liked both ideas, and should keep them both, and somehow, this week, they both went live.

A little bit about the Perl4Science site: Its hosted on GitHub pages, mostly because its free, but it also fosters that GitHub feel of “lets share our code” which is a major part of using open source for science. Futher it uses Jekyll for a rendering engine and a cool project called Octopress to manage the Jekyll stuff. The details are in the site, including details on how you can contribute.

For now it contains some links to a few Perl science-related modules, and some links to the science related talks at YAPC::NA 2012. I want to see both lists grow. If you know of good modules or good talks please fork the site repo or mention in the comments here. I also hope to share some useful code snippets, but I don’t have a place for that just yet.

Finally, and I wish I didn’t have to mention this, but we are working on a set of standards for inclusion in both sites. For now, lets just say, if you are going to contribute, lets keep it professional and Perl/Science related, and the site owners will make final ruling on what is added. Hopefully we don’t have to use that power often.

So that bit of legaleese aside, please come and enjoy both sites. I hope people learn and people teach others. Lets make Perl (good Perl) relevant in the science community again!

After coming home from YAPC::NA I have a renewed vigor for coding. Because of that, I decided to brush up one of my modules that I haven’t released, document it and release it to CPAN.

Schwern and others talked about how to bring new people into Perl. For many this means making sure to include women and minorities in events and projects. For science however, I think part of the problem is the inertia of commonly used software. People don’t want to use Perl, because Mathematica makes math easy. True, but it makes programming hard IMO.

So here it is, another in my line of Perl-for-Science modules: Math::Mathematica hopes to make doing science easier in Perl. It basically starts a command-line instance of Mathematica in a PTY and controls the IO to and from it. This allows for easy writing of scripts those people that want the power of Mathematica’s math engine with the power of Perl’s language (something that Mathematica distinctly lacks).

Here is a simple example.

use Math::Mathematica;
my $math = Math::Mathematica->new;
my $result = $math->evaluate('Integrate[Sin[x],{x,0,Pi}]');

returns 2, as expected.

Of course I would prefer that you scientists/mathematicians look into my PerlGSL modules or PDL, however if you need to make a slower transition from Mathematica to Perl, this should help ease you in.

For completeness, the equivalent PerlGSL code would be

use PerlGSL qw/:integration/;
my $pi = 4*atan2(1,1);
my $result = int_1d( sub{ sin(shift) }, 0, $pi );

With this post I am happy to announce the release of my new distribution: PerlGSL. This accompanies several other releases I’ve made in the past few days, I’ll get to those in a moment.

A few days ago I asked what I should call my new multidimensional integration module. The discussion centered on whether it was more important that it required the GSL library, or whether it was a set of bindings for the GSL (was that set complete)? Was it a dist in its own right needing a toplevel name, or that it was mathematical and should be under Math::?

After discussion and reflection, I have decided that I wanted a toplevel namespce for this project, mostly because the need to satisfy the external dependency on the GSL separates these modules from others. To make it worthy of that honor, I have made it into a dist in its own right, not unlike other named dists like Mojolicious or Catalyst, though more modular.

Unlike those projects I am not reserving the entire namespace for myself; I want people to contribute to the PerlGSL namespace. Is it a set of bindings to the GSL? No, but close. I’m calling the namespace a ‘collection of interfaces’. Can there can be more than one interface to the same library? I’m OK with that. Does any need to span an entire library? No. Can a library pull several functions from different places to create one useful Perl module? By all means!

So what does the dist named PerlGSL do? First it serves to define the namespace. Second, if you install it, it will install what I am calling the “standard modules”. So far I am the only author of these “standard” modules, but I would love to add yours, though I reserve the right no to. I want the individual modules to live on their own, but be installable together; a modular, bottom-up collection, but one that can be installed together for convenience. PDL, for example, is a great dist, but it’s huge and mostly monolithic; I can’t just install what I need. I hope that PerlGSL finds a nice balance between monolithic and separate dists.

Ok on to the technical stuff. So far I have uploaded two new modules, and rechristened another. The new ones are PerlGSL::Integration::SingleDim and PerlGSL::Integration::MultiDim, I think their names give away their tasks :-). I have rechristened Math::GSLx::ODEIV2 as PerlGSL::DiffEq. These are all part of the “standard” modules, though you only get PerlGSL::DiffEq if you have GSL >= 1.15. I have also released a new version of Math::GSLx::ODEIV2 which announces its deprecation, though it does still provide the ode_solver function via PerlGSL::DiffEq for now.

I hope to add more functionality as I need them. I hope you might do the same. The GSL is too big to ask one person to wrap it all; very few people will ever need all of it. It is really good software though, and it works really well with Perl. I hope you enjoy it.

(Sorry, this has been a bit stream of consciousness, I have been working on this a little too much in the past few days to compose something concise it would seem.)

While I am still working out the bugs from Alien::Base I have released a little scientific side project named Physics::RayTransfer.

Calling all laser physicists! Does modeling your cavity using Ray Transfer (ABCD) matrices bore you? Do you regularly forget to include one of the matrices on the reversed arm on the round trip? Do you hate using that symbolic mathematical language? Try Physics::RayTranser!

It slices, dices, makes julienne fries and of course is a totally object oriented way to model your laser cavities (or other optical systems). No round trip matrices needed!

use Physics::RayTransfer;

# build the system using helper constructors
my $sys = Physics::RayTransfer->new();
$sys->add_mirror;
$sys->add_space->parameter(sub{shift});
$sys->add_mirror(8);

# parameter for for cavity length
# from 0 to 10 in 0.1 (cm) increments
my $d = [ map { $_ / 10 } (0..100) ];

# spot size at right mirror (OC) at 1063 nm 
# for each cavity length!
my @data = 
  map { $_->[1]->w(1063e-7) }
  $sys->evaluate_parameterized($d);

Finally, some of you might complain that the whole thing is written in MooseX::Declare and so you have to install that whole monstrosity just to use it. Oh well, its really fast to write, and I find writing OO scientific code very intuitive using it, so get over it. :-)