My first session of the day is Strawberry Perl: Achieving Win32 Platform Equality, presented by Adam Kennedy. Originally, I had considered a Parrot talk, but I saw a similar talk at SCALE6x, and I happened upon Adam on IRC this morning. I chatted briefly with him about his talk, and he happens to be in communication with a friend of mine, who is working on Camelbox, a Windows build of Perl originally targeted as a way to easily distribute applications written with Gtk front ends (I hope I got the motivation correct).
Recently, Adam has been funded by The Perl Foundation, Perl in Israel, and Stonehenge to use Perl from nothing but his flash drive. This provides an excellent motivation to get Strawberry Perl working in a highly portable way.
Originally, Perl was awesome and worked everywhere—except Windows. That was okay, because Windows didn’t matter. No one did any real work on Windows. Then, around 1995, Windows started to matter. A brief history of Perl on Windows followed, resulting in what is today ActiveState.
Much of what Adam wrote for PPI does not work in ActivePerl, which makes it a non-starter for him, as he tends to work on Windows. Anything depending on Scalar::Util or List::MoreUtils modules will not work with the ActivePerl build system. This led to an embarrassing problem for Adam when he gave a talk three years ago at OSCON. He couldn’t give his demo, because PPI would not build in ActivePerl. In fact, ActiveState’s package manager has gotten so much worse that almost any module that is at all useful does not exist—and thus nothing useful can be done on Windows (big surprise).
Moving away from ActiveState, this talk is essentially about Adam trying to get his own laptop to work. That’s really all he wants. It’s a modest desire. More importantly, the CPAN module has to work. Without that, what’s the use of Perl?
So Adam offered a prize: a yard-high stack of cases of any beer desired by the first person who could provide a fully-installable and working (by the above definition of working) version of Perl for Windows. After six months and no sign of a winner, he changed the prize to “craploads” of beer. In 24 hours, he received two entries. The winner cheated a lot, but the loser was Vanilla Perl, which has become a testing ground for experimentation.
Strawberry Perl is the Perl for Windows designed for people who don’t use Windows. That is, the people who do all of their work on Unix or Unix-like systems—Linux, Solaris, and Mac OS X. The main goal of the project is to make it easy—it is Perl, after all.
In the future will come Chocolate Perl—completing the holy trinity of neopolitan flavors—for people who know Windows, but don’t know Perl, and thus the Unix-like characteristics of Perl.
The target of Adam’s financial support is Portable Perl: Perl for flash drives. Carry it around, install CPAN modules onto, or from, the flash drive. It’s network-aware, does the right thing, and juliennes fries. An excellent standard being developed for portable apps is, in fact, PortableApps.com, where applications such as Firefox or Putty can be downloaded and installed to those ever-growing flash drives.
Available Thursday at the Perl Foundation‘s booth in the expo hall will be branded flash drives with Portable Perl on them. At least, I think I heard that correctly.
I really like the work Adam is doing. He’s accomplished so much to get Perl everywhere. That’s a cause I can get behind.
“The main problem today is Vista.”
— Adam Kennedy
Okay, I took that out of context, but I couldn’t resist capturing the quote. What he really means is that changes made to Windows in Vista have made things not work, in particular the access control. It’s not an unusual problem when upgrading to new systems, but it is more difficult with proprietary platforms, which Open Source authors have very little access to.
Hi there, I’m Gisle and I work for ActiveState. I just wanted to
comment on the issues raised about ActivePerl in this post.
Claiming that PPI and other modules depending on List::MoreUtils do
not work in ActivePerl isn’t accurate. What’s true is that the free
repository ActiveState has provided for PPM packages built from CPAN
has not been able to provide a pre-built List::MoreUtils and therefore
not a pre-built PPI because of technical compatibility issues. Even
if our PPM repository did not provide these packages, you could easily
install them from other PPM repositories or use the CPAN shell the way
Strawberry Perl now supports. There is nothing in ActivePerl itself
that has made it unsuitable for running these modules.
ActivePerl has supported out-of-the-box module install from source via
the CPAN shell for users that had the free MinGW compiler installed
for almost 3 years now (since our 815 release).
I’m also glad to say that the problems with our PPM repository will
soon be history, and that you can already install PPI without problems
from our new PPM repositories, currently in beta at
. The beta repository currently
contain about 2000 additional Windows packages compared to the old
repository. The built system for the new repository is a complete
rewrite where we let the CPAN shell do most of the hard work, giving
us a system with much higher success rate and one that puts up
pre-built packages usually within a day after they have been published
to CPAN. We are quite exited about it and we hope our ActivePerl
users as well as the Strawberry Perl users will find it a useful
service.
I almost didn’t approve the comment from Gisle Aas, because I really don’t care about ActivePerl. I am not a Windows user, so ActivePerl really doesn’t show up on my radar aside from the occasional user I need to support who uses it.
However, my strong belief in Free Speech led me to post it, even if I don’t agree or care about it.
Regardless of how proactive ActiveState is at defending ActivePerl, the fact that Strawberry Perl and Camelbox even exist, along with some of the issues I’ve seen Ovid have with the build system, tells me that something actually is wrong with it. My understanding is that, when people have gone to ActiveState for support, they don’t receive any. We’re the Perl community, and we’re good at getting things done.
You say that you don’t agree with my comment. Was the anything in particular you find wrong?
The URL to our beta repository seem to have gone missing; it was supposed to be http://ppm.activestate.com/beta/
So, if all of this supposedly works already, why aren’t these people using ActivePerl instead of rolling their own Perl distributions. It’s been my experience that people of the caliber of Adam Kennedy don’t spend this much of their time on things like Strawberry Perl without good reason.
Why, if these things supposedly just work, do Adam and Ovid have such trouble getting things to just work?
Again, I don’t use Windows and I don’t use ActivePerl. I have been a Linux user for over ten years and feel very uncomfortable when using Windows, so I’m not the right person to say what’s right or wrong with ActivePerl. However, both Adam and Ovid have had quite a bit to say about the frustrations they’ve experienced with it.
I had not heard of the beta PPM repository and I welcome any improvements in ActiveState’s CPAN support.
Historically, though, these links reflect what I’ve seen of ActiveState’s PPM:
http://ppm.activestate.com/BuildStatus/5.6-T.html
http://ppm.activestate.com/BuildStatus/5.8-T.html
I’m just singling out the T’s because many of those Test:: modules happen to be important to me and I’ve had mixed results over the years getting the CPAN sources built on win32 via ActiveState Perl.
Adam also indicated in his talk that Vanilla and Strawberry Perl will help shorten the feedback cycle in order to get more attention on win32 specific issues in modules. And this is really what needs to happen rather than hoping Activestate will shoulder the entire burden of CPAN on win32.
po, do you have comparable build-status tables for Linux or Strawberry Perl?
It might just be that most of those modules weren’t created by someone who
programs portably.
http://testers.cpan.org/