Re: [perl #132268] Floating point anomalies
From: Brandon Allbery Sent: Friday, October 13, 2017 4:15 AM To: sisyph...@optusnet.com.au Cc: Carl Mäsak via RT Subject: Re: [perl #132268] Floating point anomalies On Thu, Oct 12, 2017 at 5:31 AM, wrote: Perl6's printf() function looks a little suspect - though I might be missing something here. As with perl5's say function, doubles are rounded to 14 decimal digits of precision To correct that assertion, they both of course round to 15 decimal digits of precision. I question your use of 'accurate'. The low bits are *never* accurate. They're trying to be more 'precise', but the value they have will depend strongly on how exactly the value was calculated, and there are entirely reasonable design decisions that can cause them to differ between implementations. I don't think there's anything "reasonable" about a printf() implementation that tells me: $ perl6 -e 'printf "%.16e\n", Num(sqrt(3e0));' 1.7320508075688800e+00 Perl6 knows quite well that a double assigned a value of 1.7320508075688800e+00 is not equivalent to the double returned by Num(sqrt(3e0)) : $ perl6 -e 'say "not equivalent" if 1.7320508075688800e0 != Num(sqrt(3e0));' not equivalent Furthermore, perl6 also knows quite well that a double assigned the value 1.7320508075688772e+00 *is* equivalent to the double returned by Num(sqrt(3e0)): $ perl6 -e 'say "ok" if 1.7320508075688772e0 == Num(sqrt(3e0));' ok It's bad enough that perl5 and perl6 round to 15 decimal digits of precision, but at least perl5's printf will give me 17 decimal digits when I ask it to (and I think perl6 should do the same): $ perl -e 'printf "%.16e\n", sqrt(3.0);' 1.7320508075688772e+00 As a feature request, it would also be nice to see "%a" formatting implemented as that then provides one with the means to see the exact value of the given double. Cheers, Rob
Re: [perl #132279] [REGRESSION][9999] BagHash.grab with huge values (("foo" => 10000000000000000000).BagHash.grab(1))
Fixed with 975fcf6cfd8089bfc237 , tests needed
> On 13 Oct 2017, at 07:01, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> wrote:
>
> # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string: [perl #132279]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132279 >
>
>
> Code:
> ("foo" => 1000).BagHash.grab(1)
>
> ¦«2015.12»:
>
>
> ¦«2016.06»:
>
>
> ¦«2016.12»:
>
>
> ¦«2017.06»:
> Cannot unbox 64 bit wide bigint into native integer
> in block at
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
>
> ¦«f72be0f130cf»:
> Cannot unbox 64 bit wide bigint into native integer
> in block at
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
>
>
> Possible IRC discussion:
> https://irclog.perlgeek.de/perl6/2017-10-11#i_15290317
>
> Bisectable points at
> https://github.com/rakudo/rakudo/commit/87a95fc1355e01972670895b55b02bc382797fc9
Re: [perl #132279] [REGRESSION][9999] BagHash.grab with huge values (("foo" => 10000000000000000000).BagHash.grab(1))
Fixed with 975fcf6cfd8089bfc237 , tests needed
> On 13 Oct 2017, at 07:01, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> wrote:
>
> # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string: [perl #132279]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132279 >
>
>
> Code:
> ("foo" => 1000).BagHash.grab(1)
>
> ¦«2015.12»:
>
>
> ¦«2016.06»:
>
>
> ¦«2016.12»:
>
>
> ¦«2017.06»:
> Cannot unbox 64 bit wide bigint into native integer
> in block at
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
>
> ¦«f72be0f130cf»:
> Cannot unbox 64 bit wide bigint into native integer
> in block at
> /home/bisectable/git/whateverable/data/regressionable/15290317/snippet line 1
> «exit code = 1»
>
>
> Possible IRC discussion:
> https://irclog.perlgeek.de/perl6/2017-10-11#i_15290317
>
> Bisectable points at
> https://github.com/rakudo/rakudo/commit/87a95fc1355e01972670895b55b02bc382797fc9
Re: [perl #132281] [REGRESSION] .gist of a bag used to say “bag()”, now it says “Bag()” ("blogger".comb.Bag)
> On 13 Oct 2017, at 07:37, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> wrote:
>
> # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string: [perl #132281]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132281 >
>
>
> Code:
> say "blogger".comb.Bag # if you want for all the letters
>
> ¦«2015.12»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2016.06»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2016.12»:
> bag(r, l, g(2), b, e, o)
>
> ¦«2017.06»:
> bag(e, l, b, g(2), o, r)
>
> ¦«f72be0f130cf»:
> Bag(b, e, g(2), l, o, r)
>
>
> Possible IRC discussion:
> https://irclog.perlgeek.de/perl6/2017-10-09#i_15278073
>
>
> Bisectable: (2017-07-20)
> https://github.com/rakudo/rakudo/commit/21b9a720c75656b13805611544aa5ee64c4924ae
>
>
> To be honest, I don't know if that's a reasonable ticket. I guess it doesn't
> really matter if it's bag or Bag, but I'm pretty sure that the change was
> unintentional so I'm submitting it as a ticket.
>
> Maybe “bag()” is better because it resembles an actual syntax. Kind of. Judge
> yourself.
The two are *not* the same. Bag(foo) is the same as foo.Bag. Which implies
taking all values as is. Whereas bag() implies looking at the values in the
same way as “.new-from-pairs”. Observe:
$ 6 'dd bag({a => 42}); dd Bag({ a => 42 })'
(:a(42)).Bag
("a"=>42).Bag
Re: [perl #132281] [REGRESSION] .gist of a bag used to say “bag()”, now it says “Bag()” ("blogger".comb.Bag)
Oh. I guess this has to be rejected then.
On Fri, Oct 13, 2017 at 2:46 PM, Elizabeth Mattijsen wrote:
>
> > On 13 Oct 2017, at 07:37, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
> perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string: [perl #132281]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132281 >
> >
> >
> > Code:
> > say "blogger".comb.Bag # if you want for all the letters
> >
> > ¦«2015.12»:
> > bag(r, l, g(2), b, e, o)
> >
> > ¦«2016.06»:
> > bag(r, l, g(2), b, e, o)
> >
> > ¦«2016.12»:
> > bag(r, l, g(2), b, e, o)
> >
> > ¦«2017.06»:
> > bag(e, l, b, g(2), o, r)
> >
> > ¦«f72be0f130cf»:
> > Bag(b, e, g(2), l, o, r)
> >
> >
> > Possible IRC discussion: https://irclog.perlgeek.de/
> perl6/2017-10-09#i_15278073
> >
> >
> > Bisectable: (2017-07-20) https://github.com/rakudo/rakudo/commit/
> 21b9a720c75656b13805611544aa5ee64c4924ae
> >
> >
> > To be honest, I don't know if that's a reasonable ticket. I guess it
> doesn't really matter if it's bag or Bag, but I'm pretty sure that the
> change was unintentional so I'm submitting it as a ticket.
> >
> > Maybe “bag()” is better because it resembles an actual syntax. Kind of.
> Judge yourself.
>
> The two are *not* the same. Bag(foo) is the same as foo.Bag. Which
> implies taking all values as is. Whereas bag() implies looking at the
> values in the same way as “.new-from-pairs”. Observe:
>
> $ 6 'dd bag({a => 42}); dd Bag({ a => 42 })'
> (:a(42)).Bag
> ("a"=>42).Bag
>
Re: [perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)
> On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> wrote:
>
> # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string: [perl #132283]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132283 >
>
>
> Code:
> class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
>
> ¦«2015.12»:
> (bar)
>
> ¦«2016.06»:
> (bar)
>
> ¦«2016.12»:
> (bar)
>
> ¦«2017.06»:
> (bar)
>
> ¦«f72be0f130cf»:
> (bar BUILDALL)
>
>
>
> Bisectable points at two relevant commits:
> First it was BUILDALL_UNDER_CONSTRUCTION after
> https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> Now it is BUILDALL after
> https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
>
>
> I don't know if BUILDALL should be listed or not. My gut feeling says that it
> shouldn't be, but feel free to argue otherwise. I'm just the messenger.
Well, it *is* an auto-generated method that is installed in the namespace.
Just like “bar”. So either we should show both, or neither. Or introduce a
flag to include/exclude auto-generated methods. But then we would need to mark
those methods as auto-generated somehow.
Re: [perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)
> On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> wrote:
>
> # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string: [perl #132283]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132283 >
>
>
> Code:
> class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
>
> ¦«2015.12»:
> (bar)
>
> ¦«2016.06»:
> (bar)
>
> ¦«2016.12»:
> (bar)
>
> ¦«2017.06»:
> (bar)
>
> ¦«f72be0f130cf»:
> (bar BUILDALL)
>
>
>
> Bisectable points at two relevant commits:
> First it was BUILDALL_UNDER_CONSTRUCTION after
> https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> Now it is BUILDALL after
> https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
>
>
> I don't know if BUILDALL should be listed or not. My gut feeling says that it
> shouldn't be, but feel free to argue otherwise. I'm just the messenger.
Well, it *is* an auto-generated method that is installed in the namespace.
Just like “bar”. So either we should show both, or neither. Or introduce a
flag to include/exclude auto-generated methods. But then we would need to mark
those methods as auto-generated somehow.
Re: [perl #132268] Floating point anomalies
On Fri, Oct 13, 2017 at 4:59 AM, wrote: > It's bad enough that perl5 and perl6 round to 15 decimal digits of > precision, but at least perl5's printf will give me 17 decimal digits when > I ask it to (and I think perl6 should do the same): > I am wondering if youve talked to any Intel FP engineers. 17 decimal digits sounds like you expect full internal 80-bit precision even if it's not in an internal register. Good luck. (gcc does have ways of doing this on sufficiently recent processors. msvc does NOT. So, you've just demanded a Windows vs. Unix difference be enshrined in the language?) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132268] Floating point anomalies
On Fri, Oct 13, 2017 at 4:59 AM, wrote: > It's bad enough that perl5 and perl6 round to 15 decimal digits of > precision, but at least perl5's printf will give me 17 decimal digits when > I ask it to (and I think perl6 should do the same): > I am wondering if youve talked to any Intel FP engineers. 17 decimal digits sounds like you expect full internal 80-bit precision even if it's not in an internal register. Good luck. (gcc does have ways of doing this on sufficiently recent processors. msvc does NOT. So, you've just demanded a Windows vs. Unix difference be enshrined in the language?) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
[perl #132268] [MATH] Floating point anomalies
On Fri, 13 Oct 2017 05:15:58 -0700, allber...@gmail.com wrote: > On Fri, Oct 13, 2017 at 4:59 AM, wrote: > > > It's bad enough that perl5 and perl6 round to 15 decimal digits of > > precision, but at least perl5's printf will give me 17 decimal digits when > > I ask it to (and I think perl6 should do the same): > > > > I am wondering if youve talked to any Intel FP engineers. 17 decimal digits > sounds like you expect full internal 80-bit precision even if it's not in > an internal register. Good luck. > (gcc does have ways of doing this on sufficiently recent processors. msvc > does NOT. So, you've just demanded a Windows vs. Unix difference be > enshrined in the language?) > Perhaps the discussions about who talked to Intel engineers could be moved somewhere off the RT? The person fixing this ticket can figure out how much precision we can possibly give, without any luck wished upon those who made a feature request.
[perl #132268] [MATH] Floating point anomalies
On Fri, 13 Oct 2017 05:15:58 -0700, allber...@gmail.com wrote: > On Fri, Oct 13, 2017 at 4:59 AM, wrote: > > > It's bad enough that perl5 and perl6 round to 15 decimal digits of > > precision, but at least perl5's printf will give me 17 decimal digits when > > I ask it to (and I think perl6 should do the same): > > > > I am wondering if youve talked to any Intel FP engineers. 17 decimal digits > sounds like you expect full internal 80-bit precision even if it's not in > an internal register. Good luck. > (gcc does have ways of doing this on sufficiently recent processors. msvc > does NOT. So, you've just demanded a Windows vs. Unix difference be > enshrined in the language?) > Perhaps the discussions about who talked to Intel engineers could be moved somewhere off the RT? The person fixing this ticket can figure out how much precision we can possibly give, without any luck wished upon those who made a feature request.
[perl #132285] [REGRESSION] Error message talks about null strings when trying to create a num32 Blob (Blob[num32].new(2e0))
Fixed in https://github.com/rakudo/rakudo/pull/1189 Not sure where tests should go, roast or rakudo?
Re: [perl #132268] Floating point anomalies
From: Brandon Allbery Sent: Friday, October 13, 2017 4:15 AM To: sisyph...@optusnet.com.au Cc: Carl Mäsak via RT Subject: Re: [perl #132268] Floating point anomalies On Thu, Oct 12, 2017 at 5:31 AM, wrote: Perl6's printf() function looks a little suspect - though I might be missing something here. >> As with perl5's say function, doubles are rounded to 14 decimal digits of >> precision To correct that assertion, they both of course round to 15 decimal digits of precision. > I question your use of 'accurate'. The low bits are *never* accurate. > They're trying to be more 'precise', but the value they have will depend > strongly on how exactly the value was calculated, and there are entirely > reasonable design decisions that can cause them to differ between > implementations. I don't think there's anything "reasonable" about a printf() implementation that tells me: $ perl6 -e 'printf "%.16e\n", Num(sqrt(3e0));' 1.7320508075688800e+00 Perl6 knows quite well that a double assigned a value of 1.7320508075688800e+00 is not equivalent to the double returned by Num(sqrt(3e0)) : $ perl6 -e 'say "not equivalent" if 1.7320508075688800e0 != Num(sqrt(3e0));' not equivalent Furthermore, perl6 also knows quite well that a double assigned the value 1.7320508075688772e+00 *is* equivalent to the double returned by Num(sqrt(3e0)): $ perl6 -e 'say "ok" if 1.7320508075688772e0 == Num(sqrt(3e0));' ok It's bad enough that perl5 and perl6 round to 15 decimal digits of precision, but at least perl5's printf will give me 17 decimal digits when I ask it to (and I think perl6 should do the same): $ perl -e 'printf "%.16e\n", sqrt(3.0);' 1.7320508075688772e+00 As a feature request, it would also be nice to see "%a" formatting implemented as that then provides one with the means to see the exact value of the given double. Cheers, Rob
[perl #132287] [CONC] stall/block in async heavy code
# New Ticket Created by Justin DeVuyst
# Please include the string: [perl #132287]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132287 >
Below is the best golfing I could manage. I ran it like so for
bisecting:
while perl6 test.pl6; do :; done
The symptom is that sometimes (90%+ on my box and ungolfed) the program
seems to stall out on the qqx line. The last thing that is printed is
"before". But on earlier commits (that actually build) no such
stallage
happened for a couple minutes run time.
[jdv@new-host-2]$ cat test.pl6
use v6.d.PREVIEW;
my %c = (:0reactor_count);
my $s = supply {
whenever IO::Socket::Async.listen('0.0.0.0', 5000) -> $c-conn {
%c{$c-conn}++;
emit $c-conn;
%c{$c-conn} = Supplier.new;
$c-conn.Supply.lines.tap({
%c{$c-conn}.emit: $_ });
}
}
sub start_reactor ($msgs-in) {
start {
react whenever $msgs-in -> $msg-in {
say "before";
say qqx{echo foo};
say "after";
%c++;
}
}
}
start {
react whenever $s -> $c-conn {
start {
start_reactor(%c{$c-conn}.Supply);
}
}
}
sleep 1;
my $c = await IO::Socket::Async.connect('0.0.0.0', 5000);
await $c.print("foo\n");
sleep 1;
exit %c ?? 0 !! 1;
[jdv@new-host-2]$
[jdv@new-host-2]$ git bisect good
80b49320cf854ac68a17cdd216575ee26e380325 is the first bad commit
commit 80b49320cf854ac68a17cdd216575ee26e380325
Author: Jonathan Worthington
Date: Wed Sep 13 16:08:58 2017 +0200
Initial re-implementation of thread pool scheduler
Has separate general and timer queues with separate workers, and
also
introduces affinity queues, which are intended for cases where
events
will be fed into a `Supply`, and thus there's no point having lots
of
threads competing over them only to immediately stumble over each
other. The separate timer queue helps with timer events being
delayed,
for example by a process producing a load of output.
The new implementation also adds a supervisor, which is where we
will
put the smarts on how many threads to have in the pool. For now, it
is
already smart enough to start a lot less threads than the previous
scheduler when they obviously aren't needed, which should help a
good
bit with memory consumption, as well as to add more when needed to
break deadlocks. This area will be further developed in upcoming
commits. The default maximum number of threads has been raised to
64,
now that the behavior of the scheduler is not to innevitably end up
starting the maximum number of threads even when they don't have
any
work to do.
Finally, a new RAKUDO_SCHEDULER_DEBUG environment variable can be
set
to see how many and what kinds of threads are being started.
:04 04 249e0613cf30b283f4fc3cbb0003474377f6019d
3bb01ba4471016067e4b542a2158ee3184cdc85c M src
:04 04 6a4e2506cb269875ff4d40054758a34e24c9024d
6a827bbc76dc09ba2cb3fda55083ebb3074ae552 M tools
[jdv@new-host-2]$
[perl #131515] [BISECTME][PERF] Performance loss in some commits
I'll take a look a bit later. It feels like the commit you mentioned is the right one, which makes me think that we can reject this ticket, but at that pace the spectest will get to turtle speeds even though all our changes will be justified. Anyway, I'll bisect it first and then we'll have a look at what can be done to Make the Spectest Fast Again. On 2017-06-05 14:27:28, c...@zoffix.com wrote: > On Mon, 05 Jun 2017 13:28:00 -0700, elizabeth wrote: > > Generally, we don’t care about performance once we have an > > unrecoverable exception that needs to be reported. If the stresstest > > regression is caused by trying to do Levenstein on method names > > (which > > can be a lot on some objects), then maybe the performance of > > spectest/stresstest can be accounted for by *just* the tests that > > throw Method Not Found errors? > > Yeah, I think the nqp version of the exception is proof that's the > wrong commit, otherwise > it'd've got faster than even pre-commit. > > Something else was the cause, but I ran out of steam hunting it.
[perl #132287] [REGRESSION][CONC] stall/block in async heavy code
RAKUDO_SCHEDULER_DEBUG=1 perl6-gdb-m --ll-exception -e 'while 1 { use
v6.d.PREVIEW; my %c = (:0reactor_count); my $s = supply { whenever
IO::Socket::Async.listen("0.0.0.0", 5000) -> $c-conn { %c{$c-conn}++; emit
$c-conn; %c{$c-conn} = Supplier.new; $c-conn.Supply.lines.tap({
%c{$c-conn}.emit: $_ }); } }; sub start_reactor ($msgs-in) {
start { react whenever $msgs-in -> $msg-in { say "before"; say QX("echo foo");
say "after"; %c++; } } }; start { react whenever $s -> $c-conn {
start { start_reactor(%c{$c-conn}.Supply); } } }; sleep 1; my $c
= await IO::Socket::Async.connect("0.0.0.0", 5000); await $c.print("foo\n");
sleep 1; }'
Eventually prints out (for me):
Unhandled exception in code scheduled on thread 4
Too few positionals passed; expected 6 arguments but got 2
in block at SETTING::src/core/IO/Socket/Async.pm line 151
in block at SETTING::src/core/ThreadPoolScheduler.pm line 225
in block at SETTING::src/core/ThreadPoolScheduler.pm line 224
in method run-one at SETTING::src/core/ThreadPoolScheduler.pm line 224
in method dispatch: at SETTING::src/core/Mu.pm line 732
in block at SETTING::src/core/ThreadPoolScheduler.pm line 258
[perl #132288] [REGRESSION][9999] .tail with large negative arguments (say (4,5,6).tail(-9999999999999999999))
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132288] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132288 > Code: say (4,5,6).tail(-999) ¦«2015.12»: () ¦«2016.06»: () ¦«2016.12»: MoarVM panic: Memory allocation failed; could not allocate 12233720368547758088 bytes «exit code = 1» ¦«2017.06»: Cannot unbox 64 bit wide bigint into native integer in block at /home/bisectable/git/whateverable/data/regressionable/15219088/snippet line 1 «exit code = 1» ¦«f72be0f130cf»: Cannot unbox 64 bit wide bigint into native integer in block at /home/bisectable/git/whateverable/data/regressionable/15219088/snippet line 1 «exit code = 1» Possible IRC discussion: https://irclog.perlgeek.de/perl6-dev/2017-09-26#i_15219088 Output on all releases: https://gist.github.com/e2dcff80e1517153e8a6b8b401c9da46 No useful output from Bisectable. I think that the behavior on 2015.12 is right. It should not throw an exception just because your negative number is slightly larger. So the right output would be “()” no matter how large or small your negative value is.
[perl #132289] [REGRESSION] Lost line number in Proc::Async's “no such file or directory” error
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132289]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132289 >
Code:
my $a = Proc::Async.new(); $a.stdout.tap(-> $a {});
$a.stderr.tap(-> $a {}); if (await $a.start).exitcode { say "oops"} else { say
"ok"}
¦«2015.12»:
no such file or directory
in block at
/home/bisectable/git/whateverable/data/regressionable/15215457/snippet line 1
«exit code = 1»
¦«2016.06»:
no such file or directory
in block at
/home/bisectable/git/whateverable/data/regressionable/15215457/snippet line 1
«exit code = 1»
¦«2016.12»:
===SORRY!===
no such file or directory «exit code = 1»
¦«2017.06»:
Unhandled exception in code scheduled on thread 3
no such file or directory
«exit code = 1»
¦«f72be0f130cf»:
Unhandled exception in code scheduled on thread 4
no such file or directory
«exit code = 1»
Possible IRC discussion: https://irclog.perlgeek.de/perl6/2017-09-26#i_15215457
If we can print “in block at … line 1” then we definitely should. And we
probably can, judging by the output on 2015.12.
[perl #132290] [LTA] .gist of a Method does not always show the its .name (.say for .^methods)
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132290]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132290 >
Code:
say .name, “ – ”, .gist for .^methods
Result:
from-iterator – from-iterator
from-slurpy – from-slurpy
from-slurpy-onearg – from-slurpy-onearg
from-slurpy-flat – from-slurpy-flat
new – new
to – to
from – from
sum – sum
fmt – fmt
BIND-POS – BIND-POS
reification-target – reification-target
iterator – iterator
sink – sink
STORE – STORE
eager – eager
Capture – Capture
FLATTENABLE_LIST – FLATTENABLE_LIST
FLATTENABLE_HASH – FLATTENABLE_HASH
CALL-ME – CALL-ME
pick – pick
roll – roll
reverse – reverse
rotate – rotate
combinations – combinations
permutations – permutations
join – join
push – push
append – append
unshift – unshift
prepend – prepend
shift – shift
pop – pop
item – item
of – of
hyper – hyper
race – race
lazy – lazy
flat – flat
lazy-if – lazy-if
Bool – Bool
Int – Int
end – Method+{}.new
Numeric – Numeric
Str – Str
elems – Method+{}.new
AT-POS – Method+{}.new
EXISTS-POS – Method+{}.new
ACCEPTS – ACCEPTS
list – Method+{}.new
values – Method+{}.new
keys – Method+{}.new
kv – Method+{}.new
pairs – Method+{}.new
antipairs – Method+{}.new
invert – Method+{}.new
gist – gist
perl – perl
List – Method+{}.new
Slip – Method+{}.new
Array – Method+{}.new
Supply – Method+{}.new
is-lazy – is-lazy
sort – Method+{}.new
tail – tail
Bag – Method+{}.new
MixHash – Method+{}.new
Mix – Method+{}.new
Set – Method+{}.new
BagHash – Method+{}.new
SetHash – Method+{}.new
BUILDALL – BUILDALL
I think that “Method+{}.new” is a LTA gist for a method
object.
[perl #132291] [LTA] Too few positionals passed to '' (for [:a] X [:b] -> ($i, $j) { })
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132291]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132291 >
Code:
for [:a] X [:b] -> ($i, $j) { }
Result:
Too few positionals passed to ''; expected 2 arguments but got 0 in
sub-signature
in block at -e line 1
Passed to what?
FWIW this is not a regression. Previously it was saying “Too few positionals
passed; expected 2 arguments but got 0 in sub-signature” which is not any
better.
[perl #132291] [LTA] Too few positionals passed to '' (for [:a] X [:b] -> ($i, $j) { })
Oh, but maybe it's worth mentioning that the name was added in this commit:
https://github.com/rakudo/rakudo/commit/7783fcab24813054902414f30f6fd4fd60823c30
On 2017-10-13 20:13:01, alex.jakime...@gmail.com wrote:
> Code:
> for [:a] X [:b] -> ($i, $j) { }
>
> Result:
> Too few positionals passed to ''; expected 2 arguments but got 0 in
> sub-signature
> in block at -e line 1
>
>
>
> Passed to what?
>
>
> FWIW this is not a regression. Previously it was saying “Too few
> positionals passed; expected 2 arguments but got 0 in sub-signature”
> which is not any better.
[perl #132292] [REGRESSION] Recursively .emit-ing from the tap of the same supply bails out
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132292]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132292 >
Code:
my $s1 = Supplier.new; $s1.Supply.tap: { say $_; $s1.emit(2) if $++ < 5; say
"here" }; $s1.emit(1)
¦2017.06:
1
2
2
2
2
2
here
here
here
here
here
here
¦HEAD(012c80f):
1
here
2
Possible IRC discussion:
https://irclog.perlgeek.de/perl6-dev/2017-09-21#i_15197905
The behavior change two times, first it started hanging after
(2017-09-18)
https://github.com/rakudo/rakudo/commit/4a8038c2956e863bc661a2a00e8371eb98002608
And then the hang was resolved (incorrectly?) in
(2017-09-22)
https://github.com/rakudo/rakudo/commit/547839200a772e26ea164e9d1fd8c9cd4a5c2d9f
I think the output on 2017.06 makes more sense.
[perl #132293] [REGRESSION] It is no longer possible to create native ints with .new (int32.new(42))
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132293] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132293 > Code: say int32.new(42) ¦«2016.10,2016.11,2016.12,2017.01,2017.02,2017.03,2017.04.3,2017.05, 2017.06,2017.07,2017.08,2017.09»: 42 ¦«HEAD(012c80f)»: No such method 'BUILDALLPLAN' for invocant of type 'Perl6::Metamodel::NativeHOW' in block at /tmp/B93UszWrfP line 1 Bisectable points at (2017-09-19) https://github.com/rakudo/rakudo/commit/0834036dd436ac7372c8c0fe2f49511a4f5186dd
[perl #132012] [ANNOYING] Numeric values of signals are wrong (say +SIGUSR1)
There's something regression-ish about it. Code: say $*KERNEL.signal: SIGUSR1 ¦79b8ab9d3f^: 10 ¦79b8ab9d3f: 30 See (2017-06-02) https://github.com/rakudo/rakudo/commit/79b8ab9d3f9a5499e8a7859f34b4499fb352ac13 On 2017-09-01 15:39:42, alex.jakime...@gmail.com wrote: > We now have a note in the docs about this. When fixed, change the docs > accordingly (*maybe* saying that versions before X are known to have a bug). > > https://github.com/perl6/doc/commit/39e3efc08d > > See IRC discussion: https://irclog.perlgeek.de/perl6/2017-09-01#i_15103501 > On 2017-09-01 03:33:34, alex.jakime...@gmail.com wrote: > > Code: > > say +SIGUSR1 > > > > Result: > > 30 > > > > > > However, on my system SIGUSR1 is *not* 30 (it is 10). I guess rakudo > > should try harder to find proper values of the system it runs on. > > > > See this doc issue: https://github.com/perl6/doc/issues/1474
[perl #131966] [REGRESSION][9999] Shaped native arrays with negative sizes (my int @a[-9999999999999999])
Actually, it is a regression. Code: my int @x[-2**63]; say @x.shape ¦«2015.12»: (-9223372036854775808) ¦«2016.06»: Illegal dimension in shape: -9223372036854775808. All dimensions must be integers bigger than 0 in block at /home/bisectable/git/whateverable/data/regressionable/15074816/snippet line 1 «exit code = 1» ¦«2016.12»: (-9223372036854775808) ¦«2017.06»: (-9223372036854775808) ¦«f72be0f130cf»: (-9223372036854775808) Possible IRC discussion: https://irclog.perlgeek.de/perl6-dev/2017-08-26#i_15074816 So it was first fixed in (2016-04-09) https://github.com/rakudo/rakudo/commit/46dca95547949bc3d791efb2620d362a68176fdc and the accidentally broken in (2016-11-24) https://github.com/rakudo/rakudo/commit/1b840f19599027f980fcc54f4b565ef06a1043bc On 2017-08-26 16:43:20, alex.jakime...@gmail.com wrote: > Code: > my int @x[-2**63]; > say +@x > > Result: > -9223372036854775808 > > > See RT #126800 for exactly the same issue with non-native arrays: > https://rt.perl.org/Ticket/Display.html?id=126800
[perl #132294] [REGRESSION][PERF] INTERPOLATE-related change made matching of large strings slower
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132294] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132294 > Code: my $a = rx/aab/; 'a' x 99 ~ 'b' ~~ /$a/; say now - INIT now ¦«2015.12»: 5.21453528 ¦«2016.06»: 2.98116495 ¦«2016.12»: 4.7695178 ¦«2017.06»: 4.2054743 ¦«f72be0f130cf»: 3.93059297 Possible IRC discussion: https://irclog.perlgeek.de/perl6-dev/2017-08-24#i_15066525 The time swings back and forth but there's a clear regression (from <3 seconds to >4). Bisectable points at (2016-09-14) https://github.com/rakudo/rakudo/commit/c3b044df16957057ff2d64297f3bcdbdbad622a1
