The behaviour has now changed to something different but also wrong:
> ":4\x[308]a".EVAL
a => 0
It should yield either a syntax error or the same thing as ":4a".
Given that "4\x[308]" is not being accepted as a digit in term context
or in Str.Int coercion, it should presumably yield a syntax
There was another attempt to fix this in 1b898c81, which does prevent
clashes between the Int class object and defined Int values, and similar
clashes for some other classes, but there remain other cases of this
kind of .WHICH clash:
> Str.WHICH
Str|U43431280
> for Str, "U43431280" { say (.WHICH,
# New Ticket Created by Timothy Bollman
# Please include the string: [perl #130160]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130160 >
It appears that when iterating lazily through a list that's been flattened (the
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #130158]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130158 >
From https://irclog.perlgeek.de/perl6/2016-11-23#i_13618534
15:43 timotimo
On Fri, 19 Aug 2016 10:06:01 -0700, c...@zoffix.com wrote:
> This code produces the following exception with Rakudo dd5c28. If
> interval is changed to a larger
> value, the issue does not occur:
>
> react {
> whenever Supply.interval(.001) {
> done if $++ > 1000;
> }
> }
> sleep
On Fri, 11 Nov 2016 08:57:19 -0800, c...@zoffix.com wrote:
> On Tue, 05 Jul 2016 08:34:51 -0700, zef...@fysh.org wrote:
> > But if the content is non-numeric only by having diacritics on the
> > digits,
> > the coercion produces a bad result:
> >
> > > "34\x[308]5".Int
> > 3
>
> Thanks for the
On Tue, 18 Oct 2016 08:39:21 -0700, barto...@gmx.de wrote:
>
> Again, for the records: lizmat++ put in a bandaid for rakudo-j with
> Rakudo commit 666128fc6e. The tests from S32-list/head.t run fine, but
> the underlying problem is still there.
The bandaid was remove recently (Rakudo commit
