Re: Non-Perl TAP implementations

[Adam Kennedy]

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 results in an object is a better choice than scraping from
a print buffer.  One of the frustrating issues with Perl's testing
tools is the limited flexibility we have due to reading the output from
STDOUT.

The TAP output should really just be for humans.  It should also be
reconfigurable, but obviously we can't do that because Test::Harness
would choke.


I disagree.

I think one of the key strengths of TAP, as opposed to most other 
testing systems out there, is that the test results are language-agnostic.


It means we can do things like using a Perl Harness to hit web pages 
built by PHP-generated TAP output.


Or mix tests for multiple languages in a single environment/system/dist.

Certainly a more robust grammar could be useful, and an EBNF grammar 
sounds wonderful.


Adam K


Since it looks like we're going to stick with reading information from
a print buffer, we should at least publish an EBNF grammar for the
output.  (Interestingly, if we did that, we could potentially
incorporate that into Test::Harness and allow folks to provide their
own grammars and thus structure the output to better suit their needs. 
Of course, I would like a Ponie with that, too).


Cheers,
Ovid

Re: Non-Perl TAP implementations

[Ovid]

--- "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 might (might) be inclined to argue the point, but even then
it's questionable.  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.

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing list, please send 
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Non-Perl TAP implementations

[Adam Kennedy]

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 late.

Schwern made one small change in the STDERR format, and the recursive 
cascade of failing test-testing modules hit something like 3000 CPAN 
distributions.


Changing TAP without extreme caution, planning and co-ordination could 
get be very very nasty, especially out there in the darkpan.


Adam K

Re: Non-Perl TAP implementations

[chromatic]

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 the 
results is tedious work."  I've certainly wished occasionally for an API 
before reading reality's greeting card full of counterarguments.

-- c

Re: Non-Perl TAP implementations

[A. Pagaltzis]

* 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;

Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type

[Patrick R. Michaud]

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.
> 
> Aye, it was auto-promoting to latin1 and was changed to ascii-by-default
> by me and Leo a while ago.

After reading some of the comments and thinking about it some
more, I think having double-quoted strings auto-promote to 
iso-8859-1 by default is probably not a good idea.

> > If PGE is always outputting UTF-8 literals, what stops it from always
> > prefixing every literal "unicode:", even if it only uses Unicode characters
> > 0 to 127?
> 
> Indeed, it would be much easier if unicode:"" on an ascii-only string
> can automatically go back to use ascii for representation, and choose to
> use utf8 (or better, latin1/ucs2) only iff there is high-bit parts in it.

Yes, this would be a good solution also.

(It doesn't resolve the original problem that prompted this
RFE, so I'll open a separate ticket for that.)

Thanks,

Pm

Re: Non-Perl TAP implementations

[Geoffrey Young]

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's knowledge, for much of Apache-Test STDERR is the apache
error_log, so we override things so errors are sent to STDOUT where they're
immediately visible as output from the http client.

so, as long as there remains an official way to redirect the two streams as
I deem fit then it doesn't matter to me.  but I thought folks might like to
be reminded that there's no guarantee that STDERR and STDOUT are the same
"screen" so mixing up where test output and/or diagnostics ends up may or
may not be a good thing, depending on your pov.

--Geoff

Re: Non-Perl TAP implementations

[Michael Peters]

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 belongs?
> 
> Unfortunately, it probably is too late.
> 
> 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.

In fact, the TAP spec explicitly says that diagnostics can/should be
mixed with test output. At least to me, that means they're on the same
output stream.

http://search.cpan.org/~petdance/Test-Harness-2.56/lib/Test/Harness/TAP.pod#Diagnostics

> Changing TAP without extreme caution, planning and co-ordination could
> get be very very nasty, especially out there in the darkpan.

I do agree that caution and coordination is necessary. It's the test
modules themselves (Test::More, etc) that print to STDOUT/STDERR, right?
 And there sure are a lot of them. If I had any TAP producing test
modules on CPAN I'd volunteer to change them :)

-- 
Michael Peters
Developer
Plus Three, LP

Re: Non-Perl TAP implementations

[Geoffrey Young]

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'ed out or documented.
> 
> 
> 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?  so I use an age old (but undocumented) feature of Config, then
Config changes and it's _not_ my fault?[1]  of course it is - perl is great
because you can go mucking around with stuff you shouldn't, but everyone
knows it's your own fault if it bites you later on.

--Geoff

[1] http://dev.perl.org/perl5/list-summaries/2005/20051003.html

Re: Non-Perl TAP implementations

[Adam Kennedy]

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. 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 :)


