Well, the final version of perl 5.12.0 has been integrated into the build process for a few days now.

The reason it hasn't been released yet is that there are a few final things I've been working on:

  1. A C++ custom action to do the "perl relocation" step. Beta 1 actually called the Perl script that the zip file will use - and while that's fast enough, it's not as robust as I'd feel comfortable with. I wrote it as a separate executable, it works, now I just have to connect the C++ code to Windows Installer, and that is not looking as easy as I expected... but it should be done today, if everything goes well. (My sister is moving out, and I'll need to help her today, too.)
  2. I've heard reports of crashes on 64-bit systems during uninstallation - I want to get on fixing that as soon as #1 is done.
  3. It's going to take 8 hours after those two things are done to build Strawberry Perl, and then 4 more hours or so to upload it.

24-36 hours, I hope (48 at the most), and Beta 2 will be announced here, and will include a 5.12.0 final.

This means that the April 2010 final version (not Beta 2) will be the last version of Strawberry Perl 5.8.9 built. It'll still be supported for a while (how long is up for discussion - I'm thinking until the October 2010 releases, myself), but I'd encourage moving to 5.10.1 or 5.12.x.

You CANNOT assume that sizeof(void*) and sizeof(long int) are equal and expect your module to compile in a Win32 environment with 64-bit (x64/amd64/Intel64, etc...) compilers - at least if gcc is the compiler that's being used with Perl.

The reason is that it isn't! sizeof(void*) == 8, sizeof(long int) == 4 in this case.

We have a tracking bug in Perl-Dist-Strawberry that we call "the bitness of the why" that tracks modules that we'd like to see fixed with regard to this and other 64-bit issues. It's at http://rt.cpan.org/Public/Bug/Display.html?id=55336 (non-logged-in) or https://rt.cpan.org/Ticket/Display.html?id=55336 (logged-in) if you want to look at it.

If you have a module that you expect to work on 64-bit Strawberry Perl, you should be able to install the 64-bit 5.12.0-RC0 beta, and try to install your module there. Some may already be - that means that they compile, and probably pass their tests. you++!

kmx is doing a lot of the work in this regard, and I thank him for it.
Go to http://strawberryperl.com/beta/ to test them...

And I could use the testing, on many machines.

Yes, I know that one of the custom actions causes a memory access error on 64-bit machines. (I'll have to check if this is the case for all builds, or just for 5.12.0-RC0.)

Yes, I know that there is a cosmetic issue (strange characters) in an error dialog.

Anything else you find, PLEASE report.
Well, Strawberry Perl Beta 1 has been released, at least in the perl 5.8.9 and 5.10.1 incantations.

Speaking of 5.8.9, I'll build a D-drive version for final, but not for the beta testing. This is ONLY because 5.12.0 final is not out yet.

As for the 5.12.0-RC0 versions, I'm working on getting relocation to work with them, and have been playing "whack-a-mole" with small problems with it - the main one now being that some of the .packlist files have been left behind in previous versions of Strawberry, usually because I just picked up the modules with the wrong name, so Perl::Dist::WiX could not find the packlist. I've done this about 8 times in the past 2 days, along with going to my party caucus last night, helping my mother pack for a month-long trip, and the other etcetera of a normal life...

It hasn't been important in the past, but when I did the build to find out which files needed relocated, I used the .zip file to do it, not the .msi with the files missing. And no, I'd prefer that the .packlist files come along. inc::latest wants them now, among other things.

And each build takes 1 hr 40 mins to create, then move it over to another VM to run a logged install (msiexec /l*vi sb-msi.log /i strawberry-perl-5.12.0-RC1.0-beta-1.msi), then determine how to get the file in, etc... that takes a little time.

I just realized this morning that I can attempt to deal with all of them at once. How?

Well, to do that, I need to do one more build. One where I can give it a property to bypass the relocation script. (I needed to set a condition to run the relocation script on installs only, anyway, so I just added the property to that condition.) Then if there is still a problem, I run it a second time with logging off and that property set. I do a "dir /s /w /v > msi.txt", uninstall the msi, extract the .zip, do a dir on it with the same options, but redirecting with a different file.

At that point, I bring the two files back into my development VM, which has File::List::Object. I load them into two FLO objects, and subtract the msi one from the zip one, and print out what files are left over.

That's the missing file list, and I can nuke what moles are left all at once!

That'll take building one more build, then testing it on a Windows XP VM, then my Windows 7 host machine, building 64-bit a time or two and testing IT on the host machine (it may need nuke-a-moled just because I can't install all the Strawberry modules on 64-bit yet, and I may have missed excluding one or two from the list that's generated for a 64-bit build), and it'll be soon releasable to a suspecting world! Hopefully late tonight, but could be tomorrow.
die(), or die() not ... there is no try().
  —Yoda, on exceptions in Perl.

Well, as the Perl Foundation blog says, I'm working on getting relocation working, and it'll be a race to see what gets done first: getting relocation working, or Perl 5.12.0 RC0.

Once both are done, I'll release the first betas for the April cycle.

Right now, I've hooked in a "choose the location" dialog into the installer for 5.11.5+ versions, and I've just finished blocking the ability to install into a directory with spaces.

(Unfortunately, until I can safely run dmake (which I know does not work) and all the other modules in the toolchain that Perl relies on in a directory with spaces, I'm blocking the ability to install into a directory with spaces. There is a code to get around it, if you REALLY want to know... but you have to ask me for it, and I can't support it if you do.)

The other "unfortunately" that's a problem is perl RT#73562, which is going to prevent 5.10.1 from being relocated if I don't get a patch I can use for it.
The last week or so, a lot of the work on Strawberry Perl has gone to making sure that what I'm calling the "gcc4" toolchains from the mingw64 project will work to build Strawberry Perl.

And it's looking like that will happen, as the two toolchains (a 32-bit one and a 64-bit one) will work, at least as far as building what's been called "Vanilla Perl" in the past is concerned.

There are three XS modules in current versions of Strawberry that have issues with 64-bitness that I know of so far. (Compress::unLZMA, Math::Pari, and Crypt::OpenSSL.) I may find out about more as I attempt to build Strawberry Perl.

KMX has built new versions of the libraries that some XS modules rely on (postgresql, mysql, libgd, libtiff, libjpeg, etc.) that should not have name conflicts with other DLL's on the system, and the 32-bit versions will work with both the gcc3 and gcc4 toolchains.

I'm attempting a 32-bit build tonight of Strawberry Perl with 5.11.5, gcc4, and the new libraries. After that, I'll attempt to do the same with 5.10.1.

Soon will also be a 64-bit test with 5.11.5 and the 64-bit "new libraries".

As I've previously stated, 5.10.x versions of Strawberry will be 32-bit only, and will stay on the current "gcc3" toolchain. They WILL use the new libraries - which will solve DLL problems that have sometimes occured when other programs have DLL's with the same name.

I've said in the past that we'd have a 64-bit version of Strawberry available for April. That will be both true and false, for I won't be able to release a non-beta version of 5.12.0 before April 30th (for that to happen, I'd have to have the perl 5.12.0 tarball available to build upon before April 2nd, and I don't think that'll happen, with apologies to the perl5-porters.)

