Re: satiating cpantesters
Eric Wilhelm wrote: But you didn't succeed because something's wrong and thus on the way out you must mention to the poor user what that might be. I suppose if we had a leave() function, you could get something like 'warn can't install without ...; exit 0' from 'leave can't install without ...', but we don't because a successful program doesn't have anything to say because there's nothing wrong. I'm not sure. A synthetic example here would be some config parser that uses various XML parsers internally. Say the user doesn't have a reasonably fast XML parser installed but the slowest module possible. The config parser might use that one as a fallback and still work correctly (so technically the tests succeeded) but it might be so abysmally slow as to warant a warning to the user on exit. So even on success (technical correctness), you might want to warn the user about the possible problems with his/her setup without failing the tests. LG Rene
Re: satiating cpantesters
Eric Wilhelm wrote: # from David Cantrell # on Wednesday 06 January 2010 03:48: Exiting with a 0 status would seem to be the least clunky solution. exit(0) means Stop now and claim to have succeeded But you didn't succeed because something's wrong and thus on the way out you must mention to the poor user what that might be. Fine, but if you *don't* claim to have succeeded, then you have to expect that software that looks for failures will spot the failure and report it. -- David Cantrell | http://www.cantrell.org.uk/david It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it -- Alan Cooper
Re: satiating cpantesters
# from David Cantrell # on Saturday 09 January 2010 07:44: Fine, but if you *don't* claim to have succeeded, then you have to expect that software that looks for failures will spot the failure and report it. As the author's fault? Right. --Eric -- perl -e 'srand; print join( ,sort({rand() 0.5} qw(sometimes it is important to be consistent)));' --- http://scratchcomputing.com ---
Re: satiating cpantesters
On Sat, Jan 09, 2010 at 11:48:19AM -0800, Eric Wilhelm wrote: # from David Cantrell # on Saturday 09 January 2010 07:44: Fine, but if you *don't* claim to have succeeded, then you have to expect that software that looks for failures will spot the failure and report it. As the author's fault? Right. No. Reporting a failure is not the same as assigning blame. -- David Cantrell | Enforcer, South London Linguistic Massive I apologize if I offended you personally, I intended to do it professionally. -- Steve Champeon, on the nanog list
Re: satiating cpantesters
On Wed, Dec 16, 2009 at 10:53:22AM -0800, Eric Wilhelm wrote: # from David Cantrell Mmmm, more special cases. From a user's (ie, a module author's) point of view, isn't it easier to remember exit(0) than to remember exactly what message to spit out? Easier to remember, maybe. But the challenge isn't memory (we usually just look things up, right?), it's education. If you have to educate about the unnatural exit(0) *and* that makes the code clunky, it would seem like a better idea to educate about something that isn't so creaky. Exiting with a 0 status would seem to be the least clunky solution. exit(0) means Stop now and claim to have succeeded. It means that in every perl program and, indeed, every non-perl program. Better to educate them about something clean and easy to remember than to educate them that there's a special case for this (for which they'll have to either remember an exact string or look it up every time). -- David Cantrell | A machine for turning tea into grumpiness If you have received this email in error, please add some nutmeg and egg whites, whisk, and place in a warm oven for 40 minutes.
Re: satiating cpantesters
# from David Cantrell # on Wednesday 06 January 2010 03:48: Exiting with a 0 status would seem to be the least clunky solution. exit(0) means Stop now and claim to have succeeded But you didn't succeed because something's wrong and thus on the way out you must mention to the poor user what that might be. I suppose if we had a leave() function, you could get something like 'warn can't install without ...; exit 0' from 'leave can't install without ...', but we don't because a successful program doesn't have anything to say because there's nothing wrong. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: satiating cpantesters
* Eric Wilhelm enoba...@gmail.com [2010-01-06 18:15]: But you didn't succeed because something's wrong The Makefile is not missing because the program crashed before it managed to generate one. It is missing because the program successfully determined that installation cannot proceed. The program succeeded. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: satiating cpantesters
On Mon, Dec 14, 2009 at 11:46:07PM -0800, Eric Wilhelm wrote: # from Burak Gürsoy # on Monday 14 December 2009 12:20: Well... Either die OS unsupported\n is an exception (since I get NA for that) That's special-cased for Hysterical Raisins. Yeah. Makes me wonder why fatal m/^Unsupported configuration: .*/ errors couldn't be made NA. Mmmm, more special cases. From a user's (ie, a module author's) point of view, isn't it easier to remember exit(0) than to remember exactly what message to spit out? -- David Cantrell | semi-evolved ape-thing What a lovely day! Now watch me spoil it for you.
Re: satiating cpantesters
# from David Cantrell # on Wednesday 16 December 2009: Makes me wonder why fatal m/^Unsupported configuration: .*/ errors couldn't be made NA. Mmmm, more special cases. From a user's (ie, a module author's) point of view, isn't it easier to remember exit(0) than to remember exactly what message to spit out? Easier to remember, maybe. But the challenge isn't memory (we usually just look things up, right?), it's education. If you have to educate about the unnatural exit(0) *and* that makes the code clunky, it would seem like a better idea to educate about something that isn't so creaky. --Eric -- Ignorance more frequently begets confidence than does knowledge. -- Charles Darwin --- http://scratchcomputing.com ---
Re: satiating cpantesters
On Tue, Dec 15, 2009 at 2:46 AM, Eric Wilhelm enoba...@gmail.com wrote: # from Burak Gürsoy # on Monday 14 December 2009 12:20: Well... Either die OS unsupported\n is an exception (since I get NA for that) Yeah. Makes me wonder why fatal m/^Unsupported configuration: .*/ errors couldn't be made NA. Maybe a wiser idea is to require Devel::AssertOS or whatever module it was, to make sure your module will build on the appropriate platform. Thus, if your assertion can't be installed, your module build will fail due to NA wouldn't it? --Eric -- Issues of control, repair, improvement, cost, or just plain understandability all come down strongly in favor of open source solutions to complex problems of any sort. --Robert G. Brown --- http://scratchcomputing.com ---
Re: satiating cpantesters
# from Burak Gürsoy # on Monday 14 December 2009 12:20: Well... Either die OS unsupported\n is an exception (since I get NA for that) Yeah. Makes me wonder why fatal m/^Unsupported configuration: .*/ errors couldn't be made NA. --Eric -- Issues of control, repair, improvement, cost, or just plain understandability all come down strongly in favor of open source solutions to complex problems of any sort. --Robert G. Brown --- http://scratchcomputing.com ---