While the expression:
@x[1 .. Inf];
is happily accepted by Pugs, this one:
@x[1..Inf];
fails with the message:
*** Error: No compatible subroutine found: "&.Inf"
I noticed this when revisiting the original Pugs golf examples.
If I was just playing golf, I would use:
@x[1...];
wh
Ron Blaschke wrote:
[ skip dynclasses .t on Win32 ]
Just my opinion on this: I'd rather see failures for things that need
to be fixed. Tests should only be skipped if they are not applicable
on the current system, or the test busts everything. Others may feel
different, of course.
The old p
Bob Rogers wrote:
Below please find an additional test case for t/pmc/hash.t that defines
50K keys, while checking that earlier entries are still present. This
takes about 0.8 sec on my 1.8GHz AMD box, tunable by increasing I22. Is
this the sort of thing you had in mind?
Yeah. Thanks. It
Bob Rogers wrote:
+ I22 = 5
+ set_multiple_keys(P30, I22, I29, I22)
+ print_multiple_keys(P30, I29, I30, I20)
+ print_multiple_keys(P30, I21, I30, I20)
^^^
c&p typo
Small reminder: always "make test" before submitting patches
Thank
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 22 May 2005 17:07:48 +0200
Bob Rogers wrote:
> + I22 = 5
> + set_multiple_keys(P30, I22, I29, I22)
> + print_multiple_keys(P30, I29, I30, I20)
> + print_multiple_keys(P30, I21, I30, I20)
Hi,
Back from holydays.
Yup, ok I'm gonna see what I can do for Parrot :)
Regards,
On 5/17/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> On Tue, May 17, 2005 at 04:37:42PM +0200, Gr?oire P?n wrote:
> > First congrats for the advancement on implementing Perl 6, it's impressive.
>
> Thanks for
Kevin Tew schrieb:
Debian sid reports m4 --version as
GNU M4 1.4.3
Written by Rene' Seindal.
notice the captial M.
Thanks, applied.
CU, Bernhard
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Uri Guttman wrote:
>>> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> I'm currently rewriting the hash implementation in
>> src/hash.c. The
LT> new hash structure has just one piece of malloced memory with
LT> b
> "BR" == Bob Rogers <[EMAIL PROTECTED]> writes:
BR>Uri Guttman wrote:
>> here is an odd thought to add to that. since your hash is a single hunk
>> of ram, you could use offsets inside it instead of pointers. that means
>> it could be both shareable (given locks) and even writabl
On Sun, May 22, 2005 at 05:57:45PM +1000, Andrew Savige wrote:
> While the expression:
> @x[1 .. Inf];
> is happily accepted by Pugs, this one:
> @x[1..Inf];
> fails with the message:
> *** Error: No compatible subroutine found: "&.Inf"
Thanks, fixed now. :)
/Autrijus/
pgptNe99K7vz9.pgp
On Fri, May 20, 2005 at 03:23:51PM +0800, Autrijus Tang wrote:
> So I'm finally starting to implement multi-level invocants in MMDs.
> I'd like to sanity check some cases first, though.
Hmm, Warnocked? I'll assume this is sane, until told otherwise, then. :)
Thanks,
/Autrijus/
pgpsOW4QFeuMz.pg
On 5/20/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> So I'm finally starting to implement multi-level invocants in MMDs.
> I'd like to sanity check some cases first, though.
Dewarnocking time.
> Are these two assumed to be identical?
>
> multi sub foo ($x, $y)
> multi sub foo ($x, $y :
Autrijus Tang wrote:
Hmm, Warnocked? I'll assume this is sane, until told otherwise, then. :)
Darn. I was hoping that Larry would field this one. In his absence, I'll take
a swing at it. The usual all(any(@Larry), none($Larry)) caveats apply.
So I'm finally starting to implement multi-le
Luke wrote:
foo($a : $b : $c)
foo($a : $b : $c : )
Hmm, I'm doubting that reflecting how many invocants you have on the
caller side is a good idea. It seems awfully brittle in the face of
reimplementation.
Yep. And that's precisely why we previously ruled against colons in the call
# New Ticket Created by Will Coleda
# Please include the string: [perl #35944]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35944 >
Leo's recent patches to seem to have improved the state of affairs,
but I'm still havi
On Mon, May 23, 2005 at 11:07:59AM +1000, Damian Conway wrote:
> >Hmm, I'm doubting that reflecting how many invocants you have on the
> >caller side is a good idea. It seems awfully brittle in the face of
> >reimplementation.
>
> Yep. And that's precisely why we previously ruled against colons i
Autrijus wrote:
Err, wait. From S06:
# Indirect multimethod call...
handle_event $w, $e: $m;
Is this single-dispatch?
No. I think it's vestigial (or ought to be). Luke's argument against colons in
multimethod calls is compelling from a maintainability point-of-view.
Damian
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 22 May 2005 16:58:00 +0200
Bob Rogers wrote:
> Below please find an additional test case for t/pmc/hash.t that defines
>
>>50K keys, while checking that earlier entries are still present. This
>
> takes about 0.8 sec
On Mon, May 23, 2005 at 12:38:14PM +1000, Damian Conway wrote:
> >Err, wait. From S06:
> >
> ># Indirect multimethod call...
> >handle_event $w, $e: $m;
> >
> >Is this single-dispatch?
>
> No. I think it's vestigial (or ought to be). Luke's argument against colons
> in multimethod calls
Autrijus Tang wrote:
In that case:
$w.handle_event($e: $m);
should be illegal as well, right?
Right.
That is, the App (functional application) form always zero or one
invocants, and it is illegal to specify more than one.
Right.
Damian
20 matches
Mail list logo
