Re: Getting Fed Up with ActiveState
by rinceWind (Monsignor) on Dec 01, 2006 at 12:00 UTC
|
Ovid++
I'm a developer of some Windows Perl apps on ActivePerl at work, albeit 5.6.1. I've more or less given up on ActiveState's PPM repository, and don't even bother trying to use any PPMs from it. I gather there are other repositories with folks who are more receptive: Randy Kobes' bribes repository and crazyinsomniac's one, but I do my own module installs from CPAN, as I have MVC etc.
I'm also trying out Strawberry Perl at home on my laptop (the only home machine I use Windows on), with a large degree of success! CPAN works out of the box, including C compiles.
--
Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ? (Missquoting Janis Joplin)
| [reply] |
|
| [reply] |
|
| [reply] |
|
|
Re: Getting Fed Up with ActiveState
by Limbic~Region (Chancellor) on Dec 01, 2006 at 13:24 UTC
|
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?
- Report Bugs
- Email: activeperl-feedback@activestate.com For Suggestions
- Email: support@activestate.com to request help with problems
| [reply] |
|
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.
| [reply] |
|
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] |
|
|
|
Re: Getting Fed Up with ActiveState
by syphilis (Archbishop) on Dec 01, 2006 at 13:14 UTC
|
but ActiveState's build status information is virtually useless
I pretty much agree with all you have written - but the page to which the above quote linked is (imo) more of an indictment on perl's default "make test" output, than anything else.
As for the failure message that you get for Darwin, that is indeed very odd. There may be others here that can explain it - I certainly cannot. You could always seek an explanation by posting to ActiveState's PPM mailing list, though there's no guarantee that will produce a satisfactory answer. For my part, I'm always prepared to accept that something very weird will happen when I see things like Warning: prerequisite Test::More 0.6 not found. We have 0.54
Cheers, Rob | [reply] |
Re: Getting Fed Up with ActiveState
by perrin (Chancellor) on Dec 01, 2006 at 19:58 UTC
|
I understand it can be frustrating, but try to remember who you're talking about here. ActiveState's Perl team is not some faceless evil entity; it's a bunch of perl hackers just like you, who you probably had lunch with at a conference at some point. The fact that these well-meaning people have not been able to make every CPAN module available perfectly on PPM should tell you something: it's damn hard to build every CPAN module, much less build them all on Windows.
There is much less standardization in CPAN dists than many of us assume. The prereqs are often wrong or incomplete, there are lots of custom build scripts that need to be modified for Windows, many test suites either only work for the author or expect interactive input, and the sheer volume of the task is just enormous.
I personally have always had good experiences with PPM, which is doubly surprising since I expected installing anything on Win32 to be a nightmare. I installed full DBD::Oracle support on a Windows machine effortlessly thanks to them.
| [reply] |
|
| [reply] |
|
Can you explain a bit more? What is it that you think they chose not to do in this case?
| [reply] |
|
why I will not use ActiveState again
by rjbs (Pilgrim) on Dec 01, 2006 at 13:35 UTC
|
I used to use ActivePerl, but now that there are better alternatives, I will never use them again.
My favorite discovery was pretty recent. They totally replaced File::Path with another implementation that has different bugs and the same version number. I couldn't figure out why there were warning coming from ExtUtils::Install on Win32 until I found that rmtree was behaving differently on false input.
What! The! Hell!
| [reply] |
|
They totally replaced File::Path with another implementation that has different bugs and the same version number
You're quite right - which surprised me. A diff of ActivePerl build 819 and perl 5.8.8 built from CPAN source produced (in part) the following:
-our $VERSION = "1.08"; # but modified for ActivePerl
+our $VERSION = "1.08";
I think they should have at least made mention of the modification in the File::Path documentation.
Cheers, Rob | [reply] [d/l] |
|
You'll find the following note in the ActivePerl ChangeLog:
* File::Path's rmtree() function has been replaced to address security vulnerability CAN-2005-0448.
We have basically adopted the version from Debian Linux.
BTW, we also publish this patch file that documents how the current ActivePerl differs from the official 5.8.8.
| [reply] |
|
|
|
|
That same change to file-path also causes breakage in the rmtree of files across SMB/CIFS shares. Previous to this patch, there was no issue. Not to mention that the patch applied doesn't exclude Windows from it as a platform.
I tried the following experiment:
- Add a variable: my $Is_Windows = $^O eq 'MSWin32';
- Wrap the two race/exploit checks in if (!$Is_Windows).
The AS patch was sloppy at best, careless at worst. Windows doesn't use GNU Fileutils, as far as I know.
| [reply] [d/l] [select] |
|
| [reply] |
|
I posted the above message. New to the perlmonks site, and created the new user in another tab. Sorry.
| [reply] |
Re: Getting Fed Up with ActiveState
by randyk (Parson) on Dec 01, 2006 at 20:31 UTC
|
I think part of the problem here is the versions required for the dependencies of
Scalar-List-Utils and
Test-Simple are greater than those which come with the core ActivePerl distribution. ActiveState doesn't supply ppm packages of the core ActivePerl modules, in order to prevent possible breakages of basic functionality. From that point of view, it's understandable why packages which depend on newer versions of core modules aren't supplied.
This problem is being addressed to a certain extent with PPM4 (coming with ActivePerl 819 and higher), where it is possible to install packages to different areas, including that where the core modules reside. However, compatibility must be maintained with previous ActivePerl versions, where it was not so easy to upgrade core modules. For now, probably the best way to approach this from a ppm standpoint is to use the external repositories mentioned in other replies.
| [reply] |
|
A much larger part of the problem has always been that CPANRUN ( our build system for CPAN ) was designed fairly naively and has had only cursory attention paid to it since then. I know Gozer would love to have the time to re-implement from scratch but ActiveState is much smaller and more tightly focused than it has been in the past, and we just haven't found the time.
In my time supporting ActivePerl and PPM I've always felt really lucky that some people (like Randy) are also maintaining PPM repositories and filling in the blanks where CPANRUN falls down. It's pretty easy to install additional repositories using the PPM::Repositories package.
| [reply] |
|
| [reply] |
Re: Getting Fed Up with ActiveState
by bart (Canon) on Dec 01, 2006 at 19:51 UTC
|
I'm really wondering if the blame shouldn't be put on Scalar::Util instead. That module can be installed both in an XS version, or in a Pure Perl version. And refaddr won't be there, if the latter is the case.
So, blame the fact that Scalar::Util Pure Perl and Scalar::Util XS use the same module name and version number (they actually get installed from the same distro) and no obvious way to distinhuish between them. | [reply] |
Re: Getting Fed Up with ActiveState
by Corion (Patriarch) on Dec 02, 2006 at 19:42 UTC
|
One thing I didn't get during this thread is, what prevents you from setting up your own repository and creating and distributing the PPMs your software needs? SocialText do this (for Debian), and I don't really see why you couldn't.
| [reply] |
Re: Getting Fed Up with ActiveState
by Herkum (Parson) on Dec 01, 2006 at 15:10 UTC
|
Are you complaining about the ActiveState build on Windows, or ActiveState in general?
I am sure that a number of problems with ActiveState Perl can be traced backed to Win32. PPM is an attempt to get around Windows lack of a built in C compiler and no make program. In fact, most of the issues with ActiveState can probably be traced back to having to work with Windows.
Referring to Perl on Windows then the ActiveState build is easy to get up and running. It has some problems but I don't see anything comparable to it.
Other systems which come with make and a C compiler I would never consider ActiveState.
| [reply] |
Re: Getting Fed Up with ActiveState
by BrowserUk (Patriarch) on Dec 01, 2006 at 13:42 UTC
|
| [reply] [d/l] |
|
BrowserUk,
I think this is a good idea. Or rather, I think it is a fantastic idea to provide binary distributions of modules requiring C compilers to Windows users on the CPAN. I don't necessarily think it should be an "author provides it or none at all" thing. If the author didn't develop on Win32 there should still be a mechanism to allow someone else to provide the binary distribution.
| [reply] |
|
I don't necessarily think it should be an "author provides it or none at all" thing.
Agreed. But the motivation of the 'abandon ActiveState move' seems to be primarily driven by module authors who's modules are being flagged as 'unbuildable' by the automated AS process.
I think I can understand why AS do not fix the automated process. It's probably simply one of survival. They are (now again I think) as smallish company with limited pockets trying to survive. Any manual intervention into their automated process--which they provide free to the community with little possibility of return--would be a pure sink on their resources. They are already providing the storage, cpu and bandwidth.
I think that the premise that "they should do more" is flawed. Adding the need for personnel, to manually intervene, to the equation, could make the service and/or company go away completely! I also think that fostering the expectation that large volumes of win32 Perl (corporates and individual) users (as opposed to hackers) will abandon AS for a DIY build it yourself on every machine alternative is forlorn and pointless.
The moves in this direction, like strawberry perl, are motivated by the wish to make things easier for the Perl module developers--which by and large means non-win32 users--rather than the vast majority of win32 Perl users.
Making life easier for module writers to write, build & test their modules on win32 is a strong and good motivation. And it can only benefit win32 users also in the long term, by giving them access to a wider set of modules. But maybe the best solution would to not throw the baby out with the bath water.
If AS could provide a mechanism for allowing volunteer intervention to correct 'broken' automated builds might be one solution. Using CPAN to provide a central repository for binary distributions might be another. I realise that binary distributions can be bigger than a standard module, and that CPAN disk space is neither limitless and is also provided free to the community--and by many mirrors--by generous donations.
But then, there is an awful lot of cruft on CPAN now--stuff that hasn't been updated or downloaded for years if not decades--along with other stuff that probably shouldn't have ever made it up there in the first place.
Then again, I'm the wrong person to be having any of these thoughts--but I have them anyway.
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] |
|
|
|
|
There is a very definite reason not to do this in the general case.
The people who have set up CPAN mirrors are donating their bandwidth and storage. If we started uploading binaries (be it PPM or .par's) of all CPAN modules for all versions of perl and for several OS's, the size of the CPAN archive would explode. That might or rather will be considered abuse.
A further issue is that the distribution of binaries from untrusted sources is a major security issue. Suppose anybody could upload a binary for any module. Madness!
Now, laying these points aside, let me tell you that I am regularily uploading binaries to CPAN. Yes, you read that right. I'm violating my own advice here.
Reason for this lies in the nature of those binaries: They're binary builds of PAR (now PAR::Packer) for win32 only. Mainly, this is because PAR has itself traits of a package manager and providing a binary can mean the user does not need to do fancy bootstrapping to get it to work. This has been relaxed now that PAR was split into two distributions, however. The other reason is that Win32 is one of the major user platforms for PAR and doesn't always come with a C compiler. Furthermore, the security issue is sort of minimized by that those packages are always by the same CPAN user as the release manager for PAR itself.
That being said: Why upload PPM's to CPAN which can only reasonably be used with a single specific distribution of perl? (ActivePerl) Instead, you could use .par archives and provide support for auto-installing them if no compiler was found. This works well with PAR right now.
Steffen
| [reply] |
|
Yes, you read that right. I'm violating my own advice here.
S'funny how things are okay for 'special cases', when those special cases are close to our own hearts.
The people who have set up CPAN mirrors are donating their bandwidth and storage.
Some interesting numbers. Template::Toolkitv2.15.zip PPM is 494 Kb.
Template::Toolkitv2.15 .tar.gz is 761 Kb.
There are currently no less than 15 versions of the latter being mirrored. Loosing two of those old versions (to say backpan) would allow 3 versions of the PPM to be held without creating any extra demand on the mirrors.
the distribution of binaries from untrusted sources is a major security issue.
Do you inspect every line of every source file in each package you install? What about all the .t files? Does anyone?
Why would you view the authors of source distributions as trustworthy, and those same people packaging those same modules in binary form as untrustworthy? If you have the processes and procedures in place to verify the integrity of your systems when you build a module from CPAN via a source distribution, those same processes and procedures should also be used to detect miscreant binary installations.
There is a pervasive logical disconnect here that says source is safe and binary not. But pervasive does not mean correct. Any and all software sourced from outside your organisation is potentially dangerous. And the idea that all the risks are negated by the potential for visual inspection, even if anyone actually did that--which they don't--is so profoundly wrong, that the idea itself, and those that expound it, should be actively and vigorously countered at every opportunity.
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] |
|
|
|
Re: Getting Fed Up with ActiveState
by jk2addict (Chaplain) on Dec 01, 2006 at 14:55 UTC
|
Strawbery-Perl++. I got fed up with AS perl PPMS and collisions between compiled things from them vs. Randys Theoryx PPM (although, Randy has always been very helpful, and got me through some noasty how-to compile issues with AxKit/libxml/libxslt and their Perl cousins).
Strawberry Perl has been an utter joy to work with on windows so far, with only a few modules not compiling completely. If it weren't for testing with my older perl installs, I would have banished AS perl from my machines long ago.
Now, if someone would just fix Dango::Socket on win32 perl... :-)
| [reply] |
Re: Getting Fed Up with ActiveState
by imacat (Initiate) on Dec 01, 2006 at 16:09 UTC
|
As a Perl module author, I believe there are multiple ways of building/installing Perl modules for ActivePerl: PPM, nmake, CPAN or even CPANPLUS. It's documented in perlmodinstall(1).
If there's a PPM I'll use PPM (since it is pre-tested). If not, I'll try to built it myself with CPAN or nmake.
I understand that ActiveState is a commercial company and I can do not much about it. But we have several alternative solutions anyway.
| [reply] |
Re: Getting Fed Up with ActiveState
by Steve_p (Priest) on Dec 06, 2006 at 06:33 UTC
|
This has to be one of the most jaw-dropping threads I've ever seen on Perlmonks. Had the OS been some sort of Linux, and the vendor was some Linux vendor, the response would have been get yourself a C compiler and learn how to use CPAN.
Excuse me, but, why should it be any different here? Perl compiles with multiple versions of Visual C++, Borland C++, and MinGW, which are all free for the downloading. Does ActiveState have a monopoly on Windows Perl? I don't think so. On the other OS's mentioned, they either are distributed with a gcc, or gcc's or other C compilers are easily available.
What confuses me the most is that neither aliased or Class::BuildMethods require a C compiler. So
C:> cpan -i aliased
should work just fine to install the modules. Previous threads by crazyinsomniac can provide you with the code needed to generate the nice HTML doc's that come with ActiveState, or you could just use "perldoc", but I'll let you make that call.
Unfortunately, the statement that troubles me the most is "Perl on Windows is crippled due to poor support." If that statement weren't so baseless, it would be insulting to the many people who have provided several thousands of hours of free programming and support to get Perl to work on Windows. Those people aren't just ActiveState, but also many of the people responding to this thread. Oddly enough, Perl has compiled and run on Windows for years, and will continue to do so for years to come. Much like all the other OS's supported by Perl, it routinely passes the 170,000+ test cases on a daily basis. As has been said elsewhere, Perl is everywhere. Just to let you know, that includes Windows.
| [reply] [d/l] |
|
This has to be one of the most jaw-dropping threads I've ever seen on Perlmonks. Had the OS been some sort of Linux, and the vendor was some Linux vendor, the response would have been get yourself a C compiler and learn how to use CPAN.
Instead of skimming the thread, may I recommend reading it? This has been repeatedly discussed.
And do you want a job in our support department telling our thousands of Windows users how to install a C compiler, nmake, configure CPAN, and install the necessary modules they need/want? And in the unlikely event they make it past all of that, are you also willing to take all of the support calls you'll get when a module fails to install but the customer thinks it's our fault because we provide the dedicated server, rather than the module author's fault? People who get a *nix server from us generally have a better understanding of technical issues involved but the Windows folks don't.
I can't tell you how many Windows servers we have (not allowed) but we're the largest hosting provider in the United Kingdom and many of our customers aren't programmers and don't want to be programmers. They just want to install a bulletin board, maybe some blog software, or something similar. They're consumers, not developers, and if they choose Windows, they're used to just installing stuff and forgetting about it.
| [reply] |
|
And do you want a job in our support department telling our thousands of Windows users how to install a C compiler, nmake, configure CPAN, and install the necessary modules they need/want?
Thousands of Windows users who want to program in Perl.
It's not totally out of line to suggest that Perl programmers on any platform learn to manage a C compiler. (I could see an exception for programming students.)
Vanilla/Strawberry don't take that complexity away -- they just provide the compiler and other tools and pre-configure everything so it just works. They also include upgrades to a bunch of 5.8.8 core modules to provide better Windows support out of the box.
It's packaged and standardized complexity instead of complexity that every person frustrated with AS has to figure out and solve for themselves.
If you're talking about Windows end-users of a program written in Perl, then I would imagine the better solution is using PAR or something to package everything they need rather than relying on them to install Perl itself and get necessary dependencies from CPAN or PPMs.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
|
And do you want a job in our support department telling our thousands of Windows users how to install a C compiler, nmake, configure CPAN, and install the necessary modules they need/want?
Who said anything about giving a C compiler to a user. I was suggesting one for you. Why would I give a customer a compiler when I can simply build a solution for them? This reminds me of a quote from elsewhere...
Perhaps you have forgotten that this is an engineering discipline, not some sort of black magic.
ActiveState, much like all *nix will not provide all of CPAN for download as a package. It simply isn't practical. You can, however, make it easier on yourself by providing your customers a Perl with several hundred extra modules out of the box.
But what is the solution for the modules that you don't provide or ActiveState doesn't build PPMs for? In the case of dedicated hosting customers on Windows, the answer is rather simple. Host your own PPM repository for them.
Here's how it works. Hosting customer calls up with a request for a module to have a PPM built. A level two support person attempts to build the PPM for them in something closer to a development box. Certain modules could be automatically declined like PDL, which requires a Fortran compiler, or modules that require special licensing like DBD::Oracle or DBD::DB2. If it can be built, you add it to your repository. If not, you let the customer know that it is not available at this time, and give them a solution for how you can resolve it through licensing or other means. For modules you can build, you add it to a custom build script of modules to watch CPAN for, so if a new version is released, it just pulls it down and create a new PPM.
As time goes on, you will probably want to make the process more automated, like eliminating the support person from the process, unless problems occur in the build. My guess is that you could even put a web front end on this and let customer request the modules be added by themselves.
| [reply] |
|
|
| [reply] |
Re: Getting Fed Up with ActiveState
by Andrew_Levenson (Hermit) on Dec 05, 2006 at 22:10 UTC
|
Is this something I have to worry about doing trivial scripting, or will it only apply if and when I have some real work to do?
$\=" ";$u=0;$w=0;x(qw/4A 16 07 86/);sub x{while(@_){$u**=$w?$w:$#_;
print map{$w<$u?chr(hex shift):chr(hex reverse(shift))}$_;$w+=length%2
+!=1?-1:1}}
| [reply] [d/l] |
|
or will it only apply if and when I have some real work to do?
There's a good chance it won't apply to you even if/when you do have "some real work to do".
Cheers, Rob
| [reply] |
Re: Getting Fed Up with ActiveState
by wjw (Priest) on Dec 06, 2006 at 05:27 UTC
|
I am sort of late coming in on this, but have been following along with interest... . There are a lot of good points made throughout this discussion, technical and otherwise. I have learned a fair amount just reading through all of them. I appreciate that...
I have experienced fustrations with ActiveState as well. Usually on winxx of some flavor. I have seldom experienced such problems on *nix platforms using CPAN, but it has happended. On the other hand, ActiveState has been a real time saver (productivity enhancer) for the most part. I really appreciate what they have done and are doing. That being said, I also think that Ovid has identified real issues and has taken the time and made the effort to come up with a solution to those issues, and done a good job of explaining the motivation for his efforts. It seems to me that it is a rational response to frustration, and pretty much reflects the attitude that has driven the open source community forward for so long... If it frustrates you, or you just don't like it... well change it if you can, and share the opportunity with others. Over the long haul, the worst that can happen is something useless is created, the best thing that can happen is that some problems get solved and another option becomes available... . Thanks again to everyone that posted for providing some enlightening points of view and interesting technical points.
...the majority is always wrong, and always the last to know about it...
| [reply] |
Re: Getting Fed Up with ActiveState
by rahed (Scribe) on Dec 01, 2006 at 19:35 UTC
|
I also used ActivePerl on Windows and gave up using it because of many missing modules.
Now I am content with perlwin32 which compiled fine with MinGW.
I was not able to install Tk though, probably some missing stuff, but didn't dig into. If necessary rather work with gtk2. | [reply] |
Re: Getting Fed Up with ActiveState
by Anonymous Monk on Dec 01, 2006 at 17:07 UTC
|
I use the Visual Package Manager, part of the PDK form AS.
Also, whats to stop someone from just manually running Makefile.PL when Build.PL borks? :) | [reply] |
|
| [reply] |
|
From what I remember, Ubuntu, Debian, and Mac OS X Perl's all had the same problem with Scalar::Util. Appartantly, something in how Scalar::Util installed it shared lib was different than the other modules. This have been fixed with change #28344.
| [reply] |
Re: Getting Fed Up with ActiveState
by vkon (Curate) on Dec 02, 2006 at 00:29 UTC
|
absolutely nonsence.
I found their support very effective, and a very large addition to Open Source
I am very happy to have centralised Win32 support, and mentioned by you Strawberry Perl is too diletantic and not time proven, unlike ActiveState with their personel many of them deserving deep respect.
Not a first time I am surprised how a person with huge XP like yours can talk nonsence.
indeed, XP means nothing, you prove this.
Go, downvote me, I will be just happy on receiving '--' in this particular case.
I am proud to have better knowledge than yours with less XP. | [reply] |
|
I noticed that with the exception of my Strawberry Perl reference, you didn't address a single point I made. Instead, you tell how friendly ActiveState has been (and I do agree on this point) and you then attack me. This is not productive. I listed very concrete issues and linked to the evidence.
Since AS can't support core module upgrades, users cannot use modules which require those (but see next paragraph). Since AS apparently doesn't fall back to Makefile.PL if the Build.PL has problems, users cannot use those modules. And when we have modules which have all tests pass but are still listed as failing, I, as a module author, have no way out.
Yes, I can tell users how to find other PPM repositories or tell them how to install a compiler and find nmake, but when I have thousands of dedicated servers, this becomes a support nightmare, drives up costs, and ensures that my company has to spend more more working around problems in a build process we don't control instead of providing more features for our customers. This costs our company money.
These are issues that ActiveState has known about for years. For a small company, they've done great things for the Perl community and I don't want to disparage that, but when one of the fundamental needs of a particular open-source product is not met, it becomes a stumbling block and toolchains must not fail if it can be avoided. The more difficult a toolchain is to work with, the more likely someone is to choose different tools. I've emailed ActiveState in the past about related problems and Adam Kennedy has communicated with them for over a year on this, to no avail. Even a quick search on Google has led me to a number of similar horror stories. I also know of at least one module author who no longer worries about Windows because of how painful things are. How this could possibly serve the needs of the Perl community, I don't know.
| [reply] |
|
| [reply] |
|
|
|
|
I admit that I quickly become too aggressive to your responce...Actually, sorry, I should have more concrete points on the matter.
Please excuse me for my tone.
But when you met some difficulty/bug, far more productive is to correctly work with misbehaviour, but driving people away from AS is counterproductive.
You say some bug costs you money. But isn't *every* bug cost money, more or less?
Finding a way around bugs costs human attention, which turns out to be money in the end.
My example - my PocketPC throws away my internet browser, so I need to reload via mobile network some pages again, and again, so this cost me money spent on trafic.
Okay, calming down once again :) let me notice that value of binaries produced by ActiveState is not only exact versions of binaries, but this entire support of several languages together makes even more added value. (I mean new alternative of perl/Tk feature ActiveTcl, which is a big step forward)
Returning to your original question, there was similar problem in Perl core itself, longly discussed in p5p.
There was an error for module searching algorithm. If you have module in the core, but then install it from CPAN, then you get both versions on disk, but actually used version is wrong one. Very old and very serious problem, and I even suspect you faced namely this problem.
what to do in the realm of thousands of frustrated users? Switch to python?
In my opinion calm discussion with p5p and with AS (which are sometimes are same people) is the best option.
Best regards,
Vadim.
PS Thanks for constructive reply, and please forgive my yet other ramblings, which a hopelly not such aggressive this time :)
| [reply] |
|
Since AS can't support core module upgrades, users cannot use modules which require those
But AS perl can (and does) support core module upgrades. Any user with a compiler (either a free/commercial M$ compiler, or the freely available MinGW compiler) can upgrade core modules on ActivePerl. If that's not happening, then I think you should blame the user ... not ActiveState.
I think it's up to the user to overcome the PPM shortcomings. It's not a difficult task.
Cheers, Rob
| [reply] |
|
|
|
|
| [reply] |
|
I think the word you were looking for is "Alpha"
I don't really understand why Strawberry perl is alpha. There's nothing alpha about the components that make up the Strawberry distro - namely dmake, MinGW, and MinGW-built Perl. Yet, somehow there's a (perceived) reason to label a pre-packaged distro of those components as being "alpha" ?
Calling it "alpha" casts, by association, unwarranted doubts (imo) upon the reliability of the components that make up the package.
Cheers, Rob
| [reply] |