Adam K

namespace bug 2?

[Will Coleda]

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', ''
.namespace [ '' ]

.sub a :immediate
  $P1 = new .String
  $P1 = "ok\n"
  store_global "eek", $P1
.end

.namespace [ 'sub_namespace' ]

.sub whee :main

$P1 = find_global 'eek'
print $P1
.end
CokeZero:~/research/parrot/languages/tcl wcoleda$ ../../parrot foo.pir
Global 'eek' not found
current instr.: 'bork;sub_namespace;whee' pc 12 (foo.pir:14)

Re: Non-Perl TAP implementations

[Smylers]

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 one.

> so I use an age old (but undocumented) feature of Config, then Config
> changes and it's _not_ my fault?[1] 
> 
> [1] http://dev.perl.org/perl5/list-summaries/2005/20051003.html

But there Schwern invoked Tom Christian:

  You are wicked and wrong to have broken inside and peeked at the
  implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTED]>

Note that's specifically to do with peeking inside.

If you don't peek inside some code but merely observe its output, and
its output always behaves in a particular way, then relying on that
output is not the same as relying on implementation details.

Smylers

Re: Non-Perl TAP implementations

[Adam Kennedy]

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'ed out or documented.


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?  so I use an age old (but undocumented) feature of Config, then
Config changes and it's _not_ my fault?[1]  of course it is - perl is great
because you can go mucking around with stuff you shouldn't, but everyone
knows it's your own fault if it bites you later on.


At one level of abstraction, I think the blame is absolutely clear.

The trouble is when you introduce recursion.

The aformentioned change to Test::Builder broke 3 different Test-Testing 
modules that relied on it.


That broke 28 Test modules which used them.

That broke 115 various CPAN modules.

That broken 880 other CPAN modules.

And so on and so forth, until the end number ended up somewhere between 
2000 and 3000 distributions.


So 30% of all CPAN modules broke.

This included things like almost ALL of WWW::, because Mechanize got 
sucked into it. God knows how many darkpan Mech modules got hurt as well.


Do we blame ALL of those 100s of developers?

Does blame even matter at that point?

This is what I mean by becoming an API even though you didn't want to be.

Adam K

Re: namespace bug 2?

[Leopold Toetsch]

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

Re: namespace bug 2?

[Will Coleda]

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 the HLL root namespace (derived from  
the .HLL directive)


Tcl is currently avoiding the problem by going back to NAMESPACE_ROOT  
and drilling down to get to the parent namespace. 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 the PDD about it. (Seems you can only walk  
*down* the hierarchy, not up.)


On Apr 18, 2006, at 11:14 AM, 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 and correct behavior.

leo

Re: namespace bug 2?

[Chip Salzenberg]

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 and correct behavior.

I think it's correct, though I don't remember speccing it.  :-)

By analogy: Suppose your Unix working directory is "/tmp".  The reason that
it's a feature (rather than a bug) that open("foo") opens "/tmp/foo" is a
that you can easily defeat the default directory with a full absolute path.

I think Leo's default root and Will's overriding it for his current code are
both the right thing.  All we need is to consider which root overrides are
going to be needed and provide convenient ways to do them, rather than the
current awkward work-up-from-namespace-root thing.

