Re: [MacPerl] libwww-perl-5.41 now available

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Tue, 22 Dec 1998, Chris Nandor wrote:

> At 03.01 -0500 1998.12.22, Rich Morin wrote:
> >IMHO, there are three problems here:
> >
> >  *  It isn't as easy as it should be for Mac users to access the CPAN,
> >     unpack tar.gz archives, etc.  This needs some technology and/or dox.
> 
> Agreed, and somewhat in progress.  We have docs that seem to work for most
> people who read them, in the book.

How about this?  MacCPAN loads a list of Mac-compatible modules from CPAN
Testers, or from another page built from CPAN Testers.  By this, I mean it
shows up in MacCPAN if CPAN Testers marks it okay on Macs.  Perhaps upon
highlighting the module, its summary information shows up in an info panel
out to the side.  You could select "get the readme for this item".  Or if
you double-click it, then... 

MacCPAN goes out and gets the .tar.gz file (because some modules will be
straight Unix modules).  It creates a subfolder inside its MacCPAN
Download folder, uses Perl to untar and the Compress::Zlib module to
unzip. It checks the MD5 signature to lend credibility to the binary. 
(This part is sounding suspiciously like CPAN). 

It checks the line endings, and converts them if necessary. It should be
able to figure out where to put it, either by reading a Makefile and
looking for magic convertible strings ("I recognize that Unix location,
and know a Mac equivalent"), or by a special Mac-only distribution file
(first option's better), or perhaps by parsing module names, or some other
brilliant method supplied by the reader.  It moves the files to the proper
locations (MacCPAN of course knows where its "blessed" MacPerl folder is,
which of course implies that you could have a production MacPerl and
MacCPAN and test MacPerls/MacCPANs.)  It runs Autosplit as necessary.

So far, I think everything has been quite doable (piecewise complete, a
mathematician might say).  The next step is continuing along the Makefile
to testing.  I'm too green to know much about that, so I would omit it for
now.  Of course, heh heh, I've left the code for MacCPAN as an exercise
for the reader.  Perhaps if I had written code instead of English, I'd be
there already...talkers and doers, and all that.  Sometimes I'm a talker.

This would make MacPerl more easily expandable, and make updates much
easier (as Unix CPAN does).  Anybody can change the oil in their car,
right?  The steps are well documented, and it's a simple process.  But it
is hard to argue with "automatic," and time/trouble savings can mean a lot
even when they are small.  Laziness, you know, one of the cardinal
programmer virtues.

> >  *  There isn't an easy way for someone to know if a script has been
> >     "ported" to MacPerl.  Some sort of flag fields in the indexes?
> 
> I think that getting module authors ot make changes, in addition to CPAN
> Testers, is the way to go.  I have mentioned before I have no time to
> continue testing MacPerl for CPAN Testers, and Paul is busy testing other
> platforms, and does the occasional MacPerl module.  We need someone else(s)
> to help here if it is to work.  CPAN Testers can be a central place to see
> if a module works, and the notes there can point to ports or note what
> changes need to be made.

If its format were regularized, a MacCPAN.html might be built from it.  If
it just works on the Mac, fine.  If a port is available, some standard
switch/tag to point to the port location (preferrably in the /Mac
directory on CPAN in a standardized MacCPAN .tar.gz file).  If several
different versions are available and they can't or shouldn't be packaged
together for choosing _after_ download, for size reasons or whatever, then
a standard requirements syntax should also be used. 

Hopefully, then, one entry at CPAN Testers would be enough to enable a
MacCPAN to handle the file.

One other facet of MacCPAN:  an experimental "try a non-Mac module."  This
would load the full CPAN listing, download etc. as usual, and try to
install it.  If someone wanted, they might try to incorporate some
intelligence in bypassing standard porting obstacles.  Then, maybe, if it
worked, an option to notify CPAN Testers could be given.


> But as noted several times before, we need people to help.  I decided I was
> not going to kill myself doing something that other people can do; if
> people find it important enough to get done, it will get done.  If they do
> not find it important, it will not get done, and there is no sense in me
> doing something people don't want done.

I definitely want to help, but right now I'm in a crunch, (cue the 70's
music) staying alive financially, since I don't have a steady job.  And
I'm not currently using MacPerl for Mac-based work, though that may change
soon.

> I think people _do_ want modules tested for MacPerl compatability, so I am
> having a tough time figuring out why people aren't lining up to help.  :/

It will happen, it just takes time.  I think this list helps motivate me,
especially with the wacky MacPerl hacks and useful stuff that gets posted.
Thanks, everybody.




--
MattLangford 




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