Just reload parrot. Ran:
make realclean
perl Configure.pl
make
make test
The result:
11 tests and 579 subtests skipped.
Failed 14/254 test scripts, 94.49% okay. 176/6439 subtests failed,
97.27% okay.
make: *** [test] Error 1
And no, I'm not going to open 176 tickets on this!
--
__END__
Just
Here's the Parrot::Coroutine patch; I will commit this if nobody
objects.
It seems to me that this should be mentioned in docs/compiler_faq.pod
as an alternative way to do coroutines . . . I will take a look at this.
In fact, it might be safer to deprecate Coroutine.pmc until it can be
r
On Fri, Oct 13, 2006 at 04:56:05PM -0700, Jonathan Lang wrote:
: Trey Harris wrote:
: >All three objects happen to be Baz's, yes. But the client code doesn't
: >see them that way; the first snippet wants a Foo, the second wants a Bar.
: >They should get what they expect, or Baz can't be said to "d
On 10/7/06, Damian Conway <[EMAIL PROTECTED]> wrote:
The C> formatting code specifies that the contained text is
to be set in an I
I've probably been hanging around Web standards nazis for too long,
but can we get a separate code to mark the title of a document that
can't be linked to (say, a b
Trey Harris wrote:
In a message dated Fri, 13 Oct 2006, Jonathan Lang writes:
> Since Baz does both Foo and Bar, you cannot use type-checking to
> resolve this dilemma.
Why not? Why shouldn't this work:
my Foo $obj1 = getBaz(); # object is a Baz
$obj1.baz(); # Foo::baz is c
In a message dated Fri, 13 Oct 2006, Jonathan Lang writes:
Since Baz does both Foo and Bar, you cannot use type-checking to
resolve this dilemma.
Why not? Why shouldn't this work:
my Foo $obj1 = getBaz(); # object is a Baz
$obj1.baz(); # Foo::baz is called
my Bar $obj2 =
Jack is tasked to write a role "Foo". He does his job right, and
produces a role that perfectly produces the set of behaviours that
it's supposed to. Among other things, he defines a method
"&Foo::baz:()". He also writes a routine, "&foo:( Foo )", which calls
&Foo::baz.
Jill is tasked to write
Author: particle
Date: Fri Oct 13 11:08:30 2006
New Revision: 14918
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Log:
[PDD03[: clarify examples for :named syntax
Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
Jonathan Lang wrote:
If I understand you correctly, the pain to which you're referring
would come from the possibility of a name that's reserved by the newer
version of Pod, but not by the older version. Wouldn't the simplest
solution be to let a Pod document announce its own version, much like
Tim Bunce wrote:
> That's going to cause pain when people using older parsers try to read
> docs written for newer ones. Would a loud warning plus some best-efforts
> fail-safe parsing be possible?
Indeed. And that's a important use-case.
But best-effort is difficult when you're talking about f
HaloO,
Jonathan Lang wrote:
class GenSquare does GenPoint does GenEqual
{
has Int $.side;
method equal ( GenSquare $p --> Bool )
{
return $self.GenPoint::equal($p) and $self.side == $p.side;
}
}
This is exactly what I don't want. Such an equal method needs to be
written in each an
11 matches
Mail list logo
