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

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



On Tue, Dec 22, 1998 at 07:21:48AM -0500, Chris Nandor wrote:
} 
} 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.

I'm testing right now, in fact.  For MacPerl, I report on the modules
I install for use, since I'm going to run the tests anyway in that
case.  I might as well report the results.  I always report on your
modules, because it's never a good idea to take the author's word for
it :-)  (Of course it's going to work on the author's machine or it
wouldn't have been shipped.)

} 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.
} 
} 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 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.  :/

Because it so hard, I'd guess.  On Linux, right now, I'm testing a new
module:

cpan> test Set::IntSpan

followed (in another xterm) by "cpantest -p <cut and paste> -g".
After a while I'll go back to the CPAN window and see what happened.
Then, usually, I add " pass -auto" to the cpantest string and hit
return.  I can do this while handling my email in the morning or
eating lunch/surfing the Web at work.  The hard part is when something
goes wrong, when you have to start looking at the module and its docs
to see if what went wrong is a documented problem and if it can be
fixed.

On MacPerl?  At the moment, I'd have to 1) download the module by
hand, 2) unpack the module by hand.  Now, if I'm lucky, I can gimmick
@INC so that I can run the tests, but I might actually have to set up
the blib tree if files are out of place.  Then I can run the tests.
At the moment I have a script that can be pointed at a t folder and
run all the *.t inside with do, (although this doesn't always work
with tests that rely on their environment).  This script relies on the
module being installed properly, since it doesn't set @INC, but that
could be changed.

If the tests, don't run, is it the module or the tests?  In many
cases, it's the tests.  For example, Lincoln Stein has written CGI so
that it autodetects what platform you're running on and does The Right
Thing.  But the tests use pipes and \r\n, and so have to be ported.
The LWP patch I sent to Gisle Aas was followed by a larger patch to
the LWP test suite, because it did such things as rely on /etc/passwd
and /tmp and the ability to run two perls at once so one could be a
server and one a client.  (And all you can do about the tests that run
two perls is turn them off.)  It's, unfortunately, all too common for
a module to work perfectly out of the box while its test suite needs
to be ported.  (We could, of course, be hard nosed about such problems
and just fail the module, as I usually do when people use 5.005
additions and fail to document or check Perl version.)

I agree completely we need volunteers to test for MacPerl.  Several,
in fact, who can divide the work load, because it's not as easy as
testing under Unix.  I can handle three Unix flavors with little
problem, but doing MacPerl by myself would be a real burden the way
things are today.  The MacPerl installation scripts will help a great
deal to reduce the load, but won't solve all the problems.  If we can
find testers, we can begin feeding patches back to the authors so that
CPAN itself becomes more useful to MacPerl users.


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

-- 
Paul Schinder
schinder@pobox.com

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