Re: The spewing problem.

* Ovid <[EMAIL PROTECTED]> [2008-01-15 20:30]: > Care to explain the term 'monkeypatch'? http://en.wikipedia.org/wiki/Monkey_patch Basically, grubbing around in someone else’s guts. Regards, -- Aristotle Pagaltzis //

Re: The spewing problem.

Ovid wrote: --- Sam Vilain <[EMAIL PROTECTED]> wrote: However I am yet to see anything other than a monkeypatch on Ovid's journal, and an incomplete patch linked earlier on the thread. Care to explain the term 'monkeypatch'? I've always heard of it as injecting code into someone elses [brok

Re: The spewing problem.

--- Sam Vilain <[EMAIL PROTECTED]> wrote: > However I > am yet to see anything other than a monkeypatch on Ovid's journal, > and an incomplete patch linked earlier on the thread. Care to explain the term 'monkeypatch'? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl

Re: The spewing problem.

Aristotle Pagaltzis wrote: > * Geoffrey Young <[EMAIL PROTECTED]> [2008-01-14 17:05]: >> it's useful to me because I say it is. personally I don't feel >> the need to defend something many people would like to see this >> like we're being forced to here. > > Yeah, agreed. Why is everyone so dogmat

Re: The spewing problem.

--- Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote: > Yeah, agreed. Why is everyone so dogmatic and prescriptive? What > happened to giving people enough rope to hang themselves if they > really want to? Didn't you hear? There's only one way to do it ;) Cheers, Ovid -- Buy the book - http://ww

Re: The spewing problem.

* Geoffrey Young <[EMAIL PROTECTED]> [2008-01-14 17:05]: > it's useful to me because I say it is. personally I don't feel > the need to defend something many people would like to see this > like we're being forced to here. Yeah, agreed. Why is everyone so dogmatic and prescriptive? What happened t

Re: The spewing problem.

--- Adam Kennedy <[EMAIL PROTECTED]> wrote: > If we're concerned about losing the diagnostics, then just have it > fail > on the NEXT test... > > Put the... > > if ( any failures ) { bail out } > > ... at the beginning of the ok call, not at the end. FYI: That was Aristotle's suggestion and

Re: The spewing problem.

On Jan 13, 2008, at 8:22 PM, Adam Kennedy wrote: Because if my test script is startled, I want it to stop and fall over. Google for "feinting goat". Adam K fainting = falling unconscious feinting = making a false attack to lure your opponent off guard before the real attack A feinting

Re: The spewing problem.

Geoffrey Young wrote: > schwern has a valid point in not wanting to lose > diagnostics upon implementing this feature, but outside of that it > wastes too many cycles going back and forth like this over what is a > pretty minimal feature. Stop wasting cycles arguing, and start posting patches

Re: The spewing problem.

Michael Peters wrote: Michael G Schwern wrote: Michael Peters wrote: make test || echo -e "\a" I keep digging away at this because I'm looking for a problem other than "I want to see the first failure". And that's what I'm hearing from you and from Matisse and everyone else. Yours is a li

Re: The spewing problem.

Test::Builder should just do what it's told. If the code that IS responsible for testing suites tells it to bail on fail, that's exactly what it should do. Adam K chromatic wrote: On Monday 14 January 2008 02:27:56 Ovid wrote: --- chromatic <[EMAIL PROTECTED]> wrote: How is this simpler

Re: The spewing problem.

Michael G Schwern wrote: > Michael Peters wrote: >>make test || echo -e "\a" > > I keep digging away at this because I'm looking for a problem other than "I > want to see the first failure". And that's what I'm hearing from you and from > Matisse and everyone else. Yours is a little different

Re: The spewing problem.

On Monday 14 January 2008 02:27:56 Ovid wrote: > --- chromatic <[EMAIL PROTECTED]> wrote: > > > How is this simpler than 'bail on fail' or 'die on fail'? > > It doesn't conflate "output TAP results from tests" with "interpret > > TAP results from tests". > Neither does "die on fail". > "Die on

