* Andy Armstrong <[EMAIL PROTECTED]> [2008-08-22 00:35]:
> Indeed - but there's a sweet spot somewhere between specifying
> too little and specifying too much. It's entirely proper that
> there should be a debate about where that sweet spot is - and
> parsimony should be a guiding principle - but t
* Ricardo SIGNES <[EMAIL PROTECTED]> [2008-08-21 19:00]:
> Ovid (and I) would like it to be JSON, pending any better idea
> (that we agree is better).
FWIW, after some consideration, I find myself drifting toward
the JSON camp as well. It’s a slow drift, but I just can’t help
disliking YAML for ma
* Eric Wilhelm <[EMAIL PROTECTED]> [2008-08-21 18:50]:
> Does it have to be just one? Now and forever?
It doesn’t have to be *just* one, but it needs to be *at least*
one, and specifically at least one that *everyone* supports, so
that you can count on having a way to make an emitter and
consumer
On 21 Aug 2008, at 23:37, Michael G Schwern wrote:
What IETF list?
https://www.ietf.org/mailman/listinfo/tap
--
Andy Armstrong, Hexten
Ovid wrote:
> Folks, this really, really needs to go to the IETF list.
What IETF list?
--
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
On 21 Aug 2008, at 22:41, chromatic wrote:
I've written a handful of TAP producers and consumers myself, as
well as
software which other people have used in ways I never intended. The
more
complexity you add to a system to reduce the complexity people have
to manage
to use your system as yo
On Aug 21, 2008, at 14:48, Andy Armstrong wrote:
There was meant to be a smiley in my response. I was just relieved
it wasn't some debug /I'd/ left lying around - so thanks :)
:-D
Best,
David
--- On Thu, 21/8/08, chromatic <[EMAIL PROTECTED]> wrote:
> I've written a handful of TAP producers and consumers
> myself, as well as
> software which other people have used in ways I never
> intended. The more
> complexity you add to a system to reduce the complexity
> people have to manage
On 21 Aug 2008, at 22:05, David E. Wheeler wrote:
print join ' ', @command, $/;
Oh Jesus, that was stupid. Must've been debugging and completely
forgot about it. Sorry for the noise, and thanks for the prompt reply.
There was meant to be a smiley in my response. I was just relieved it
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 Thu, 21/8/08, chromatic <[EMAIL PROTECTED]> wrote:
> That part is the wad.
No, for the most part, it's a simple list of key/value pairs.
> (You might find it amusing to note that the SOAP folks
> didn't use the
> sack/potato/wad metaphor when naming their failure.)
SOAP has the problem
On Aug 21, 2008, at 13:58, chromatic wrote:
I wonder why anyone wants a test so complex that its diagnostic
requires you
to serialize and deserialize objects and/or nested data structures
to and
from custom TAP producers and consumers, and, if you really need to
do that,
if you should start
On Aug 21, 2008, at 12:09, Andy Armstrong wrote:
That's your code, no?
From https://svn.kineticode.com/pgtap/tags/rel-0.02/pg_prove
push @command, qw(
--no-psqlrc
--no-align
--tuples-only
--pset pager=
--pset null=[NULL]
--set ON_ERROR_ROLLBACK=1
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 Thu, 21/8/08, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> Well, exactly how are we defining "sack",
> "potato", and "wad" here, and
> how does it have anything to do with what people want?
To be fair, those were chromatic's words, not mine, so I'm not sure exactly
what he meant by them and
# from Ovid
# on Thursday 21 August 2008 11:53:
>> If TAP goes any further than saying "Yes, you *can*
>> stuff a big wad of custom data in this ganky old potato sack
>> ... there may be a hole in the bottom ...
>> so if there's any other way, we encourage you to do that" ...
What would this "any
On 21 Aug 2008, at 19:54, David E. Wheeler wrote:
Is there some way to eliminate that noisy line that shows the
command that will be run?
That's your code, no?
From https://svn.kineticode.com/pgtap/tags/rel-0.02/pg_prove
push @command, qw(
--no-psqlrc
--no-align
-
Howdy,
When I run the pgTAP tests through pg_prove, which uses TAP::Harness,
it looks like this:
% pg_prove -d try sql/*.sql
psql --dbname try --no-psqlrc --no-align --tuples-only --pset
pager= --pset null=[NULL] --set ON_ERROR_ROLLBACK=1 --set
ON_ERROR_STOP=1 --set QUIET=1 --file
--- On Thu, 21/8/08, chromatic <[EMAIL PROTECTED]> wrote:
> If TAP goes any further than saying "Yes, you *can*
> stuff a big wad of custom
> data in this ganky old potato sack, but it's ugly and
> covered in spiders and
> there may be a hole in the bottom, so if there's any
> other way, we enco
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 Aug 21, 2008, at 09:57, Ricardo SIGNES wrote:
Schwern would like it to be YAML (a superset of JSON), with the
phrasing
"consumers MUST understand JSON and SHOULD understand YAML."
+1
David
On 21 Aug 2008, at 19:02, David E. Wheeler wrote:
On Aug 21, 2008, at 06:55, Thomas Klausner wrote:
unexpected consequences. It also highlights the issue of
Test::Harness's long-standing practice of stripping the .t extension
from filenames. Why? If we want other extensions, stripping them is
# from Ricardo SIGNES
# on Thursday 21 August 2008 09:57:
>> Does it have to be just one? Now and forever?
>
>Some people want the spec to say that diagnostics (not free-form
> additional data blocks) are always readable by any TAP consumer,
> which means they need a declared format. It needs to
On Aug 21, 2008, at 06:55, Thomas Klausner wrote:
unexpected consequences. It also highlights the issue of
Test::Harness's long-standing practice of stripping the .t extension
from filenames. Why? If we want other extensions, stripping them is
probably bad.
FYI, when I run both .t Perl and .s
On Aug 21, 2008, at 08:06, Paul Johnson wrote:
On Thu, Aug 21, 2008 at 10:09:32AM -0400, Christopher H. Laco wrote:
I've got one at home now that also has .rb files...
Why .phpt instead of .php?
Why not .t for every language?
Because that's how the harness knows what program to execute: P
On 21 Aug 2008, at 17:57, Ricardo SIGNES wrote:
Ovid (and I) would like it to be JSON, pending any better idea (that
we agree
is better).
I'm in the JSON camp too.
--
Andy Armstrong, Hexten
Folks, this really, really needs to go to the IETF list. I mentioned in here
because the list wasn't set up yet, but IETF list is the official spot for this
and we can avoid spamming people here with this. That being said, on with the
show! ...
--- On Thu, 21/8/08, Eric Wilhelm <[EMAIL PROTEC
* Eric Wilhelm <[EMAIL PROTECTED]> [2008-08-21T12:46:59]
> # from Ovid
> >1. YAML is prettier.
> >2. JSON, unlike YAML, is stable.
> >
> >Let's not forget that the debated requirement for diagnostics is that
> > the generators and consumers speak the same language
>
> Does it have to be just one
# from Ovid
# on Thursday 21 August 2008 09:28:
>> (2) YAML is better suited for complex serialization than JSON.
>1. YAML is prettier.
>2. JSON, unlike YAML, is stable.
>
>Let's not forget that the debated requirement for diagnostics is that
> the generators and consumers speak the same langua
* Ovid <[EMAIL PROTECTED]> [2008-08-21T12:28:52]
> Let's not forget that the debated requirement for diagnostics is that the
> generators and consumers speak the same language, not that the *consumer*
> emit anything in particular. If you prefer the appearance of YAML to JSON,
> have the consumer
--- On Thu, 21/8/08, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> * chromatic <[EMAIL PROTECTED]> [2008-08-20T13:59:14]
> > Aren't these two separate concerns, human versus
> machine readability? The
> > latter rarely respects ambiguity.
>
> Yes.
>
> Right now, there seem to be two pro-YAML argu
* Ovid <[EMAIL PROTECTED]> [2008-08-21T05:36:11]
> Both of us found this much cleaner. However, this might have unexpected
> consequences. It also highlights the issue of Test::Harness's long-standing
> practice of stripping the .t extension from filenames. Why? If we want other
> extensions, strip
* chromatic <[EMAIL PROTECTED]> [2008-08-20T13:59:14]
> Aren't these two separate concerns, human versus machine readability? The
> latter rarely respects ambiguity.
Yes.
Right now, there seem to be two pro-YAML arguments.
(1) It's easier to for humans read.
Sure. I will admit that. It is e
On Thu, Aug 21, 2008 at 10:09:32AM -0400, Christopher H. Laco wrote:
> I've got one at home now that also has .rb files...
>
> Why .phpt instead of .php?
Why not .t for every language?
I have a suspicion that I will like the dot change but not the .t
change.
--
Paul Johnson - [EMAIL PROTECTED
Andy Lester wrote:
>
> On Aug 21, 2008, at 4:36 AM, Ovid wrote:
>
>> Why? If we want other extensions, stripping them is probably bad.
>
>
> We definitely want other extensions. I have a pending project that
> relies on running .t and .phpt next to each other.
>
> xoa
I've got one at home n
On Aug 21, 2008, at 4:36 AM, Ovid wrote:
Why? If we want other extensions, stripping them is probably bad.
We definitely want other extensions. I have a pending project that
relies on running .t and .phpt next to each other.
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com
On 21 Aug 2008, at 14:55, Thomas Klausner wrote:
unexpected consequences. It also highlights the issue of
Test::Harness's long-standing practice of stripping the .t extension
from filenames. Why? If we want other extensions, stripping them is
probably bad.
Actually, I'd love to have the extensi
Hi!
On Thu, Aug 21, 2008 at 02:36:11AM -0700, Ovid wrote:
> unexpected consequences. It also highlights the issue of
> Test::Harness's long-standing practice of stripping the .t extension
> from filenames. Why? If we want other extensions, stripping them is
> probably bad.
Actually, I'd love
On 21 Aug 2008, at 10:36, Ovid wrote:
You'll see this:
t/proverun ok
t/regression .. ok
t/results . ok
t/scheduler ... ok
t/source .. ok
t/spool ... ok
t/state ..
I've just committed a minor change that both Andy and I have wanted for a long
time, but I do wonder if it will impact others. Instead of seeing this:
t/proverun..ok
t/regressionok
t/results...ok
t/scheduler..
# from Elliot Shank
# on Wednesday 20 August 2008 22:14:
>>> This all built up over years as I tried to automate away each
>>> stupid distribution packaging mistake I've made in releasing
>>> something to CPAN.
>>
>> This should be a module. I'd use it.
>
>What about foy's Module::Release?
"This
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 Wed, Aug 20, 2008 at 12:57 PM, David Golden <[EMAIL PROTECTED]> wrote:
>> Anyway. I am in the "Keep MANIFEST in repo and manually update" camp.
>
> Me, too, usually.
Me three.
--
Shawn Boyette
<[EMAIL PROTECTED]>
43 matches
Mail list logo
