You are right insomuch as Vanilla Perl IS meant to be as close to being a naked Perl core as we can make it. In this regard it tries to take the purist line even if it creates difficulties. Because it's identifying these difficulties clearly that are a major cause of our current situation.
But, given that we are approaching the solution from some distance away, it's quite clear that there is zero chance of Vanilla being magically made into a useful and more importantly SIMPLE in only a few months.
Indeed, what is probably going to be needed is a full release cycle of Perl itself.
I think Vanilla Perl 5.8.9 is going to be a very different beat entirely, and potentially much more useful in and of it's own right. But that still doesn't invalidate the usefulness in having an experimental-only "Win32 Perl core only" distribution, so that we can identify further problems.
Strawberry is the answer to the question "what is the smallest and most self-contained Win32 Perl distribution we can make, that is as easy to install and start using as people are used to on Windows".
Rather than making people go through the effort of installing Bundle::CPAN and any other core and toolchain upgrades from Vanilla in the 5.8.8 release cycle, it means we can have a relatively slim but still quite usable Perl distribution.
Something we can point people at and say "If you want to write Perl programs that use CPAN modules, you can use that". And it will be as trivial to set up and get started as people are used to.
Now, while you are also right in that we might need some better support for the Win32API modules, I'm not willing to take any of that on face value. I think that the Win32API modules need to only be going in on the basis of necesity, on a one by one basis.
So I think we'll certainly see Win32API::Registry and Win32::TieRegistry in Strawberry, because they are needed by Bundle::CPAN. At this point I'm also about 90% sure we'll see Win32API::File in there as well.
Beyond those two I still don't see any evidence that other Win32 API modules are absolutely necesary to the Perl toolchain, and that they can't just be installed later like any other module.
Where Vanilla is "Core Perl", Strawberry is "Core Perl + Toolchain". It gets us past the current problems of bootstrapping the Perl toolchain in THIS release cycle, and lets us have a distribution you can actually write code on and have some expectation it will run, and that you can install any other CPAN modules you might need in a relatively straight forward manner.
Now if you want to schlurp in every single thing in Win32:: and bundle the lot, you might be a little more interested in the Chocolate Perl concept :)
But it is my style, and has been a successful strategy so far, to attack these problems in discrete steps. It creates a much richer and more diverse ecosystem of solutions, and doesn't expose you to the sort of risks you face trying to tackle the ENTIRE problem space in one hit. | [reply] |
Beyond those two I still don't see any evidence that other Win32 API modules are absolutely necesary to the Perl toolchain, and that they can't just be installed later like any other module.
Seriously Adam, how well do you know the API? Ive read elsewhere that youve stated that you arent a C programmer and aren't a Win32 developer, so on what basis do you form that conclusion?
I mean I can think of a variety of places where proper API support would be useful. Consider a module I've seen you discuss elsewhere, Term::Readline::Perl, if Win32::Console was core then the possibility that TRP could be made fully functional on Win32 Perl would be much higher.
I think there is a clear reluctance in p5p to put dependencies on non-core modules into core modules, so im doubtful that route is very useful. Even if we assume people do go the "Win32 support is optional" route (they havent really so far) I reckon at some point there will be so much cruft in the core code checking for proper Win32 support that I reckon it will outweigh just bundling the modules into core anyway. And as far as I can see the only valid reason proper Win32 support is omitted from core is distribution size, which itself actually would only affect the handful of people regularly working on core. (I think the true reason is actually just that there is a certain amount of prejudice and ambivalence towards the platform in the p5p group).
Anyway, you seem to really like the "no special flower" comment, so I'll throw one back at you: One size does not fit all. Everything has special needs, and thats ok. The world would be a very bland and boring place if there were "no special flowers".
And as a last follow up, for all my comments, please dont think that I dont support what you are doing with Vanilla Perl and Strawbery Perl. I do support it1 . I think its a breath of fresh air in the Win32 Perl scene and i think long term it will achieve a lot of good things. So thanks a lot.
1. except the name, I hate the name "Strawberry Perl", why not White-Perl and Blue-Perl or something that is at least shorter to type?
---
$world=~s/war/peace/g
| [reply] |
Personally I find this all a moderate touch amusing as I have long argued that Win32 perl is less than it should be because core perl just doesnt support enough of the Windows API to work around the fact that Windows doesnt behave like UNIX.
I agree.
If strawberry perl is what is required to get enough of a consensus on this particular issue that we actually see some better Win32 API support in core then ill be happy.
I was basically asking "Is will acheive that"?
You mention elsewhere that MinGW isn't compatible with VC++v8. When I went looking for the fabled "free MS compiler", this was the one I found. Is v7 also available?. I still use v6, but if v8 is the only free one available, then maybe the discussion above about making Perl compile with that is also a valid area of discussion.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
