Ovid writes:
> Schwern ... does not object to renaming TAPx::Parser to TAP::Parser.
Please do it! For anybody first encountering it after the rename it is
one less arbitrary fact to remember, one less question they have about
it.
And obviously the sooner the better, from the point of view of
mi
Hi all,
Per an email from Schwern, he does not object to renaming TAPx::Parser
to TAP::Parser. Hence, we have an official 'blessing' from him for
claiming this namespace. Does anyone have any thoughts/objections to
this? I realize that enough people are using TAPx::Parser that it
might be a tin
(Resent from the address I've actually subscribed from!)
Hi all,
Per an email from Schwern, he does not object to renaming TAPx::Parser
to TAP::Parser. Hence, we have an official 'blessing' from him for
claiming this namespace. Does anyone have any thoughts/objections to
this? I realize that e
On 3/5/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>> > Instead of having to disable (or enable) CC for every new tool,
>> > I'd want a setting that new tools could look at without me having
>> > to change the META.yml in all of my distributions then
>> > re-uploading them all.
...
>I'm just sayi
# from Ricardo SIGNES
# on Monday 05 March 2007 10:09 am:
>* brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
>
>> ... without me having to
>> change the META.yml in all of my distributions then re-uploading
>> them all.
>
>So, for some subset of META.yml settings, you could consult the
> mod
# from brian d foy
# on Monday 05 March 2007 10:41 am:
>In article <[EMAIL PROTECTED]>, Ricardo
>
>SIGNES <[EMAIL PROTECTED]> wrote:
>> * brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
>>
>> > I'm not talking about the particular field name, but the idea that
>> > I'd want to say in META.ym
# from Ovid
# on Monday 05 March 2007 05:38 am:
>I have no idea what to name that switch, though, as 'warnings' is
>already taken to enable warnings in the programs. '--tap-warnings' is
>probably a decent choice even though I prefer '--squeal-like-a-pig'.
--have-a-good-talking-to
--tsk
--E
# from Ovid
# on Monday 05 March 2007 06:26 am:
>--- Andy Lester <[EMAIL PROTECTED]> wrote:
>> I'm very wary of potentially hidden files causing changes to whether
>> my tests pass or not. "Gee, these tests pass for me, but not for
>> you..." caused by a hidden .rc file. :-(
Sure, but that might
In article <[EMAIL PROTECTED]>, Ricardo
SIGNES <[EMAIL PROTECTED]> wrote:
> * brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
> > I'm not talking about the particular field name, but the idea that I'd
> > want to say in META.yml "Don't send me mail", or whatever setting I
> > want.
> >
> >
On 3/5/07, Ovid <[EMAIL PROTECTED]> wrote:
Good point. How about, if an .rc file is used, the output of runtests
is something like:
shared_cp $ runtests -lrq
Using .rc file: /home/ovid/.runtestsrc
t/cp_demo_lib.ok
t/cp_lib..ok
t/db_conne
* brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
> I'm not talking about the particular field name, but the idea that I'd
> want to say in META.yml "Don't send me mail", or whatever setting I
> want.
>
> Instead of having to disable (or enable) CC for every new tool, I'd
> want a setting th
--- Eric Hacker <[EMAIL PROTECTED]> wrote:
> I'd try to use something like YAML for as much of the output as
> practical, especially the configuration information or warnings. Perl
> is great at parsing, but why make it difficult. Especially for the
> person I'll worship who'll write the Eclipse
--- Andy Lester <[EMAIL PROTECTED]> wrote:
>
> On Mar 5, 2007, at 8:16 AM, Ovid wrote:
>
> > Sounds reasonable. I'm planning on doing a new dev release tonight
> > (pretty much what's in Subversion right now), so it won't be in
> there
> > right away, but I do like this idea.
>
> I'm very wary
On Mar 5, 2007, at 8:16 AM, Ovid wrote:
Sounds reasonable. I'm planning on doing a new dev release tonight
(pretty much what's in Subversion right now), so it won't be in there
right away, but I do like this idea.
I'm very wary of potentially hidden files causing changes to whether
my test
--- Adrian Howard <[EMAIL PROTECTED]> wrote:
> It would be nice if the warnings could be made more granular. For
> example I like trailing plans, but non-TAP output might be an issue.
>
> Maybe an .*rc file of some kind ala Perl::Critic?
Sounds reasonable. I'm planning on doing a new dev rel
Given all of this chat, what would folks think about an optional
switch
to 'runtests' (the TAPx::Parser equivalent to 'prove'), which would
warn users about which test programs are being run without a plan?
Rather than a warning, I'd rather have a failure. I've considered
putting this in Te
Given all of this chat, what would folks think about an optional switch
to 'runtests' (the TAPx::Parser equivalent to 'prove'), which would
warn users about which test programs are being run without a plan?
Brilliant idea.
In functional testing, there are situations where one doesn't know how
m
On 5 Mar 2007, at 13:38, Ovid wrote:
--- Eric Hacker <[EMAIL PROTECTED]> wrote:
Given all of this chat, what would folks think about an optional
switch
to 'runtests' (the TAPx::Parser equivalent to 'prove'), which would
warn users about which test programs are being run without a plan?
T
--- Eric Hacker <[EMAIL PROTECTED]> wrote:
> > Given all of this chat, what would folks think about an optional
> switch
> > to 'runtests' (the TAPx::Parser equivalent to 'prove'), which would
> > warn users about which test programs are being run without a plan?
That should have read 'run with
Dominique Quatravaux wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andy Lester wrote:
Good Lord do I get frustrated at the handwringing over test
counting. Look, it's simple. You write your tests. You run it
through prove. You see how many tests it reports. You add it at
the top of
--- Ovid <[EMAIL PROTECTED]> wrote:
> Given the recent talks about test plans, here's what I have in
> .vim/plugin/ToggleTestPlan.vim:
*snip*
Given all of this chat, what would folks think about an optional switch
to 'runtests' (the TAPx::Parser equivalent to 'prove'), which would
warn users abo
Given the recent talks about test plans, here's what I have in
.vim/plugin/ToggleTestPlan.vim:
if exists( "toggle_test_plan" )
finish
endif
let toggle_test_plan = 1
map tp :call ToggleTestPlan()
function ToggleTestPlan()
call SavePosition()
let curr_li
22 matches
Mail list logo