http://www.perlmonks.org?node_id=587182


in reply to Getting Fed Up with ActiveState

Ovid,
I know that AS is not perfect but it would be nice to keep things in perspective. Perl on Win32 would still be in the dark ages without them - really. Jan Dubois and team are incredibly responsive to issues. For example - see this.

Oh, and have you contacted AS for support?

Cheers - L~R

Replies are listed 'Best First'.
Re^2: Getting Fed Up with ActiveState
by Ovid (Cardinal) on Dec 01, 2006 at 14:25 UTC

    I've emailed them in the past and I received a helpful response, but it's obvious that the Module::Build versus ExtUtils::MakeMaker problem has still not been properly addressed (I even described a solution for them). Also, I have already emailed them about this particular issue (and copied that link).

    That being said, they've had years to work this out and they still can't get it right? I completely understand how some problems can be hard and it's tough looking from the outside in, but we're talking about a problem that CPAN has managed to generally get right long ago (and where it gets it wrong, you can still at least install the modules and cross your fingers).

    AS's Build and PPM systems are, in my opinion, fundamentally flawed and have been for a long time. I really do feel bad for saying stuff like this as I know Jan Dubois and his colleagues probably don't appreciate the grief and I can't possibly know the constraints they have to deal with, but it doesn't change the fact that now I have to rewrite code at work due because of this and it's certainly not the first time I've been put in this position.

    Cheers,
    Ovid

    New address of my CGI Course.

[reply]
Re^2: Getting Fed Up with ActiveState
by adamk (Chaplain) on Dec 02, 2006 at 07:06 UTC
    Partly the reason this stuff can't be fixed is that it can't be fixed.

    I spent a YEAR trying to get my modules (most of which need refaddr via deps) supported in the PPM build system, to no available.

    I even spoke to them IN PERSON, was assured something would be worked out, and eventually got to the position at the end of the day that some of the technical bugs in the PPM system CAN'T be fixed due to commercial reasons.

    Likewise, they can't bundle GCC with Perl like Vanilla/Strawberry does due to licensing conflicts, with those licenses there for commercial reasons.

    So after a year of trying, I simply concluded that depsite their previous good works, which I appreciate, ActiveState has now reached the point of damaging Perl. That's nothing against the individuals involved, just that ActivePerl appears to me to have worked itself into a commercial and legal position that is untenable.

    And so I decided to, like the internet, route around it and just make a "normal" Win32 Perl distribution that removed the commercial constraints and did things the way I was used to having them on Unix.

    And the end result after the help of dozens of awesome volunteers was Strawberry.
[reply]

      most of which need refaddr via deps

      Thing I dont get about this is that I can see a couple of work arounds for this problem that would be pretty easy to do. For instance before you use any dependencies you use Scalar::Util then check if refaddr is available and if not then you simply create your own Scalar::Util::refaddr().

      But I guess I'm glad you didnt find a solution as the Milkshake-Perls are a real bonus. More competition in the marketplace is a good thing. :-)

      ActiveState has now reached the point of damaging Perl

      I'll just add that I think that this is extreme. They do lots of stuff for the perl community, maintain some of its most important modules, and provide for free services that are very valuable to the community. I think they should be respected for that.

      ---
      $world=~s/war/peace/g

[reply]
      ActiveState has now reached the point of damaging Perl

      Interesting notion ... I doubt that ActiveState would wish to damage Perl. If they are being forced to do so, then perhaps that's an indictment of the legalities involved (as opposed to an indictment of the course of action that ActiveState have chosen to pursue).

      Basically, I'm just wondering whether you should instead be asserting that "the law has reached the point of damaging perl". (I'm not a lawyer, so I can't give an answer ... and if I were a lawyer, then my answer would probably be biased :-)

      Cheers,
      Rob
[reply]
      Likewise, they can't bundle GCC with Perl ...

      Can't? Or don't want to? You do realise that there is a difference don't you?

      I don't want them to bundle GCC with their distributiom, and I'm bloody sure that a large number of their corporate clients don't just 'not want them to', but would abandon them and Perl if they did.

      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]
        I'm bloody sure that a large number of their corporate clients don't just 'not want them to', but would abandon them and Perl if they did

        Maaaan ... much as I love you - that's not an astute assertion to make.

        ActivePerl already supports MinGW's gcc compiler. One can use either that compiler, or an MS compiler, with ActivePerl - and that state of affairs would not change if AS distributed MinGW's gcc with their ActivePerl builds.

        If the corporate clients did not wish to use the gcc compiler that was being (hypothetically) shipped with ActivePerl, then they would simply ignore its presence and proceed with "business as normal".

        Cheers,
        Rob
[reply]

In Section Meditations