Re: [perl #126941] [LTA] very long right shift gratuitously fails

2015-12-17 Thread Elizabeth Mattijsen
> On 17 Dec 2015, at 03:37, Zefram (via RT) > wrote: > > # 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 >

Re: [perl #126943] [BUG] errors for large left shifts

2015-12-17 Thread Elizabeth Mattijsen
> On 17 Dec 2015, at 03:48, Zefram (via RT) > wrote: > > # 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 >

Re: [perl #126943] [BUG] errors for large left shifts

2015-12-17 Thread Zefram
Elizabeth Mattijsen via RT wrote: >As with #126941, commit f6091476486d29c8886d gives this a slightly >better error message, at least until 6.c. Providing any error here, rather than a wrong answer, resolves this issue. At least it does so for the cases with a non-zero lhs, for which the correct

[perl #126936] LTA Error on is cached trait without use experimental

2015-12-17 Thread via RT
# New Ticket Created by Zoffix Znet # Please include the string: [perl #126936] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126936 > When `is cached` trait is used without declaring `use experimental :cached` the error

Re: [perl #126936] LTA Error on is cached trait without use experimental

2015-12-17 Thread Elizabeth Mattijsen
> On 16 Dec 2015, at 20:52, Zoffix Znet (via RT) > wrote: > > # New Ticket Created by Zoffix Znet > # Please include the string: [perl #126936] > # in the subject line of all future correspondence about this issue. > #

Re: [perl #126935] [BUG] bad .perl for paths with pipe characters

2015-12-17 Thread Zefram
Elizabeth Mattijsen via RT wrote: >Fixed with 8d50dabfa9a3b690b18a Done the hard way. Because it lacks most of the refinements of Str.perl, it looks like it might still have bugs that Str.perl avoids. For example, leading combining characters will become part of the grapheme of the opening

Re: [perl #126942] [BUG] large right-shift of negative loses sign

2015-12-17 Thread Elizabeth Mattijsen
> On 17 Dec 2015, at 03:41, Zefram (via RT) > wrote: > > # 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 >

[perl #126948] [BUG] DateTime does not follow ISO 8601 entierly

2015-12-17 Thread via RT
# New Ticket Created by Sylvain Colinet # Please include the string: [perl #126948] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126948 > I work with a webservice (Discord) that provide timestamp in the ISO 8601 format.

[perl #124084] Must initialize num/num32/num64 ?

2015-12-17 Thread jn...@jnthn.net via RT
On Mon Mar 16 05:09:58 2015, elizabeth wrote: > my num $a; say $a > NaN > my num32 $a; say $a > 0 > my num64 $a; say $a > NaN > Fixed, and test in S02-types/native.t unfudged. Also added a load of related tests.

Re: [perl #126935] [BUG] bad .perl for paths with pipe characters

2015-12-17 Thread Elizabeth Mattijsen
> On 17 Dec 2015, at 16:16, Zefram wrote: > > Elizabeth Mattijsen via RT wrote: >> Fixed with 8d50dabfa9a3b690b18a > > Done the hard way. Because it lacks most of the refinements of > Str.perl, it looks like it might still have bugs that Str.perl avoids. > For example, leading

Re: [perl #126935] [BUG] bad .perl for paths with pipe characters

2015-12-17 Thread Zefram
Elizabeth Mattijsen via RT wrote: >In any case, Str.perl cannot be used, because it puts double quotes >around it. Which would be a set of double quotes too many. I think you've misunderstood somewhere. The code that I proposed does not have a multiple-quotation bug, but what you've committed

[perl #126950] [BUG] IO::Path.perl produces incorrect expression structure

2015-12-17 Thread via RT
# New Ticket Created by Zefram # Please include the string: [perl #126950] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126950 > IO::Path.perl produces output of the general form $a.IO(:SPEC($b),:CWD($c)), but it turns out

Re: [perl #126950] [BUG] IO::Path.perl produces incorrect expression structure

2015-12-17 Thread Elizabeth Mattijsen
> On 17 Dec 2015, at 18:13, Zefram (via RT) > wrote: > > # New Ticket Created by Zefram > # Please include the string: [perl #126950] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=126950 >

Re: [perl #126935] [BUG] bad .perl for paths with pipe characters

2015-12-17 Thread Zefram
Elizabeth Mattijsen via RT wrote: >Don't think so: if you interpolate a Str into a "", then it calls the >.Str method on it, *not* the .perl method. I'm not sure where you think this is relevant. I was not expecting implicit .perl calls from any interpolation. The code that I proposed

Re: [perl #126935] [BUG] bad .perl for paths with pipe characters

2015-12-17 Thread Elizabeth Mattijsen
> On 17 Dec 2015, at 17:31, Zefram wrote: > > Elizabeth Mattijsen via RT wrote: >> In any case, Str.perl cannot be used, because it puts double quotes >> around it. Which would be a set of double quotes too many. > > I think you've misunderstood somewhere. The code that I

[perl #126951] Interpolating a typed hash into an argument list produces wrong keys

2015-12-17 Thread via RT
# New Ticket Created by Sam S. # Please include the string: [perl #126951] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126951 > Example: sub f (*%args) { say .perl for %args.keys } my %typedhash

[perl #126955] [BUG] more .perl string quoting problems

2015-12-17 Thread via RT
# New Ticket Created by Zefram # Please include the string: [perl #126955] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126955 > The roles CompUnit::Repository::Locally and IO::Local each have a bug similar to [perl

Re: [perl #126942] [BUG] large right-shift of negative loses sign

2015-12-17 Thread Parrot Raiser
Does a shift value longer than the word length make any sense anyway? On 12/17/15, Elizabeth Mattijsen wrote: >> On 17 Dec 2015, at 03:41, Zefram (via RT) >> wrote: >> >> # New Ticket Created by Zefram >> # Please include the string: [perl

[perl #126954] [POD] declarator blocks don't parse contents as POD

2015-12-17 Thread via RT
# New Ticket Created by Lloyd Fournier # Please include the string: [perl #126954] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126954 > #| look it's a C! sub thing { ... } say #-> ["look its a C"]

Re: [perl #126942] [BUG] large right-shift of negative loses sign

2015-12-17 Thread Zefram
Parrot Raiser via RT wrote: >Does a shift value longer than the word length make any sense anyway? With bignums, yes it does. > -123 +< 200 -197653379443855803891661337357963000110230968235283518742069248 (Also, 32 isn't really my word length.) -zefram

Re: [perl #126935] [BUG] bad .perl for paths with pipe characters

2015-12-17 Thread Elizabeth Mattijsen
> On 16 Dec 2015, at 12:31, Zefram (via RT) > wrote: > > # 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 >

[perl #126945] outer frame does not match expected static frame

2015-12-17 Thread via RT
# New Ticket Created by Lloyd Fournier # Please include the string: [perl #126945] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=126945 > perl6 -e '{ berp => "lerp", ( with "herp" { $_ => "derp" } ) }' This is Rakudo

Re: [perl #126945] AutoReply: outer frame does not match expected static frame

2015-12-17 Thread Lloyd Fournier
should have mentioned: When invoking cuid_1_1450351791.17598 '', provided outer frame 0x7fbeb3c409b0 (cuid_3_1450351791.17598 '') does not match expected static frame 0x7fbeb3c40ad0 (cuid_2_1450351791.17598 '') in block at -e:1 and that if you replace the () with 'do' it doesn't happen. On