There will be a 64-bit beta available soon - most likely by the end of this month. While I'm currently testing 64-bitness with 5.11.5, 5.11.6 will probably be available in 2 weeks, and I'll release the beta soon after that. There will be NO non-beta 5.11.x versions of Strawberry Perl - as those perl versions are practically betas themselves.

The intent is to have 3 or 4 beta test versions of Strawberry Perl for the first beta towards the April release:

  1. A 32-bit

  2. A 32-bit

  3. A 64-bit

  4. A 32-bit with the Professional additions may or may not happen.

Watch for the beta to come out around St. Patrick's Day, with betas a week or so afterwards.
The generation toolchain for Strawberry Perl Professional Alpha 1 has been released as CPAN modules if you want to see it.

They're all development versions (final versions of the modules will generate final versions of Strawberry Perl and Strawberry Perl Professional.)

To install the generation toolchain, type in the lines below:

cpan CSJEWELL/Perl-Dist-WiX-1.102_100.tar.gz
cpan CSJEWELL/Perl-Dist-Strawberry-2.02_03.tar.gz
cpan CSJEWELL/Perl-Dist-Chocolate-2.02_01.tar.gz

Of course, the svn repository is at http://svn.ali.as/cpan/trunk/Perl-Dist-*/

Well, there is now an alpha version of Strawberry Perl Professional up. I'm calling it Alpha 1 (as opposed to, say, " Alpha 1") because it's be built on top of Strawberry Perl [The January 2010 version.]

"Strawberry Perl Professional Alpha 1" includes:

  1. All graphical toolkits that I know about and can get to build easily (Tk, Wx, and Win32::GUI at the moment. OpenGL will be in the next version.)

  2. Graphical CPAN client (CPANPLUS::Shell::Wx) and POD viewer (Tk::Pod) *

  3. The Padre perl IDE, and Perl::Tidy, Perl::Critic, and Catalyst plugins for it.

  4. Moose and a number of MooseX modules.

  5. Catalyst::Runtime, Catalyst::Devel, and a number of Catalyst/CatalystX modules, including the Catalyst::Manual.

  6. A console Perl-language shell (Perl::Shell) - Devel::REPL may be in the next version. **

  7. Dist::Zilla, Devel::NYTProf, Perl::Critic, Perl::Tidy, BioPerl...

  8. ... and everything that's already in Strawberry Perl.

(Everything that's specifically in Professional is listed in DISTRIBUTIONS.txt)

One goal for the next release is to have Padre linked in as the default editor for .pl, .pm, and .pod files. This alpha is just to test the modules chosen and to shake things down - and maybe prod a few more CPAN module authors into getting their modules working better on Windows.

There is no release notes page for this build yet - that will come with the next alpha or beta, whatever I decide to call it.

There will be no 5.8.9.x version of Strawberry Perl Professional - It will only come in 5.10.1.x versions for the moment. It's taking me 4 1/2 hours to do one build of Professional, and I just bought this machine in October - anybody want to contribute to a second machine to start a build farm?

To download this version, go to the Strawberry Perl beta page.

I'm calling it an alpha because I KNOW some things do not work, and others may not work well.

In particular, CPANPLUS::Shell::Wx (the graphical CPAN shell linked from the start menu) crashes just after the splash screen starts. You, in particular, have been prodded. :) If you know Wx, send the author patches. (I'm going to start learning it)

* Devel::ebug::Wx [a graphical Perl debugger] would be nice to have, also, but Devel::ebug is not testing correctly at the moment, so I don't trust it enough to include it here. If you want it, apply tuits.

** I may or may not remove one of these before release. Depends on what is wanted and working well.

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world...
Surely some revelation is at hand;
Surely the Second Coming is at hand.
  —William Yates, The Second Coming

I've got 3 release announcements to do:

  1. Strawberry Perl January 2010.

    It's been out for over a week - I really should start writing these release announcements beforehand. This is an "upgrade version" - The only new module is GDBM_File. There are a number of non-user-facing internals changes, however. Things just got too busy over the holidays to do the user-facing changes that were planned. is at: http://strawberry-perl.googlecode.com/files/strawberry-perl-
    Other releases are mentioned at: http://strawberryperl.com/releases.html

  2. "Strawberry Perl plus Padre" 0.56.

    This is the new version of what has been previously called "Padre Standalone". In this case, it's been updated to the latest versions of both Strawberry Perl and Padre.

    http://strawberryperl.com/download/padre/strawberry-plus-padre-0.56.msi http://strawberryperl.com/download/padre/strawberry-plus-padre-0.56.zip

  3. "Merge Module" for Strawberry Perl.

    We're starting to build a merge module that can be used in other Windows Installer packages. The infrastructure to do this was one of the things that got added to Strawberry Perl in this version.

    If you're wondering "What is a merge module?" - a merge module is a Windows Installer "sub-package" that can be included in other packages.

    More documentation about how to include Strawberry Perl in their own software will be posted within the next few days.

Plans for April:

  • Relocatability on install

  • "Strawberry Professional"

  • 64-bit versions

  • perl 5.12.x (assuming it gets released soon enough)

  • Non-admin installation and support

Usual location: http://www.strawberryperl.com/beta/

This one is close to the final version for January 2010.

It includes a ParserDetails.ini file (which was missing in October 2009) and also includes GDBM_File (which was requested for the Koha library software)

Please test this and report bugs, as we are getting close to the end of the month, and I intend to release the final version for January 2010 before I need to call it February 2010 if at all possible.

Special note: If your module is one that's in Strawberry Perl (see http://www.strawberryperl.com/release-notes/ for a list) I will be pulling down the versions of your modules that will be included in Strawberry Perl on Tuesday at approximately 0800 US Mountain Standard Time (1500 GMT)

If your module has not been uploaded to CPAN by that point, and it includes a specific fix for Win32 systems, you'll have to e-mail me at csjewell at cpan dot org in order to get it in.

If I need to delay (or use a development version) because a specific fix is going to be arriving on CPAN after that time, again, e-mail me and we'll talk.
I just don't happen to be a "regular blogger" right now...

But I will mention that I've finally got January 2010 Beta 1 up.

There aren't going to be many changes - got distracted quite a lot over the holidays, and a lot of things just "aren't ready for prime time yet", but there are a few improvements.

To get it, go to http://strawberryperl.com/beta/ , as usual.
The major additions to Strawberry Perl for October 2009 are:

  1. We now provide 5.10.1 instead of 5.10.0 (5.8.9 is still available, as well.)

  2. We now include DB_File, so that BioPerl will install.

  3. Module::Signature and Crypt::SSLeay are now installed, as well as other crypto modules, so that we have support for signing CPAN modules (and checking the signature of CPAN modules) and for https: web sites.

  4. We now include DBD::Pg and the Postgres client library, so that PostgreSQL databases can be used without any other software installed.

  5. We now separate Strawberry-installed modules from the modules you install. Because of this, future versions may be able to not have to delete all the modules that you install.

Of course, report any bugs you encounter with Strawberry itself, or any enhancements you'd like to see, to the appropriate places, and download it at http://strawberryperl.com/

(Yes, I know the announcement is a week+ late - I've been busy getting stuff going for January already!)
There are a number of major things that are going to be added - some visible, some not - for January. This isn't in any particular order.

1) Toolchain updates - I plan to be able to update the toolchain to gcc 4.x for builds of perl 5.12.x, which should be coming out within the next 3 months or so. 5.10.x builds will still be with the current toolchain. This also includes the ability to have a 64-bit build of Perl - people have requested it.

Status: The ability to switch toolchains has been put in. We're working on getting a stable gcc 4.x compiler that can build both 32 and 64-bit versions.

Note that 64-bit and perl 5.12.x versions of Strawberry will stay as betas through the January release cycle - they will not become non-beta until April at the earliest.

2) Relocatability: The ability to install Strawberry Perl anywhere, instead of hard-coding the installer to c:\strawberry.