How about:

   find_global ['name'; 'space'], '$var'   # from HLL root
   find_global [], '$var'  # *at* HLL root

Or a two step version -- more flexible but a bit less convenient:

   $P0 = get_namespace ['name'; 'space']   # from HLL root
   find_global $P0, '$var'

   $P1 = get_namespace []  # *at* HLL root
   find_global $P1, '$var'

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: namespace bug 2?

[Chip Salzenberg]

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 proposed
in my previous message is already spec'd.

Tada, done!  :-)

> I'm using the first version, but it's relative to the namespace set  
> in .namespace, not relative to the HLL root namespace (derived from  
> the .HLL directive)

That's definitely a bug.

> 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 the PDD about it. (Seems you can only
> walk *down* the hierarchy, not up.)

That's true.  Given aliasing there may not be just one parent, but I don't
suppose the distant chance of that will keep you from wanting this feature...?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: namespace bug 2?

[Will Coleda]

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.


Heh, I'm sleepy so I forgot that the C form  
proposed

in my previous message is already spec'd.

Tada, done!  :-)


I'm using the first version, but it's relative to the namespace set
in .namespace, not relative to the HLL root namespace (derived from
the .HLL directive)


That's definitely a bug.

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 the PDD about it. (Seems you  
can only

walk *down* the hierarchy, not up.)


That's true.  Given aliasing there may not be just one parent, but  
I don't
suppose the distant chance of that will keep you from wanting this  
feature...?


Well, for the tcl interpreter/compiler, there's not a huge need.  
Either I keep doing it the way I'm doing it now (and I'm *only* doing  
it for getting at the internals at the moment); or you say bug and I  
go back to doing it with find_global. Either works, I just want the  
docs and the code to line up, and I don't want to have to jump  
through too many hoops. I asked about getting the parent because in  
this particular case, I know it's just one up, and having to go all  
the way back to the top offended my sensibilities. =-)


As for the language itself, I'm fairly certain that you can't have a  
parent/child relationship for namespaces in tcl that doesn't  
correspond directly to the naming of those namespaces.


So, 'Foo::Bar' *has* to be the parent namespace of 'Foo::Bar::Baz'.  
So I don't really *need* parrot to provide a way to do this,  
presuming I know the name of the namespace, which I think I have to.


So, for now, don't consider this an RFE on my behalf. (Though I  
reserve the right to come back in six months and demand it! =-)

Re: namespace bug 2?

[Chip Salzenberg]

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 the PDD about it. (Seems you can only
> >>walk *down* the hierarchy, not up.)
> >
> >That's true.  Given aliasing there may not be just one parent, but I don't
> >suppose the distant chance of that will keep you from wanting this 
> >feature...?
> 
> Well, for the tcl interpreter/compiler, there's not a huge need.  
> Either I keep doing it the way I'm doing it now (and I'm *only* doing  
> it for getting at the internals at the moment); or you say bug and I  
> go back to doing it with find_global.

I think we should hold off this until we have a non-diagnostic use case.

I think it's a good idea to add this, as long as we name it in a way that
aliasing doesn't confuse the users.  How about

   PMC *get_original_parent()

?

It does occur to me that we might want a weak reference there, so that
namespaces can evaporate.

It also occurs to me more strongly that we don't want to have a get_name()
but rather

   PMC *get_original_name()

because aliasing may make the original and actual names differ.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

TODO tests

[Nicholas Clark]

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 started passing would be noticed.

I bring this up because we seem to have inadvertently fixed really old regexp
bugs that we didn't have a test case for, but I realise that right now adding
TODO tests wouldn't actually have been *that* useful - if a TODO passes we
don't notice.

It would be good if we were in a position to notice. I'm not sure how much
work that would be.

Nicholas Clark

Re: TODO tests

