With my repository working again and PPI 1.200 release, the next project I hope to catch up on is Strawberry Perl. I think this has taken on particular importance now because of the Perl Survey results, which showed that about 50% of Perl users have used Windows in the last year, but only 5% of Perl users ONLY used Windows.
When comparing Strawberry Perl and ActivePerl it's fairly clear to me that ActivePerl is the best distribution for Windows-only developers and Strawberry is better for cross-platform developers.
I'd just never realised how dominant the cross-platform case was compared to the Windows-only case. I'd always thought that the Windows-only case was dominant.
Before I changed jobs recently and got distracted by writing the repository manager, my previous "train project" was to update and refactor the modules (Perl::Dist::Strawberry and friends) that are used to generate the Vanilla and Strawberry Perl distributions
I've managed to remove most of the bit-rot and I've cleaned up the codebase a bit.
To make things a bit easier for myself, I've moved the modules into my repository for now, and I'll be starting incremental releases (of the modules).
From there, I want to try and get another (beta) release of Strawberry Perl 5.8.8 out before 5.10.0.
I'd also like to try and upgrade the Vanilla/Strawberry Perl website at the same time, as I've had a few people emailing me asking if it was dead when that is anything but the situation.
I've mentioned this in some emails when asked about Vanilla and Strawberry Perl, but it probably is worth repeating here...
Strawberry Perl has led to a substantial shift for many people from installing modules in PPM form to installing directly from CPAN. That means that a lot more test suites are being run on MSWin32 and a lot more bugs are seeing the light of day.
Much of the energy of project participants in the last year or so has been going to gradually squashing these bugs. You can see some of the activity on the Vanilla Perl Problem Modules page.
The other side effect was that I was inspired to write CPAN::Reporter to make it easy for anyone with CPAN.pm to automatically submit test reports to CPAN Testers and to authors. This helped re-energize smoke testing on Win32 -- flushing out even more Win32 bugs.
So overall, while Strawberry Perl itself hasn't changed in over a year, the quality and capabilities of Perl on Win32 have been steadily improving.
-- dagolden
Wither 5.10?
grinder on 2007-10-22T08:34:00
David,
May I put in a request for a 5.10 version of Strawberry Perl, even though it's not yet released? Or otherwise, how can the kids try this at home?
What do I need, over and above the blead source, to compile it and produce my own, say, Mango Perl on Win32?
Re:Wither 5.10?
Alias on 2007-10-22T10:26:02
At the moment you need to wait for a little bit for me to get the refactor of Perl::Dist finished, as there's no sane way to build atm... but that shouldn't be too far away.
Re:Strawberry ActiveState
jplindstrom on 2007-10-18T22:26:01
My actual subject was "Strawberry > ActiveState", but that got clobbered somehow...Re:Strawberry ActiveState
Alias on 2007-10-19T01:50:56
It's a "bug" (pudge may not actually consider it a bug).
SlashCode does not escape comment headers.Re:Strawberry ActiveState
Alias on 2007-10-18T22:54:34
The main reason we kept the label on was that I wanted to be really conservative with a distribution.
Re:Strawberry ActiveState
Alias on 2007-10-19T04:23:42
The thing is, if you have pure-Win32 programmers that never touch Unix, they tend to be using Visual Studio and so on already. They have a familiarity with Visual Studio and the Win32 ways of working,
In this environment, the better and less confusing environment for them does seem to be ActiveState.Re:Strawberry ActiveState
jk2addict on 2007-10-19T13:18:09
I've found the opposite. I use Visual Studio.NET at $work, all day, every day so I'd consider that being a pure win32 programmer. But that's now in the age of.NET, where you don't have to know a lick of C to do real things, like http modules, services, etc.
Back in the Visual Studio 6 days, one could compile a perl module [mod_perl.. oi] even if you didn't know C [as painful as it may have been to get studio to play along], and you could be fairly certain that the modules would work just fine.
When.NET 1.0, 1.1, 2.0 came along, everytime I try compiling in VS.NET, I have a good chance of getting something that isn't quite stable because AS perl might have been compiled with VC6, while I'm in VS.NET compiling XS. IF you're a hardcore C person, maybe this isn't an issue for you to fix. For just a full time VS.NET user, forget it.
All in all, a nightmare sometimes for no apparent reason. I gladly use strawberry perl because I know it doesn't come with all the insanity of guessing which framework/dlls the module is actually going to compile against and whether it wll work with AS perl or not.
