use Perl

In response to the release of Perl::Shell, Shawn Moore had some fairly nasty initial feedback he chose to post to cpanrantings.

So I thought I should at least explain why I created it (in a location that won't be polluting).

Like with many areas pioneered by more advanced users, my main problem is mostly with Windows support.

Lets start with Devel::REPL, and why I didn't just use it instead.

Partly, this is my fault. For some reason, I thought Devel::REPL used Coro, so when "testing" Devel::REPL I first tried to install Coro, which won't build on Windows at all.

Of course, because I was completely mistaken about Devel::REPL I missed the fact that Devel::REPL installs just fine on Win32. I really should have known better, since Matt Trout himself uses Windows.

The only problem with DeveL::REPL is that the perl shell it provides "re.pl" doesn't work on Windows as documented, because the .pl extension is associated with who knows what.

Devel::REPL also has some other minor problems, such as using vstrings in use lines (which throws a warning), allowing incomplete statements (although a few patches from me to the PPI functionality should fix that) and odd visual behaviour when you print something without a trailing newline.

Frankly, Python did the shell usability things really really well, and I would personally would just like a clone of the way they do it.

Looking at this situation, I'll probably end up ditching Perl::Shell, and moving "perlthon" to App::Perlthon instead, since it should be a fairly lightweight wrapper around Devel::REPL, once some bugs in Devel::REPL are fixed.

As for the other alternatives suggested by Shawn Moore, the field is a bit thinner.

Shell::Perl doesn't work on Windows, so is irrelevant.

App::Perl does install, and it's iperl shell does SORT of work, but all the prompts spew weird crap to the command line. It looks like maybe it's coloured ansi gone bad.

perlconsole installs on Win32, then spews some warnings that stink of Unix biases, and doesn't support implicit multi-line statements, plus is kinda noisy.

Zoidberg I have never heard of, and would never have found in a CPAN search, and also doesn't work on Windows.

Finally, Sepia's Makefile.PL starts with the particularly inspiring comment...

        To actually use this package in a useful way, you probably need to
        move the Emacs Lisp files somewhere. Where will depend on your
        installation.
... and then starts asking questions about optional features I have no idea about.

It installs, but at that point I actually looked at the search.cpan page for Sepia, to discover it isn't even a shell at all, but some kind of extension for an editor I don't even use. So the message makes a bit more sense, but the module is still useless to me.

So apart from Devel::REPL, they are all entirely useless from a cross-platform perspective (but obviously more useful if you don't mind being Unix-specific).

Apart from the initial mistake of misjudging Devel::REPL, it would seem there WAS room for a new shell.

I agree that with Devel::REPL, there's probably no need for another complete standalone shell. Instead, I'll probably just fix the various annoying bugs in Devel::REPL, and then rewrite "perlthon" around it instead.

Unless of course, Devel::REPL wanted to use it instead of the current re.pl script...

strawberry-perl-5.10.0.2.exe (Strawberry Perl 5.10.0.2 Installer)

strawberry-perl-5.8.8.2.exe (Strawberry Perl 5.8.8.2 Installer)

Due to the work on the Perl on a Stick grant, not a lot in terms of man hours has been done on the main Strawberry Perl distribution in this quarter (and it has also delayed the release by about a month due to some major modifications to Perl::Dist).

Apart from the usual updating of the toolchain and bundled modules to the current versions, this release adds one major and one minor feature.

Most importantly, the dreaded Vista GCC compatibilities are now finally killed, once and for all. This release contains the (long awaited) production GCC release with the MinGW team's fix for the Vista incompatibility bug. In addition to this, I have a number of reportes now that the Vista Service Pack 1 update also repairs this bug for previous Strawberry Perl releases.

The other minor change added in this release is the addition of Math::Pari to the list of modules bundled in the default release. This is not useful directly, but means that an important and difficult dependency of many crypto-related modules is now reliably available.

This should result in much better ability for Win32 CPAN Testers machines to test the various crypto modules, which should subsequently help improve the deplorable state of the Perl crypto modules on Windows platforms.

Although this release does not come in a Portable version (yet), the Perl::Dist infrastructure needed to produce Portable releases automatically at the same time as the regular releases is now largely completed.

So the new limited edition black "Perl on a Perl on Stick Stick" USB flash drives should work correctly on Vista machines as well.

With this release out of the way, I get to concentrate on finishing talks for YAPC::EU. Good thing too, since I leave for Copenhagen tomorrow.

As usual, if there's any immediate feedback or something isn't working correctly, please post it below.

I'm happy to report that phase 2 of the Perl on a Stick grant is now completed.

This phase required the creation of code that would take an existing distribution, and make the necesary changes to convert that distribution into a portable distribution/

This now works ok, and given the interest in a future OS X Perl on a Stick I've also kept it completely cross platform (or so I believe).

Portable::Dist is available on the CPAN if you want to see the specific changes needed to make a distribution portable.

This brings me to Phase 3 - Integration, in which I will be integrating the use of Portable::Dist into the Perl::Dist distribution building system, so that in future we can built Portable versions of ANY distribution at on the additional cost an extra compile run.

Having now completed basically all the enbugging, I shall also be moving more agressively on the debugging front.

Seriously, the things I do for you people.

With the Portable alpha, and feedback starting to roll in, the most obviously blocker for Perl on a Stick is that the batch files produced by pl2bat don't work when Perl isn't in PATH, which for the portable situation is a given.

The trouble with batch programming is that it's such a dead language at this point, it's hard to even find good information about it.

So in Portland, I undertook an expedition to the glorious fantabulous Powell's Books, in the hope that if anyone could find me something, they could.

Alas, the only remain batch file programming book in the United States was stuck in their warehouse in Chicago! :(

Fortunately, Powell's expert Michael Schwern came to my rescue and after some scrounging in the second hand books sections, emerged with just what I needed.

Aside from being extremely old, it also happens to be about the most embarrassing technical book I've ever owned. Pulling it out at the coffee shop in front of an assembled gaggle of Perl/OSCON geeks resulted in a loud chorus of laughter...

http://www.flickr.com/photos/xwrn/2702817504/

And so between this book, some built in Windows help information, and some online tutorials, I've managed to piece together a fix to pl2bat to make the batch script look for and use the perl executable in the same directory as the .bat file, rather than using the PATH version.

The specific line is:

FOR %%i IN ( %0 ) DO %%~di%%~piperl -x -S %0 %*

In a way, I'm quite lucky that it turned out so easy, given how utterly dysfunctional Windows batch is as a "language". By comparison, shell script is elegant and well structured.

The key problem here is that batch doesn't have any string manipulation functions at all, nor does it have much of a file system interface either.

It does (sort of) support variables, which is the "%i" in the above. Except that it's only %i if you use a variable on the command line. Inside a batch script you have to use %%i instead. Don't ask me why, I've never seen any explanation. It just is.

The "perl -x -S" bit is straight forward by comparison...

%0 is the equivalent of $0, and %* is the equivalent of @ARGV.

The tricky bit here is that there's literally no way to turn a string like C:\strawberry\perl\bin\foo.bat into C:\strawberry\perl\bin\perl.exe, so you can call the correct Perl instance.

So instead, we need to badly abuse some evil functionality built into the FOR command/loop.

The FOR command has a bunch of wildly diverse, and utterly insane, ways of working.

But the interesting one is when you use it to iterate over files, like so:

FOR %%variable IN ( file1.txt file2.txt ) DO something

If, and ONLY if, FOR is used to iterate over a list of files, and it knows they are files, then some magic %%variable stuff comes into existance.

These looks like %%~(letter)variable, and let you access different bits or variations of the file name.

The two useful ones in this case is %%~dvariable, which gives us the drive letter for the file in the form "C:", and %%~pvariable which gives the path in the form "\strawberry\perl\bin\".

And thus, by doing a completely useless single value for loop FOR %%i IN ( %0 ) DO we can cause the magic variables we need to come into existance, from which we can just do a simple string concatination (which needs no syntax, because it's just implied) and add perl.exe to the end, which gets us all the way to something that is rediculous, but works.

Of course, this only works post-installation, and wouldn't be usable at all if you called it in the modules blib at build time...

Making THAT works gets even weirder, and will most likely require more thought.

But it does look like I'll have batch stuff working properly by the time YAPC::EU rolls around, making the YAPC::EU "Perl on a Perl on a Stick Stick" much more functional than the American version :)

It's reasonably to say that I expected my OSCON Strawberry Perl talk to be somewhat incendiary.

I also had hoped that (like last time with the PPI talk) a number of ActiveState people would be in the audience, so that we could talk about these issues directly.

But alas, other than one person I'm aware of working on the FOSSCoach booth, as far as I can tell ActiveState didn't show up at OSCON. (I could be wrong, but I would imagine if they were there, they'd be at my talk)

They have, at least, responded to some of the commentary generated by the talk

http://sirhc.us/journal/2008/07/23/oscon-2008-strawberry-perl-achieving-win32-pl atform-equality/

Although this could easily descend into a Chinese whispers argument here, it's worth pointing out a few clarifications.

For a talk, I think it's reasonable to sum up the status of modules as "they don't work". Yes, technically they DO "work" on ActivePerl, in the sense that you can install ActivePerl, then completely ignore the method they provide for installing modules, set up your own compiler and make, configure CPAN yourself, and then do the install directly, running the tests, and then once installed the code will "work".

Or you can ignore the server they provide for installing PPM packages, and use somebody elses. Or you can ignore repository clients and download the tarballs by hand and build them yourself. And so on, and so forth...

But it's my position that once you provide an installation channel as the default way to install packages, that you judge the distribution based on THAT channel, not on some workaround method.

Similarly the claim that CPAN works on ActivePerl "out the box".

As far as I'm concerned, "out the box" means you can just install the distribution, then start CPAN and type "install Module" and it Just Works.

I don't consider "out the box" to mean installing the distribution, then separately downloading and installing a compiler, configuring it yourself, and installing make, and then configuring CPAN, and THEN starting CPAN and typing "install Module".

All of this leads me to wonder if anyone at ActiveState actually dogfoods their own distribution in an "out of the box" configuration.

Fortunately, at least this situation looks like it may improve, now that they are throwing away the PPM respository and starting again. The Beta does indeed look much better.

To mark my Strawberry Perl talk at OSCON (which although somewhat lightly attended was well received) I had desperately tried to have both the new Vista-compatible July 2008 Strawberry beta, AND the second alpha release of Perl on a Stick ready for my talk.

Despite burning both the midnight oil AND a dozen or so CPU hours, I missed it due to an untimely flash-drive-transmitted computer virus I think I caught from an Internet Cafe in Sydney while doing some field testing of Perl-on-a-Stick and the PortableApps.com platform.

This was a bit sad, since with the mighty help of Jim Brandt and the TPF we had procured a 50-run limited edition flash drive, labelled with the Perl onion logo (i.e. The Perl logo on a memory stick). I had hoped to be able to distribute them (for a small donation to the TPF of course) during the talk.

No matter though, because I did manage to get the final packaging issues for this new release (which combines BOTH the July 2008 Vista-compatible Strawberry Perl AND the Perl-on-a-Stick alpha 2 code) resolved by early evening, and produced the first master zip file.

The result? The special new Super Schwag "Perl on a Perl on a Stick Stick" flash drive, featuring Perl both on the outside AND on the inside of the memory stick.

I believe there are around 40 left at this point, although based on initial demand just from the late evening, it looks like they are going to disappear very quickly tomorrow.

If you happen to be in Portland, or know someone that is, you can find them available for a donation of $15 from the Perl Foundation stand in the Expo Room at OSCON 2008. Hallway and expo-only passes are available to grt if needed I believe.

Based on the reaction so far, if we run out I will try to arrange a second batch to take to YAPC::EU.

I've also had more than one person ask me if Perl-on-a-Stick distribution could be produced targeting Mac OS X rather than Windows.

In principle I don't see why this couldn't be done, although worry adding this capability to Perl::Dist would be quite difficult and possible MORE than double the code size.

But then the Portable is mostly cross platform already, and the main problem would be working out exactly HOW you would structure a complete Perl installation (including C libraries and what not) inside a directory at an arbitrary location.

I'm not sure a standalone installer for Mac OS X has been done before (could be wrong here though). But it does remain an excellent idea though, given the Mac density amongst the Perl glitterati.

Apart from pushing forwards to production releases, the only other plans I have for Perl::Dist in the short term is to try and split out the C-specific code form the Perl-specific code, with a view to creating an alternate build subclass capable of creating some sort of "Vanilla Perl 6" Win32 distribution.

This pair of new releases incorporates both the new (far more robust than the original) File::ShareDir implementation, as well as the new install_share command in Module::Install to go with it.

When using install_share for new releases, please make your dependency on File::ShareDir is set to 1.00 or higher to ensure you have the new implementation (Module::Install will not automatically add it, but may in the next release).

This release of Module::Install also includes a fairly large number of small to medium changes (see the Changes file if you are interested) but nothing that should be particularly explosive in nature.

I'll be around a lot over the next few days to keep an eye out for any fallout from these changes, so if you find something working wrong don't be backwards in coming forwards.

Every now and then on the CPAN we get some variety of weird, unusual, destructive, or simply batshit insane insane authors.

Typically they upload one, or two, or 10, or maybe even 20 modules of dubious value, and then most of the time they burn out after 6 months or so and dissappear.

Every time this happens, discussion will circulate pondering why we don't crack down on people, or restrict uploads or something of that nature.

This talk by Clay Shirky provides what I think is the best and most elequent explaination I've seen yet of why CPAN continues to maintain such low barriers.

http://xrl.us/kkwmp

Of course, full credit for maintaining this policy for the CPAN goes to Andreas, who understood this long before the rest of us, and continues to hold firm in his position.

I've just uploaded the redesigned File::ShareDir, which should both resolve the various problems with the original design, AND (hopefully) be fully back-compatible with old previously-installed files.

Any testing people can do would be appreciated.

To install files into the new paths, please use the svn version of Module::Install from http://svn.ali.as/.

In short, previously there was some confusion between module files and distribution files, and had packlist-related problems in some areas.

The new install paths look something like .../auto/share/dist/Distribution-Name/test_file.txt

http://strawberryperl.com/download/strawberry-perl-portable-5.10.0-alpha-1.zip

This is the first release of Strawberry Perl Portable Edition for Mobile Devices and Flash Drives (or whatever the hell it ends up being called).

Firstly, please note this is extremely alpha. In fact it's SO alpha that it's basically just whatever is on my test flash drive, zipped up with no packaging at all.

To install, simply unzip it absolutely anywhere you like.

The code that implements portability can be found in the Portable:: modules, and the bootstrapping mechanism involves hooks in Config.pm, CPAN/Config.pm, File/HomeDir.pm and CPAN::Mini::Portable.

To run a Perl program, invoke it via "X:\yourpath\perl\bin\perl scriptname.pl".

CPAN installs SHOULD work.

The .bat file program launches, however, do NOT work, so don't even try.

That said, feel free to play around, break, and critique it.

Let me know how it goes. Being VERY alpha, I do expect things to break.

Thus endeth the implementation phase of my Perl on a Stick grant.

The next phase is the build phase, where I do the necesary hacking to be able to generate Portable editions via the Perl::Dist toolchain.