Re: The spewing problem.

Still curious - perhaps you can explain more about why you think this is useful thing. it's useful to me because I say it is. personally I don't feel the need to defend something many people would like to see this like we're being forced to here. schwern has a valid point in not wanting to

Re: The spewing problem.

Because if my test script is startled, I want it to stop and fall over. Google for "feinting goat". Adam K On 14/01/2008, Michael G Schwern <[EMAIL PROTECTED]> wrote: > > Adam Kennedy wrote: > > This shouldn't be any more complicated than " -g" (where g in my case > > stands for "goat" as in "fe

Re: The spewing problem.

Matisse Enzer wrote: Ok, why do you want to stop it as fast as possible when a failure occurs? >>> So I can more quickly focus on fixing that first test failure. >> I use >> make test 2>&1 | less >> Works for individual tests too >> make && perl -Mblib t/testname.t 2>&1 | less > I don't

Re: The spewing problem.

--- chromatic <[EMAIL PROTECTED]> wrote: > > How is this simpler than 'bail on fail' or 'die on fail'? > > It doesn't conflate "output TAP results from tests" with "interpret > TAP results from tests". Neither does "die on fail". "Die on fail" doesn't violate that in the slightest because it'

Re: The spewing problem.

On Jan 13, 2008, at 7:13 PM, Sam Vilain wrote: Matisse Enzer wrote: Ok, why do you want to stop it as fast as possible when a failure occurs? So I can more quickly focus on fixing that first test failure. I use make test 2>&1 | less Works for individual tests too make && perl -Mblib t/

Re: The spewing problem.

Matisse Enzer wrote: >> Ok, why do you want to stop it as fast as possible when a failure >> occurs? > So I can more quickly focus on fixing that first test failure. I use make test 2>&1 | less Works for individual tests too make && perl -Mblib t/testname.t 2>&1 | less Sam.

Re: The spewing problem.

# from chromatic # on Sunday 13 January 2008 10:28: >> How is this simpler than 'bail on fail' or 'die on fail'? > >It doesn't conflate "output TAP results from tests" with "interpret > TAP results from tests". Yes. -- I arise in the morning torn between a desire to improve the world and a desi

Re: The spewing problem.

* Michael G Schwern <[EMAIL PROTECTED]> [2008-01-14 00:35]: > Why a goat and why is it feinting? Because http://video.google.com/videoplay?docid=5306665151934403100 Regards, -- Aristotle Pagaltzis //

Re: The spewing problem.

Adam Kennedy wrote: > This shouldn't be any more complicated than " -g" (where g in my case > stands for "goat" as in "feinting goat") Ok, I'll bite. Why a goat and why is it feinting? -- ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up aft

Re: The spewing problem.

Michael G Schwern wrote: Paul Johnson wrote: This is something that I too have asked for in the past. I've even hacked up my own stuff to do it, though obviously not as elegantly as you or Geoff. Here's my use case. I have a bunch of tests that generally pass. I hack something fundamental an

Re: The spewing problem.

On Jan 13, 2008, at 10:40 AM, Michael G Schwern wrote: You see how this is distinct from "halt on first failure"? It gives me a lot more room for different solutions that don't involve just cutting off all the following information. I do see (and respect) that difference, but stopping t

Re: The spewing problem.

Michael Peters wrote: > Michael G Schwern wrote: > >> Ok, why do you want to stop it as fast as possible when a failure occurs? > > I have a 45 minute test suite and I want to work on the first failure as soon > as > possible. I also have multiple desktops and am doing other things in another >

Re: The spewing problem.

On Sunday 13 January 2008 04:27:38 Ovid wrote: > --- Salve J Nilsen <[EMAIL PROTECTED]> wrote: > > 1. Redirect test output to a temporary log file (which should get > > cleaned up during "make clean" &al.) > > 2. Let the harness be "aware" of this log file, and "tail(1)" it as > > things get writ

Re: The spewing problem.

On 13 Jan 2008, at 18:06, Michael Peters wrote: Ok, why do you want to stop it as fast as possible when a failure occurs? I have a 45 minute test suite and I want to work on the first failure as soon as possible. I also have multiple desktops and am doing other things in another desktop, s

Re: The spewing problem.

Michael G Schwern wrote: > Ok, why do you want to stop it as fast as possible when a failure occurs? I have a 45 minute test suite and I want to work on the first failure as soon as possible. I also have multiple desktops and am doing other things in another desktop, so I want to know as soon as

Re: The spewing problem.

On Jan 13, 2008, at 9:17 AM, Michael G Schwern wrote: Matisse Enzer wrote: On Jan 12, 2008, at 10:24 PM, Michael G Schwern wrote: Matisse Enzer wrote: I just want to be able to run a test suite with a switch that makes the entire test run stop after the first failure is reported. Ok, i

Re: The spewing problem.

Matisse Enzer wrote: > > On Jan 12, 2008, at 10:24 PM, Michael G Schwern wrote: > >> Matisse Enzer wrote: >>> I just want to be able to run a test suite with a switch that makes the >>> entire test run stop after the first failure is reported. >> >> Ok, it's nice to want things, but why do you wa

Re: The spewing problem.

Ovid said: --- Salve J Nilsen <[EMAIL PROTECTED]> wrote: Ok, a shot in the dark... 1. Redirect test output to a temporary log file (which should get cleaned up during "make clean" &al.) 2. Let the harness be "aware" of this log file, and "tail(1)" it as things get written to it, printing

Re: The spewing problem.

--- Salve J Nilsen <[EMAIL PROTECTED]> wrote: > Ok, a shot in the dark... > > 1. Redirect test output to a temporary log file (which should get > cleaned > up during "make clean" &al.) > 2. Let the harness be "aware" of this log file, and "tail(1)" it as > things > get written to it, prin

Re: The spewing problem.

Michael G Schwern said: The problem I'm hearing over and over again is "Test::Builder is spewing crap all over my screen and obscuring the first, real failure". So now that the problem is clearly stated, how do we solve it without making all that spew (which can be useful) totally unavailabl

Re: The spewing problem.

On Jan 12, 2008, at 10:24 PM, Michael G Schwern wrote: Matisse Enzer wrote: I just want to be able to run a test suite with a switch that makes the entire test run stop after the first failure is reported. Ok, it's nice to want things, but why do you want it? Almost entirely because when

Re: The spewing problem.

Matisse Enzer wrote: > I just want to be able to run a test suite with a switch that makes the > entire test run stop after the first failure is reported. Ok, it's nice to want things, but why do you want it? -- 100. Claymore mines are not filled with yummy candy, and it is wrong to tell n

Re: The spewing problem.

I just want to be able to run a test suite with a switch that makes the entire test run stop after the first failure is reported. --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/

Re: The spewing problem.

Michael G Schwern wrote: > Paul Johnson wrote: >> This is something that I too have asked for in the past. I've even >> hacked up my own stuff to do it, though obviously not as elegantly as >> you or Geoff. Here's my use case. >> >> I have a bunch of tests that generally pass. I hack something >

Re: The spewing problem.

On 12 Jan 2008, at 18:33, chromatic wrote: The problem I'm hearing over and over again is "Test::Builder is spewing crap all over my screen and obscuring the first, real failure". So now that the problem is clearly stated, how do we solve it without making all that spew (which can be usefu

Re: The spewing problem.

On Saturday 12 January 2008 07:03:16 Michael G Schwern wrote: > The problem I'm hearing over and over again is "Test::Builder is spewing > crap all over my screen and obscuring the first, real failure".  So now > that the problem is clearly stated, how do we solve it without making all > that spew

The spewing problem.

Paul Johnson wrote: > This is something that I too have asked for in the past. I've even > hacked up my own stuff to do it, though obviously not as elegantly as > you or Geoff. Here's my use case. > > I have a bunch of tests that generally pass. I hack something > fundamental and run my tests.