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