[perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

2017-10-12 Thread via RT 
# 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.

[perl #132282] [REGRESSION] Weird “Cannot find method 'gist'” problem

2017-10-12 Thread via RT 
# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #132282]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132282 >


Code:
-> (Str() $a, Str() :$b) { say [$a, $b] }('abc'.match(/(.) $=. ./))

¦«2015.12»:
[a b]

¦«2016.06»:
[a b]

¦«2016.12»:
[a b]

¦«2017.06»:
Cannot find method 'gist': no method cache and no .^find_method
  in block  at 
/home/bisectable/git/whateverable/data/regressionable/15277191/snippet line 1
 «exit code = 1»

¦«HEAD»:
Cannot find method 'gist': no method cache and no .^find_method
  in block  at 
/home/bisectable/git/whateverable/data/regressionable/15277191/snippet line 1
 «exit code = 1»


Possible IRC discussion: 
https://irclog.perlgeek.de/perl6-dev/2017-10-09#i_15277191

This was caused by “uncurse” branch merge: 
https://gist.github.com/e908b4fcec227d6a66abd509c150c414

I'm just the messenger, I don't know what's going on in that code and if it 
should work at all. But the error message does not feel right at all.

[perl #132281] [REGRESSION] .gist of a bag used to say “bag()”, now it says “Bag()” ("blogger".comb.Bag)

2017-10-12 Thread via RT 
# 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.

[perl #132280] [REGRESSION][PERF] Cool methods that take and pass a Capture are uber slower (.contains: 'meow' for ^10000_00)

2017-10-12 Thread via RT 
# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #132280]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132280 >


Code:
.contains: 'meow' for ^1_00; say now - INIT now

¦«2015.12»:
1.51822016

¦«2016.06»:
1.354473

¦«2016.12»:
1.8226411

¦«2017.06»:
«timed out after 10 seconds» «exit signal = SIGHUP (1)»

¦«f72be0f130cf»:
«timed out after 10 seconds» «exit signal = SIGHUP (1)»


Possible IRC discussion: 
https://irclog.perlgeek.de/perl6-dev/2017-10-09#i_15278959


Bisectable points at 
https://github.com/rakudo/rakudo/commit/8c88b0cc62ee25000603a920002d2060bdb9f5a1

[perl #132262] [BUG] Quote braid misses Main braid's language change due to new ops

2017-10-12 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
This is actually a regression.

Code:
$ = ""; sub postfix:<♥> { $^a + 42}; say "{ 5♥ }"

¦«2015.12»:
47

¦«2016.06»:
47

¦«2016.12»:
47

¦«2017.06»:
===SORRY!=== Error while compiling
/home/bisectable/git/whateverable/data/regressionable/15285677/snippet
Bogus postfix
at /home/bisectable/git/whateverable/data/regressionable/15285677/snippet:1
--> "; sub postfix:<♥> { $^a + 42}; say "{ 5⏏♥ }"
expecting any of:
infix
infix stopper
statement end
statement modifier
statement modifier loop «exit code = 1»

¦«HEAD»:
===SORRY!=== Error while compiling
/home/bisectable/git/whateverable/data/regressionable/15285677/snippet
Bogus postfix
at /home/bisectable/git/whateverable/data/regressionable/15285677/snippet:1
--> "; sub postfix:<♥> { $^a + 42}; say "{ 5⏏♥ }"
expecting any of:
infix
infix stopper
statement end
statement modifier
statement modifier loop «exit code = 1»


Possible IRC discussion:
https://irclog.perlgeek.de/perl6-dev/2017-10-10#i_15285677

Bisectable points at 25 possible candidates:
https://gist.github.com/Whateverable/1510af516a727e3d09d1e19b39123f0e

There's some stuff about braids in these commits so maybe some inspiration can
be taken from there.

On 2017-10-10 11:30:50, c...@zoffix.com wrote:
> If you enter the Quote braid, then define a new op, and then try to
> use it in a block within quotes, it fails to find the routine:
>
> 18:29 m: ""; sub postfix:($) {}; "{ 5! }";
> 18:29 camelia rakudo-moar e13512: OUTPUT: «5===SORRY!5===
> Error while compiling ␤Negation metaoperator not followed by
> valid infix␤at :1␤--> 3""; sub postfix:($) {}; "{ 5!7⏏5
> }";␤ expecting any of:␤ infix␤ infix stopper␤»
>
> But if you move the first quotes past the sub, then it works:
>
> 18:29 Zoffix m: sub postfix:($) {}; ""; "{ 5! }";
> 18:29 camelia rakudo-moar e13512: OUTPUT: «WARNINGS for
> :␤Useless use of constant string "" in sink context (line 1)␤Use
> of Nil in string context␤ in block  at  line 1␤»
>
> IRC: https://irclog.perlgeek.de/perl6/2017-10-10#i_15284813

[perl #132279] [REGRESSION][9999] BagHash.grab with huge values (("foo" => 10000000000000000000).BagHash.grab(1))

2017-10-12 Thread via RT 
# 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

[perl #132104] [JVM] EvalServer seems to leak memory

2017-10-12 Thread Christian Bartolomaeus via RT 
On Sat, 23 Sep 2017 12:28:53 -0700, barto...@gmx.de wrote:
> 3) Feeding the EvalServer with a program that calls 'run' (or
> Proc::Async directly) does heavily leak memory, threads and what not
> (again assuming a clean EvalServer instance started as above):
> 
> $ echo 'run("echo", "42");' > foo.p6
> $ for i in {1..500}; do ./eval-client.pl TESTTOKEN run foo.p6; done

I'm still trying to find the cause of the memory leak. Part of the problem 
seems to be that with each invokation of './eval-client.pl TESTTOKEN run 
foo.p6' three or four additional threads are started. Those threads are never 
stopped.

Some debug statements in src/core/ThreadPoolScheduler.pm indicate that with 
each invokation (s.a.) a new AffinityWorker instance and a new GeneralWorker 
instance are created (and at least one other thread). I guess those newly 
started Threads stay around until the EvalServer is killed.

[perl #131763] [ANNOYING] Merged output of Proc::Async does not work (whenever $proc { … })

2017-10-12 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
Alright! This was fixed.

Bisectable points at the merge of “better-sched” branch, which happen right
after 2017.09 release. See
https://github.com/rakudo/rakudo/commit/61a77e60a7d936415503d8916fcc7546569e9135

Zoffix++ found some tests:
https://github.com/perl6/roast/commit/ae3eea8a8b43d9c6b1be6b0f825f696df346a457

However, these tests are not enough to resolve this ticket. We'd need a stress
test that does it in a loop several times, just like it is described in the OP.

In any case, this is no longer ANNOYING and is simply TESTNEEDED.

On 2017-07-17 21:34:25, alex.jakime...@gmail.com wrote:
> Code:
>
> sub get-output() {
> my $proc = Proc::Async.new: ‘echo’, ‘test’;
> react {
> #whenever $proc.stdout { } # ←↙ these work
> #whenever $proc.stderr { } #
> whenever $proc { } # ← this doesn't
> whenever $proc.start { }
> }
> say $++;
> }
>
> loop { get-output }
>
>
>
>
> The result depends on your luck. Sometimes it gets stuck on the second
> execution, sometimes it manages to do it over 20 times and then gets
> stuck.
>
> According to this it is supposed to work:
> https://irclog.perlgeek.de/perl6-dev/2017-07-12#i_14862898
>
> I don't know if there's any trap I'm getting into, or if it's just a
> bug. Anyway, I hope a ticket won't hurt.

Re: [perl #132268] Floating point anomalies

2017-10-12 Thread Brandon Allbery via RT 
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, so we get:
>
> $ perl6 -e 'say 1.001e0;'
> 1
>
> $ perl -E 'say 1.001e0;'
> 1
>
> On perl5 we can get to see a more accurate rendition of the base 10 value
>

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.

-- 
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

2017-10-12 Thread Brandon Allbery 
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, so we get:
>
> $ perl6 -e 'say 1.001e0;'
> 1
>
> $ perl -E 'say 1.001e0;'
> 1
>
> On perl5 we can get to see a more accurate rendition of the base 10 value
>

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.

-- 
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

2017-10-12 Thread sisyphus1 
-Original Message- 
From: Zoffix Znet via RT

Sent: Wednesday, October 11, 2017 11:09 PM
To: sisyph...@optusnet.com.au
Subject: [perl #132268] Floating point anomalies


What you describe looks to be similar to the other issue I have in my
private bug stash:

   say  .1e0  +  .2e0  ==  .3e0;  # False
   say 1.0e-1 + 2.0e-1 == 3.0e-1; # True;

And a brief look into guts suggests it's to do with the way our Nums are
constructed during parsing. I was able to repro the issue with the C
version of what we do in our Grammar: https://glot.io/snippets/eufyogt02g


Yes, the anomaly with those particular values lies in the assignment of .3e0
versus the assignment of 3.0e-1.
Looks like it's the difference between calculating 3 * 0.1 and 30 * 0.01:

$ perl -le 'print scalar reverse unpack "h*", pack "d<", 3 * 0.1;'
3fd4

$ perl -le 'print scalar reverse unpack "h*", pack "d<", 30 * 0.01;'
3fd3

At least, the calculation of 3.0e-1 produces produces the first value (which
is overstated by one ULP), and the calculation of 0.3e0 produces the second
(which is correct).



So yeah, the plan is to eventually address these.


That's good news.


If you spot any more inconsistencies and weirdness, please report them.


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, so we get:

$ perl6 -e 'say 1.001e0;'
1

$ perl -E 'say 1.001e0;'
1

On perl5 we can get to see a more accurate rendition of the base 10 value
using printf():

$ perl -e 'printf "%.16e\n", 1.001e0;'
1.0011e+000

But that doesn't work on perl6:

$ perl6 -e 'printf "%.16e\n", 1.001e0;'
1.e+00

Is there something amiss here ?

Cheers,
Rob

[perl #132275] a Promise using a `temp`ed variable gets untemped version

2017-10-12 Thread Zoffix Znet via RT 
Notabug: https://irclog.perlgeek.de/perl6-dev/2017-10-12#i_15293653

12:50   jnthn   start blocks don't make a complete clone of the dynamic scope, 
so they'll see any mutations in it
12:50   They just have a reference to the context they were invoked in

[perl #132275] a Promise using a `temp`ed variable gets untemped version

2017-10-12 Thread Zoffix Znet via RT 
Notabug: https://irclog.perlgeek.de/perl6-dev/2017-10-12#i_15293653

12:50   jnthn   start blocks don't make a complete clone of the dynamic scope, 
so they'll see any mutations in it
12:50   They just have a reference to the context they were invoked in

[perl #132275] a Promise using a `temp`ed variable gets untemped version

2017-10-12 Thread via RT 
# New Ticket Created by  Zoffix Znet 
# Please include the string:  [perl #132275]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132275 >


If you `temp` a variable and access it from within a Promise at a time AFTER 
the flow
left the block, you'll get the untempted version:

m: my $x = 42; { my $x = 70; start { sleep 1; say $x; } }; sleep 2
rakudo-moar 4b8a0e: OUTPUT: «70␤»
m: my $x = 42; { temp $x = 70; start { sleep 1; say $x; } }; sleep 2
rakudo-moar 4b8a0e: OUTPUT: «42␤»
m: my $x = 42; { temp $x = 70; start { say $x; }; sleep 1 }; sleep 2
rakudo-moar 4b8a0e: OUTPUT: «70␤»

This sorta makes sense if you squint, but makes `temp` somewhat less useful. 
Was wondering if there's a way to make this Just Work and for the Promise to 
output the temped value (so all cases above would output `70`)

IRC: https://irclog.perlgeek.de/perl6-dev/2017-10-12#i_15293619