I've started on this, and what has been done is in the svn. I'll start work on this again after #3 is done.

3) Building Strawberry Perl as a msi merge module for use in other programs.

Status: In progress - 80%+ done as far as Perl::Dist::WiX is concerned. After that, I need to test this with Strawberry. This is inchstones number 4 and 5 in the grant.

4) Building off a git checkout. This was requested in p5p - and it's really a good idea - it'll make things easier for me when testing new versions of Perl.

Status: This is done and working as far as Perl::Dist::WiX is concerned. This may or may not be put into Strawberry, I haven't decided yet, and even then, I'd never release a non-beta version off a (non-tagged) git checkout.

5) Integration scripts (local::lib, .zip/environment variables, .zip/relocatability)

Status: Not started yet. #2 is a requirement for being able to get the .zip/relocatability one done, so all 3 will probably be done at the same time - proabbly late in November.

6) Ability to install Strawberry as a non-administrator/current-user-only.

Status: Barely started. Will work on this and #2 at the same time.

7) Add an option to load the README.TXT file and the release notes page at the end.

Status: Not started yet. Probably won't get done until after the relocatability.

8) Checking for other perl installations in the PATH.

Status: Not started yet.

9) Windows Explorer integration

Status: We're still discussing what exactly we want to do and how.
Here are the release candidate files - all wrapped up and ready to be tested to destruction. If there's a bug, let me know at csjewell@cpan.org.

If there are no bugs reported in a week or so, they'll be the final versions. If there are bugs that absolutely need fixed before January, another release candidate will be created.

Yes, unfortunately, the "eternal uninstall" problem is still there in these versions - I haven't had time on the right computer to do anything about it. [That'll be late this week/next week, but I don't want to put a fix for that in a release without having it in a beta - I recall the problems I had with July's Beta 1 in that department, and I don't want the same thing to happen with a release.]


