Michael G Schwern writes:
> David E. Wheeler wrote:
>
> > On Apr 18, 2008, at 10:50, chromatic wrote:
> >
> > > My argument was complex: solve the real problem or don't solve it.
> > > The in between position is silly and won't make anyone happy.
> >
> > Yes. The choices, as I see them, are:
> >
On Apr 19, 2008, at 08:15, Michael G Schwern wrote:
#3 is just #2 following an existing cow path. In short, we have a
good idea that official vs user is going to be a problem. Is anyone
arguing it won't? We have a simple, elegant solution to it that
doesn't cause another problem. The cost
# from Eric Wilhelm
# on Saturday 19 April 2008 09:07:
>Of course, I would want strict key checking to be off by default and
>enabled only by the 'strict' pragma. But conveniently: the pragma is
>declared by the tap stream (i.e. emitter.)
And further: strictness must be automatically disabled
# from Michael G Schwern
# on Saturday 19 April 2008 08:15:
>The prefixing solution sucks, but it's all we have... and that's a bad
> place to be. Rather than arguing about a sucky solution, does anyone
> have another solution to offer?
I'm not sure what you mean by "prefixing"[1], or what sucks
David E. Wheeler wrote:
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in
between position is silly and won't make anyone happy. (However, the
first
person to suggest RDF triples gets a lecture from *all* parties.)
Yes. T
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in
between position is silly and won't make anyone happy. (However,
the first
person to suggest RDF triples gets a lecture from *all* parties.)
Yes. The choices, as I see th
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 Apr 17, 2008, at 22:44, chromatic wrote:
I don't know how to put this any more clearly, so I'm content to let
this
thread die here and watch TAP v15 careen off into crazy town.
(Alternately,
I could be the one careening off into crazy town, but at the risk of
making
an argument from aut
--- Michael G Schwern <[EMAIL PROTECTED]> 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
> has
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 cares.
I don't understand. There can be no collision. Official TAP keys all
start with a lower case letter.
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 cares.
> I don't understand. Ther
chromatic wrote:
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
displ
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
Executive summary: User key collision is not a show stopper.
chromatic wrote:
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
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
chromatic wrote:
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 key of the same name, but different function
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 key of the same name, but different functionality
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 key of the same name, but different functionality, later. Thus the
separation of local from official keys.
This part I thin
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 later, if there's a rough consensus
chromatic wrote:
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 regard to YA
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 regard to YAML diagnosti
On Apr 13, 2008, at 15:58, chromatic wrote:
The problem with an infinitely expandable protocol that tries to do
everything
is that it's infinitely expandable and tries to do everything.
Might be nice
to rein that in a little bit more. Or don't, and instead make it
trivial to
add ad-hoc ke
--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
> Now, what, in your example, are the keys you want to
> standardize/reserve for tap specific purposes? IMHO all keys (file,
> line, results, have, want, name, display) are specific to
> Test::Differences. You probably don't want to standardize them,
Ovid <[EMAIL PROTECTED]> writes:
> --- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
>
>> Then maybe I haven't understood what the standardization of
>> diagnostics is about.
>>
>> I thought it is primarily meant for the *user* of TAP to transport
>> its own diagnostics of its own test runs and test
--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
> Then maybe I haven't understood what the standardization of
> diagnostics is about.
>
> I thought it is primarily meant for the *user* of TAP to transport
> its own diagnostics of its own test runs and test results?
>
> I for instance would use i
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Ovid wrote:
>> --- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
>>> And we are talking about the diagnostics part, which is primarily for
>>> the user, so the rules are reversed there.
>> There are two goals we want:
>> 1. Make it as human-readable as
On Sun, Apr 13, 2008 at 03:58:58PM -0700, chromatic wrote:
> and you'll end up with the protocol equivalent of spaghetti. Anyone care to
> guess how many X-* headers there are in all of the SMTP clients and servers
> in the wild? How about HTTP headers? Maybe you don't have to care about
$
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 choose the custom keys and they
> >> cho
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 choose the custom keys and they choose what
they need and can handle.
That sort of eliminates the upgrading pro
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 Apr 13, 2008, at 11:37, Michael G Schwern wrote:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can
use.
I don't have any particular reason. Just a feeling t
David E. Wheeler wrote:
On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but I'm
worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
I d
On Sun, 13 Apr 2008 18:41:04 +0100
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Two possible solutions:
>
> A) Just reserve ASCII [a-z]. This is very easy to check for but I'm
> worried it's carving out too small a space.
>
> B) Reserve "lower case" and leave the spec a little fuzzy around
On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but
I'm worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
B) Reserve "lower case" and
Ovid wrote:
--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
And we are talking about the diagnostics part, which is primarily for
the user, so the rules are reversed there.
There are two goals we want:
1. Make it as human-readable as possible.
2. Maximize flexibility.
As for human-readable
--- Steffen Schwigon <[EMAIL PROTECTED]> wrote:
> A see. But TAP isn't SMTP or HTTP and an explicit prefix matches the
> "be descriptive" of Schwern, doesn't it?
>
> And we are talking about the diagnostics part, which is primarily for
> the user, so the rules are reversed there.
There are two g
Michael Peters <[EMAIL PROTECTED]> writes:
> Steffen Schwigon wrote:
>
>> How about reserving a prefix for TAP related keys and allow/ignore
>> everything else?
>>
>> Explained in another way:
>>
>> a prefix lowercased "tap-" for TAP
>>
>
> Thumbs down from me. You don't see HTTP headers havin
Steffen Schwigon wrote:
> How about reserving a prefix for TAP related keys and allow/ignore
> everything else?
>
> Explained in another way:
>
> a prefix lowercased "tap-" for TAP
>
Thumbs down from me. You don't see HTTP headers having to prefix all of their
labels with 'HTTP-' or email he
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Here's the descriptive way to specify how the diagnostic keys work.
>
> 1) We reserve every key which begins with a lower case letter
> 2) We say nothing about anything else
> 3) All keys are optional
How about reserving a prefix for TAP related k
39 matches
Mail list logo
