Ovid wrote:
--- David Wheeler <[EMAIL PROTECTED]> wrote:
Test.Simple—JavaScript. It looks and acts just like tap, although in
reality it's tracking test results in an object rather than scraping
them from a print buffer.
http://openjsan.org/doc/t/th/theory/Test/Simple/
Tracking the resul
--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> If that were universally true, we wouldnât have plaintext network
> protocols, would we? And I think making TAP a protocol instead of
> an API was the right choice.
As already noted, I freely admit I was wrong. If TAP was a "Perl only"
thing, I mi
chromatic wrote:
On Monday 17 April 2006 18:50, Ovid wrote:
The only problem I see with that is the occasional buffering errors I
see on my Mac where the STDERR and STDOUT don't line up.
Agreed. Is it too late to send everything to STDOUT where it belongs?
Unfortunately, it probably is too
On Tuesday 18 April 2006 00:20, Ovid wrote:
> As a language-independent tool, an API is silly and
> I'm a fool for shooting my keyboard off for thinking only about the
> implementation problems as opposed to its benefits.
I'm sure you're not the only person who has thought "Hey, screen scraping t
* Adam Kennedy <[EMAIL PROTECTED]> [2006-04-18 09:30]:
> especially out there in the darkpan.
What about the deadpan?
SCNR,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
On Sun, Apr 16, 2006 at 06:24:58PM -0700, Audrey Tang via RT wrote:
> Nicholas Clark wrote:
> > IIRC having ASCII as the default was a deliberate design choice to avoid
> > the confusion of "is it iso-8859-1 or is it utf-8" when encountering a
> > string literal with bytes outside the range 0-127.
chromatic wrote:
> On Monday 17 April 2006 18:50, Ovid wrote:
>
>
>>The only problem I see with that is the occasional buffering errors I
>>see on my Mac where the STDERR and STDOUT don't line up.
>
>
> Agreed. Is it too late to send everything to STDOUT where it belongs?
just for everyone'
Adam Kennedy wrote:
> chromatic wrote:
>> On Monday 17 April 2006 18:50, Ovid wrote:
>>
>>> The only problem I see with that is the occasional buffering errors I
>>> see on my Mac where the STDERR and STDOUT don't line up.
>>
>> Agreed. Is it too late to send everything to STDOUT where it belong
Adam Kennedy wrote:
>
>>> Schwern made one small change in the STDERR format, and the recursive
>>> cascade of failing test-testing modules hit something like 3000 CPAN
>>> distributions.
>>
>>
>> While I agree that this caused problems, those modules were relying on a
>> format that was not spe
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not spec'ed out or documented.
That is irrelevant
Here's another potential NS issue. It looks like find_global is being
affected by the .namespace directive: it's my understanding it should
only be affected by the .HLL directive. If you comment out the
second .namespace in this code, it prints "ok".
.$ cat foo.pir
.HLL 'bork', ''
.namespac
Geoffrey Young writes:
> Adam Kennedy wrote:
>
> > That is irrelevant. You put something into CPAN, get massive numbers
> > of people using it, and leave it alone and have it remain stable for
> > 4 years, it becomes an API whether you wanted it to be or not :)
>
> really?
I'm with Adam on this
Geoffrey Young wrote:
Adam Kennedy wrote:
Schwern made one small change in the STDERR format, and the recursive
cascade of failing test-testing modules hit something like 3000 CPAN
distributions.
While I agree that this caused problems, those modules were relying on a
format that was not spec
Will Coleda wrote:
Here's another potential NS issue. It looks like find_global is being
affected by the .namespace directive:
Yes. It sets the current namespace below the HLL namespace.
I think, this is the specced and correct behavior.
leo
From the PDD:
-
=item $P0 = find_global $P1, $S0
=item $P0 = find_global $S0
Find $P0 as the variable $S0 in the current namespace. or in $P1,
relative
to the HLL root namespace.
-
I'm using the first version, but it's relative to the namespace set
in .namespace, not relative to t
On Tue, Apr 18, 2006 at 05:14:30PM +0200, Leopold Toetsch wrote:
> Will Coleda wrote:
> >Here's another potential NS issue. It looks like find_global is being
> >affected by the .namespace directive:
>
> Yes. It sets the current namespace below the HLL namespace.
> I think, this is the specced
On Tue, Apr 18, 2006 at 11:34:49AM -0400, Will Coleda wrote:
> From the PDD:
> =item $P0 = find_global $P1, $S0
> =item $P0 = find_global $S0
> Find $P0 as the variable $S0 in the current namespace. or in $P1, relative
> to the HLL root namespace.
Heh, I'm sleepy so I forgot that the C form propos
On Apr 18, 2006, at 12:19 PM, Chip Salzenberg wrote:
On Tue, Apr 18, 2006 at 11:34:49AM -0400, Will Coleda wrote:
From the PDD:
=item $P0 = find_global $P1, $S0
=item $P0 = find_global $S0
Find $P0 as the variable $S0 in the current namespace. or in $P1,
relative
to the HLL root namespace.
On Tue, Apr 18, 2006 at 12:42:38PM -0400, Will Coleda wrote:
> On Apr 18, 2006, at 12:19 PM, Chip Salzenberg wrote:
> >On Tue, Apr 18, 2006 at 11:34:49AM -0400, Will Coleda wrote:
> >>On a side note, is there a way to get at the parent namespace if you have
> >>a namespace? I don't see anything in
Last time I checked the core has "6 TESTS UNEXPECTEDLY SUCCEEDED"
What's the expected number of unexpected successes?
Can it be made to be zero, even though we're testing the test modules?
If so, I think that that would be useful, as it would mean that any (real)
TODO test that unexpectedly starte
On Tue, Apr 18, 2006 at 06:30:20PM +0100, Nicholas Clark wrote:
> Last time I checked the core has "6 TESTS UNEXPECTEDLY SUCCEEDED"
> What's the expected number of unexpected successes?
> Can it be made to be zero, even though we're testing the test modules?
>
> If so, I think that that would be u
Nicholas Clark wrote:
Last time I checked the core has "6 TESTS UNEXPECTEDLY SUCCEEDED"
What's the expected number of unexpected successes?
Can it be made to be zero, even though we're testing the test modules?
If so, I think that that would be useful, as it would mean that any (real)
TODO test
On Tue, Apr 18, 2006 at 01:21:37PM -0500, Steve Peters wrote:
> One of my unwritten TODOs is to go through the current Perlbug queue and
> write test cases for all the currently testable problems. My hope is
> that unexpected fixes would be caught much sooner in these cases. I've
> made a bit of
Author: allison
Date: Tue Apr 18 13:45:23 2006
New Revision: 12354
Added:
trunk/docs/pdds/clip/pdd22_io.pod
trunk/docs/pdds/clip/pdd23_exceptions.pod (contents, props changed)
trunk/docs/pdds/clip/pdd24_events.pod
trunk/docs/pdds/clip/pdd25_threads.pod
Removed:
trunk/docs/pdds/cli
One of my unwritten TODOs is to go through the current Perlbug
queue and
write test cases for all the currently testable problems.
Hey! That's one of my unwritten TODOs, too!
In the long term, however, it would be great if Test::Harness
recognized
individual TODO test cases that passed an
On 4/18/06, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Last time I checked the core has "6 TESTS UNEXPECTEDLY SUCCEEDED"
> What's the expected number of unexpected successes?
> Can it be made to be zero, even though we're testing the test modules?
>
> If so, I think that that would be useful, as i
On Apr 8, 2006, at 19:49, Bob Rogers wrote:
. . .
=item *
C creates an exception handler and pushes it onto the
control
stack. It takes a label (the location of the exception handler)
as its
only argument. [Is this right? Treating exception handlers as
label
jumps rathe
Author: larry
Date: Tue Apr 18 18:09:20 2006
New Revision: 8874
Modified:
doc/trunk/design/syn/S02.pod
Log:
Clarifications on the relationship of Capture objects to references.
Modified: doc/trunk/design/syn/S02.pod
BTW, the patch only shows TODO pass status when no failures occur.
Oh and obviously all of Test::Harness'es tests pass. :-)
This patch doesn't apply against my latest dev version of
Test::Harness. I'm going to have to massage it manually.
But I like the idea. Thanks.
xoa
--
Andy Lester
Please try out this dev release. I'd like to make it 2.58 tomorrow.
Thanks, demerphq for the patch.
has entered CPAN as
file: $CPAN/authors/id/P/PE/PETDANCE/Test-Harness-2.57_05.tar.gz
size: 68798 bytes
md5: 61fce5eed1556ad9d603072c07bb62ae
No action is required on your part
Request e
--- Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > While I agree that this caused problems, those modules were relying
> on a
> > format that was not spec'ed out or documented.
>
> That is irrelevant. You put something into CPAN, get massive numbers
> of
> people using it, and leave it alone and ha
On 4/19/06, Andy Lester <[EMAIL PROTECTED]> wrote:
> > BTW, the patch only shows TODO pass status when no failures occur.
> >
> > Oh and obviously all of Test::Harness'es tests pass. :-)
>
> This patch doesn't apply against my latest dev version of
> Test::Harness. I'm going to have to massage it
On 4/19/06, Ovid <[EMAIL PROTECTED]> wrote:
> to handle got/expected failure information in Java or C? There are
> pretty rich data structures we could put out there and YAML might help.
> That would also likely simplify a parser.
If you mean you want pluck YAML test results from a noisy input s
* Ovid <[EMAIL PROTECTED]> [2006-04-19 07:20]:
> What if someone wants more diagnostic information or more
> complete failure information? We might find things useful
> enough that that we feel compelled to update TAP. If so, TAP
> needs to be versioned and we need to figure out how to
> accomoda
34 matches
Mail list logo