It turns out that Portable and the "vendor" changes butted heads and broke horns against each other, so that @INC was messed up and the portability code never got ran. :(

At any rate, I'm making a patching .zip available that replaces 2 files in the Strawberry Perl October 2009 Beta 2 portable .zip available at http://strawberryperl.com/beta/.

The patch files provide a workaround for RT#50062, which should fix RT#50087, and it also adds the updated portableshell.bat that is mentioned in RT#49958.

(The README file mentioned in RT#49958 itself will be added in the next beta or the first release candidate, whatever happens.)

I know some people would rather I not use sitecustomize.pl, but it was either that or patch the perl binary itself - and Strawberry tries to avoid that as much as possible. [We DO patch the modules in a few places, and we do patch the files that configure perl's build process - but we don't patch any *.c files.]

Considering the purpose of sitecustomize.pl, however, I've decided that we'll end up patching perl in order to get the correct order and fix the relocation, however - if not for the final, for the January versions.
The Strawberry Perl October 2009 Beta 2 versions (, are now available at http://strawberryperl.com/beta/ .

This release was built with an updated version of the builder modules than were used for the July 2009 versions ( of Strawberry Perl. In particular, there is now a link to the release notes installed when Strawberry Perl is installed, and non-core modules Strawberry Perl installs are now in /strawberry/perl/vendor/lib, instead of /strawberry/perl/site/lib.

Core modules that were upgraded after the decision to stop accepting changes for the 5.10.1 release of perl are included, and up-to-date support modules for Strawberry are included, as well.

DBD::Pg, Imager, GD, Net::SMTP::TLS, Crypt::SSLeay (so LWP can now handle https:// sites), and Module::Signature are included.

Current developer releases of BioPerl are now easily installable. (Just don't add SOAP::Lite as an optional dependency.)

Release notes for the betas are at: http://strawberryperl.com/release-notes/ and http://strawberryperl.com/release-notes/ .

Please report any bugs in the distribution to me, either on irc.perl.org/#win32, or by e-mailing me - but before you do, check the release notes to make sure that it hasn't already been reported.
Since Strawberry Perl October 2009 Beta 2 (I'm skipping Beta 1 because of the beta 1 this time) is still not out yet (I was attempting to build it Thursday and Friday, and I'll try again tomorrow or Monday), I'll just do an "As seen on IRC" entry. Expect it early next week.

(irc.freenode.org/#perl IIRC)
<apeiron> (though I echo the "use cpan already, dammit" position, considering the people who work on perl's toolkit are blessed with this thing called "clue")

<harleypig> We should petition God to open source the universe.

[Personally, I agree, but at least it has good documentation.]

<CSJewell> Strawberry doesn't need to include everything - or even everything that's commonly used. It DOES need to provide what is both commonly used and hard/annoying to build [and the libraries required], what makes it easy to install modules (pip, PAR, that sort of thing), and the prerequisites (and sometimes, what needs them as prerequisites) for the first two.

(OK, that last one is me. But it explains a point I need to make. Feel free to ask me to include your module or whatever in Strawberry. If I say no, it's probably because it doesn't fit the last statement, or it's not stable enough yet. And that doesn't mean I don't want it to WORK under Strawberry. I'd love that. It's just that Strawberry can't include all of CPAN - nor should it.)
Well, the antlering is done.

The "new libraries" are done, also.

Now I'm doing what I call the "vendorperl" changes - first to Perl:Dist::WiX (which is in testing right now) and then to Strawberry.

Once the vendorperl changes are done, I'll probably build the first beta.

On another note, Adam Kennedy says 'The ultimate definition of "supported by Strawberry" is "Can I run > cpan install blah" and it works' - and we get more and more modules supported each release.

Well, because of the new libraries, Bio::Perl is almost to that point. It failed only one test when I tried it 2 nights ago, and that has been corrected in the bioperl svn - http://rt.cpan.org/Public/Bug/Display.html?id=49474 - so the next version WILL be "supported by Strawberry".

THAT is good news.

Hope to get the betas built and announced early next week, and I'll post more then!
I'm hanging by my thumbnails waiting for news right now... but I'll describe what's happening with the Perl-Dist-WiX trunk, since that's what I'm working on at the moment.

I'm not doing the grant work at this point, I'm doing work to make the grant work easier.

Looking back at the list for October, I'm surprised at how few things are done so far, and how many other improvements have been made.

I'm doing the antlering (conversion to Moose) right now. Antlering the lower levels is mostly done. (The upper levels will wait until after October.) With the antlering comes a few other things:

1. Automatic handling (not just announcement) of duplicate directories.
2. User (or at least subclass-) specified ordering of the lists of task to do.
3. Checkpointing works now. This makes things a LOT easier to debug.
4. Being able to e-mail the build logs once the build is completed. (which hasn't been tested yet. :( )

Most of these are things I wasn't thinking of in July.

Of course, the Math::Pari bug is fixed - I really need to make a generic interface for PAR files that are different for each version.

The Win32::Process/5.8.9 problem is just waiting for a production version of ExtUtils::ParseXS to really be fixed (although I'm willing to use development versions in October if it's not in a production version by then).

WWW::Mechanize works now, as of 1.60, so Catalyst::Devel works now, as well. (And yes, the Padre people have asked if we can put the Catalyst plugin in.)

Detection of other perl installs / deletion of duplicate Strawberry path entries will have to wait until after October, I've had no time to do it, same with the script to help in using local::lib.

Easy BioPerl installation MAY get into October, but won't be in the first betas.

A link to the release notes on the web site will be installed with the betas. (This was something that wasn't on my list for October, but I think it's a good idea.)
Strawberry now identifies itself in perl -V as of Beta 3 and the final build.

This is for the convienence of people helping out other people and authors reading CPAN Testers reports, which usually ask for perl -V to be ran on the system to get an idea of what the person on the other end is running.

The way it identifies itself is by pretending to be a machine named "strawberryperl" with a version of the "operating system" equivalent to the version of Strawberry being executed and the date being the date that Strawberry was built. It's a little cheat - but it works for the purpose.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname='Win32 strawberryperl #1 Mon Jul 20 00:01:14 2009 i386'

Previous versions of Strawberry Perl, and of ActiveState, don't do this. However, ActiveState has its own ways of specifying the build number, from what I understand. Here's what they give...

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
    osname=MSWin32, osvers=5.0, archname=MSWin32-x86-multi-thread

To get just that line, there are two possibilities:

1) run perl -V:myuname
2) run perl -MConfig -e "print qq($Config{myuname}\n)"

In a perl program, do this as a detection routine if you REALLY need to (you really should detect capabilities instead, like checking if the compiler is a GCC compiler, etc...):

use Config;

# ...

my $new_strawberry = $Config{myuname} =~ m{\AWin32 [ ] strawberryperl}msx;
Well, I'm the new Strawberry Perl release manager/pumpking/whatever the job is called.

Talk about diving in to the Perl community with a splash.

Adam Kennedy is only giving up two thirds of the job that he had, however. He'll be Strawberry's "project manager" - the elder statesman of the project, if you will. I'll still have his cool head, sharp coding skills, and vast knowledge available for advice when I need them.

My quick and funny description of what our jobs entail is that I'm now the one that has to herd the cats. Adam gets to point the direction that the cats are to be herded. (I like the cat-herding imagery. It just fits me so well, in more ways than one. My immediate family has two cats, and my grandmother has five.)

So, what's really involved in the job? Well, it means three things:

1) I build Strawberry, and I write the code that builds Strawberry. I'm planning on some neat things happening with Strawberry over the next 3 to 6 months - the building code has significantly evolved since January 2009 when I started hacking on it, and it'll evolve some more. By January 2010, it'll be 90% new code since that point in 2009, if it isn't already.

If you feel like helping to write the code, feel free to check it out! I won't refuse patches!

I'm on p5p for this reason - I need to know what's coming up. If 5.10.1 comes before October 2009 (as I hope it does), I hope to have a beta-test Strawberry Perl version available soon afterwards.

2) If a module that Strawberry needs or that I'm interested in having work under Strawberry does not compile or test correctly, I'm available to help fix it. Note that I said help. I do not have infinite tuits. I wish I did.

3) I give advice (and sometimes patches) on how to make Perl scripts and modules work under Microsoft Windows. I'm on IRC quite a bit for that purpose. This isn't an official part of the job per se, but it's a neccessary one - if you can't explain how Strawberry does what it does, should you really have this job?

It's a volunteer position for the most part, and I'm glad to have it. I hope to gain your confidence, as I know some people are asking (and have asked) "Why is a new guy taking over this position from Adam Kennedy? We don't know him from Adam. (pun intended.) Can he do the job?" I find it easiest to answer those in reverse order.

For the second question, the proof is in the pudding, and the pudding in question happens to be the July 2009 version of Strawberry Perl.

I do plan to keep future releases within the first month of the quarter, with the aim being to have them released by the Friday after the second Monday of the release month in my time zone [which happens to be United States Mountain time, currently GMT-6.] (The second Monday does not work so well for me.)

If you want to know when beta or release candidate versions will come out, please contact me, and I'll put your e-mail address on my list of people to contact, or you can check win32-vanilla@perl.org or use.perl.org/~DiamondInTheRough/journal or csjewell.dreamwidth.org. (Speaking of which, I do have a few DW invite codes if people in the Perl community want them!)

As for the first, I'm not a rank newbie, it's just that I haven't stepped up and done much to make myself noticed until now. (That, and for the most part, I've lived too far away from any groups of Perl users.) I've been programming in Perl since 1999, with version 5.005_04, for web sites, data manipulation, and system administration on Linux and FreeBSD, and remember running ActiveState builds of 5.6.0 on my Windows boxes soon after that. I was at the 2002 YAPC::NA in St. Louis (I lived in Columbia, Missouri at that point in time) - haven't been able to get to any since. I also released a module on CPAN back in 2007. (It's now only on the BackPAN - the code got incorporated into its parent module about 3 weeks after release.) The first version of Perl::Dist::WiX was distribution #2 that I released to the public - and there are other distributions that I've written now on CPAN, as well as modules that I've sent patches to.

Just like most Perl programmers, I release modules and fix bugs when I have itches to scratch. Strawberry was a big itch.

I know I still have quite a bit to learn, but I'm learning it quick (I don't quite have the Camel book memorized yet), and am glad to have the opportunity to learn, and to have fun doing it. I say that because working on Strawberry has been fun for me for the most part. Occasionally frustrating (I have some pretty slow computers), but fun.

I'm sometimes impatient, and I'm sometimes lazy. Hubris? Not the way Miss Jewell brought up her little boy! (At least, not much.)

Feel free to ask any questions you'd like to know, and I'll try to answer them.
With the pending release of a new version of Perl comes a new version of Strawberry Perl.

Perl 5.10.1-RC1 was tagged about 52 hours ago, and Strawberry Perl has been updated to build on that version of Perl with the modules a Windows user needs to get other modules and compile them - the same modules that the regular versions of Strawberry Perl have.

The new version will soon be available from http://strawberryperl.com/beta/.

Note that it IS a beta, so this is not recommended for production environments.
but we have a problem with the final release of

This is one of those things that "nobody told me about" until now, and I'm not blaming the person who finally told me.

The question is, which mailing list do I need to monitor so that I hear about breakage like this BEFORE I do a final build?

At any rate, the bug. It turns out that the version of ExtUtils::ParseXS I installed when upgrading the cpan toolchain was broken on pre-5.10.0 versions - which explains why Win32::Process would not build on 5.8.9 (It had been frustrating me for a month - since the buggy version got released to CPAN, it looks like.)

A development version HAS been released that fixes the bug, but no production version yet.

I'm rebuilding with the patch (the new download files will be called "", but will still identify themselves as in perl -V, just with 4 August 2009 build dates.)

If you're using the original, do this, and the breakage should be fixed:

C:\> cpan
cpan> look DAGOLDEN/ExtUtils-ParseXS-2.20_03.tar.gz
C:\strawberry\...2.20_03-xxxxxxxx> perl Build.PL --installdirs core
C:\strawberry\...2.20_03-xxxxxxxx> Build && Build test && Build install
C:\strawberry\...2.20_03-xxxxxxxx> exit
cpan> exit

(bold-italic text is what is typed, other text is where you type it at.)

You may wish to install IPC::System::Simple before you exit the CPAN prompt. That'll serve two purposes: 1) It tests that Win32::Process will indeed build with the fix installed (because ISS depends on Win32::Process) and 2) It allows system() to be autodie'd - which I couldn't include in due to this problem.
Well, the Strawberry Perl for Windows website has been up and advertising the July 2009 release for 8 hours now, and the release has been up for over 20 hours. It's time to announce that fact to the Perl community at large.

This IS the biggest change that has happened to Strawberry Perl yet, and a lot more has changed than just the installer format. The installer format change allows Strawberry Perl to do things that weren't easily possible before - such as allowing installation across entire organizations - and more will be possible in the next few releases.

To get it, just go to strawberryperl.com.

From the release page:

  • The largest update to Strawberry ever!

    • 4th-generation WiX-based toolkit Perl::Dist::WiX.

    • New .msi installer, allowing numerous improvements.

    • Installable across entire organisations via Active Directory.

    • Uninstall now removes environment values correctly.

    • Uninstall now removes post-install CPAN modules correctly.

    • Start menu now has cleaned up and correct icons.

  • Big improvements to built-in modules.

    • All Perl 5.10.1 CPAN auto-upgrade features now included.

    • CPANPLUS is now pre-configured correctly (but not yet the default).

    • By popular demand, DBD::mysql is available in the default install.

Most dual-life modules are upgraded to their current versions from the CPAN, and local::lib is included in Strawberry Perl now.

The .msi installers will require that you are an administrator in order to install on the machine - they make global changes to environment variables and registry entries.

And yes, if you're wondering why Alias is not announcing it, it's because he's left it up to me (Curtis Jewell, CSJewell on IRC and on the CPAN) to announce, and is making me the new maintainer of Strawberry Perl. That way, he has more time to code! I'll introduce myself in a blog post in the near future on csjewell.dreamwidth.org. Don't worry, the download locations will still be the same as before.
Kids are born knowing Perl but with the education system most of them lose their ability by the time they grow up. - szabgab@cpan.org

For those adults who have to remember their childhood on Win32 systems, and for those kids who still know Perl, Strawberry Perl is one of the available versions, and it's only going to get better.

This is the third "release candidate" build, but failing a horrible bug in the next 8 hours, this will be the release build for July 2009.

Edit: (11:45am 31 July, Salt Lake City time) These ARE the release builds, and the website has been updated to link with them.

We now include the MySQL client library, so that DBD::mysql will work out of the box.

DBD::Pg had to be dropped, as explained previously.

And I took the opportunity to fix Math::Pari support on 5.8.9, and update it to the current version on 5.10.0.

These three things are the only changes to the release candidates below:

It turns out that we linked to import libraries, not static libraries, for DBD::mysql and DBD::Pg. This means that we have to include the relevant dynamic link libraries.

For DBD::mysql, all we have to do is add the one library. This we'll do with the versions of Strawberry Perl that we create later today and tomorrow, and this fix will be in the version of Padre Standalone (which is "on top of" Strawberry) that Gabor wants to distribute at YAPC::EU - I'm building it right now, so that he can get it in time.

The problem is DBD::Pg - its main library links to 9 others, including MSVCRT80.DLL and LIBEAY32.DLL/SSLEAY32.DLL. We can't just drop in the MSVCRT80.DLL, and there may be legal issues with including the other two - I'd have to check.

Because of the short amount of time, Adam and I have decided to pull DBD::Pg from the July release. I hope to be able to include it in one of the next two releases once I get the problems solved. (October 2009 or January 2010)

These will be the only changes to Strawberry Perl from the second release candidate to - hopefully - the final release candidate. (I'm using the same mini-CPAN that I built the two release candidates with.)
I do have plans for the October 2009 version of Strawberry Perl, and for releases of other perl distributions based on it.

And yes, there will be others.

The Enlightened Perl people would not mind if I made a distribution based on Task::Kensho - I'm told to call it Satori Perl. (I will note that it will stay beta for while - I'm pretty conservative, and I'd have to check the modules used heavily, as I know that there's one problem module already. )

The Padre people want a standalone version (as mentioned in the previous entry) with Padre installed, with all its prerequisites.

And that's just the two I know about and that would go up to the CPAN.

Somebody on IRC wanted a "Strawberry + Perl 6" (Actually "Padre + the Perl 6 plugin") - that's still too much in flux and still quite a bit unpackageable (it was tested in January and it had a LOT of hardcoding in the build process) to want to try and aim for that for October. Plus the fact that you have to pull svn builds of Parrot to build Rakudo. MAYBE January 2010. MAYBE. I have adequate tuits, but not overabundant tuits.

So without further adieu, here's the list.

Anybody wanting to add to it, please comment, and I might just edit the entry.

  1. One of the three top priorities for October is to make creating perl distributions for Windows even easier. How I intend to do that - I can't mention here just yet. I'm still mulling it over and talking to others about it. But come October, you may very well be able to install multiple "Strawberry-subclass" distributions without problems, and/or be able to include Strawberry easily in other Windows Installer files.

  2. Top priority #2 is what I'm calling the "vendorperl" branch - the ability to put the modules installed by a perl distribution in a 'vendor' directory, as described in schwern's description of the difference between core/perl, vendor, and site.

  3. Top priority #3: Making Strawberry relocatable, at least on a "drive" level.

  4. Other capabilities and things that will probably be included are:

    • A script to allow easier use of the local::lib module by non-administrators (the .msi does require administrator access to install)

    • The installer will delete duplicate PATH entries from previous installations of Strawberry Perl.

    • Detection of other perl installs at install time.

    • WWW::Mechanize. (not neccessarily including it in Strawberry, but making sure it installs seamlessly. And it IS going into Satori.) Anybody who's tried to install it on Win32 knows what I mean. It's a FAQ. HTTP::Server::Simple needs to just work on Strawberry, at least, and then Mechanize will be easy.

    • Win32::Process and 5.8.9. For some reason, this combination is just fine in a base Perl::Dist::WiX, but Perl::Dist::Strawberry spits it back up pre-chewed. (it doesn't pass "dmake".)

    • Giving the building process more antlers than it already has. (Currently File::List::Object is the only part of the build process that has antlers. I'd like to get rid of the dependency on Object::InsideOut - it's lots slower creating 20000+ objects than Moose would be.)*

    • Factoring out the code backing the release tests into their own module, like I did with File::List::Object earlier.

    • There are a few issues with Portable that I'll see if I (or others) can take a swing at somehow.

    • I'd like to make BioPerl installable on Strawberry without too much pain.

    • Also, the Math::Pari installed on 5.8.9 is a 5.10.0 par. Oops. Teeth. (channeling the Men in Black.) NOW they tell me. Done.

* I have to admit, my ideas on this have evolved. At first, all of Perl::Dist::WiX::* used Object::Tiny as a base class, because the original code from Perl::Dist::Inno I based it on did. At about March or April, I was running into problems with multiple inheritance and overlapping accessors with that, so I switched to Object::InsideOut for most packages at that point, because I didn't know Moose at all. Now I'm seeing the problems with OIO (speed, Storability - can't use checkpoints without it) and am wanting to switch to Moose. I'll switch over slowly between late July and late September, package by package.

I've been remiss in posting this here - the Strawberry Perl beta has been updated for about 4 days now - but it's time to announce that the last beta for Strawberry Perl is now available.

I've gotten permission from Adam Kennedy to move the download page onto the Strawberry Perl site at http://strawberryperl.com/beta/, so July 2009 Beta 3 can be downloaded there. Support information is still at my personal site.

In addition to the improvements described on the download and support pages, I also changed the images used in the installer to higher-color images, so that people with better monitors and graphics cards aren't restricted to what I could put into 256 colors.

Along with that, I've updated Perl::Dist::Padre to use the same build process as the Strawberry betas (I'll put a dev release of the module on CPAN soon), and released a first beta of a Windows Installer version of Padre Standalone.

This distribution includes the modules updated from July 2009 Beta 3, the modules the Padre editor relies on, and the Padre editor itself.

It does not include any plugins at the moment, but those should be easy to install, as it is based on Strawberry Perl, and has the same capability to use CPAN and CPANPLUS.

It still looks like Strawberry (in fact, it installs in c:\strawberry, so please do NOT install this on top of Strawberry at the moment, or the other way around) and it does not have any additional links for Padre at the moment.

It is at http://perlide.org/download/binary/padre-standalone-

Support for the DISTRIBUTION is under the same rules as the Strawberry Perl betas.

Support for Padre is through the normal channels for the editor.
Well, Strawberry Perl (July 2009) Beta 2 is now up and available.

What does this mean?

Two things.

1: The uninstall bug that was in Beta 1 is now fixed.
2: DBD::Pg and DBD::mysql are now included (although the version of DBD::mysql that's included is old enough that help compiling an up-to-date version would be helpful)

The purpose of the beta process for the July 2009 version of Strawberry Perl is to get the bugs out of the .msi installer [also known as the "fourth-generation" installer] and have first-class support of open-source databases. DBD::SQLite has been improved, DBD::ODBC was in April 2009, and now PostgreSQL and MySQL will be supported.

If you want to help, go to http://csjewell.comyr.com/perl/strawberryperlbeta.html to download it and help out the cause. Let me know of any bugs.



June 2011

192021 22232425

Style Credit


RSS Atom
Page generated Oct. 17th, 2017 09:44 am
Powered by Dreamwidth Studios

Expand Cut Tags

No cut tags

Most Popular Tags