Re: satiating cpantesters

2010-01-13 Thread Rene Schickbauer

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

2010-01-09 Thread David Cantrell
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

2010-01-09 Thread Eric Wilhelm
# 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

2010-01-09 Thread David Cantrell
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

2010-01-06 Thread David Cantrell
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

2010-01-06 Thread Eric Wilhelm
# 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

2010-01-06 Thread Aristotle Pagaltzis
* 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

2009-12-16 Thread David Cantrell
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

2009-12-16 Thread Eric Wilhelm
# 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

2009-12-15 Thread Jonathan Yu
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

2009-12-14 Thread Eric Wilhelm
# 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
---