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

[Chris Nandor <pudge@pobox.com>]

At 00.50 -0500 12.27.1998, robinmcf@altern.org wrote:
>>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

That you was a generic you.


>>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?

It is fairly large and getting larger.


>>1.  comp.lang.perl.misc sucks rocks.
>
>hmm, maybe, I find it useful for picking up tips on generic Perl tho

I don't.  :)


>>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 don't understand what that means in the context of the status quo, in the
context of what actually is the case in reality.  What do you mean "raise
the awareness of perl compatibility so that we no longer have to do all the
tweaking to get standard issue modules to work"?  Do you mean make
something like perlport and CPAN Testers and merge the MacPerl port changes
back into the core?  That is what is happening.  If you mean something
else, then, specifically, what?


>>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.

I disagre.  I see no evidence for that.  As to "staggering" numbers of
Win32 modules, I go to:

  http://www.cpan.org/modules/00modlist.long.html#Part2-ThePerl5M

I count 25 Win32 modules.  I count 15 Mac modules.  There are a lot more
Mac modules not on the list, and there are probably some Win32 modules not
on the list.  I just don't see facts to back up your assertions.  And while
I wouldn't mind there bing as many or more Mac modules, I don't ever expect
to see that happen, because more people use Win32.


>>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

I think you don't really know what you are saying.  What are we not doing?
I have listed several things we ARE doing.  What are we NOT doing?


>>Heh.  You have NOT seen perlport.pod, then, I guess.

>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?

If you want to rule what is on CPAN with an iron fist, then Perl is not for
you.  Perl culture is open in every way possible.  If you don't want to
bother making your module work on all platforms, that is your right.  What
is needed are people to test the module and give it a failing grade so
people know it does not work.


>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.

There IS a motivation.  CPAN Testers.  But few people in the MacPerl
community want to and are able to actually test.  I want to, but no longer
have the time.  Paul Schinder does some.  Others have expressed interest,
but cannot for various time reasons.  I had hoped that given the very high
number of people on the mac-perl list, that some people would be able to do
it.

But the fact that it is not done is not an argument against CPAN Testers.
It is evidence of something else.  It may be that the MacPerl community
does not deserve to make problems known to the rest of the community,
because it will not do the minimal amount of work itself.



>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

You don't really have any idea what p5p does and does not care about.  I
have shown you plenty of examples of p5p caring about it, and have plenty
more.  CPAN Testers.  perlport.  Making \015, \012, or \015\012 work as a
newline in scripts.  Merging MacPerl-specific changes back into the core.

Did you know that the two current pumpkings are two of the most actively
interested people in portability?  Graham Barr started CPAN Testers with
me, and he is the 5.005 pumpking.  Gurusamy Sarathy did a huge amount of
Win32 work, and he and I gave the talk on Portable Perl at the last Perl
Conference, and he is the 5.006 pumpking.  Jarkko Hietaniemi is the CPAN
librarian, so to speak, and he probably uses more different platforms than
anyone else.  Andreas Koenig runs PAUSE (the upload server for CPAN) and
has worked with us to try to get Mac-native archive formats to work with
CPAN (to no avail, unfortunately).  Jon Orwant, also a CPAN guy, has worked
with me to address MacPerl concerns.  Tom Christiansen and Nathan
Torkington worked with some of us to try to see if code in their wonderful
book Perl Cookbook would have any serious problems with MacPerl, and to
address some MacPerl concerns in the book (the lack of space for all of
this is part of what led to perlport in the first place).

You obviously also missed the heated discussion recently on p5p about
trying to make open() a little "more portable", with the primary case in
point being path separators in MacPerl.  Yes, dozens of people flaming each
other all because of Mac OS path separators.  All persons involved saw a
need in making things work as well as possible in MacPerl.  There was, of
course, significant disagreement on the best way to reach that goal.

But p5p cannot do it all.   It is up to us, the MacPerl community, to do
most of the work.  Some of us are doing the work already, in and near p5p.
But the community is the one that must do most of the work.  If a module
does not work on CPAN, or if it does work, report it to CPAN Testers.  This
is up to Us.  I don't know how you would expect p5p to even check for such
a thing.  That is our job.  Who on p5p or who works for CPAN would you ask
to check to see if these modules work on Macs?

I hope that after your complaining about how things should be, you are
volunteering to do some work.  I do not like clp.misc, but if you do, then
"evangelize" MacPerl there.  I do not have time to do CPAN Testers, but if
you are so upset about how some modules don't work, as I am, then I take it
you are volunteering to test modules.  Good.  Contact Paul Schinder and/or
me and we can help get you started.

--
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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