[perl #128860] [LTA] [@LARRY] List.invert only works if the list contains Pairs but the error message isn't very clear about that fact

[Larry Wall via RT]

Binding of the map routine internally now requires list elements to bind as 
Pair, which improves the error message.

(The alternate approach of inserting a CATCH into the map closure could in 
theory produce an even better message, but it appeared to slow things down more 
than the Pair binding approach.)

Note that we cannot make the degenerate case of .invert the same as .antipairs, 
because .invert must expand list values into multiple antipairs. In any case, 
.antipairs is 5-10 times faster since it doesn't have to check for such 
expansion.

Fix in baeabb4c4e8f5d223da8632130b4dfcd020d40ba

Test in 63c1f009b910a5c87186b2201383682ad7a0f724

[perl #128915] [BUG] multi-dim Hash turnes items into List

[via RT]

# New Ticket Created by  Wenzel Peppmeyer 
# Please include the string:  [perl #128915]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128915 >


my %multi-dim;
%multi-dim{1;2;3} = 42;
dd %multi-dim{1;2;3}
# OUTPUT«(42,)␤»

# expected:
OUTPUT«42␤»

[perl #123072] [GLR] 'for' loop in sink context isn't invoking block in sink context

[Larry Wall via RT]

Some method calls were not properly sunk as a final statement in a loop.

Fix in 977797fa401856e5310155f13469b7e6ff5f620a

Test in bc8fa4fd8d449573eb6001b5f43f8890f65b9196

Re: [perl #128818] [BUG] sprintf %f bogus rounding

[Zefram]

Attached is a straightforward implementation of the floating-point
printf conversions.  I believe it to be correct.  In addition to the
decimal %e, %f, and %g, I did the rather useful hexadecimal %a, thus
far entirely missing from Rakudo's sprintf.

I needed some supporting floating-point utilities, for which I translated
most of my Perl 5 module Data::Float (including some parts not actually
used by the formatting code).  Many of these constants and functions
really ought to be made available in Rakudo in some form, particularly the
IEEE 754r standard functions such as nextafter().  All of them would gain
a lot of performance from a C-level implementation that knows the exact
layout of the floating-point type; the code here is clunky but portable.

An observation: testing floating-point code is substantially impeded by
not having reliable means of inputting and outputting floating-point
values.  In this case, working on output code, I was impeded by
some problems with Rakudo's decimal->float conversions on input,
hence the handful of recent bug reports from me on that subject.
(This work also produced a slew of bug reports about Perl 5's printf
%a.)  In investigating and reporting those bugs I was impeded by
the lack of good floating-point output facilities in Rakudo, hence
the less-than-obvious ways of examining Num values in those reports.
Input and output facilities support each other.

A consequent suggestion: rather than working on decimal floating-point
I/O straight away, as a matter of priority you should add hexadecimal
floating-point input and output.  Currently you have no hex output,
and only some unadvertised and limited input (no exponent handling)
in Str.Num.  The hex is much easier to get right than the decimal,
because the radices are commensurable.  Once hex I/O is available, it's
good for all kinds of debugging purposes, for injecting test values and
examining results.  Having straightforward and reliable I/O makes all
other floating-point issues much easier to approach.  Hex would also be
an easier way to solve [perl #128819] than anything relying on decimal.

-zefram
# writable scalar references

my sub ref_to(Mu $a is rw) { my @s; @s[0] := $a; @s }
my sub read_ref(@s) { @s[0] }
my sub write_ref(@s, Mu $nv) { @s[0] = $nv }

# floating-point utilities (imitating most of Perl 5 Data::Float)

my @powtwo = (2e0,);
my @powhalf = (0.5e0,);

sub mult_pow2(Num:D $value is copy, Int:D $exp is copy) {
my @powa := @powtwo;
if $exp < 0 {
@powa := @powhalf;
$exp = -$exp;
}
loop (my $i = 0; $i != @powa.end && $exp != 0; $i++) {
$value *= @powa[$i] if $exp +& 1;
$exp +>= 1;
}
for ^$exp { $value *= @powa[*-1]; }
return $value;
}

my $min_finite_exp;
my $max_finite_exp;
my $max_finite_pow2;
my $min_finite;

my @directions = (
{
expsign => -1,
powa => @powhalf,
xexp => ref_to($min_finite_exp),
xpower => ref_to($min_finite),
},
{
expsign => +1,
powa => @powtwo,
xexp => ref_to($max_finite_exp),
xpower => ref_to($max_finite_pow2),
},
);

while !@directions[0] || !@directions[1] {
for @directions -> $direction {
next if $direction;
my $lastpow = $direction[*-1];
my $nextpow = $lastpow * $lastpow;
unless mult_pow2($nextpow, -$direction *
(1 +< $direction.end)) == $lastpow {
$direction = True;
next;
}
$direction.push: $nextpow;
}
}

for @directions -> $direction {
my $expsign = $direction;
my $xexp = 1 +< $direction.end;
my $extremum = $direction[*-1];
loop (my $addexp = $xexp; $addexp +>= 1; ) {
my $nx = mult_pow2($extremum, $expsign * $addexp);
if mult_pow2($nx, -$expsign * $addexp) == $extremum {
$xexp += $addexp;
$extremum = $nx;
}
}
write_ref($direction, $expsign * $xexp);
write_ref($direction, $extremum);
}

sub pow2(Int:D $exp where $exp >= $min_finite_exp && $exp <= $max_finite_exp) {
mult_pow2(1e0, $exp)
}

my $significand_bits;
my $significand_step;
{
my $i;
loop ($i = 1; ; $i++) {
my $tryeps = @powhalf[$i];
last unless (1e0 + $tryeps) - 1e0 == $tryeps;
}
$i--;
$significand_bits = 1 +< $i;
$significand_step = @powhalf[$i];
while $i-- {
my $tryeps = $significand_step * @powhalf[$i];
if (1e0 + $tryeps) - 1e0 == $tryeps {
$significand_bits += 1 +< $i;
$significand_step = $tryeps;
}
}
}

my 

Re: [perl #128903] [BUG] SetHash::push not implemented

[Elizabeth Mattijsen]

Will look at this as part of a Set/SetHash overhaul

> On 12 Aug 2016, at 05:19, Wenzel Peppmeyer (via RT) 
>  wrote:
> 
> # New Ticket Created by  Wenzel Peppmeyer 
> # Please include the string:  [perl #128903]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128903 >
> 
> 
> my SetHash $sh .= new; $sh.push('a');
> 
> # OUTPUT:
> # OUTPUT«Cannot resolve caller push(SetHash: Str); none of these signatures 
> match:␤ (Any:U \SELF: |values is raw)␤  in blockline 1␤»
> 
> # Any::push tries to call SetHash::push and fails because there is no such
> # method.

Re: [perl #128595] [LTA] -M with non-existant module breaks 'exit' in REPL

[Elizabeth Mattijsen]

Hmmm… the todo’d test for this now passes, but the problem still exists (apart 
from the hanging).  So I guess this is a Test Needs To Be Adapted case.

> On 10 Jul 2016, at 22:58, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #128595]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128595 >
> 
> 
> If -M includes a module that can't be found, the output is quite LTA. Not 
> only is the module message spammed on each output, but trying to exit by 
> typing `exit` fails (pressing ^D works).
> 
> A suggestion is to abort REPL startup if -M-included modules cannot be found.
> 
> zoffix@VirtualBox:~$ perl6 -MFoo
> Couldn't load Rakudo REPL.pm: Could not find Foo at line 1 in:
>/home/zoffix/.perl6
>/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/site
>/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/vendor
>/home/zoffix/.rakudobrew/moar-nom/install/share/perl6
>CompUnit::Repository::AbsolutePath<76770752>
>CompUnit::Repository::NQP<68716568>
>CompUnit::Repository::Perl5<68716608>
> Falling back to nqp REPL.
>> exit
> Could not find Foo at line 1 in:
>/home/zoffix/.perl6
>/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/site
>/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/vendor
>/home/zoffix/.rakudobrew/moar-nom/install/share/perl6
>CompUnit::Repository::AbsolutePath<76770752>
>CompUnit::Repository::NQP<68716568>
>CompUnit::Repository::Perl5<68716608>
>  in any load_module at src/Perl6/World.nqp line 1190
>  in any do_pragma_or_load_module at src/Perl6/World.nqp line 1120
>  in any loading_and_symbol_setup at src/Perl6/World.nqp line 610
>  in any comp_unit at src/Perl6/Grammar.nqp line 1157
>  in any TOP at src/Perl6/Grammar.nqp line 460
> 
>> 

Re: [perl #128900] [LHF] Make ^C in REPL abort the current line, if one is running

[Elizabeth Mattijsen]

Fixed with be7ce04 , tests needed


Turns out this was slightly more involved than just setting up a CATCH block, 
as the CATCH block will only be seen either in the executing thread, or in the 
.tap block of the signal handler.

So in the end, I decided to always start the code in a separate thread with 
“start”, and let another Promise be reset by ^C, and then wait for either 
promise to be kept.

> On 11 Aug 2016, at 20:35, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #128900]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128900 >
> 
> 
> If you start the REPL and then run:
> 
> sleep 5
> 
> Or any other long running command, it'll "hang" for a long time. If you 
> attempt to press Control+C to abort that line, you end up exiting REPL.
> 
> When ^C is pressed while a line in REPL is running, it should abort that 
> line, instead of exiting. And the current behaviour is to be maintained in 
> that pressing ^C when nothing is running exitings the REPL.
> 
> Relevant IRC conversation: 
> http://irclog.perlgeek.de/perl6/2016-08-11#i_13007834
> 
> Specifically:
> [lizmat]: fwiw, I think it should be pretty trivial to catch SIGINT in a 
> signal handler, then die("SIGINTED") in there, and then let the CATCH handler 
> cleanup

[perl #128904] [BUG] - Comparing Shaped Arrays

[via RT]

# New Ticket Created by  djgoku 
# Please include the string:  [perl #128904]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128904 >


I wanted to do (IRC Log of #perl6: 
http://irclog.perlgeek.de/perl6/2016-08-12#i_13009688 
):

my @a[2;2] = ([1, 2], [3,4]);
my @b[2;2] = ([1, 2], [3,4]);

@a ~~ @b; # I get this error: Partially dimensioned views of arrays not yet 
implemented. Sorry.

Though this works:

# start http://irclog.perlgeek.de/perl6/2016-08-12#i_13009865 


say [[1,2],[3,4]] ~~ [[1,2],[3,4]]; 

also:

say [[1,2],[3,4]] env [[1,2],[3,4]];

# end http://irclog.perlgeek.de/perl6/2016-08-12#i_13009865

Jonathan Otsuka

[perl #128914] [BUG] decimal->float conversion differs for literals and Str.Num

[via RT]

# New Ticket Created by  Zefram 
# Please include the string:  [perl #128914]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128914 >


> "9.998e0".EVAL - "9.998e0".Num
1.77635683940025e-15

Observe that the same string yields different Num values when interpreted
as a Num literal and when coerced.  Where the string is meaningful both
ways, this is a bug.  Obviously there are some situations where the
syntax of Perl 6 literals doesn't exactly match what one would expect of
a Str.Num conversion, but that's not the case here.  Where the syntax
matches, as it does in this case, or more generally where the same
digits are presented with the same weights, one would expect the core
decimal->float conversion to behave the same for both.

The conversions yielding different values implies that at least one
of them is individually incorrect.  In this case, the coercion yields
the correctly-rounded value, and the literal is getting it wrong.
[perl #128912] is concerned with these conversions being incorrect per se,
and my test case there used the conversion for literals.  The difference
between the two forms of decimal->float conversion is not merely a matter
of literals getting it wrong and coercion getting it right: there are also
cases where the coercion gets it wrong.  In fact, coercion gets it wrong
in the [perl #128912] test case: both literal interpretation and coercion
get "9.999e-5" wrong in the same way.  I have not yet encountered a case
where literal interpretation gets it right and coercion gets it wrong,
but nor can I say that there isn't such a case.

-zefram

[perl #128913] [BUG] decimal->float non-monotonic conversion

[via RT]

# New Ticket Created by  Zefram 
# Please include the string:  [perl #128913]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128913 >


> "9.9981e0".EVAL < "9.998e0".EVAL
True

Observe that the literal with a greater nominal value yields a lower
Num value.  (The .EVAL circumlocution is required to work around [perl
#128820].)  This implies that at least one of the literals is getting
incorrect rounding, which was the subject of [perl #128912].  (In fact
the greater one is getting correct rounding and the lower one is not.
The correct roundings of both are the same.)  But this case goes beyond
the rounding merely being incorrect; with this behaviour the rounding
isn't even self-consistent.

-zefram

[perl #128912] [BUG] decimal->float bad rounding

[via RT]

# New Ticket Created by  Zefram 
# Please include the string:  [perl #128912]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128912 >


> (9.999e-5 * 2e0**66).Int * 5**8 -  * 2**58
287369
> (9.99895e-5 * 2e0**66).Int * 5**8 -  * 2**58
-103256

The above computations show, scaled up, the difference between a Num value
and the exact value 9.999e-5.  As you can see, the Num that arose from
the "9.99895e-5" literal was slightly closer than the Num
that arose from the "9.999e-5" literal.  The closer of these two is in
fact the closest representable IEEE double precision value to 9.999e-5.
Thus this literal "9.999e-5" has not yielded the closest available Num
to its nominal value; this is a bug.  glibc's strtod() handles this case
fine, yielding the closer value.

Note that the only rounding occurring in this test case is on the
decimal->float conversion.  The multiplication by a power of two,
conversion of integer-valued float to Int, and all the Int arithmetic,
are all exact.

-zefram

Re: [perl #128900] [LHF] Make ^C in REPL abort the current line, if one is running

[Elizabeth Mattijsen]

Working on this now

> On 11 Aug 2016, at 20:35, Zoffix Znet (via RT)  
> wrote:
> 
> # New Ticket Created by  Zoffix Znet 
> # Please include the string:  [perl #128900]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=128900 >
> 
> 
> If you start the REPL and then run:
> 
> sleep 5
> 
> Or any other long running command, it'll "hang" for a long time. If you 
> attempt to press Control+C to abort that line, you end up exiting REPL.
> 
> When ^C is pressed while a line in REPL is running, it should abort that 
> line, instead of exiting. And the current behaviour is to be maintained in 
> that pressing ^C when nothing is running exitings the REPL.
> 
> Relevant IRC conversation: 
> http://irclog.perlgeek.de/perl6/2016-08-11#i_13007834
> 
> Specifically:
> [lizmat]: fwiw, I think it should be pretty trivial to catch SIGINT in a 
> signal handler, then die("SIGINTED") in there, and then let the CATCH handler 
> cleanup

[perl #128906] [BUG] Supply .throttle hangs/wrong results

[via RT]

# New Ticket Created by  刘刊 
# Please include the string:  [perl #128906]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128906 >


As shown below, of the 3 consecutive times the following code was run, 2 hung.
the results produced didn't make sense either, unless I misunderstood how 
throttle should work.

8< === 8<

use v6;

my $s = Supply.from-list(^6);
my $t = $s.throttle: 3, { sleep 3; $_ };

$t.act: -> $v { $v.result.say };
$t.wait

8< === 8<

liukan@candor:~/Code$ time perl6 foo
0
1
2
3
4
5
0

real0m6.188s
user0m0.160s
sys0m0.036s
liukan@candor:~/Code$ time perl6 foo
0
1
2
3
4
5
1
^C

real0m33.380s
user0m0.128s
sys0m0.012s
liukan@candor:~/Code$ time perl6 foo
2
0
3
4
5
0
^C

real0m33.155s
user0m0.128s
sys0m0.032s
liukan@candor:~/Code$

liukan@candor:~/Code$ perl6 -v
This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
implementing Perl 6.c.

liukan@candor:~/Code$ uname -a
Linux candor 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux