On Tuesday, September 17, 2013 01:13:26 PM Mark Stosberg wrote:
> An attempting-to-be-neutral summary would be very helpful.
Pro of adding -w to test runs:
- that's how Test::Harness has always worked, and people might be
relying
on that behavior
Cons of adding -w to test runs:
On Friday, May 03, 2013 01:34:35 PM Ovid wrote:
> ... you'll have to do a lot of work to convince people that starting out
> with an effectively random environment is a good way to test code.
Before you dismiss the idea entirely, consider that our real live code running
for real live clients ru
On Wednesday, December 12, 2012 09:51:27 AM Ovid wrote:
> So, does this look useful for folks?
Yes, please. I would use it last month if I could.
> Is there anything you would change?
I don't *love* maintaining individual driver files (t/subsystem/feature.t),
but I do like being able to run te
On Wednesday, April 11, 2012 at 09:39 AM, Andy Lester wrote:
> In this example:
>
> BEGIN {
> use_ok( 'App::Ack' );
> use_ok( 'App::Ack::Repository' );
> use_ok( 'App::Ack::Resource' );
> use_ok( 'File::Next' );
> }
> diag( "Testing App::Ack $App::Ack::VERSION, File::Next $File::N
On Saturday, November 26, 2011 at 12:44 AM, Gabor Szabo wrote:
> I can just imagine what people outside of the Perl community
> will say when they see such code in the official distribution of Perl.
The same things they already do?
-- c
On Friday, November 25, 2011 at 01:02 PM, Michael G wrote:
> We did it once with Test::Harness::Straps, though not nearly that well
> thought out, and it worked.
Do you know anyone (besides me) who used it?
> I do see a work around. Document that TB2::Mouse can be used, but you MUST
> add it a
On Friday, November 18, 2011 at 06:21 PM, Michael G wrote:
> If I'm hearing you correctly, your argument is that t/test.pl is internal to
> the core and does not need to be documented or tested.
I thought his point was rather that it doesn't need to be stable[1] across
releases of Perl 5.
I cur
On Thursday, November 10, 2011 at 05:57 PM, Michael G wrote:
> If you don't want global warnings, explicitly turn them off with BEGIN { $^W
=
> 0 }.
I thought the argument that test modules should set global policy unilaterally
died out when I made Test::MockObject *not* enable UNIVERSAL::isa
On Thursday, November 10, 2011 at 08:14 AM, H Brand wrote:
> no change whatsoever. I've now added -w to all #! lines in the t files
That's good, that Test::Harness "helpfully" adding magic global hidden command
line options to all invocations isn't the problem here. It's bad that the
problem is
On Thursday, November 10, 2011 at 08:07 AM, H Brand wrote:
> All my test files (in this project) have "use warnings;" (and of
> course "use strict;")
Not "use warnings" but the -w command line flag -- the non-lexical, warnings-
on-everywhere one.
-- c
On Thursday, November 10, 2011 at 07:15 AM, H Brand wrote:
> I however do not understand why prove seems to be safe, but make test
> is not
Do your test files use -w? If not, what happens if you add it and run them with
prove?
This *should* make no difference, but I have a suspicion.
-- c
On Wednesday, October 26, 2011 at 09:58 PM, Michael G wrote:
> So now the question is one of good event handler design, which I don't have
> experience with. How does one design a good event handler? Is the pattern
> one method per type of event? Or one method to do the dispatching? Or
> somet
On Saturday, June 25, 2011 at 09:41 am, Gabor Szabo wrote:
> For projects like Padre we would like to be able to upload versions and let
> the end user easily decide which version they would like to use.
The best* approach I've seen so far is to add version numbers to names, as
does perl5i--alth
On Thursday 04 February 2010 at 09:01, Ovid wrote:
> Is anyone able to replicate the test failures I'm getting for
Test::Class::Most on Perl 5.10.1 Linux/Solaris? I can't (even on those
boxes).
I can replicate them with ./Build disttest but not ./Build test. If I remove:
return
On Sunday 31 January 2010 at 23:39, Ovid wrote:
> I'm thinking about going one step further and hitting the Modern::Perl-like
> road:
> use Test::Most tests => 23;
This seems entirely appropriate to me, provided it only enables strict and
warnings. (The feature pragma is, obviously, less
On Sunday 03 January 2010 at 09:23, Ovid wrote:
I would be happy to continue this discussion an another list; which one is
most appropriate?
> What is our concern vis-a-vis the camel
Any use of the camel in a fashion which may cause confusion with products,
services, or initiatives of the tra
On Sunday 03 January 2010 at 03:21, Leo Lapworth wrote:
> Maybe someone could get a grant to hire someone/a company with design skills
> to come up with a better logo than the onion?
It seems rather unlikely that TPF will go through the business of applying for
another trademark because you don'
On Saturday 02 January 2010 at 18:59, Eric Wilhelm wrote:
> Am I alone here in thinking that we should be using the Onion trademark
> rather than O'Reilly's trademark camel on the perl.org sites?
I agree completely. Using someone else's trademark is asking for trouble.
(If promissory estoppel
On Tuesday 22 December 2009 at 14:23, Michael G wrote:
> Putting in error checking at some key locations is fine, but the prospect of
> adding `or die "Can't print $foo: $!"` to every print and close makes me
> want to claw my eyeballs out. Its unfortunate MakeMaker can't rely on
> autodie and
On Tuesday 14 July 2009 02:43:44 Ovid wrote:
> Thus, I'm trying to think of a way of solving my problem now, not at some
> hypothetical date in the future.
Next option: write your own test harness which dies when it encounters a bonus
test. This should take you less than an afternoon.
If that
On Monday 13 July 2009 06:56:15 Ovid wrote:
> We currently have over 30,000 tests in our system. It's getting harder to
> manage them. In particular, it's getting harder to find out which TODO
> tests are unexpectedly passing. It would be handy have to some option to
> force TODO tests to die o
On Thursday 26 March 2009 11:27:13 Michael G Schwern wrote:
> If I was to come up with a good argument as to why not to run the tests in
> production that would be it. The possibility of screwing up the production
> data is too great.
That's the only reason I wouldn't do it, either -- and in tha
On Thursday 19 February 2009 04:05:37 Ovid wrote:
> Properly, if we want to report SKIPs for each test (presumably with
> numbers), then we want to report failing TODOs with each test for
> consistency's sake.
I don't like that. You can already get this behavior with the --directives
flag from
On Wednesday 18 February 2009 10:14:14 Pedro Figueiredo wrote:
> 5.8.8 is the default system Perl in both Darwin and Linux, 5.10.0 was
> installed manually by me. Can anyone please shed some light on this?
Check the version of Test::Harness installed; that's what interprets and
reports the TAP e
On Thursday 12 February 2009 16:19:55 Michael G Schwern wrote:
> chromatic wrote:
> > Why? It would be practically useless unless they proved all cases of
> > input (user and hardware), in which case it would only be practically
> > useless for every case which lacks compl
On Thursday 12 February 2009 14:09:41 Michael G Schwern wrote:
> I hope somebody writes a provable kernel.
Why? It would be practically useless unless they proved all cases of input
(user and hardware), in which case it would only be practically useless for
every case which lacks complete proo
On Wednesday 11 February 2009 13:25:09 Steffen Schwigon wrote:
> "TAP::DOM" is a nice idea. Thank you, too. But although DOM isn't
> strictly associated to XML, most people would probably have this
> connotation in mind...
Even so, the connotation of an Object Model for a Document certainly descr
On Friday 23 January 2009 23:25:05 Michael G Schwern wrote:
> chromatic wrote:
> > That assumes that the TAP parser has some degree of control over the TAP
> > emitter, which is an assumption I would like people to stop making
> > universally.
> > I don't cut of
On Friday 23 January 2009 20:48:57 Michael G Schwern wrote:
> But these days a TAP parser can catch most premature exits by just looking
> at the exit code of the test, so the plan is less useful than it once was.
That assumes that the TAP parser has some degree of control over the TAP
emitter,
On Friday 23 January 2009 10:23:47 Eric Wilhelm wrote:
> Given any cross-platform skip issue or
> optional-dependency condition, you have a situation where the plan
> becomes harder for a human to get right. In that case, I want to
> program the test to react to the environment rather than shippi
On Wednesday 21 January 2009 13:47:24 Ovid wrote:
> If a programmer listed '3' as their skip reason, that would be interpreted
> as the number of tests to skip. Admittedly, it would be stupid for
> programmers to do that (and unlikely that they would), but we shouldn't be
> telling them "here's an
On Wednesday 12 November 2008 22:36:31 demerphq wrote:
> > I really, really, really don't want PAUSE modifying my stuff after it's
> > uploaded. Oh god the mysterious bugs. And then there's the fact that
> > the code I've put my name and signature on is not the same code as is
> > being distribu
On Tuesday 28 October 2008 14:12:08 Rick Fisk wrote:
> CPANTS looks more like a pet peeve list wrapped
> up in a pseudo game where "playing" results in a lose-lose for the
> developer.
That's a very different problem though, one which has produced a situation
where a buggy release of a module in
On Tuesday 28 October 2008 10:54:33 Salve J Nilsen wrote:
> - Salve, worried that the next step is to paint pink ponies and rainbows
> all over CPAN.
Hey look, a slippery slope argument combined with the false dilemma fallacy!
Salve, there really are more possibilities in the world bes
On Monday 27 October 2008 10:45:46 Salve J Nilsen wrote:
> > Remember, this is not a project designed only to say "This code sucks."
> > Its intent is to encourage people to improve their code. My code doesn't
> > magically get better when someone finds a bug. It magically gets better
> > when
On Monday 27 October 2008 05:40:03 Salve J Nilsen wrote:
> I think _some_ kind of shaming should be allowed. Carrots are good, but
> sticks work too when applied in a respectable fashion.
> But taking down the hall of shame smells awefully like the chinese press
> rules ("We are only allowed to p
On Thursday 23 October 2008 11:25:05 Yitzchak Scott-Thoennes wrote:
> On Thu, October 23, 2008 10:37 am, chromatic wrote:
> > I don't care about backchannel communication between other authors and
> > CPAN Testers, but how can you blame Shlomi for thinking that public
>
On Thursday 23 October 2008 06:34:41 Ovid wrote:
> That being said, why are you trying to publicly humiliate people by sending
> this information to Perl-QA? I've contacted Perl-QA to try and find a smoke
> author before, but not to "name and shame". That just seems rude.
I don't care about back
On Monday 22 September 2008 15:23:44 Eric Wilhelm wrote:
> Yes. Would someone please explain to me how this issue is not already
> made a mostly non-issue by having a proper umask and running CPAN as
> non-root?
If I were so inclined and had access to your machine, I could do a lot of
damage th
On Monday 22 September 2008 08:41:31 Michael G Schwern wrote:
> Shlomi Fish wrote:
> > Let's suppose Makefile.PL is world-writable. While the distro is being
> > unpacked, a malicious user writes something like:
> >
> > {{{
> > system('rm -fr $HOME');
> > }}}
> >
> > to it, and after you come to
On Tuesday 16 September 2008 05:13:38 Nicholas Clark wrote:
> So everyone gainfully employed because they know what they are doing is
> automatically disqualified?
Ah yes, the Wikipedia Fallacy of Collective Alethiology.
-- c
On Tuesday 09 September 2008 15:10:13 Michael G Schwern wrote:
> The goal of the test seems to be to detect that a customized caller()
> routine is not blown away by Sub::Uplevel. A much safer way to do that is
> to have your customized caller() just flick a file-scoped variable when it
> gets ca
On Friday 05 September 2008 16:52:05 brian d foy wrote:
> In article <[EMAIL PROTECTED]>, chromatic
> > If I could see somehow that my distribution implicitly runs on
> > Perl 5.001 (or explicitly runs only on 5.11.0), or that it has no
> > Makefile.PL or Build.PL, or
On Friday 05 September 2008 12:08:10 David Golden wrote:
> There is sufficient outrage now over email volumes that waiting for
> the preference system seems pointless and hopefully, in exchange for
> quick action now, those that are most annoyed will be willing to be
> patient during the transitio
On Friday 05 September 2008 11:23:07 David E. Wheeler wrote:
> And if you have to opt-in, I imagine that would solve the biggest
> complaint, yes? It's the unsolicited email reports that are annoying,
> right?
They are annoying, but I'm not sure it's my biggest complaint. There's also
the arbit
On Friday 05 September 2008 10:46:59 brian d foy wrote:
> You keep saying spam, but that's not the right term. You're being an
> ass characterizing it like that.
It's unsolicited, opt-out, bulk mail generated by an army of robots trying to
get me to care about things I don't necessarily care abo
On Friday 05 September 2008 10:31:29 Aristotle Pagaltzis wrote:
> I would be interested to know that you don’t care about supporting
> my configuration, but as you don’t even care enough to declare
> your non-support explicitly, I have to find out otherwise.
I don't like the check testers/grumble
On Friday 05 September 2008 06:07:53 Aristotle Pagaltzis wrote:
> * chromatic <[EMAIL PROTECTED]> [2008-09-04 23:15]:
> > UNIVERSAL::isa and UNIVERSAL::can are examples of applying the
> > design principle of Report Bugs Where They Are, Not Where They
> > Appear.
>
On Friday 05 September 2008 08:48:36 David E. Wheeler wrote:
> On Sep 4, 2008, at 10:09, chromatic wrote:
> Well, you can ignore the FAILs. Or you can evaluate each one to
> determine if you could change something your code to make it easier
> for your users. No one compels you to
On Thursday 04 September 2008 15:21:19 David Cantrell wrote:
> What I'm not willing to do, however, is to manually check every report
> and ensure perfection that way. Why? Because it takes too long, and I
> have a job and a life. And anyway, I'd still make mistakes - and even if
> I don't make
On Thursday 04 September 2008 10:50:37 David Cantrell wrote:
> Maybe I should start being equally loud and obnoxious about obviously
> stupid and broken things like the existence of UNIVERSAL-isa. It might
> give you some appreciation for how you're coming across here.
UNIVERSAL::isa and UNIVERS
On Thursday 04 September 2008 11:30:51 David Golden wrote:
> It shouldn't be any big deal to report a failure -- once -- to an
> author. That's just the normal bug-report cycle as an author might
> get from any human user. Author can look into it (if they care to),
> decide if it's a legitimate
On Thursday 04 September 2008 08:30:19 Greg Sabino Mullane wrote:
> Sorry, but paying attention is the author's job. A fail is something that
> should be fixed, period, regardless of the number of them.
My job is editor, not programmer. Also novelist -- but again, not programmer.
Certainly not
On Thursday 04 September 2008 01:19:44 Eric Wilhelm wrote:
> Let's pretend that I'm a real jerk of an author and I only care about
> whether my code installs on a perl 5.8.8+ (a *real* perl -- no funky
> vendor patches) with a fully updated and properly configured toolchain
> and the clock set to
On Wednesday 03 September 2008 10:38:16 Eric Wilhelm wrote:
> If I see two reports about canned beets, I'm likely to just give up.
>
> So, we all agree that testing is good, but please... test the *code*?
>
> "The old version of the installer is broken"? So what?
The question is whether CPAN Tes
On Tuesday 02 September 2008 14:09:04 David Golden wrote:
> Remember -- this whole thread started with "why exit 0?" Is that
> really too much to ask an author with particularly unusual
> requirements to learn and use?
Changing the way some 6000 registered authors work to meet the needs of one
On Tuesday 02 September 2008 12:45:19 David Cantrell wrote:
> And no matter how much certain people might bitch and whine about how
> users ought to upgrade their toolchain, the fact is that they don't. I
> wish they did, but they don't.
If the CPAN Testers client already requires developers to
On Tuesday 02 September 2008 10:48:38 David Golden wrote:
> Instead of the annoyance of authors writing "warn $foo and exit 0",
> now they'll need to use configure_requires in META.yml to demand an
> up-to-date version of Module::Build. And it still won't work on an
> older Perl with an older CPA
On Tuesday 02 September 2008 11:01:44 David Golden wrote:
> > You encourage what you measure,
>
> In theory, yes. In practice, that hasn't been the experience to date.
> Testers over 70K:
>
> 1 587018 Chris Williams (BINGOS)
> 2 318527 Andreas J. König (ANDK)
> 3 188392 David Gold
On Tuesday 02 September 2008 07:11:12 David Cantrell wrote:
> On Mon, Sep 01, 2008 at 05:26:11PM -0700, chromatic wrote:
> > (Step three is probably to stop rewarding people for sending ever-more
> > reports and start rewarding people for sending *useful* reports.)
>
> Th
On Monday 01 September 2008 17:22:48 Aristotle Pagaltzis wrote:
> * David E. Wheeler <[EMAIL PROTECTED]> [2008-09-01 23:20]:
> > surely there's a better way, no?
> Ask the maintainers of M::B, EU::MM and M::I to all export a
> `halt` function that does just this? That would also provide
> a conve
On Monday 01 September 2008 05:17:56 David Golden wrote:
> You need:
>
> if (!$dot_version) {
> warn "You must install the graphviz package..." and exit 0;
> }
Is the CPANAuthorNotes page comprehensive about all of the special magic a
CPAN author has to know to mollify cranky testers? T
On Saturday 30 August 2008 05:01:11 David Golden wrote:
> You can write "die" on missing prerequisites if you want, as long as
> you realize that CPAN Testers can't tell that from an error condition
> that you (or others) might actually care about.
Why die on missing prereqs? I use a META.yml be
On Thursday 21 August 2008 14:29:54 Ovid wrote:
> Remember, all of this is OPTIONAL. If you don't want it, don't use it.
I'm not sure that line of thinking works well for standards, OOXML
notwithstanding. Acme::Calendar::Mayan might want to define a vigesimal type
to encode time intervals; wh
On Thursday 21 August 2008 13:07:22 Eric Wilhelm wrote:
> Well, exactly how are we defining "sack", "potato", and "wad" here, and
> how does it have anything to do with what people want?
Specifying a serialization format in TAP diagnostics says "Here's a
serialization format you can use to store
On Thursday 21 August 2008 11:04:11 Eric Wilhelm wrote:
> But this raises the question of: what does it mean for a consumer
> to "understand" the diagnostic? How far down into the content
> (keys/values) of the diagnostic does the TAP spec want to go? What is
> the consumer going to *do* with t
On Mon, Aug 18, 2008 at 03:36:15PM +0200, Aristotle Pagaltzis wrote:
> * Michael Peters <[EMAIL PROTECTED]> [2008-08-18 15:30]:
> > YAML does support things that JSON does not (types, embedded
> > documents, etc) but I've been in doubt that we'd ever need
> > those things for TAP anyway.
> That
On Wednesday 06 August 2008 20:12:43 Michael G Schwern wrote:
> So I encourage folks to use "have" and "want" in the future. I'll be using
> them in Test::Builder2.
Parrot port updated in r30154 as well.
-- c
On Saturday 26 July 2008 20:18:13 David E. Wheeler wrote:
> That has been my reaction. I do assume, though, that aside from
> Jonathan Rockaway's comments that seem to justify the suspicion that
> it's just MySQLite, that the major difference will be that Drizzle
> (terrible name, BTW) will be a c
On Friday 25 July 2008 19:52:55 Andy Lester wrote:
> On Jul 25, 2008, at 9:48 PM, chromatic wrote:
> > Lovely. Let me know if I can help. (I had lunch with Brian Aker
> > today; he wanted some independent review from someone from a very
> > different but similar world.)
&
On Friday 25 July 2008 19:36:48 Andy Lester wrote:
> Drizzle is the new fork of MySQL that removes many many features to
> save weight, but is still able to handle concurrent users unlike SQLite.
It's more than that.
> The current MySQL testing system is done like PHP: Programs create big
> ugly
On Thursday 03 July 2008 16:38:55 Rick Fisk wrote:
> People use CPAN to solve a particular problem. They don't go looking to
> download packages merely because they exist or are popular so I don't
> see a parallel between CPAN and Cnet.
>
> The idea of displaying download rates in my view is not
On Monday 30 June 2008 15:03:14 David Cantrell wrote:
> On Mon, Jun 30, 2008 at 11:42:23PM +0200, Aristotle Pagaltzis wrote:
> > (The problem is that one of the aspects of kwalitee was supposed
> > to be that the module is properly documented ??? regardless of how
> > good the documentation is, i
On Monday 30 June 2008 12:50:09 Eric Wilhelm wrote:
> The kwalitee metrics should be useful data points when selecting between
> multiple modules, which means that the searcher (me) makes the
> decisions about which ones are important.
I don't think that's possible.
Where CPANTS works now is ide
On Monday 30 June 2008 04:01:01 Salve J Nilsen wrote:
> If people are actually annoyed about getting in the "hall of shame", we
> shouldn't remove the hall, but instead give them useful info on how to get
> out of it. If authors add useless "workarounds" just to get on the top of
> the CPANTS game
On Sunday 29 June 2008 23:08:50 Jonathan Rockway wrote:
> * On Sun, Jun 29 2008, chromatic wrote:
> > However, does making CPAN a better place require publishing a Hall of
> > Shame on perl.org?
> >
> > http://cpants.perl.org/highscores/hall_of_shame
>
>
On Sunday 29 June 2008 11:02:17 Gabor Szabo wrote:
> On Sun, Jun 29, 2008 at 4:49 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > I thought the goal of Kwalitee was to identify good free software, not to
> > humiliate thousands of other authors of free software for not
> &g
On Sunday 29 June 2008 02:28:54 Thomas Klausner wrote:
> For example:
> http://cpants.perl.org/kwalitee.html#no_cpants_errors
> no_cpants_errors
> Shortcoming: Some errors occured during CPANTS testing. They might
> be caused by bugs in CPANTS or some strange features of this
> d
On Saturday 28 June 2008 08:54:34 Gabor Szabo wrote:
> It seems that the game theme is after all turned into "fierce competition"
> or "lack of interest" depending on ... I don't know on what, but neither is
> good for CPAN.
> In some cases - me included - people fix the symptom to get the metric
On Wednesday 25 June 2008 03:15:59 Thomas Klausner wrote:
> One comment regarding 'each devel sets his/her own kwalitee metrics':
> This could be quite easy for the various views etc. But I'm not sure how
> to calculate a game score then. Do we end up with lots of different
> games? But then, it's
On Tuesday 24 June 2008 02:08:00 Paul Fenwick wrote:
> As the user of a module, it's possible for me to pass in tainted data. The
> module doesn't know from where it's been sourced. However, unless the
> *intent* of the module is to untaint this data, anything derived from that
> data should pro
On Tuesday 24 June 2008 00:50:27 Paul Fenwick wrote:
I forgot to respond to another portion of this post; I apologize for double
responses.
> > I'm very much not happy to get bug reports and test failures and big red
> > bars against my distributions because an automated heuristic which
> > appl
On Tuesday 24 June 2008 00:50:27 Paul Fenwick wrote:
> > I also hate to get bug reports saying "You should add this line of code
> > even if it does nothing useful to all of your modules, because it's not
> > there!"
> Unfortunately while the code may do nothing useful to *your* modules per
> se,
On Monday 23 June 2008 22:57:26 Paul Fenwick wrote:
> As such, I'd like to propose a new (optional) kwalitee metric. Like using
> strict and warnings, modules should "use re 'taint'" at the top of the code
> as well. Even modules that exist to untaint data *should* be doing this,
> as it means t
On Monday 09 June 2008 21:28:40 Gabor Szabo wrote:
> The issue I am trying to solve is how to catch and report
> when a test suit gives any warnings?
Is it even possible? I thought one of the goals of CPANTS was not to run any
of the distribution's code directly. The most useful metrics seem t
On Saturday 17 May 2008 20:48:24 Aristotle Pagaltzis wrote:
> You’re not following.
>
> 1. There is non-broken code which isn’t being tested directly.
>
> 2. There is a test that ensures its correctness, but only
>indirectly, as part of testing something else.
>
> 3. That something else is cur
PHP's Symfony has a test framework called lime, based on Test::More:
http://www.symfony-project.org/book/1_0/15-Unit-and-Functional-Testing
I just heard about a C++ test framework based on lime called lemon:
http://eric.scrivnercreative.com/?p=8
-- c
On Monday 12 May 2008 11:41:58 Bram wrote:
> What I'm suggesting is that it outputs something similar for TODO test
> that return an unexpected result.
TODO means "if it's anything but this, tell me". You're trying to extract two
bits of information from one bit of data. Zombie Claude Shanno
On Friday 18 April 2008 20:18:40 Chris Dolan wrote:
> How can the above example occur? How do two different user tags get
> applied to a single test result? In the Test::Exceptions vs.
> Test::Deep examples mentioned earlier (IIRC) I can see how a single
> TAP *stream* can have conflicting tags,
On Friday 18 April 2008 10:34:02 David E. Wheeler wrote:
> You've convinced me: there should be nothing to distinguish official
> from unofficial keys at all, until or unless it actually becomes an
> issue.
>
> Funny how this tends to be the opposite of the conclusion that Ovid
> draws from your a
On Thursday 17 April 2008 20:21:52 Michael G Schwern wrote:
> chromatic wrote:
> > If TAP v15 adds a
> > new reserved key, anyone who deliberately upgrades may need to modify
> > both the producer and consumer to deal with the collision, if that person
> > even c
On Thursday 17 April 2008 19:10:21 Michael G Schwern wrote:
> As for why it'll work with TAP, with a few exceptions (exit_status, or
> whatever we decide to call it, is currently the only one), diagnostic keys
> do not effect test parsing. It's not a show stopper. At worst, a
> displayer that ha
On Thursday 17 April 2008 17:56:25 Michael G Schwern wrote:
> We're working around the same issue Perl 5 is having adding new keywords.
> In Perl 5, since keywords and user-defined subroutines share the same
> space, we can't add a new keyword without risking clashing with a
> user-defined subrou
On Thursday 17 April 2008 16:17:48 Michael G Schwern wrote:
> chromatic wrote:
> >> We'd like folks to be able to add their own keys as they need without
> >> first wondering whether it might be useful for others or worrying if we
> >> might add a
On Thursday 17 April 2008 15:16:53 Michael G Schwern wrote:
> chromatic wrote:
> > That's my suggestion. Figure out the minimal set of keys that we expect
> > to use in the near future and reserve those. Document them. Suggest
> > that we might add more keys
On Wednesday 16 April 2008 22:57:21 David E. Wheeler wrote:
> In principal I completely agree with you, chromatic (that is, I agree
> with the principal you espouse here; my agreement is not purely
> theoretical ;-)). But how does that work in practice? Specifically
> with re
On Sunday 13 April 2008 14:58:33 Michael G Schwern wrote:
> chromatic wrote:
> > On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
> >> Remember, the producer and the displayer of the non-reserved keys are
> >> both under local user control. They choo
On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
> Remember, the producer and the displayer of the non-reserved keys are both
> under local user control. They choose the custom keys and they choose what
> they need and can handle.
That sort of eliminates the upgrading problem, doesn't i
On Thursday 10 April 2008 04:14:15 Gabor Szabo wrote:
> The issue was raised on the Oslo Hackathon that it would be cool
> if we could keep the tests around so that they can be executed
> later again making sure that even after one has upgraded other
> parts of his system the previously installed
On Wednesday 09 April 2008 02:08:18 Ovid wrote:
> --- chromatic <[EMAIL PROTECTED]> wrote:
> > All* of the TAP I've ever seen has been transient data generated by
> > one tool, processed by another tool, and almost immediately discarded.
> All of the Java I
1 - 100 of 518 matches
Mail list logo