[Steve Peters]

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 useful, as it would mean that any (real)
> TODO test that unexpectedly started passing would be noticed.
> 
> I bring this up because we seem to have inadvertently fixed really old regexp
> bugs that we didn't have a test case for, but I realise that right now adding
> TODO tests wouldn't actually have been *that* useful - if a TODO passes we
> don't notice.
> 
> It would be good if we were in a position to notice. I'm not sure how much
> work that would be.
> 

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 a start on this, and given tuits (or proper financial
motivation) I'm hoping to finish it sometime this year.  Of course,
writing new test cases for new tickets as they come in would help this
task immensely.

In the long term, however, it would be great if Test::Harness recognized
individual TODO test cases that passed and reported on them.  Maybe this
would be worthy of a Summer of Code project, or it may actually be
something much easier and basic that a normal grant would work for this.


Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: TODO tests

[Randy W. Sims]

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 that unexpectedly started passing would be noticed.

I bring this up because we seem to have inadvertently fixed really old regexp
bugs that we didn't have a test case for, but I realise that right now adding
TODO tests wouldn't actually have been *that* useful - if a TODO passes we
don't notice.

It would be good if we were in a position to notice. I'm not sure how much
work that would be.


This was recently discussed in qa, but I don't think anything became of 
it :(


 

Randy.

Re: TODO tests

[Nicholas Clark]

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 a start on this, and given tuits (or proper financial
> motivation) I'm hoping to finish it sometime this year.  Of course,

The is an application form for motivation:
http://www.perlfoundation.org/gc/grants/proposals.html

Beware. Motivation is a double edged sword. It means everyone knows that
you're going to do stuff.

Nicholas Clark

[svn:parrot-pdd] r12354 - in trunk: . docs/pdds/clip

[allison]

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/clip/pddXX_events.pod
   trunk/docs/pdds/clip/pddXX_exceptions.pod
   trunk/docs/pdds/clip/pddXX_io.pod
   trunk/docs/pdds/clip/pddXX_threads.pod

Changes in other areas also in this revision:
Modified:
   trunk/   (props changed)
   trunk/MANIFEST

Log:
Blessing the draft PDDs with numbers.

Added: trunk/docs/pdds/clip/pdd22_io.pod
==
--- (empty file)
+++ trunk/docs/pdds/clip/pdd22_io.pod   Tue Apr 18 13:45:23 2006
@@ -0,0 +1,773 @@
+# Copyright: 2001-2006 The Perl Foundation.
+# $Id $
+
+=head1 NAME
+
+docs/pdds/pddXX_io.pod - Parrot I/O
+
+=head1 ABSTRACT
+
+Parrot's I/O subsystem.
+
+=head1 VERSION
+
+$Revision $
+
+=head1 SYNOPSIS
+
+open P0, "data.txt", ">"
+print P0, "sample data\n"
+close P0
+
+open P1, "data.txt", "<"
+S0 = read P1, 12
+P2 = getstderr
+print P2, S0
+close P1
+
+...
+
+=head1 DEFINITIONS
+
+A "stream" allows input or output operations on a source/destination
+such as a file, keyboard, or text console. Streams are also called
+"filehandles", though only some of them have anything to do with files.
+
+=head1 DESCRIPTION
+
+This is a draft document defining Parrot's I/O subsystem, for both
+streams and network I/O. Parrot has both synchronous and asynchronous
+I/O operations. This section describes the interface, and the
+L section provides more details on general
+implementation questions and error handling. 
+
+The signatures for the asynchronous operations are nearly identical to
+the synchronous operations, but the asynchronous operations take an
+additional argument for a callback, and the only return value from the
+asynchronous operations is a status object. The callbacks take the
+status object as their first argument, and any return values as their
+remaining arguments. 
+
+The listing below says little about whether the opcodes return error
+information. For now assume that they can either return a status object,
+or return nothing. Error handling is discussed more thoroughly in the
+implementation section.
+
+=head2 I/O Stream Opcodes
+
+=head3 Opening and closing streams
+
+=over 4
+
+=item *
+
+C opens a stream object based on a string path. It takes an
+optional string argument specifying the mode of the stream (read, write,
+append, read/write, etc.), and returns a stream object. Currently the
+mode of the stream is set with a string argument similar to Perl 5
+syntax, but a set of defined constants may fit better with Parrot's
+general architecture. 
+
+  0PIOMODE_READ (default)
+  1PIOMODE_WRITE
+  2PIOMODE_APPEND
+  3PIOMODE_READWRITE
+  4PIOMODE_PIPE (read)
+  5PIOMODE_PIPEWRITE
+
+The asynchronous version takes a PMC callback as an additional final
+argument. When the open operation is complete, it invokes the callback
+with two arguments: a status object and the opened stream object.
+
+=item *
+
+C closes a stream object. It takes a single string object
+argument and returns a status object.
+
+The asynchronous version takes an additional final PMC callback
+argument. When the close operation is complete, it invokes the callback,
+passing it a status object.
+
+=back
+
+=head3 Retrieving existing streams
+
+These opcodes do not have asynchronous variants.
+
+=over 4
+
+=item *
+
+C, C, and C return a stream object for
+standard input, standard output, and standard error.
+
+=item *
+
+C converts an existing and already open UNIX integer file
+descriptor into a stream object. It also takes a string argument to
+specify the mode.
+
+=back
+
+=head3 Writing to streams
+
+=over 4
+
+=item *
+
+C writes an integer, float, string, or PMC value to a stream.  It
+writes to standard output by default, but optionally takes a PMC
+argument to select another stream to write to.
+
+The asynchronous version takes an additional final PMC callback
+argument. When the print operation is complete, it invokes the callback,
+passing it a status object.
+
+=item *
+
+C writes an integer, float, string, or PMC value to standard
+error.
+
+There is no asynchronous variant of C. [It's just a shortcut.
+If they want an asynchronous version, they can use C.]
+
+=back
+
+=head3 Reading from streams
+
+=over 4
+
+=item *
+
+C retrieves a specified number of bytes from a stream into a
+string. [Note this is bytes, not codepoints.] By default it reads from
+standard input, but it also takes an alternate stream object source as
+an optional argument.
+
+The asynchronous version takes an additional final PMC callback
+argument, and only returns a status object. When the read operation is
+complete, it invokes the callback, passing it a status object and a
+string of byte

Re: TODO tests

[Andy Lester]

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 and reported on them.  Maybe  
this

would be worthy of a Summer of Code project, or it may actually be
something much easier and basic that a normal grant would work for  
this.


At least put it in the queue...

xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: TODO tests

[demerphq]

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 it would mean that any (real)
> TODO test that unexpectedly started passing would be noticed.
>
> I bring this up because we seem to have inadvertently fixed really old regexp
> bugs that we didn't have a test case for, but I realise that right now adding
> TODO tests wouldn't actually have been *that* useful - if a TODO passes we
> don't notice.
>
> It would be good if we were in a position to notice. I'm not sure how much
> work that would be.

With the attached (hacky) patch i get the following results:

All tests successful (6 subtests UNEXPECTEDLY SUCCEEDED), 58 tests and
388 subtests skipped.
Passed Test   Stat Wstat Total Pass  Passed  List of Passed
---
../ext/B/t/optree_constants.t   306  20.00%  14 16 19 21 23 28
Files=1224, Tests=164595, 872 wallclock secs ( 0.00 cusr +  0.00 csys
=  0.00 CPU)
cd ..\win32

So its ext/B/t/optree_constant.t thats unexpected happy.

BTW, the patch only shows TODO pass status when no failures occur.

Oh and obviously all of Test::Harness'es tests pass. :-)

cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
diff -wurd sync/lib/Test/Harness.pm 27865/lib/Test/Harness.pm
--- sync/lib/Test/Harness.pm	2005-09-29 01:28:56.0 +0200
+++ 27865/lib/Test/Harness.pm	2006-04-18 22:39:09.618240400 +0200
@@ -218,8 +218,8 @@
 
 local ($\, $,);
 
-my($tot, $failedtests) = _run_all_tests(@tests);
-_show_results($tot, $failedtests);
+my($tot, $failedtests,$todo_passed) = _run_all_tests(@tests);
+_show_results($tot, $failedtests, $todo_passed);
 
 my $ok = _all_ok($tot);
 
@@ -317,7 +317,7 @@
 _autoflush(\*STDOUT);
 _autoflush(\*STDERR);
 
-my(%failedtests);
+my(%failedtests,%todo_passed);
 
 # Test-wide totals.
 my(%tot) = (
@@ -372,11 +372,16 @@
 # state of the current test.
 my @failed = grep { !$results{details}[$_-1]{ok} }
  [EMAIL PROTECTED];
+my @todo_pass = grep { $results{details}[$_-1]{ok} &&
+   $results{details}[$_-1]{type} eq 'todo' }
+[EMAIL PROTECTED];
+
 my %test = (
 ok  => $results{ok},
 'next'  => $Strap->{'next'},
 max => $results{max},
 failed  => [EMAIL PROTECTED],
+todo_pass   => [EMAIL PROTECTED],
 bonus   => $results{bonus},
 skipped => $results{skip},
 skip_reason => $results{skip_reason},
@@ -398,8 +403,20 @@
 my @msg;
 push(@msg, "$test{skipped}/$test{max} skipped: $test{skip_reason}")
 if $test{skipped};
-push(@msg, "$test{bonus}/$test{max} unexpectedly succeeded")
-if $test{bonus};
+if ($test{bonus}) {
+my ($txt, $canon) = _canondetail($test{max},$test{skipped},'Todo passed',
+@{$test{todo_pass}});
+$todo_passed{$tfile} = { canon   => $canon,
+ max => $test{max},
+ failed  => $test{bonus},
+ name=> $tfile,
+ percent => 100*$test{bonus}/$test{max},
+ estat   => '',
+ wstat   => '',
+   };
+
+push(@msg, "$test{bonus}/$test{max} unexpectedly succeeded\n$txt");
+}
 print "$test{ml}ok$elapsed\n".join(', ', @msg)."\n";
 }
 elsif ( $test{max} ) {
@@ -436,7 +453,7 @@
 }
 elsif($results{seen}) {
 if (@{$test{failed}} and $test{max}) {
-my ($txt, $canon) = _canonfailed($test{max},$test{skipped},
+my ($txt, $canon) = _canondetail($test{max},$test{skipped},'Failed',
 @{$test{failed}});
 print "$test{ml}$txt";
 $failedtests{$tfile} = { canon   => $canon,
@@ -492,7 +509,7 @@
 
 $Strap->_restore_PERL5LIB;
 
-return(\%tot, \%failedtests);
+return(\%tot, \%failedtests, \%todo_passed);
 }
 
 =item B<_mk_leader>
@@ -551,13 +568,23 @@
 
 
 sub _show_results {
-my($tot, $failedtests) = @_;
+my($tot, $failedtests, $todo_passed) = @_;
+
+
 
 m

Re: early draft of exceptions PDD

[Allison Randal]

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 rather than full subroutines is error-prone.]


They are not "jumps" but continuations, so in a sense they are more
general than subs, which don't have prior state.


Right, a continuation taken on the address of a label in the current  
compilation unit.


HLL exception handlers on the other hand, are likely to be written as  
independent subroutines, much like the current signal handlers in  
Perl 5. An exception handler is closer to an event handler than it is  
to a return continuation. (The design choice is between having  
exception handlers that are complete compilation units, or just code  
segments. Both are valid options. And it may be that we want to  
support both.)


The "error-prone" comment has to do with control flow. The effect of  
the current implementation is that when the interpreter catches an  
exception, it dumps control flow at the label that was captured in  
the continuation. Any control flow after that is the responsibility  
of the developer, and it's easy to get it wrong.


It might be more helpful if the continuation taken was a return  
continuation: where to return to if an exception is caught and  
successfully handled.




   =item *

   C pushes a subroutine object onto the control  
stack. If the

   control stack is unwound due to an exception (or C, or
   subroutine return), the subroutine is invoked with an integer  
argument:
   C<0> means a normal return; C<1> means an exception has been  
raised.

   [Seems like there's lots of room for dangerous collisions here.]


I'm not sure what you mean by "collisions" here, nor why you think  
they

would be dangerous.


Specifically, because the control stack is used for multiple  
different things, it's easy to get into a situation where the thing  
you're popping off the stack isn't what you meant to pop off the  
stack. It's one of the reasons we aren't using stack-based control  
flow through most of Parrot.



Arguably, C is too simplistic; it
doesn't provide for such things as the repeated exit-and-reenter
behavior of coroutines, and there is no mechanism to specify a thunk
that gets called when *entering* a dynamic context . . .


That too.


   =back

   =head1 IMPLEMENTATION

   [I'm not convinced the control stack is the right way to handle
   exceptions. Most of Parrot is based on the continuation-passing  
style of

   control, shouldn't exceptions be based on it too? See bug #38850.]


Seems to me there isn't any real choice.  Exception handlers are  
part of

the dynamic context, and dynamic contexts nest in such a way as to
behave like a stack.  Even pure CPS implementations that want to
maintain dynamic state have to create an explicit stack in a global
variable somewhere.


"dynamic contexts nest in such a way as to behave like a stack" is  
true, but not necessarily the same thing as storing all exception  
handlers on a single global stack that's also used for primitive  
control flow.


Let's take the example of something that recently came up:  
asynchronous I/O with exceptions. The current implementation says:  
push a global exception handler onto the stack, call the routine that  
might throw an exception, then pop the exception handler off the  
stack. But with asynchronous I/O, the exception handler is likely to  
be popped off the stack long before the async call throws an  
exception. Or, if you delay popping off the exception handler until  
the async callback is called, then you may have other exception  
handlers pushed onto the stack in the mean time (possibly exception  
handlers for other async calls).


In theory, the return continuation maintains the state of the  
caller's control stack, so you can invoke return continuations up the  
CPS chain until you reach a dynamic context where the exception is  
handled. But where does control flow go after you handle an exception  
from an async op?


   Other opcodes respond to an C setting to decide  
whether to
   throw an exception or return an error value. C  
throws an
   exception (or returns a Null PMC) if the global name requested  
doesn't
   exist. C throws an exception (or returns a Null PMC)  
if the
   name requested doesn't exist in a lexical, current, global, or  
built-in

   namespace.

   It's a little odd that so few opcodes throw exceptions (these  
are the
   ones that are documented, but a few others throw exceptions  
internally
   even though they aren't documented as doing so). It's worth  
considering

   either expanding the use of exceptions consistently throughout the
   opcode set, or eliminating exceptions from the opcode set  
entirely. The
   strategy for error handling should be consistent, whatever it  
is. [I
   like the

[svn:perl6-synopsis] r8874 - doc/trunk/design/syn

[larry]

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
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podTue Apr 18 18:09:20 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 15 Apr 2006
+  Last Modified: 18 Apr 2006
   Number: 2
-  Version: 23
+  Version: 24
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -558,6 +558,13 @@
 parentheses.  The C<$()>, C<@()> and C<%()> forms defaults to C<$/> as the
 implicit argument.
 
+C objects fill the ecological niche of references in Perl 6.
+You can think of them as "fat" references, that is, references that
+can capture not only the current identity of a single object, but
+also the relative identities of several related objects.  Conversely,
+you can think of Perl 5 references as a degenerate form of C
+when you want to refer only to a single item.
+
 =item *
 
 A signature object (C) may be created with coloned parens:
@@ -1429,13 +1436,13 @@
 
 =item *
 
-There's also no
-"C" because symbolic dereferences are now syntactically
-distinguished from hard dereferences.  C<@{$arrayref}> must now be a
-hard reference, while C<@::($string)> is explicitly a symbolic reference.
-(Yes, this may give fits to the P5-to-P6 translator, but I think it's
-worth it to separate the concepts.  Perhaps the symbolic ref form will
-admit hard refs in a pinch.)
+There's also no "C" because symbolic dereferences
+are now syntactically distinguished from hard dereferences.
+C<@($arrayref)> must now provide an actual array object, while
+C<@::($string)> is explicitly a symbolic reference.  (Yes, this may
+give fits to the P5-to-P6 translator, but I think it's worth it to
+separate the concepts.  Perhaps the symbolic ref form will admit real
+objects in a pinch.)
 
 =item *
 

Re: TODO tests and test::harness

[Andy Lester]

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 => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Test::Harness now tells you which TODOs passed unexpectedly

[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 entered by: PETDANCE (Andy Lester)
Request entered on: Wed, 19 Apr 2006 05:33:58 GMT
Request completed:  Wed, 19 Apr 2006 05:50:05 GMT

Thanks,
--
paused, v460



--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Non-Perl TAP implementations

[Ovid]

--- 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 have it remain stable for 4 
> years, it becomes an API whether you wanted it to be or not :)

I'm sure most folks here are familiar with the aforementioned buffering
issues, but on the off chance you don't know the sorts of difficulties
that writing to separate output streams causes, read Dominus'
"Suffering from Buffering" (http://perl.plover.com/FAQs/Buffering.html)

What's frustrating about this is that I completely agree with Adam.  We
cannot simply have error and diagnostic output shunted to STDOUT.  What
about having the error and diagnostic information sent to both STDERR
*and* STDOUT?  That could solve the buffering problem, but we'd likely
have duplicate information being output.  Is there an easy solution?

If we can solve this problem, then I can more reliably write a grammar
that can be applied to a single stream of data.  I've toyed with the
idea of TAP::Parser, but we're not there yet.  That raises the next
issue.  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 accomodate that.  Also, how do we want
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.

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing list, please send 
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: TODO tests and test::harness

[demerphq]

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 manually.
>
> But I like the idea.  Thanks.

You're welcome. If it helps It was against Test-Harness-2.56.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Non-Perl TAP implementations

[demerphq]

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 stream
Id say youd probably be wrong. YAML is about as inappropriate a tool
for that purpose as I can imagine. Id say that using a white-space
sensitive data representation in such a circumstance would  be an
abject nightmare.

I should think that youd have a much easier time using Data::Dumper
and its ->Pad and ->Indent(0) method than you ever would with YAML.

DD output is more regular than YAML, and can be output so the full
dump is on a single line meaning that buffering issues shouldnt be as
difficult to resolve. Using ->Pad you could easily add a "magic
marker" to identify the beginning of a dump stream (regardless as to
its size). Heck with a DD structure you could use a regex to match the
entire dump as DD's output is that predictable.

Seriously Id be surprised to hear a single thing that makes YAML
preferable to something like DD for the purposes I understand we are
discussing. And i can think of a lot of reasons YAML would be
suboptimal.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Non-Perl TAP implementations

[A. Pagaltzis]

* 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
> accomodate that.

Hmm, has anyone else ever designed an extensible, versioned
plaintext protocol before, maybe?

:-)

Just think of TAP as a wire protocol. Then most questions just
disappear. There is also have a very large body of prior art to
consult.

Regards,
-- 
Aristotle Pagaltzis //