[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: We don't need evangelism, we need democracy(was Re: [MacPerl] macCPAN)




>Well, until Mac OS can fully support Unixisms, I think that is what we are
>stuck with.

I wouldn't have said "stuck with" but I'm not debating the obvious
technical differences

>And if you think that puts MacPerl into the realm of hobbies, then you are
>misinformed.

Your perhaps misreading what I intended I don't look on MacPerl as being
hobbyist - I think however  we seem to keep trying to marginalise ourselves
and by doing so we get ourselves pigeonholed as such


>Is Win32 for hobbyists?  AS/400?  VMS?  These and more all require
>significantly
>different Stuff to get perl and related technologies to work.

Win32 has an exhaustive collection of modules on CPAN - why can't we?


>1.  comp.lang.perl.misc sucks rocks.

hmm, maybe, I find it useful for picking up tips on generic Perl tho

>2.  Because most MacPerl users on this list, those who have voiced opinions
>on the matter like mailing lists better than Usenet for, at least, the
>purpose of discussing MacPerl.

Again you have misunderstood me, I'm not advocating the discussion of
MacPerl specifics in a forum like CPLM, what I am advocating is that we
raise the awareness of perl compatibility so that we no longer have to do
all the tweaking to get standard issue modules to work - MacPerl speaks
both Mac and Perl, and when it comes down to Perl _that's_ where we should
be pushing for awareness

>I believe Mac OS has more platform-specific modules than any other
>platform, save Win32.  But I don't see why this is relevant.
The number of modules for Win32 on CPAn is staggering - and this I believe
reflects the way the general Perl community gauges interest, and for
interest read importance and/or taking into consideration. Win32 seems to
be grudgingly accepted and MacPerl non existent.


>But it is not acceptable to break things significantly to make them work on
>a minor platform.  I would not support, for instance, completely redoing
>CPAN just so it can work better with MacPerl.  That is unacceptable to me,
>and to most others.

Which isn't what I'm suggesting, in one of the Camel books it says
something about "welcome to the world of Unix" - however Perl is something
a whole lot more than just a Unix orientated package and I think we are
doing nothing to make it any different



>Heh.  You have NOT seen perlport.pod, then, I guess.
>
>    http://pudge.net/macperl/perlport.pod
>    http://pudge.net/macperl/perlport.html
>
>This document is on CPAN and is also distributed with perl5.005 and later.
>In fact, I do think that this document is one of the reasons why p5p is
>more open to Making Things Work on other platforms.  They can see and know
>where the inconsistencies and problems are.

But if there isn't a policy of failing modules (ie not putting them into
CPAN) intended for general use that _don't_ take into account these
problems what use is it? This is what I'm driving at -
a FAQ is only a guideline, until there is some kind of motivation to follow
it there are still going to be modules that are _supposed_ to be cross
platform, but that need patching to get them to work.

P5P has a vested interest in portability and is _not_ the greater Perl
community and until they start to care about this - which I really don't
see them doing at the moment - the FAQ is going to be a nice completion to
the PODs and nothing else



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch