On Fri, 22 Apr 2005, Stevan Little wrote:
>
> On Apr 22, 2005, at 11:20 AM, Andy Dougherty wrote:
> > > So if TODO_ALL_FOR_RELEASE is true, we just have 'proclaim' treat all
> > > failures as TODO. Sounds effective enough.
> >
> > I'm probably misunderstanding, but this sounds *too* effective.
On Fri, 22 Apr 2005, Nathan Gray wrote:
> On Thu, Apr 21, 2005 at 02:24:29PM -0400, Stevan Little wrote:
> > On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote:
> > >I don't quite understand the global/env variable idea. Can you explain
> > >that in more detail?
> >
> > It could be something as sim
On Apr 22, 2005, at 11:20 AM, Andy Dougherty wrote:
On Fri, 22 Apr 2005, Nathan Gray wrote:
On Thu, Apr 21, 2005 at 02:24:29PM -0400, Stevan Little wrote:
On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote:
I don't quite understand the global/env variable idea. Can you
explain
that in more detail?
I
On Apr 22, 2005, at 8:51 AM, Nathan Gray wrote:
On Thu, Apr 21, 2005 at 02:24:29PM -0400, Stevan Little wrote:
On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote:
I don't quite understand the global/env variable idea. Can you
explain
that in more detail?
It could be something as simple as this:
%*EN
Andy,
I think you are misunderstanding me.
On Apr 22, 2005, at 2:57 PM, Andy Dougherty wrote:
Yes it would, but it would be a tool only used for release (if at
all). And
Pugs common practice it to mask all failures in the release.
Not exactly (again, assuming I understand this all correctly). It
On Thu, Apr 21, 2005 at 02:24:29PM -0400, Stevan Little wrote:
> On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote:
> >I don't quite understand the global/env variable idea. Can you explain
> >that in more detail?
>
> It could be something as simple as this:
>
> %*ENV = 1;
>
> It is really just a
On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote:
On Thu, Apr 21, 2005 at 11:17:11AM -0400, Stevan Little wrote:
Although after some discussion with nothingmuch on IRC, I think I have
come to good compromise.
We remove all the todo_ functions, and we add a named param "todo" to
all our test function
On Thu, Apr 21, 2005 at 11:17:11AM -0400, Stevan Little wrote:
> Although after some discussion with nothingmuch on IRC, I think I have
> come to good compromise.
>
> We remove all the todo_ functions, and we add a named param "todo" to
> all our test functions. This would allow test level TODO-
Hi,
Stevan Little wrote:
>> The idea was that t/force_todo can be deleted/cleared after a
>> release, so all tests which were only force_todoed were instantly
>> unTODOed.
>
> Unfortunately that is not how it is being used though. It sticks
> around, and in some cases maybe even being used as a i
Ingo,
On Apr 21, 2005, at 10:03 AM, Ingo Blechschmidt wrote:
- Should we do away with the t/force_todo file and introduce a
force_todo() function?
The idea is to move from the more centralized t/force_todo file to a
more decentralized force_todo() function which would accept a list of
test numbers
On Wed, Apr 20, 2005 at 11:30:09PM -0400, Stevan Little wrote:
> It would also allow for code like this:
>
> force_todo(1, 5, 10 .. 15, 25);
>
> Which (IMHO) is nicer than having to do this in the t/force_todo file:
>
> t/my_test.t 1 5 10 11 12 13 14 15 25
>
> I also think that havi
As I was doing a refactor of Test.pm (see r2189) a few thoughts
occurred to me.
- Should we remove all the todo_* functions and just use the
t/force_todo file?
This would cut the number of functions in Test.pm almost in half, which
would decrease loading/parsing time and memory-consumption.
H
12 matches
Mail list logo
