fixed in 323a5c077efeaa058de48871963046507e33b272
Minimal test case:
{ my $f := Failure.new("bar"); }
This doesn't seem to be sink related, at least not directly. It seems more to
be related to the difference between storing things in a local vs in a lexical,
and how those are treated on statement or return boundaries.
# New Ticket Created by Zefram
# Please include the string: [perl #126943]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126943 >
When shifting a non-zero integer left by a very large amount, generally
some kind of error shou
# New Ticket Created by Zefram
# Please include the string: [perl #126942]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126942 >
Long right shifts (longer than operand length) of negative integers
should always produce -1, b
# New Ticket Created by Zefram
# Please include the string: [perl #126941]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126941 >
> 123 +> (1 +< 64)
Cannot unbox 65 bit wide bigint into native integer
This is less than aweso
# New Ticket Created by Zefram
# Please include the string: [perl #126940]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126940 >
It seems to be intended (though it's not documented) that long bit shifts
produce the mathemati
On Thu Aug 27 09:22:02 2015, masak wrote:
> [Coke]: no.
> [Coke]: I think you misunderstood the goal of the ticket.
> [Coke]: the spec said (and still *says*, I think) that the
> *contents* of the array parameter are readonly. that's what the "one
> level down" thing refers to.
> [Coke]: Howeve
On Sat Aug 30 21:18:35 2014, masak wrote:
> m: class IncList { has @.values; submethod PRE { @!values eqv
> @!values.sort } }; say IncList.new(:values(1, 5, 3))
> rakudo-moar 5f9cd5: OUTPUT«IncList.new(values =>
> Array.new(1, 5, 3))»
> * masak submits NYI rakudobug
> m: say [1, 5, 3] eqv [1, 5
On Fri Nov 20 10:21:26 2015, nicholas wrote:
> MoarVM work towards fixing this bug is on the MoarVM branch sync-without-uv
Having already ran into various "fun" platform inconsistencies working on that
branch, I've concluded that - while I agree this issue wants fixing - it's not
something that
On Fri Dec 11 09:31:44 2015, na...@cpan.org wrote:
> 64-bit Windows 10.0.10586. 64-bit perl6 on MoarVM built using MS
> Visual Studio 2013 tools. See below for more details.
>
> I noticed[1] that several tests fail if the test script has Unix line
> endings instead of Windows. These tests succeed
On Fri Dec 11 09:31:44 2015, na...@cpan.org wrote:
> 64-bit Windows 10.0.10586. 64-bit perl6 on MoarVM built using MS
> Visual Studio 2013 tools. See below for more details.
>
> I noticed[1] that several tests fail if the test script has Unix line
> endings instead of Windows. These tests succeed
Bisected to f457007181bb6e2dcb6aefe857f36d648ae38401
On Thu Nov 12 11:41:16 2015, larry wrote:
> > p6 'my ($a, \b) = 1, 2; say $a; say b;'
> 1
> (Any)
> > p6 'my ($a, \b) := 1, 2; say $a; say b;'
> 1
> (Any)
These two now work. Tests in S04-declarations/my.t.
# New Ticket Created by Zefram
# Please include the string: [perl #126935]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126935 >
The .perl method for IO::Path objects produces faulty output:
> "/foo|bar".IO.perl
q|/foo|bar|
Parrot Raiser via RT wrote:
>prima facie evidence they simply don't know about the feature.
Or that they do know about the name scoping features.
-zefram
Elizabeth Mattijsen via RT wrote:
>This seems to apply to any variable type and any PseudoStash:
Further generalisation: it also happens for any package object (GLOBAL,
MAIN) and any role object (Iterable, Dateish). In both cases, the
.^isa misbehaviour is seen as well as the actual ability to by
16 matches
Mail list logo
