On Tue, Jul 19, 2005 at 10:49:12PM -0400, James E Keenan wrote:
> The inference I drew was that the four false positives I received for
> v0.35 came from automated testing in an environment where IO::Capture
> was already installed, so that the test script did not need to find
> IO::Capture in t
It's not unheard of for module authors to complain that the automated
test reports posted on testers.cpan.org FAIL modules that ought to PASS.
Tonight, I wish to make the opposite complaint: that one of my own
modules garnered four PASSes when it should have FAILed!
Je m'accuse: Two days ag
On Tue, 19 Jul 2005, Larry Wall wrote:
On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote:
:
: So the question is: what is the correct syntax for referring to package
: variables in the default namespace?
The * looks like a twigil but it isn't really. It's short for "*::",
where
On Jul 19, Nathan Gray said:
Autrijus Tang suggested to me that you had at one time started work on a
parser for perl6 rules.
What is the state of that project?
I started work on it back at the end of May, beginning of June, but then I
got bogged down with classwork (taking a summer course)
Hrm, the very of Regexp::Parser on CPAN is actually older than the one I'm
working with. I'll upload the current one right away.
--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
http://japhy.perlmonk.org/
Jeff,
Autrijus Tang suggested to me that you had at one time started work on a
parser for perl6 rules.
What is the state of that project?
May others help?
-kolibrie
On Tue, Jul 19, 2005 at 03:01:03PM -0400, Jeff 'japhy' Pinyan wrote:
> On Jul 19, Nathan Gray said:
>
> >May others help?
>
> Most likely. I haven't CVS'd it yet (or whatever it is they're using on
> feather.perl6.nl), but I suppose I should if multiple people would want to
> contribute.
SVN
Luke wrote:
"In absence of other information, a derived class behaves just
like its parent."
I can argue that one into the ground, but it is a postulate and
doesn't fall out of anything deeper (in my thinking paradigm, I
suppose). My best argument is that, how can you expect to add to
some
On Tue, Jul 19, 2005 at 01:58:18PM -0500, [EMAIL PROTECTED] wrote:
> Now I want to contribute an example. It shows off named parameters with
> default values (including those of code type :-) as well as currying. It
> does this by implementing Newton's method for root finding. Is this
> appro
On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote:
: Hi all,
:
: I've spent some of the afternoon wading through A12 and S10 trying to
: thoroughly understand scope in perl 6, in light of the death of use vars
: and the addition of class (as well as package & module) namespaces.
:
Autrijus Tang <[EMAIL PROTECTED]> wrote:
> I get errors:
> 1..2
> ok 1 - default sub called
> not ok 2 - default sub called in package namespace
> # Failed test (t/subroutines/defaults.t line 35, column 1-62)
> #Got: undef
> # Looks like you failed 1 tests of 2
Did you perhaps had an
On Mon, Jul 11, 2005 at 12:30:03PM -0700, Larry Wall wrote:
> Or we go the other way and, in a binge of orthogonality, rationalize
> all the "on write" traits:
>
> Current Conjectural
> === ===
> is constant is dow "die on write"
> is copy is cow "copy on
On Tue, 2005-07-19 at 18:47 +0200, "TSa (Thomas Sandlaß)" wrote:
> I strongly agree. They should share the same namespace. Since
> code objects constitute types they also share this namespace.
> This means that any two lines of
>
> class Foo {...}
> roleFoo {...}
> sub Foo {...}
> metho
On Tue, 2005-07-19 at 12:37 +0200, "TSa (Thomas Sandlaß)" wrote:
> I would think that the programmer specifies what type a class
> implements by letting it do a set of roles. This implies that
> by default a class does the very unspecific Any.
Why would a class not also define a type?
-- c
On Tue, Jul 19, 2005 at 02:21:44PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
: > > Users of the class includes people subclassing the class, so to them
: > > they need to be able to use $.month_0 and $.month, even though there
: > > is no "has $.month_0" declared in the Class implementation, onl
Hi all,
I've spent some of the afternoon wading through A12 and S10 trying to
thoroughly understand scope in perl 6, in light of the death of use vars
and the addition of class (as well as package & module) namespaces.
In the process I came up against some confusion concerning how the default
I was trying to debug this problem in Prelude.pm - I think it is the same bug:
pugs> my $x=1.222
1.222
pugs> $x.round
*** Undeclared variable: "&do_round"
at src/perl6/Prelude.pm line 278, column 9 - line 279, column 5
- Flavio S. Glock
On Tue, Jul 19, 2005 at 12:53:19PM -0500, [EMAIL PROTECTED] wrote:
> Thanks for working on this, but there is still a problem.
>
> When I run make test, the two tests both pass. When I run the test as:
>
> perl -Iblib/lib t/subroutines/defaults.t
"perl"?
> I get errors:
> 1..2
> ok 1 - default
Autrijus Tang <[EMAIL PROTECTED]> wrote:
On Mon, Jul 18, 2005 at 02:47:06PM -0500, [EMAIL PROTECTED] wrote:
> I did this. I included two tests, one without multiple packages (which
> works) and one with them (which fails). I marked the second test todo.
...and I fixed the bug promptly. :)
HaloO chromatic,
you wrote:
Have I mentioned before that I think you should be able to say:
class Foo
{
method foo { ... }
method more_foo { ... }
}
class Bar does Foo
{
method foo { ... }
}
... probably get a compile-time error that Bar doesn't support
more_foo()?
W
Ingo Blechschmidt wrote:
How do I have to annotate the type specification in the
declaration of the subroutine to not include the class Foo, but
only allow instances of Foo?
My understanding is that Foo.does(Foo) is false and sub params
are checked with .does(). This automatically excludes cl
On Mon, Jul 18, 2005 at 02:47:06PM -0500, [EMAIL PROTECTED] wrote:
> I did this. I included two tests, one without multiple packages (which
> works) and one with them (which fails). I marked the second test todo.
...and I fixed the bug promptly. :)
> Thanks for the gentle help with this proces
HaloO Damian,
you wrote:
No. If the dispatch behaviour changes under a Manhattan metric, then it
only ever changes to a more specific variant.
This statement is contradicting itself. A metric chooses the *closest*
not the most specific target. Take e.g. the three-argument cases
7 == 1+2+4 == 0
Hi,
class Foo {...}
Foo.new.isa(Foo); # true
Foo.isa(Foo); # true (see [1])
Foo.does(Class);# true
sub blarb (Foo $foo, $arg) {
...; # Do something with instance $foo
}
blarb Foo.new(...), ...;
# No problem
blarb Foo,
Parrot's method resolution order (MRO) conforms now to MRO of Python (>=
2.3) and Perl6.
See also http://www.python.org/2.3/mro.html and
http://use.perl.org/~autrijus/journal/25768
leo
HaloO Larry,
you wrote:
Implicit is that role distance is N + the distance to the nearest
class that incorporates that role for small values of N.
If class Dog does role Bark and also does role Wag, then passing a
Dog to
multi (Bark $x)
multi (Wag $x)
should result in ambiguity. The
We could have an option to do Bulk Inserts ..
On 7/17/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> "You keep using that word. I do not think
> it means what you think it means"
> -- Inigo Montoya
Quite. I abused Liskov's name greatly here. Sorry about that.
Anyway, my argument is founded on anothe
In article <[EMAIL PROTECTED]>, Brett Sanger
<[EMAIL PROTECTED]> wrote:
>> > > Test::Builder docs, in case I was going to have to roll my own
> > > prove-like tool, and didn't see an obvious call there either.
> >
> > Test::Manifest is the way to get them in a certain order.
>
> Ah, thanks. Is
29 matches
Mail list logo
