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.

    5.10.1.1 is at: http://strawberry-perl.googlecode.com/files/strawberry-perl-5.10.1.1.msi
    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)

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/5.10.1.1.beta.html 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.
.msi file (preferred)
.zip file

Note that you will have to uninstall the 0.45 version before installing this one. I'm verifying why this is the case.
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.
"I believe, but have not Googled..."

(personally, is that really faith? But then, we are talking Perl here!)
RC2 includes Win32::ErrorLog (in order for one of the Geo:: modules to work), and the 5.10.1.0 RC2 includes CPANPLUS 0.89_02, and 5.8.9.3 RC2 includes CPAN 1.94_52.

The dev versions each fix a bug that we want to include the fix for in the October 2009 versions.

I'll be building a third release candidate within the next few days for the 5.10.1.0 versions, because I forgot to make sure it included CPAN 1.94_52 (which has a bug fix that specifically applies to using a minicpan within Strawberry.)

The README file generation has also been corrected.

No other changes have been made.

At any rate, they're at the same place. Test thoroughly.
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.]

http://strawberryperl.com/download/strawberry-perl-5.10.1.0.msi
http://strawberryperl.com/download/strawberry-perl-5.10.1.0.zip
http://strawberryperl.com/download/strawberry-perl-5.10.1.0-ddrive.msi

http://strawberryperl.com/download/strawberry-perl-5.8.9.3.msi
http://strawberryperl.com/download/strawberry-perl-5.8.9.3.zip
http://strawberryperl.com/download/strawberry-perl-5.8.9.3-ddrive.msi
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 (5.10.1.0-beta-2, 5.8.9.3-beta-2) 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 (5.10.0.6/5.8.9.2) 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/5.10.1.0.beta.html and http://strawberryperl.com/release-notes/5.8.9.3.beta.html .

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 5.10.0.1 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")

(irc.freenode.org/#utah)
<harleypig> We should petition God to open source the universe.

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

(irc.perl.org/#padre)
<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!

Updates.

Sep. 5th, 2009 05:27 am
The antlering has taken some debugging, but it's going through final tests now. (Last one crashed on a module it could not download - apparently internet connection blipped. I'm making sure I have the deps right in a VM, and then I'll try again.)

Then I have to WRITE tests. :( (Well, technically, I should write a Test::Perl::Dist module - and that's half-written at the moment - and then tests using it.)

That, and is there a place for the Ironman badges that automatically gives you the code to put on the page? (Oh. Found the URL for my own badge... that works.)

My Ironman Status

I did get good news - more later, I'm tired.
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 5.10.0.6 Beta 3 and the 5.8.9.2 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:
  Platform:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname='Win32 strawberryperl 5.10.0.6 #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:
  Platform:
    osname=MSWin32, osvers=5.0, archname=MSWin32-x86-multi-thread
    uname=''


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.
I had a documentation patch for Moose (actually in Moose::Error::*) and got walked through using git in order to commit through their repo quite nicely on irc://irc.perl.org/moose.

I know that my next patch for them will be to Moose::Manual::Contributing, however. (Nothing bad, just that it assumes you've been using git for more than 20 minutes in a few places. Is why I needed walked through it!)
I happen to use Module::Starter and Module::Release for my automation - but of course, I don't do things quite the way the default configurations for those two modules want me to.

So I'm making my own plugins for future stuff.

They'll be on the way soon, the release plugins are on the other computer. :(

And for the first time, I actually get Git working enough to be comfortable with it, so I've uploaded MooseX::Error::Exception::Class to github. I'm pretty free with allowing changes - just send a pull request.
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 5.8.9.2.

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 5.8.9.2 with the patch (the new download files will be called "5.8.9.2-1", but will still identify themselves as 5.8.9.2 in perl -V, just with 4 August 2009 build dates.)

If you're using the original 5.8.9.2, 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 5.8.9.2 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:

Six of them, in fact! :)

"Padre Standalone Plus Six" is being uploaded at the moment.

The location to download from will be:

http://strawberryperl.com.nyud.net/download/padre/almost-six-0.41.msi
http://strawberryperl.com.nyud.net/download/padre/almost-six-0.41.zip

[These links go through the CoralCDN edge-cache. If that's a problem, drop the last 2 parts of the hostname.]

The MSI version is up, plan on about 90 more minutes (6pm, Salt Lake City time) for the .zip version just to be safe.

What's included (and why the name is changed) is:


  • Strawberry Perl 5.10.0.6 plus a few module updates

  • Padre 0.41 and its prerequisites

  • Padre::Plugin::Perl6 0.55 and its prerequisites

  • A test compile of Rakudo Perl 6 based on the Chicago release



Watch for a release of Strawberry Perl within the next few days, as well.

UH OH!

Jul. 29th, 2009 01:13 pm
Everybody on PerlMonks needs to change their passwords YESTERDAY, if not sooner! And if you were using it other places, change them as well, to a DIFFERENT password, as I don't think the problem is fixed yet.

A machine of theirs got hacked into and they were storing the user passwords in cleartext. (with everybody on it recommending encryption - it should have been fixed years ago - and wasn't. I think it soon will be.)
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.)
File::List::Object was made to "fill in a hole" that I saw in the CPAN module space - a way to manipulate a list of files as a list.

It's implemented using Moose - this is my first Moose class. In the future, most of the Perl::Dist::WiX build process will be implemented using Moose classes and roles.

I saw the hole while I was working on Perl::Dist::WiX. In that module, I need to pick up the lists of files installed by different perl modules and binary packages, and to be able to add, subtract, filter, etc. files from them. The reason that's the case is that Windows Installer needs to keep track of every file within an installation package - I can't just say "package up everything that was in my source C:\strawberry and install that" like the Inno Setup-based versions of Strawberry did. So I used the predecessor of this module to abstract out the keeping track. I tried looking for it on CPAN, and when I realized that this was not there, and that I could see more general uses for the module, I separated it out and put it on CPAN.

One thing I use this module for is to check and see if I'm installing the same list of files from my zip files as my msi files. I extract the zip and do a dir /s /w /b to create a filelist. Next, I delete the extracted directory, install the zip, and do another dir /s /w /b. After that, I install this module and run a short script (that's in the examples directory) to create a list of which files are missing.
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.

--Curtis
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-5.10.0.1-beta-1.msi

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.

Profile

csjewell

February 2010

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28      

Layout Credit

Layout:
[personal profile] renoir

Syndicate

RSS Atom
Page generated Feb. 9th, 2010 08:31 pm
Powered by Dreamwidth Studios