After over a year since the last release, it is with equal parts of pride and relief that I present Strawberry Perl 5.10, the next major release of the Vanilla Perl Project's flagship Perl distribution. This release represents the beginning of the third generation of release code. The first generation was a simple build script, and was used to create the original Vanilla Perl distribution. The second generation moved from a simple script to a config-driven model with Perl::Dist::Builder, and gave us create the original Strawberry Perl. The new Perl::Dist::Inno takes this beyond simple configuration and provides a complete object heirachy for modeling and compiling Win32 Perl distributions.
So now not only can you replicate Strawberry Perl yourself, you can literally sub-class Strawberry Perl and build your own custom distributions in as little as 10 lines of code. This release also sees more attention paid to Strawberry Perl's CPAN capabilities, and in particular to its out-of-the-box functionality.
The new CPAN client setup is completely zero-configuration, with CPAN::SQLite pre-installed for reduced memory consumption and a http://cpan.strawberryperl.com/ redirector, so that we can keep zero-conf users pointing at a good default repository and collect statistics on the CPAN modules that Win32 users care about the most. We've also added some little touches like a pointing the "Strawberry Perl Website" link that goes to a release-specific page, so we can update with errata and so on.
On the module side things remain much the same. We retain the previous model of bundling a large number of toolchain and CPAN-related modules, but don't bundle modules that add general functionality. For people that would like more modules pre-installed, stay tuned for information on the long-awaited "Chocolate Perl" distribution.
While the new releases is stable and very usable, it lacks in a few areas we will be addressing in the next release cycle.
HOWEVER, minus those few issues, I'm very happy with the quality of the new release, and look forward to increased sleep and some time off. Enjoy.
Re: I solved the problem.
aero on 2007-12-23T11:51:46
After initializing by "cpandb --setup" command. then the problem disappeared.
I wonder should I do this manually.Re: I solved the problem.
Alias on 2007-12-23T12:47:03
I'm surprised you had to do it at all!:(
What setup do you have?Re: I solved the problem.
aero on 2007-12-23T15:09:24
I didn't do anything after install.
cpan cpan> reload index cpan> r
also have no problem.Re: I solved the problem.
Alias on 2007-12-23T15:54:28
No, I mean what operating system, user permissions, etc...Re: I solved the problem.
aero on 2007-12-23T16:07:48
I am using Korean Windows XP.
Details of my envirionment from CPAN::Reporter says
Perl special variables (and OS-specific diagnostics, for MSWin32):
$^X = C:\strawberry\perl\bin\perl.exe
$UID/$EUID = 0 / 0
$GID = 0
$EGID = 0
Win32::GetOSName = WinXP/.Net
Win32::GetOSVersion = Service Pack 2, 5, 1, 2600, 2, 2, 0, 256, 1
Win32::IsAdminUser = 1
Platform:
osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
Re:installer has one flaw
sigzero on 2007-12-23T19:17:46
If you *have* to put it in the root directory (C:\whatever) I won't be using it. Is it really hardcoded to do that?Re:installer has one flaw
Alias on 2007-12-23T22:07:33
Unfortunately, due to some remaining issues with Perl on Win32, you have to at least have a path with no spaces in it.
Since you can get the build code yourself, you can at least now generate your own installer that installs to the location that YOU want.Re:installer has one flaw
sir_lichtkind on 2007-12-23T20:27:06
it also don't seems to remove its PATH entry after deinstal. this is a major point of suckiness that some installer have in common.Re:installer has one flaw
Alias on 2007-12-24T05:50:30
I found a hook in Inno Setup that MIGHT let me achieve the removal of the PATH entries... I'll have a shot at making it work in Update 1
Re:installer has one flaw
sir_lichtkind on 2007-12-23T20:42:23
like for instance the active state, if your installer is better on that, it's a real reason for me to switchRe:installer has one flaw
Alias on 2007-12-23T22:04:31
Unfortunately, there's nowhere in Inno Setup that you can hook that specific clean up functionality (or so it appears).
I continue to look for a way to fix that.
Re:Installed here
AndyArmstrong on 2007-12-23T19:06:44
...and I should add - thanks for all the hard work. ActiveState is fine but it's lovely to have a choice.
Re:Can work on Vista
Alias on 2007-12-26T22:38:25
I've previously done some testing on Vista Beta 1 and found things worked ok, but that was also with UAC turned off permanently.
Re:Perl::Dist::Strawberry
Alias on 2007-12-26T22:37:04
> Users who need it globally will set it themselves and it won't unnecessarily clobber environment for others.
The entire concept of Strawberry is that there are no additional steps required to get it into a working state.
The problem is that most people will NOT set TERM=dumb themselves, because most Windows uses aren't familiar with hacking things like the environment themselves.
It falls back on universal education as a crutch.
For cygwin users, you are already a step above the normal standard, and as a group are far more capable of fixing your environment than others.
There may be better ways of resolving this problem, but expecting every single user to discover a problem, learn how to fix it and do it themselves it not an appropriate solution.Re:Perl::Dist::Strawberry
tshinnic on 2008-01-08T00:03:58
Thank you for the problem report. I found it using Google and it helped me confirm what the problem was. I'd been thinking strangenesses like Strawberry tromping on DLLs or something like that, not just sneaky ENVVAR settings.Strawberry setting TERM=dumb is bad. Grrr.
Re:Example environment script
Alias on 2007-12-26T22:40:22
This sort of setup would break the normal "cmd" environment though right?
It would mean that you could ONLY use Perl via that special shortcut?
If I read it correctly, the problem was in incorrect parameter passing to some functions, and Vista catches it. I'm quite sure these function calls are actually just as incorrect on previous versions of Windows... so I see no reason why a patched gcc wouldn't work equally well on XP.
Re:MinGW patch for Vista
bart on 2007-12-27T09:48:18
Addendum: This is the post that gave me the latter idea:This is an actual mingw bug that has been tracked down to a change in the way the Microsoft standard C libraries handle invalid parameters. Older versions of the DLL would not check invalid parameters and go down potentially untested code paths with them. The versions in Vista do stricter parameter checking. Some calls made by the mingw tools pass invalid parameters to one of the functions and fail, causing the internal paths to quit working.
