Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Definitely better than AS. Compile environment included. No futzing w/PPM and VC/.NET1/NET2 libs and compilers.
    • The only thing that scared me off Strawberry was "An alpha release of Strawberry Perl is under development". How stable is it?
      • Well, you said "doing development work", so that implied not worrying about production environment stability to me.

        But either way, I've not had a single problem with it so far on two different boxen.
      • I haven’t tried to run production with it – but then, we’re talking about Windows, so damned if I’d try anyway. For what I need (light development work, once in a while), it’s been completely reliable, and certainly has proven much nicer when trying to get exotic modules working than AS Perl ever even came close to.

      • It's pretty stable -- in the sense that it's not likely to unexpectedly go belly-up on you. That said, there are substantial issues with many modules on win32 -- but that's not the fault of Vanilla/Strawberry. If a module compiles and passes its tests, then it should to be stable after that.

        Major missing piece right now: external libraries. We're working on that.

        The "alpha" in part reflects that fact that the installer package itself is evolving. Eventually, we plan to target 5.8.9 as the release ve

        • Sweet, thank you. That gives me exactly the level of detail I need about Strawberry Perl's stability.

          I don't need production quality, but I also don't want something that coredumps every few minutes, which is what I was afraid pre-alpha might be. :)

          Looks like I'll be trying Strawberry.
        • I'd also add that the other reason it's alpha is because we have high standards for what would be considered "production" quality.

          For example, CPAN modules installing on Strawberry still generate man pages, when it's highly likely people won't have man, or won't use it anyway. perldoc will almost always be enough.

          pl2bat isn't as nice as it should be.

          A half a dozen other nigglies still don't work quite clean enough yet, compared to how they should.

          And as dagolden mentions, there's a number of modules we wrot
    • I'm torn about this.

      Is it better than Cygwin Perl? On the one hand, I have Cygwin fatigue. On the other, Perl is only half of the puzzle. I want bash, too.

      Has anyone used Strawberry with MSYS bash? That might truly be heaven for me...
      • I haven't used Strawberry from within MSYS bash, but I uses the MSYS shell to build libraries for Strawberry perl and wrapped those libs into .par's for installation into the Strawberry directory structure.

        We are considering inclusion of the MSYS shell in Strawberry, by the way.

  • I live in Cygwin and am very happy with it. You may have some limitations on modules, but you may have some of those with other distributions, too.

    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Maybe if we had some sort of detail about what you are doing that would help?

    • Programming. :)

      Working on and testing modules primarily. I'm not as interested in using Perl to script OS actions or do platform-specific work.

      That said, I think I have my answer.
  • There are no situations in which Vanilla should be used for real work, because we will regularly break it without notification in order to try out some new trick and see how well it works.

    And there's no way to tell from the build numbers which ones are usable and which aren't.
    • Not entirely true. Strawberry is built upon Vanilla, so any Vanilla build used for a Strawberry release can be considered OK.

      • Maybe, but they certainly have no way of knowing which is useful easily, when Strawberry will have actual "production" versions. And we're keeping it that way on purpose. :)

        Not to mention they then have to deal with Bundle::CPAN and the other things on their own, when Strawberry will have the various bits and pieces already there.