[perl #126976] [SEGV] on "/".IO.mkdir

[Zoffix Znet via RT]

> Ticket should be closable once a test has been added to Roast.

Is it really appropriate to attempt to create such directories? I'm hesitant to 
have roast touch things outside of its directory.

[perl #128453] [BUG] t\spec\S10-packages\precompilation.rakudo.moar fails on Windows

[Zoffix Znet via RT]

Are you able to create those files manually? (e.g. 
C:\Users\sinan\AppData\Local\Temp\rakudo\tempfile-spurt-test)

[perl #127795] [BUG] "is" subroutine couldn't handle Set-valued Hash correctly in the specific case.

[Zoffix Znet via RT]

The `is` sub uses `eq` operator for comparison, which coerces items to Str. 

So this ticket comes down to whether or not .Str on sets should sort their 
elements. The problem with that is sets can contain different types of objects. 
You could further put the argument that .Strs (or .gists) of those objects 
should be used and sorted, but that still leaves the issue of two differing 
sets producing the same .Str result:

$ 6 'class Bar { method gist { "Foo" } }; say set Bar; say set "Foo"'
set(Foo)
set(Foo)

Thus, I'm closing this ticket, as it appears `is` sub is simply not an 
appropriate way to compare two sets.

[perl #128469] [BUG] sometimes done() does not work and the program freezes

[Zoffix Znet via RT]

Did a bit more experimenting, it seems to freeze only SOME of the time:

zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: 1 { say "Run 
$_"; done } }'
Run 0
^C
zoffix@VirtualBox:~$ perl6 -v
This is Rakudo version 2016.06-154-g55c359e built on MoarVM version 
2016.06-9-g8fc21d5
implementing Perl 6.c.
zoffix@VirtualBox:~$ 


But doesn't ever freeze if done is called non-first run, even if I set a tiny 
delay between intervals:

zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: .01 { say "Run 
$_"; done if $_ >= 1 } }'
Run 0
Run 1
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: .01 { say "Run 
$_"; done if $_ >= 1 } }'
Run 0
Run 1
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: .01 { say "Run 
$_"; done if $_ >= 1 } }'
Run 0
Run 1
zoffix@VirtualBox:~$ perl6 -e 'react { whenever Supply.interval: .01 { say "Run 
$_"; done if $_ >= 1 } }'
Run 0
Run 1

[perl #128469] [BUG] sometimes done() does not work and the program freezes

[Zoffix Znet via RT]

🏁

Skip-fudge added in https://github.com/perl6/roast/commit/a047d78ac9

🏁

[perl #127879] [BUG] map subroutine ignores the sequence in the specific case

[Zoffix Znet via RT]

I'm going to close this, since the original report was ruled as not a bug.

The lazines of such constructs has now also been documented in Traps.

-- 
Cheers,
ZZ | https://twitter.com/zoffix

[perl #127879] [BUG] map subroutine ignores the sequence in the specific case

[Zoffix Znet via RT]

Re-opening per TimToady's comments: 
http://irclog.perlgeek.de/perl6/2016-07-21#i_12881470

The map de-lazifies when sunk, but in this case the for's sinking doesn't seem 
to propagate to the map.

This, for example, prints all the values:

m: for ^3 { ^10 .map: *.say; Nil }; say 42;

-- 
Cheers,
ZZ | https://twitter.com/zoffix

[perl #129131] [RFC] Make .. a numeric operator, please (.say for ‘42’..‘51’)

[Zoffix Znet via RT]

On Tue Aug 30 11:46:53 2016, sml...@gmail.com wrote:
> The trap comes from the fact that `..` and `...` with a Str endpoint
> *don't* use .succ/.pred:
> 
> "35".."40"  # does something weird (and IMO useless) that is different
> from .succ

Agreed, that's weird. I'm unsure why it's counting down and is indeed "too 
smart" for what I'd expect it to do.


On Tue Aug 30 14:06:21 2016, alex.jakime...@gmail.com wrote:
> Um… since when we started to blame users for not using type
> constraints? I
> mean, wasn't it supposed to be optional? The language should not do
> stupid
> things if I decided not to use type constraints, and sure enough it
> does not do
> stupid things when it comes to all other operators, except .. and ...

It doesn't do "stupid things" with the .. operator either. I refrained from 
mentioning it earlier, but I think it would result in a more productive 
conversation if you did not assume the current behaviour was created by a 
boiled potato randomly bouncing up and down on a keyboard, calling it a "WAT" 
and a "stupid thing." The current behaviour is at least in part useful. If you 
think different behaviour is more understandable and more useful, you can 
justify it without demeaning the work that went into implementing the current 
behaviour.

Types are there to catch type bugs, which is what the original user experienced 
by expecting a string to be operated on the same as a number contained within 
it. If you want to avoid types, you pay the price in uncaught type bugs. I'm 
not above "blaming users" for being burnt because they failed to user a 
language feature.

> I mean, am I reading it wrong or something? It tells me that it is
> using .succ

I agree, the documentation can expound the templating behaviour on ranges with 
strings. I tried looking at speculations and they too appear to be sparse on 
the behaviours in strings with more than one character.

> We can schedule it for 9.d or whatever. I don't see why changing the
> behavior
> of something that is of questionable usefulness should be such a big
> NO. Let's
> fix the language instead.

So far, three core developers [^1][^2] think there's nothing to fix. My 
personal view is that it doesn't matter if it's a 9.d or a 42.d; breaking 
backwards compatibility should come with benefits, and I see none with this RFC.

[1] http://irclog.perlgeek.de/perl6-dev/2016-08-30#i_13118518
[2] http://irclog.perlgeek.de/perl6-dev/2016-08-30#i_13118542


> > to limit usefulness of ..
> 
> That's a good remark! Has anybody seen this stringy behavior being
> used
> somewhere in the wild? You know, maybe I'm proposing a removal of some
> extremely useful feature. I'd love to see some real world examples
> (something
> we should be able to have by now, I guess?).

I already pointed out the templating behaviour to obtain non-clobbering 
filenames. It's useful when creating unique files based on user file uploads. 
The templates can also be used to evaluate if a given value fits a template. Is 
that not "real world" enough?

> 
> > • Addition of 4 extra operators that very poorly represent the
> > behaviour they are meant to perform.
> 
> I agree with Sam. Let's just throw it away.

So what would provide the .succ behaviour for objects if the RFC, as I 
understand it now, aims to abolish the .succ behaviour entirely.

> 
> > Introduced inconsistency between .. and …
> 
> Here you are completely right. If we are fixing ｢..｣, then ｢...｣
> should be
> fixed as well. I didn't mention it in my first message, but please
> don't think
> that I'm saying that we should introduce inconsistencies.

Fixed how? So far you mentioned the strings do "stupid things" and I see Sam 
mentioning that we don't want the coersion to Numeric. So what *is* the 
proposed behaviour? The question applies to numerics, strings, custom objects, 
WhateverCodes, and Subs.



So far I think the original RFC to make .. a numeric operator is out. There's 
still an issue with .. not using .succ on strings. Does anyone know why that is 
the case? The templating example I presented is still valid with the pure .succ 
behaviour.

[perl #129120] [CONC] in await: Cannot invoke this object (REPR: Null; VMNull)

[Zoffix Znet via RT]

Attached 'backtrace-original.txt' is the output from the added CATCH and 
--ll-exception.

I was able to golf it down to this:

  await do for 3¹²³⁴⁵ … 3¹²³⁴⁵+127 -> $num {
  start $num.is-prime ?? "$num is prime" !! "$num is not prime";;
  }
  CATCH { .backtrace.full.say }

And that backtrace is also attached (backtrace-golfed.txt).

I tried replacing .is-prime with a bcrypt hashing, but was unable to produce 
the crash in about 8 runs:

  use Crypt::Bcrypt;
  await do for 3¹²³⁴⁵ … 3¹²³⁴⁵+127 -> $num {
  start bcrypt-hash ~$num, :15rounds;
  }
  CATCH { .backtrace.full.say }

So then I went back to my golfed version and removed the ternary operator... 
Couldn't reproduce anything in about 10 runs. Added a ternary as `?? 1 !! 2`, 
still couldn't reproduce anything, Changed the ternary to this:

  await do for 3¹²³⁴⁵ … 3¹²³⁴⁵+127 -> $num {
  start $num.is-prime ?? "$num is this" !! "$num is that";
  }
  CATCH { .backtrace.full.say }

... and it crashed the first time I ran it (backtrace-changed-ternary.txt 
attached) and then 1 more time in the next out of 7 runs.

It may of course be just a coincidence, but these are my results
  in method throw at gen/moar/m-CORE.setting line 24125
  in method result at gen/moar/m-CORE.setting line 35512
  in sub await at gen/moar/m-CORE.setting line 37569
  in block  at gen/moar/m-CORE.setting line 37568
  in block  at gen/moar/m-CORE.setting line 4845
  in method sink-all at gen/moar/m-CORE.setting line 4831
  in method sink at gen/moar/m-CORE.setting line 14540
  in block  at test.p6 line 1

Cannot invoke this object (REPR: Null; VMNull)
   at gen/moar/m-CORE.setting:24125  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:throw)
 from gen/moar/m-CORE.setting:35512  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:result)
 from gen/moar/m-CORE.setting:37569  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:await)
 from gen/moar/m-CORE.setting:37568  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:)
 from gen/moar/m-CORE.setting:4845  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:)
 from gen/moar/m-CORE.setting:4831  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:sink-all)
 from gen/moar/m-CORE.setting:14540  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:sink)
 from test.p6:1  (:)
 from test.p6:1  (:)
 from gen/moar/stage2/NQPHLL.nqp:1519  
(/home/cpan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1722  
(/home/cpan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:evalfiles)
 from gen/moar/stage2/NQPHLL.nqp:1616  
(/home/cpan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:27  
(/home/cpan/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1590  
(/home/cpan/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/m-main.nqp:47  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/m-main.nqp:38  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:)
 from :1  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:)
 from :1  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:)
cpan@perlbuild2:/tmp/tmp.AY07p77AqM$ RAKUDO_MAX_THREADS=40 perl6 --ll-exception 
test.p6 
  in method throw at gen/moar/m-CORE.setting line 24125
  in method result at gen/moar/m-CORE.setting line 35512
  in sub await at gen/moar/m-CORE.setting line 37569
  in block  at gen/moar/m-CORE.setting line 37568
  in block  at gen/moar/m-CORE.setting line 4845
  in method sink-all at gen/moar/m-CORE.setting line 4831
  in method sink at gen/moar/m-CORE.setting line 14540
  in block  at test.p6 line 1

Cannot invoke this object (REPR: Null; VMNull)
   at gen/moar/m-CORE.setting:24125  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:throw)
 from gen/moar/m-CORE.setting:35512  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:result)
 from gen/moar/m-CORE.setting:37569  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:await)
 from gen/moar/m-CORE.setting:37561  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:await)
 from gen/moar/m-CORE.setting:37568  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:)
 from gen/moar/m-CORE.setting:4845  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:)
 from gen/moar/m-CORE.setting:4831  
(/home/cpan/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:sink-all)
 from gen/moar/m-CORE.setting:14540  
(/home/cpan/.r

[perl #127264] [BUG] Inconsistent file information

[Zoffix Znet via RT]

On Tue Aug 23 11:35:55 2016, coke wrote:
> This is no longer an issue in at least 2016.07.1
> 
> Closable with tests.

The issue is still present in current bleed (2016.08.1-73-gfbeadbf)

> On Thu Jan 14 03:33:28 2016, nadim.khe...@gmail.com wrote:
> > $?FILE is the path and file name
> > 
> > callsframe.file returns the file name only

The .file actually returns the *relative path* and not just a filename:


zoffix@VirtualBox:/tmp/tmp.5AZ3SvWgK7$ tree
.
├── foo.p6
└── z

1 directory, 1 file

zoffix@VirtualBox:/tmp/tmp.5AZ3SvWgK7$ cat foo.p6 
sub foo {}
dd [ $?FILE, callframe.file, &foo.file ];
dd [ $?FILE, callframe.file.IO.abspath, &foo.file.IO.abspath ]

zoffix@VirtualBox:/tmp/tmp.5AZ3SvWgK7$ cd z

zoffix@VirtualBox:/tmp/tmp.5AZ3SvWgK7/z$ perl6 ../foo.p6 
["/tmp/tmp.5AZ3SvWgK7/z/../foo.p6", "../foo.p6", "../foo.p6"]
["/tmp/tmp.5AZ3SvWgK7/z/../foo.p6", "/tmp/tmp.5AZ3SvWgK7/z/../foo.p6", 
"/tmp/tmp.5AZ3SvWgK7/z/../foo.p6"]

[perl #128964] [BUG] Type coercion doesn't work on Block.returns

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/b508576fc5
Tests added in https://github.com/perl6/roast/commit/dedfdf91e7

[perl #129100] [BUG] method rand (Range) fails to check type of $!max

[Zoffix Znet via RT]

The issue is due to there being a multi new [^1] that takes a Real min value 
and *coerces* the max value to a real. So in the case described in this ticket, 
it will coerce the Str max to Int, and by the time we get to .rand, both args 
are Ints.

As suggested on IRC [^2], we can try removing that coercion and see if 
something explodes or not, but I'm unsure of the reasons that coercion is there.

[^1] https://github.com/rakudo/rakudo/blob/aceb4af2/src/core/Range.pm#L51
[^2] http://irclog.perlgeek.de/perl6/2016-09-04#i_13145737

[perl #129080] [LTA] Missing bit in error message about R?? in Rakudo

[Zoffix Znet via RT]

Happens with 'S' and possibly some other ops. The missing bit is the 
`$.operator`, which is obtained from `$op`

$ ./perl6  -e '1 S?? 2 !! 3'
===SORRY!=== Error while compiling -e
Cannot sequence the args of  because conditional operators are too fiddly
at -e:1
--> 1 S?? 2 !!⏏ 3

[perl #129198] [BUG] [REPL] Still problems with syntactic errors in the REPL

[Zoffix Znet via RT]

Thanks for the report.

The issue has now been fixed in 
https://github.com/rakudo/rakudo/commit/77d9d41fc4

(Tests added in the same commit).

[perl #129192] Test module does not show “expected” and “got” values if PERL6_TEST_DIE_ON_FAIL is set

[Zoffix Znet via RT]

Fixed in: https://github.com/rakudo/rakudo/commit/75ba8cc6c3
Tests: https://github.com/perl6/roast/commit/350d02be0b

[perl #129160] [RFC] enum key for optional positional does not work

[Zoffix Znet via RT]

Fixed in 
https://github.com/rakudo/rakudo/commit/490cf728e6396dd99e10ab633f33e4df8cb35a52
Tests added in 
https://github.com/perl6/roast/commit/09c8d3fd7af5b01d79dda46e462e9ae46fa5f365

[perl #128469] [BUG] done() on first entry to whenever block does not exit react {}

[Zoffix Znet via RT]

This now appears to have been fixed by some of the recent async fixes.

Tests now pass and have been unfudged in 
https://github.com/perl6/roast/commit/92951b39ee

[perl #128469] [BUG] done() on first entry to whenever block does not exit react {}

[Zoffix Znet via RT]

This now appears to have been fixed by some of the recent async fixes.

Tests now pass and have been unfudged in 
https://github.com/perl6/roast/commit/92951b39ee

[perl #129080] [LTA] Missing bit in error message about R?? in Rakudo

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/c98ab93552

Tests needed

[perl #129221] [BUG][UNI] Combinators get matched by regex even when no ignoremark is set

[Zoffix Znet via RT]

Not a bug.

See also http://irclog.perlgeek.de/perl6-dev/2016-09-08#i_13170729

[perl #128545] [LTA] [UNI] Date.new(Str) poor error message for digit with diacritic

[Zoffix Znet via RT]

Thanks for the report.

Fixed in https://github.com/rakudo/rakudo/commit/a2b6f74be1
Tests added in https://github.com/perl6/roast/commit/3ed2af4c42

[perl #129228] [SEGV] concurrent network access segfaults in libmoar.so

[Zoffix Znet via RT]

I'm unable to reproduce this on HEAD Rakudo even with $n set to 40 and 
RAKUDO_MAX_THREADS set to 50.

What is your perl6 version (perl6 -v). Are you able to try this against HEAD 
[^1]? Yesterday a fix went in addressing issues in sockets and threads; and 
recently there have been many other async fixes.


[1] Steps to build:
cd $(mktemp -d) &&
git clone https://github.com/rakudo/rakudo/ . &&
perl Configure.pl --gen-moar --gen-nqp --backends=moar &&
make &&
make install;
./perl6-m your-script.p6

[perl #128304] {BUG] :ww does not support other quotation marks (qww)

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/2287173ef2
Tests unfudged in https://github.com/perl6/roast/commit/addcec6732 

[perl #128787] [UNI] DOUBLE PARENTHESIS not recognised as parenthesis

[Zoffix Znet via RT]

Thanks for the report.

Fixed in NQP: https://github.com/perl6/nqp/commit/32fd43da48
Fixed in Rakudo: https://github.com/rakudo/rakudo/commit/87f772ee53
Tests added in https://github.com/perl6/roast/commit/9650cd258f


On Sun Jul 31 08:06:08 2016, gfldex wrote:
> m: say Q ⸨oi!⸩
> # OUTPUT«===SORRY!=== Error while compiling ␤Couldn't find
> terminator ⸨ (corresponding ⸨ was at line 1)␤at :1␤--> sa⸨oi!
> ⸩⏏expecting any of:␤⸨␤»
> # expected output:
> # OUTPUT«oi!␤»

[perl #127208] [CONC][SEGV] Non-deterministic segfaults in parallel code

[Zoffix Znet via RT]

Fudged tests added in https://github.com/perl6/roast/commit/02d698835e

Still segfaults about once in 10 runs on 2016.08.1-145-g87f772e

[perl #129242] [BUG] split gives incorrect results when splitting a number with the :skip-empty adverb

[Zoffix Znet via RT]

Thanks for the report.

It appears all of .split's adverbs were broken on Cool, including the 
.split(@needles) call form.

Fixed in https://github.com/rakudo/rakudo/commit/b771bcc97a
Tests added in https://github.com/perl6/roast/commit/060cf7abff


On Sat Sep 10 09:01:27 2016, jan-olof.hen...@bredband.net wrote:
> Tested with:
> 
> dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -v
> This is Rakudo version 2016.08.1-151-g20ed9e2 built on MoarVM version
> 2016.08-43-g3d04391
> implementing Perl 6.c.
> 
> # the problem
> 
> dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -e 'dd
> 123456.split("", :skip-empty)'
> ("", "1", "2", "3", "4", "5", "6", "")
> 
> # as can be seen the result contains two empty strings
> # compare with
> 
> dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -e 'dd
> "123456".split("", :skip-empty)'
> ("1", "2", "3", "4", "5", "6")
> 
> 
> 
> # some discussion on irc, contains results from bisectable, commitable etc
> 
> http://irclog.perlgeek.de/perl6/2016-09-10#i_13184978
> 
> /dogbert17
> 

[perl #125938] [TESTNEEDED] Numbers: 2**10000000000 and 1/(2**10000)

[Zoffix Znet via RT]

Fudging tests and reopening as the issue appears to still exist on OSX: 
http://irclog.perlgeek.de/perl6-dev/2016-09-11#i_13187953

[perl #129247] [BUG] Wait on a Supply after begin tap is hanging

[Zoffix Znet via RT]

On Sun Sep 11 07:01:11 2016, pierre.vig...@gmail.com wrote:
> Hi,
> 
> i stumbled a across a strange behaviour when playing with Supplier, i
> tried to gulf it down, starting from the documentation of supply. The
> following code, taken from the documentation and slightly modified is
> working as expected:
> 
> my $s = Supplier.new;
> my $l = $s.Supply();
> start {
>   sleep 1;
>   $s.emit(1);
>   $s.emit(2);
>   $s.done;
> }
> $l.wait;
> say "done";
> 
> If i tap the $l variable to display the value that are supplied by the
> supplier, it then hangs indefinitely:
> 
> my $s = Supplier.new;
> my $l = $s.Supply();
> $l.tap( -> $v { say "got : $v" } );
> start {
>   sleep 1;
>   $s.emit(1);
>   $s.emit(2);
>   $s.done;
> }
> $l.wait;
> say "done";
> 
> Pierre


I tried to debug this, but ultimately failed, as I'm getting spectest failures.

There are actually three issues:
1) Supply.sanitize uses a per-instance $!finished attribute and when the first 
tap gets closed, no more taps get closed. This is what causes the OP bug.
2) Supply.wait calls Supply.Promise that opens a new tap that keeps/breaks the 
Promise on done/quit. However, if this is done on-already finished Supply, that 
Promise will never complete, causing in a hang in .wait. This is what causes 
the bug if we golf OP's code to get rid of the start {}.
3) To me, it looks like there's a race condition with regards to $!finished, 
since one tap can be setting it to `1`, while another is mid-checking it. Not 
sure if it matters.

Below is my attempt at fixing it that fixes issues #1 and #2 (where .wait on a 
finished supply returns a Nil), however, this has failures in 
t/spec/S17-supply/basic.t because I'm not returning a Tap, I think.

I've also no idea why the created supplies go through the .serialize -> 
.sanitize chain where both methods look nearly identical. I'm leaving this for 
someone more knowledgeable to finish.


--8<-
diff --git a/src/core/Supply.pm b/src/core/Supply.pm
index d91c3b8..f0fa251 100644
--- a/src/core/Supply.pm
+++ b/src/core/Supply.pm
@@ -197,6 +197,7 @@ my class Supply {
 
 method tap(&emit, &done, &quit) {
 my int $cleaned-up = 0;
+return if $!finished;
 my $source-tap = $!source.tap(
 -> \value{
 emit(value) unless $!finished;
@@ -204,16 +205,16 @@ my class Supply {
 done => -> {
 unless $!finished {
 $!finished = 1;
-done();
 self!cleanup($cleaned-up, $source-tap);
 }
+done();
 },
 quit => -> $ex {
 unless $!finished {
 $!finished = 1;
-quit($ex);
 self!cleanup($cleaned-up, $source-tap);
 }
+quit($ex);
 });
 Tap.new({ self!cleanup($cleaned-up, $source-tap) })
 }
@@ -610,10 +611,11 @@ my class Supply {
 my $p = Promise.new;
 my $v = $p.vow;
 my $final := Nil;
-my $t = self.tap:
+my $t = self.tap(
 -> \val { $final := val },
 done => { $v.keep($final) },
-quit => -> \ex { $v.break(ex) };
+quit => -> \ex { $v.break(ex) },
+) or $v.keep(Nil);
 $p
 }
--8<-

[perl #129252] routines sprintf and printf need auto newline capability

[Zoffix Znet via RT]

On Sun Sep 11 13:48:04 2016, tbrowder wrote:
> Both routines need an alias (or adverb) so that a newline is
> automatically appended to the output.  I would like to see something
> like:
> 
> sprintfn
> printfn

I'd prefer to avoid adding two new subs and two new methods for the sake of 
saving a single character of typing. Since you're writing the format already 
sticking a \n into it isn't that difficult.

[perl #129255] [LTA] Syntax: Weird behavior of newline before the ... (infinite list) operator

[Zoffix Znet via RT]

On Mon Sep 12 07:33:33 2016, darek.cidlin...@atlas.cz wrote:
> 2) should the newline before the ... operator be forbidden,
> the error message could be clearer than a single asterisk.

Thanks for the report, but I think I'm going to close this without any changes.

What happens is your } without unspace after it closes the previous statement 
and you start a new one, but in this new context, the `...` is a Stub. 
Furthermore, you can give that Stub arguments to call `fail` with. So the 
compiler thinks you're giving it the Whatever as an argument to `fail` and 
that's what the error message prints out.

So improving the message would involve exempting the Whatever from allowed 
arguments to ... Stub. But... that wouldn't solve the issue entirely. For 
example, I like to use `∞` instead of Whatever Star as an end point to …. Also, 
10 < *, { whatever }, and "foo" can also be used as an end point, so we can't 
exclude all of the possible endpoints from the Stub arguments to give a better 
error message.

With knowledge that } as last thing on the line closes blocks, it was pretty 
easy for me to spot what the problem was, so I think despite the error message 
looking funky in this particular case, its content is a side-effect of 
interaction of two features and improving the message means restricting those 
features, while the target audience who would be helped by the better message 
may be rather slim.

zoffix@leliana:~$ perl6 -e '... *'
*
  in any  at 
/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm
 line 1
  in block  at -e line 1

zoffix@leliana:~$ perl6 -e '... "This is a message!"'
This is a message!
  in any  at 
/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm
 line 1
  in block  at -e line 1

zoffix@leliana:~$ 

[perl #129258] [BUG] the trans method in Cool doesn't handle adverbs correctly

[Zoffix Znet via RT]

For others reading the ticket. I asked OP to submit the fix[^1] to get some 
practice fixing Rakudo bugs, so this ticket is taken.

[1] http://irclog.perlgeek.de/perl6/2016-09-12#i_13194275

[perl #129256] [BUG] Infinite loop on CArray[].new

[Zoffix Znet via RT]

Thanks for the report!

Unfortunately the fix you provided is a no-op, because empty arrays are falsy, 
so the check doesn't add anything extra.

The issue was the nextsame candidate was the one with the slurpy that called 
the current candidate back again, resulting in an infiniloop.

The issue has now been resolved in 
https://github.com/rakudo/rakudo/commit/804bf671f8

Tests added in the same commit.

Cheers,
ZZ

[perl #129270] [BUG] Unicode ellipsis works as a Stub, but still triggers redeclaration errors

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/d63f983290
Tests added in https://github.com/perl6/roast/commit/0ade2a58c9

[perl #127421] : multi sub infix:<==> (Int $a, Str $b) { $a == $b } hangs in COMPILE time

[Zoffix Znet via RT]

On Fri Jan 29 06:50:08 2016, pawel.pab...@getresponse.com wrote:
> multi sub infix:<==> (Int $a, Str $b) { $a == $b }
> 
> Will never finish compilation on Rakudo 6.c and causes severe memory
> leak. I found that:
> 
> 1. Types must be different in signature
> (Int $a, Str $b) # hangs
> (Str $a, Int $b) # hangs
> (Int $a, Int $b) # compiles
> 
> 2. Operator must be the same in sub and block
> multi sub infix: (Int $a, Str $b) { $a eq $b } # hangs
> multi sub infix: (Int $a, Str $b) { $a == $b } # compiles


Thanks for the report. I'm unsure whether this would qualify as a bug, but 
jnthn++ wanted to know more about this
behaviour, in case it suggests buggy behaviour elsewhere, so what follows are 
my findings.

The body of the multi you're creating calls itself, which causes infinite 
recursion, hence the hang and memory growth.

The reason you see this happen during compile time is due to routine inlining 
optimizations. You can see that
by turning off the optimizer:

perl6 --optimize=0 -e 'multi sub infix:<==> (Int $a, Str $b) { $a == $b }' 
# doesn't hang

The reason (Int $a, Int $b) compiles is because it's ambiguous with the Int:D, 
Int:D candidate defined in core,
so the optimization infini-loop for it does not occur.

Using a different operator, as you described in point (2), simply avoids using 
the same operator in the body, and
so the multi never ends up calling itself.



Digging into the optimizer, it inlines the hanging multi, then runs the 
optimizer over it again, inlines it again, and
just keeps doing that, forever inlining and digging into it.

Here's the call graph for the infini-looping portion:

visit_op
├───$optype eq 'chain' -> 'call'
├───self.visit_op_children($op)
│   └───visit_children($op)
│   ├───self.visit_var($visit)
│   │   └──@!block_var_stack[$top].add_usage($var);
│   └───self.visit_var($visit)
│   └──@!block_var_stack[$top].add_usage($var);
│
└───self.optimize_call($op)
├───$!symbols.find_lexical($op.name)
│   └───self.force_value(%sym, $name, 1)
│
│   # inside if $dispatcher && $obj.onlystar {...}
├───my @ct_arg_info := self.analyze_args_for_ct_call($op)
└───self.inline_call($op, $chosen)
└───$!symbols.faking_top_routine
└───self.visit_children($inlined) <-- optimizing newly inlined code
└───self.visit_op($visit)
└───self.visit_op_children($op) <-- we're back where we 
started



I also added a print statement to start of every method and sub in 
Optimizer.nqp and here's the repeating portion of the calls:

CALLING -> in visit_op
CALLING -> in optimize
CALLING -> in is_outer_foldable
CALLING -> in visit_op_children
CALLING -> in visit_children
CALLING -> in visit_var
CALLING -> in add_usage
CALLING -> in visit_var
CALLING -> in add_usage
CALLING -> in optimize_call
CALLING -> in find_lexical
CALLING -> in force_value
CALLING -> in analyze_args_for_ct_call
CALLING -> in inline_call
CALLING -> in faking_top_routine
CALLING -> in visit_children
CALLING -> in visit_op
CALLING -> in optimize
CALLING -> in is_outer_foldable
CALLING -> in visit_op_children
CALLING -> in visit_children
CALLING -> in visit_op
CALLING -> in optimize
CALLING -> in is_outer_foldable
CALLING -> in visit_op_children
CALLING -> in visit_children
CALLING -> in visit_children
CALLING -> in visit_children

Cheers,
ZZ

[perl #129311] Simple Grammar Goes into infinite loop

[Zoffix Znet via RT]

I'm not seeing the bug here, to be honest.

The `Body` is asking for one or more tokens `Text`, *nothing* is a valid match 
for those tokens, so after matching the provided text, your grammar continues 
to match nothing infinite number of times.

[perl #129311] Simple Grammar Goes into infinite loop

[Zoffix Znet via RT]

Here's a much shorter way to reproduce it:

perl6 -e '"foo" ~~ /(.*)+/'  # hangs

While my previous explanation for why this occurs makes sense, it's worth 
noting this behaviour is not observed in Perl 5, for example:

perl -e '"foo" =~ /(.*)+/'  # does not hang

[perl #129316] [BUG] In given block, whitespace matters too much to parser.

[Zoffix Znet via RT]

Thank you for the report, however, this is not a bug.

Closing curlies ('}') end statements when they're the last 
non-whitespace/non-unspace character on the line, which is why your first 
version works.

When putting them all on one line, you have to explicitly specify where the 
statements end,
so when * < 0 {  say "Negative"; }; when * > 0 {  say "Positive"; }; default { 
say "Zero"; } will work just fine.

Cheers,
ZZ


On Tue Sep 20 08:02:39 2016, brasfield.la...@gmail.com wrote:
> Using Rakudo Star:
> ~$ perl6 -version
> This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
> implementing Perl 6.c.
> 
> With a script, try.pl, containing this text:
> given prompt "Enter a number: " {
>  when * < 0 {  say "Negative"; }
>  when * > 0 {  say "Positive"; }
>  default {  say "Zero"; }
> }
> , I get results precisely as expected. (It compiles, prompts, classifies
> its input.)
> 
> But if the script is changed, only by replacing some newline~space
> sequences with space:
> given prompt "Enter a number: " {
>  when * < 0 {  say "Negative"; } when * > 0 {  say "Positive"; } default {
> say "Zero"; }
> }
> then an error message issues:
> ~$ perl6 try.pl
> ===SORRY!=== Error while compiling /home/larry/try.pl
> Strange text after block (missing semicolon or comma?)
> at /home/larry/try.pl:8
> -->  when * < 0 {  say "Negative"; }⏏ when * > 0 {  say "Positive"; }
> default
> , which I expect to give the same result as before since Perl6 is not a
> line-oriented language (excepting a certain literal construct.)
> 
> For convenience, I attach the file I used to demonstrate this bug. I
> discovered it when trying an example which I converted to a one-liner in an
> interactive REPL session.
> 
> Best regards,

[perl #129321] [BUG] deepmap can recurse indefinitely under some circumstances

[Zoffix Znet via RT]

On Tue Sep 20 13:54:33 2016, jan-olof.hen...@bredband.net wrote:
> # tested with
> 
> dogbert@dogbert-VirtualBox ~ $ perl6 -v
> This is Rakudo version 2016.09-19-g8be36b1 built on MoarVM version 2016.09
> implementing Perl 6.c
> 
> # the following two examples behave quite differently
> 
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my @a = [1,[2,3],4]; dd
> @a.duckmap({ $_ ~~ Int ?? $_ !! Any })'   # this works as expected
> (1, (2, 3), 4)
> 
> dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my @a = [1,[2,3],"a"]; dd
> @a.duckmap({ $_ ~~ Int ?? $_ !! Any })'  # this will hang or return 'Memory
> allocation failed; could not allocate xx bytes'
> 
> /dogbert17
> 

I see why the issue occurs, but have no idea what the correct behaviour should 
be.

The docs for .duckmap read "For undefined return values, duckmap will try to 
descend into the element if that element implements Iterable." but when would 
an undefined Iterable would ever be descendable?

The hang itself happens here: 
https://github.com/rakudo/rakudo/blob/e12ebb9/src/core/metaops.pm#L685
The Any returned from your condition is undefined, so duckmap calls the block 
with it again, resulting in an infiniloop.

Based on the docs, a check for an Iterable is missing, but it feels wrong to me 
that we'd be attempting to "descend" into an undefined Iterable :S

[perl #129291] [BUG] [SEGV] problems when run()ning two procs and passing the :out of one to the :in of the other

[Zoffix Znet via RT]

On Wed Sep 21 19:37:06 2016, ddgr...@gmail.com wrote:
> Test added in https://github.com/perl6/roast/commit/6cc1a85cf4

This ticket still needs tests for Windows.

[perl #125923] [BUG] .classify-list doesn't work with BagHash in Rakudo

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/8f2279b155
Tests added in https://github.com/perl6/roast/commit/816b913d98


On Thu Aug 27 04:25:26 2015, masak wrote:
>  m: my %b := BagHash.new(); %b.classify-list( {.comb}, 20..40
> ); say %b.perl
>  rakudo-moar a46b09: OUTPUT«postcircumfix:<{ }> not defined
> for type Int [...]
>  masak: ^^
> * masak submits rakudobug
>  m: my %b; %b.classify-list( {.comb}, 20..40 ); say %b.perl
>  rakudo-moar a46b09: OUTPUT«{"2" => {"0" => [20], "1" =>
> [21], "2" => [22], "3" => [23], "4" => [24], "5" => [25], "6" => [26],
> "7" => [27], "8" => [28], "9" => [29]}, "3" => {"0" => [30], "1" =>
> [31], "2" => [32], "3" => [33], "4" => [34], "5" => [35], "6" => [36],
> "7" => [37], "8" …»
>  m: my %b := BagHash.new(); say %b{'foo'}
>  rakudo-moar a46b09: OUTPUT«0␤»
> 
> Notice how postcircumfix:<{ }> is defined on BagHash, as seen in that
> last eval. But something must go wrong inside .classify-list such that
> .{} gets called on an Int instead of on the BagHash itself.

[perl #123838] [IO] IO::Handle::tell return 0, no matter what

[Zoffix Znet via RT]

Seems to be fixed in latest Rakudo, per 
http://irclog.perlgeek.de/perl6/2016-09-26#i_13283196

Tests needed.

[perl #129374] [BUG] invalid arguments to .subst/.subst-mutate silently ignored

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/6ef4cdf543
Tests added in https://github.com/perl6/roast/commit/925cf4bd8b


On Tue Sep 27 11:39:00 2016, c...@zoffix.com wrote:
> # I have the fix; filing for records
> 
> The .subst/.subst-mutate methods slurp several of their options into a
> hash and then pass those
> along to Str.match call. The logic that handles the result of that
> call, however, does not
> pay attention to Failures. Specifically, failures resulting from
> incorrect values provided for
> the named arguments that get passed to .match:
> 
> m: say 'foo'.subst: /\w/, '', :x{2}
> rakudo-moar 222d16: OUTPUT«foo␤»
> m: say 'foo'.subst: /\w/, '', :th(2.5)
> rakudo-moar 222d16: OUTPUT«foo␤»
> m: say ($ = 'foo').subst-mutate: /\w/, '', :th(2.5)
> rakudo-moar 222d16: OUTPUT«Nil␤»
> 
> Thus, the user never receives any indication they're using the wrong
> arguments and the code behaves as the match simply fails.

[perl #129596] [BUG] .subst-mutate does not return all matches when :x option is used

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/f6524e61e8
Tests added in https://github.com/perl6/roast/commit/391ecba7b9


On Wed Sep 28 06:02:48 2016, c...@zoffix.com wrote:
> # I have the fix; filing for records
> 
> The .subst-mutate routine returns a Match object (or Nil) on singular
> operations or a List of Match objects when :g/:global is used, as that
> produces several matches.
> 
> The :x option also produces several matches:
> 
> m: say "1234567".match: /\d/, :x(5)
> rakudo-moar c01fc3: OUTPUT«(｢1｣ ｢2｣ ｢3｣ ｢4｣ ｢5｣)␤
> 
> However, only a single match object is returned when that option is
> used with .subst-mutate, even though the option does have the desired
> effect on the substitutions:
> 
> m: my $x = "1234567"; say $x.subst-mutate: /\d/, '', :x(5); say $x
> rakudo-moar c01fc3: OUTPUT«｢1｣␤67␤»

[perl #129773] [BUG] [].splice: 0, [] infiniloops

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/28bf87439e
Tests in https://github.com/perl6/roast/commit/3253db362c


On Fri Sep 30 23:14:32 2016, c...@zoffix.com wrote:
> # I have the fix; filing for records
> 
>   m: [].splice: 0, []  # w
>   rakudo-moar 1f29cb: OUTPUT«Memory allocation failed;  
> could not allocate 80320 bytes␤»
> 
> The problem is the candidate called [^1] takes the replacement array  
> as size to splice and then calls itself, ad infinitum.
> 
> Type restriction needs to be added to $size
> 
> [1] https://github.com/rakudo/rakudo/blob/1f29cb2/src/core/Array.pm#L1142
> 

[perl #129773] [BUG] [].splice: 0, [] infiniloops

[Zoffix Znet via RT]

The original fix was not enough, as passing incorrect type to `offset` also has 
the same issue.

Not pretty, but this commit fixes that issue: 
https://github.com/rakudo/rakudo/commit/b77d2b71db
And tests for offset condition hang added in 
https://github.com/perl6/roast/commit/5d8750321d




On Fri Sep 30 23:20:55 2016, c...@zoffix.com wrote:
> Fixed in https://github.com/rakudo/rakudo/commit/28bf87439e
> Tests in https://github.com/perl6/roast/commit/3253db362c
> 
> 
> On Fri Sep 30 23:14:32 2016, c...@zoffix.com wrote:
> > # I have the fix; filing for records
> > 
> >   m: [].splice: 0, []  # w
> >   rakudo-moar 1f29cb: OUTPUT«Memory allocation failed;  
> > could not allocate 80320 bytes␤»
> > 
> > The problem is the candidate called [^1] takes the replacement array  
> > as size to splice and then calls itself, ad infinitum.
> > 
> > Type restriction needs to be added to $size
> > 
> > [1] https://github.com/rakudo/rakudo/blob/1f29cb2/src/core/Array.pm#L1142
> > 
> 
> 

[perl #129779] Concurrency worse than no concurrency

[Zoffix Znet via RT]

Seems the issue has more to do with running an empty loop, rather than
performing a real computation.

This is a run on a 4-core box. Attempting to parallelize an empty loop makes
the execution 1 second slower:

my &code = { for ^2_000_000 { } };

my $start = now; (^4).map: &code; my $stop = now;
say "Serial: {$stop - $start}";

$start = now; await (^4).map: {start code}; $stop = now;
say "Parallel: {$stop - $start}";

# Serial: 1.5161628
# Parallel: 2.56597794


But running actual real-life code makes it almost 4 times faster, as 
would be expected on a 4-core box:

use Crypt::Bcrypt;
my &code = { bcrypt-hash ~rand, :15rounds; };

my $start = now; (^4).map: &code; my $stop = now;
say "Serial: {$stop - $start}";

$start = now; await (^4).map: {start code}; $stop = now;
say "Parallel: {$stop - $start}";

# Serial: 7.69045687
# Parallel: 2.087147






On Sat Oct 01 06:15:18 2016, steve.pi...@gmail.com wrote:
> This could be a stupid user problem, in which case I apologise for wasting  
> your time.
> 
> Simple concurrency demonstrations seem to work; the following completes in  
> just over a second:
> 
> perl6 -e 'await Promise.allof(start {sleep 1}, start {sleep 1}, start  
> {sleep 1});say now - INIT now'
> 
> However if the started tasks are doing any CPU-intensive work, they seem  
> to take much longer than if they had been run sequentially, without using  
> promises at all.
> 
> To reproduce the issue, please run this script.
> 
> -
> use v6;
> 
> my $r = 2_000_000;
> 
> say "Counting to $r";
> 
> my ($start, $setup, $stop);
> $start = now;
> {
>  my ($i, $j);
>  $j = $r;
>  loop ($i = 0; $i < $j; $i++) { }
> }
> $stop = now;
> 
> say "Non-promise iteration: {$stop - $start}";
> 
> my @promises;
> $start = now;
> @promises.push(start {
>  my ($i, $j);
>  $j = $r;
>  loop ($i = 0; $i < $j; $i++) { }
> });
> $setup = now;
> await Promise.allof(@promises);
> $stop = now;
> 
> say "One iteration: {$stop - $start} (setup: {$setup - $start})";
> 
> @promises = ();
> 
> $start = now;
> for (1..16) {
>  @promises.push(start {
>  my ($i, $j);
>  $j = $r;
>  loop ($i = 0; $i < $j; $i++) { }
>  });
> }
> $setup = now;
> await Promise.allof(@promises);
> $stop = now;
> 
> say "16 iterations: {$stop - $start} (setup: {$setup - $start})";
> -
> 
> What I expected:
> 
> One iteration would take roughly the same amount of time as the  
> non-promise iteration (the sleep example above would suggest that the  
> threading overhead would be less than 0.001s)
> 
> 16 iterations would take, at worst, about 16 times as long as the line  
> 'one iteration' above it.
> 
> What happens:
> 
> On a Windows 10 PC, with 6 cores (12 logical processors)
> 
> C:\Users\Steve>perl6 concurrency-wtf.pl
> Counting to 200
> Non-promise iteration: 0.6162481
> One iteration: 2.23909643 (setup: 0.00300325)
> 16 iterations: 65.56993665 (setup: 0.00700654)
> 
> On an Ubuntu 14.04.5 LTS PC, with 2 cores
> 
> steve@prole:~/$ perl6 concurrency-wtf.pl
> Counting to 200
> Non-promise iteration: 0.6948201
> One iteration: 1.9678549 (setup: 0.0024696)
> 16 iterations: 107.1483633 (setup: 0.0474610)
> 
> Also the CPU usage leaps 100% (all CPUs, all at 100%) while running, on  
> both PCs. The PCs are mostly idle otherwise (Windows 10 - about 3%  
> utilization, Linux - 199% idle)
> 
> Perl 6 version
> 
> C:\Users\Steve>perl6 -v
> This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
> implementing Perl 6.c.
> 
> steve@prole:~/$ perl6 -v
> This is Rakudo version 2016.07.1 built on MoarVM version 2016.07
> implementing Perl 6.c.

[perl #128655] Mixup in candidates through optimizer

[Zoffix Znet via RT]

Posting on behalf of dogbert17:



I believe that I have encountered the same bug under different circumstances. 
With the help of hackedNODE and others on #perl6
it seems as if the problem described below also suffers from the wrong multi 
candidate being called. In fact, it seems to happen
with any sub with int/Int multis.

dogbert@dogbert-VirtualBox ~ $ perl6 -v
This is Rakudo version 2016.09-122-gc6c0e69 built on MoarVM version 
2016.09-13-g34c375a
implementing Perl 6.c.

# the problem
dogbert@dogbert-VirtualBox ~ $ perl6 -e 'my int $i = 2482111348; say $i; $i = 
$i div 2; say $i'
2482111348
-906427974

# run the same snippet with --optimize=0
dogbert@dogbert-VirtualBox ~ $ perl6 --optimize=0 -e 'my int $i = 2482111348; 
say $i; $i = $i div 2; say $i'
2482111348
1241055674

# also works with --optimize=1
dogbert@dogbert-VirtualBox ~ $ perl6 --optimize=1 -e 'my int $i = 2482111348; 
say $i; $i = $i div 2; say $i'
2482111348
1241055674

A discussion wrt this particular problem can be found here: 
https://irclog.perlgeek.de/perl6/2016-10-04#i_13335782

[perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents

[Zoffix Znet via RT]

First a bit of deconfusion: negative exponents just mean x⁻² = 1/x². That works 
just fine and is not relevant to this ticket:

 m: say (-2) ** -2
 rakudo-moar 605f27: OUTPUT«0.25␤»

Fractional exponents mean the number is raised to the power of the numerator 
and then the denominator-th-root is taken from it. So raising to 0.1th power 
simply means we take 10th root:

 m: say 1024 ** .1
 rakudo-moar 605f27: OUTPUT«2␤»

So far so good for positive base numbers, but some stuff appears to be broken 
for roots of negatives. First, the NaN case described in this ticket:

 m: say (-1) ** .5
 rakudo-moar 605f27: OUTPUT«NaN␤»

We're taking a square root of a negative number which "doesn't exist", so we're 
dealing with Complex numbers.
The NaN result matches what we'd get from sqrt(), so this case is fine:

 m: say sqrt(-1)
 rakudo-moar 605f27: OUTPUT«NaN␤»

BUT, unlike sqrt(), if we request to deal with Complex numbers, the output from 
the infix:<**> is incorrect:

 m: say sqrt(-1+0i)
 rakudo-moar 605f27: OUTPUT«0+1i␤»
 m: say (-1+0i) ** .5
 rakudo-moar 605f27: OUTPUT«6.12323399573677e-17+1i␤»

Moreover, if we raise a negative number to an *odd* power, the result will be 
negative:

 m: say (-5)**3
 rakudo-moar 605f27: OUTPUT«-125␤»

This means that taking an *odd* root doesn't have anything to do with Complex 
numbers and should Just Work™, but Rakudo still gives us a NaN, instead of the 
original -5:

 m: say (-125)**(1/3)
 rakudo-moar 605f27: OUTPUT«NaN␤»

We can try using the "Complex mode", and that doesn't give NaN, but the result 
is wrong, so we can't use that to perform such a computation:

 m: say (-125+0i) ** (1/3)
 rakudo-moar 605f27: OUTPUT«2.5+4.33012701892219i␤»
 m: say (-125+0i) ** ((1+0i)/(3+0i))
 rakudo-moar 605f27: OUTPUT«2.5+4.33012701892219i␤»

In summation, the buggy behaviour revealed by this ticket is:
(a) odd roots (rational powers with odd denominators) produce NaN instead 
of actual non-complex result
(b) rational powers on complex numbers produce wrong results



On Sat Jul 09 09:51:38 2016, pmichaud wrote:
> On Sat, Jul 09, 2016 at 05:19:49AM -0700, Itsuki Toyota wrote:
> > See the following results
> >
> > $ perl6 -e 'say -1 ** -0.1'
> > -1
> > $ perl6 -e 'say reduce * ** *, -1, (-0.1)'
> > NaN
> 
> This is not a bug in "reduce" itself.  Exponentiation has higher
> precedence than unary minus, so the first expression is being
> parsed and executed as -(1 ** -0.1)  and not  (-1) ** -0.1.
> From my rakudo (ver 2016.06-50-g5a4963f):
> 
> $ ./perl6 -e 'say -1 ** -0.1'
> -1
> $ ./perl6 -e 'say (-1) ** -0.1'
> NaN
> 
> So, the reduce subroutine is doing exactly the same thing as
> &infix:<**> here does with a negative base.
> 
> At the moment I'm inclined to believe that a negative integer with
> negative exponent should return NaN, but someone with more mathematics
> sense than I would have to make that call.
> 
> Pm

[perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents

[Zoffix Znet via RT]

First a bit of deconfusion: negative exponents just mean x⁻² = 1/x². That works 
just fine and is not relevant to this ticket:

 m: say (-2) ** -2
 rakudo-moar 605f27: OUTPUT«0.25␤»

Fractional exponents mean the number is raised to the power of the numerator 
and then the denominator-th-root is taken from it. So raising to 0.1th power 
simply means we take 10th root:

 m: say 1024 ** .1
 rakudo-moar 605f27: OUTPUT«2␤»

So far so good for positive base numbers, but some stuff appears to be broken 
for roots of negatives. First, the NaN case described in this ticket:

 m: say (-1) ** .5
 rakudo-moar 605f27: OUTPUT«NaN␤»

We're taking a square root of a negative number which "doesn't exist", so we're 
dealing with Complex numbers.
The NaN result matches what we'd get from sqrt(), so this case is fine:

 m: say sqrt(-1)
 rakudo-moar 605f27: OUTPUT«NaN␤»

BUT, unlike sqrt(), if we request to deal with Complex numbers, the output from 
the infix:<**> is incorrect:

 m: say sqrt(-1+0i)
 rakudo-moar 605f27: OUTPUT«0+1i␤»
 m: say (-1+0i) ** .5
 rakudo-moar 605f27: OUTPUT«6.12323399573677e-17+1i␤»

Moreover, if we raise a negative number to an *odd* power, the result will be 
negative:

 m: say (-5)**3
 rakudo-moar 605f27: OUTPUT«-125␤»

This means that taking an *odd* root doesn't have anything to do with Complex 
numbers and should Just Work™, but Rakudo still gives us a NaN, instead of the 
original -5:

 m: say (-125)**(1/3)
 rakudo-moar 605f27: OUTPUT«NaN␤»

We can try using the "Complex mode", and that doesn't give NaN, but the result 
is wrong, so we can't use that to perform such a computation:

 m: say (-125+0i) ** (1/3)
 rakudo-moar 605f27: OUTPUT«2.5+4.33012701892219i␤»
 m: say (-125+0i) ** ((1+0i)/(3+0i))
 rakudo-moar 605f27: OUTPUT«2.5+4.33012701892219i␤»

In summation, the buggy behaviour revealed by this ticket is:
(a) odd roots (rational powers with odd denominators) produce NaN instead 
of actual non-complex result
(b) rational powers on complex numbers produce wrong results



On Sat Jul 09 09:51:38 2016, pmichaud wrote:
> On Sat, Jul 09, 2016 at 05:19:49AM -0700, Itsuki Toyota wrote:
> > See the following results
> >
> > $ perl6 -e 'say -1 ** -0.1'
> > -1
> > $ perl6 -e 'say reduce * ** *, -1, (-0.1)'
> > NaN
> 
> This is not a bug in "reduce" itself.  Exponentiation has higher
> precedence than unary minus, so the first expression is being
> parsed and executed as -(1 ** -0.1)  and not  (-1) ** -0.1.
> From my rakudo (ver 2016.06-50-g5a4963f):
> 
> $ ./perl6 -e 'say -1 ** -0.1'
> -1
> $ ./perl6 -e 'say (-1) ** -0.1'
> NaN
> 
> So, the reduce subroutine is doing exactly the same thing as
> &infix:<**> here does with a negative base.
> 
> At the moment I'm inclined to believe that a negative integer with
> negative exponent should return NaN, but someone with more mathematics
> sense than I would have to make that call.
> 
> Pm

[perl #129810] [BUG] JSON error output does not work with "use" (unknown) module

[Zoffix Znet via RT]

Fixed in https://github.com/rakudo/rakudo/commit/3b5ef07cee
Tests added in 
https://github.com/perl6/roast/blob/412539ab809a769b7bf36df02c4aba8040f95f7e/S04-exceptions/exceptions-json.t#L27


On Wed Oct 05 11:07:23 2016, nxadm wrote:
> Hi,
> 
> Great job adding JSON error output (lizmat++). This will make tooling a 
> lot better!
> 
> So far it seems to work well, but I found a use case where no JSON is 
> thrown, but the regular error text. Specifically, the error output is 
> skipped when a module is loaded that does not exit.
> 
> I created some 'error state' modules to test the perl6 syntax support: 
> https://github.com/nxadm/syntastic-perl6/tree/JSON_2016.09/t (the code 
> hasn't yet been ported to support JSON).
> 
> Here is the output of for the module_not_found.pm6 where the JSON output 
> is not thrown:
> 
> 
> ~/Code/syntastic-perl6/t$ /opt/rakudo/bin/perl6 -v
> This is Rakudo version 2016.09 built on MoarVM version 2016.09
> implementing Perl 6.c.
> 
> ~/Code/syntastic-perl6/t$ cat module_not_found.pm6
> unit package ModuleNotFoundTest;
> use abcdefghijklmnopqrstuvwxyz1234567891011121314151617181920;
> 
> ~/Code/syntastic-perl6/t$ RAKUDO_EXCEPTIONS_HANDLER=JSON 
> /opt/rakudo/bin/perl6 -c module_not_found.pm6
> Unhandled exception: Can't serialize an object of type 
> CompUnit::DependencySpecification
> at :1 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:throw)
>   from gen/moar/m-CORE.setting:819 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:die)
>   from gen/moar/m-CORE.setting:807 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:die)
>   from gen/moar/m-CORE.setting:39400 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:39376 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:39395 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:)
>   from gen/moar/m-CORE.setting:4908 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:push-all)
>   from gen/moar/m-CORE.setting:2697 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:push-until-lazy)
>   from gen/moar/m-CORE.setting:16196 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:reify-until-lazy)
>   from gen/moar/m-CORE.setting:17249 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:join)
>   from gen/moar/m-CORE.setting:2066 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:join)
>   from gen/moar/m-CORE.setting:39395 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:39376 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:39395 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:)
>   from gen/moar/m-CORE.setting:4908 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:push-all)
>   from gen/moar/m-CORE.setting:2697 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:push-until-lazy)
>   from gen/moar/m-CORE.setting:16196 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:reify-until-lazy)
>   from gen/moar/m-CORE.setting:17249 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:join)
>   from gen/moar/m-CORE.setting:2066 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:join)
>   from gen/moar/m-CORE.setting:39395 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:39376 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:39410 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:to-json)
>   from gen/moar/m-CORE.setting:26815 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:process)
>   from gen/moar/m-CORE.setting:24542 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:)
>   from gen/moar/m-CORE.setting:24540 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:)
>   from gen/moar/m-CORE.setting:24538 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:print_exception)
>   from gen/moar/m-CORE.setting:24630 
> (/opt/rakudo/share/perl6/runtime/CORE.setting.moarvm:)
>   from gen/moar/stage2/NQPHLL.nqp:1559 
> (/opt/rakudo/share/nqp/lib/NQPHLL.moarvm:command_eval)
>   from src/Perl6/Compiler.nqp:27 
> (/opt/rakudo/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
>   from gen/moar/stage2/NQPHLL.nqp:1499 
> (/opt/rakudo/share/nqp/lib/NQPHLL.moarvm:command_line)
>   from gen/moar/m-main.nqp:47 
> (/opt/rakudo/share/perl6/runtime/perl6.moarvm:MAIN)
>   from gen/moar/m-main.nqp:38 
> (/opt/rakudo/share/perl6/runtime/perl6.moarvm:)
>   from :1  (/opt/rakudo/share/perl6/runtime/perl6.moarvm:)
>   from :1  (/opt/rakudo/share/perl6/runtime/perl6.moarvm:)

[perl #129829] .pick on large ranges returns binary-sparse result

[Zoffix Znet via RT]

Looks like libtommath has now been fixed: 
https://github.com/libtom/libtommath/pull/57

On Sat Oct 08 14:47:40 2016, timo wrote:
> Apparently libtommath is known to leave some bits 0 when specific
> conditions for the defines are met; i haven't looked but i suspect we
> are hitting exactly this problem:
> 
> https://github.com/libtom/libtommath/pull/56
> 
> not sure why it's been quiet since april.
> 

[perl #129838] [LTA] Too-short indent in HEREDOCs produces gut-referencing error

[Zoffix Znet via RT]

Gave it a go by adding more files to Backtrace.is-setting, but gave up because 
it looked kinda smelly.

I added a check for m-Perl6-Actions.nqp, then for Perl6/Grammar.nqp, and at 
that point it started referencing Perl6/Grammar.moarvm, so I gave up.



On Mon Oct 10 11:47:33 2016, biod...@gmail.com wrote:
> I solved it. I actually sent the report cause they said I should at the IRC
> chat. Apparently, it was considered a poor error notification.
> 
> I had a quote with END and two spaces on the line. Removed the 2 spaces and
> worked.
> 
> att,
> 
> On Mon, Oct 10, 2016 at 8:30 AM, Elizabeth Mattijsen via RT <
> perl6-bugs-follo...@perl.org> wrote:
> 
> > When does this happen exactly?
> >
> > > On 10 Oct 2016, at 04:14, Eduardo CAPANEMA (via RT) <
> > perl6-bugs-follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by  Eduardo CAPANEMA
> > > # Please include the string:  [perl #129838]
> > > # in the subject line of all future correspondence about this issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=129838 >
> > >
> > >
> > > Hi guys,
> > >
> > > Friends on IRC kindly asked me to submit this error report:
> > >
> > > Asked to remove 2 spaces, but the shortest indent is 0 spaces  in any
> > > descend at gen/moar/m-Perl6-Actions.nqp line 473
> > > Asked to remove 2 spaces, but the shortest indent is 0 spaces  in any
> > > descend at gen/moar/m-Perl6-Actions.nqp line 468
> > > Use of uninitialized value $conditions of type Any in string context
> > > Any of .^name, .perl, .gist, or .say can stringify undefined things, if
> > > needed.  in sub MAIN at create-table.pl line 29
> > > Use of uninitialized value $hash-values of type Any in string context
> >
> >
> >

[perl #129856] namespace clashes

[Zoffix Znet via RT]

I've narrowed down the issue to this condition: if the package's name is part 
something that we already have in core, then this bug (is it a bug?) appears:

No names to clash with core types; everything works:
$ cat Foo.pm6 
unit package Bar;
class Ber {}
$ perl6 -I. -MFoo -e 'say Bar::Ber'
(Ber)

Now package, as Op's, clashes with core Pod:: namespace the issue is there:
$ cat Foo.pm6 
unit package Pod;
class Ber {}
$ perl6 -I. -MFoo -e 'say Pod::Ber'
Could not find symbol '&Ber'
in block  at -e line 1

And this can be reproduced if we clash with something else, like IO role:
$ cat Foo.pm6 
unit package IO;
class Ber {}
$ perl6 -I. -MFoo -e 'say IO::Ber'
Could not find symbol '&Ber'
in block  at -e line 1



On Wed Oct 12 07:07:19 2016, mt1...@gmail.com wrote:
> Hi,
> 
> I wanted to define a class in the 'Pod' package like so (in file 
> lib/Pod/Render.pm6)
> 
> 
> use Pod::To::HTML;
> unit package Pod;
> class Render {
># ...
> }
> 
> 
> Then use it
> 
> use Pod::Render;
> my Pod::Render $pr .= new;
> 
> Throws the exception
> 
> ===SORRY!===
> Type 'Pod::Render' is not declared
> at /home/marcel/Languages/Perl6/Projects/pod-render/bin/pod-render.pl6:10
> -->   my Pod::Render⏏ $pr .= new;
> Malformed my
> at /home/marcel/Languages/Perl6/Projects/pod-render/bin/pod-render.pl6:10
> -->   my Pod::⏏Render $pr .= new;
> 
> 
> I expect it to instantiate without problems as seen in my other projects.
> 
> When the declaration becomes like below, everything goes well.
> 
> use Pod::To::HTML;
> class Pod::Render {
> 
> }
> 
> 
> Greetings,
> Marcel
> 

[perl #129862] [BUG][POD] Pod::To::Text failing on uneven row lengths

[Zoffix Znet via RT]

PR merged[^1]; tests needed.

[1] 
https://github.com/rakudo/rakudo/commit/7af9ec9d90d4ec8e9732e979729df85a80f7ec11


On Wed Oct 12 13:50:31 2016, david.warring wrote:
> I got this error from a typo in a large table. Needed to do a little
> work to find the problematic row.
> 
> Have raised Rakudo PR#903 which hopefully addressees this
> 
> On Wed Oct 12 13:34:45 2016, tbrowder wrote:
> > On Wed, Oct 12, 2016 at 3:22 PM, David Warring  > follo...@perl.org>
> > wrote:
> > > # New Ticket Created by  David Warring
> > > # Please include the string:  [perl #129862]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=129862 >
> > >
> > >
> > > Consider pod.pl:
> > >
> > > =begin pod
> > >
> > > =begin table
> > > a | b | c
> > > l | m | n
> > > x | y
> > > =end table
> >
> > With the current state of rakudo
> > ​ pod
> > , ill-formed tables are problematic.  Try redoing the table like this
> > (adding the separator for the missing column, making the column
> > spacing the
> > same, lining up the column separators):
> >
> > =begin table
> > a | b | c
> > l | m | n
> > x | y |
> > =end table
> >
> > ​It still might not work with the empty cell.

[perl #129874] [BUG] Strange closure-related issue in block interpolation

[Zoffix Znet via RT]

Spoke too soon. The issue is the Nil return type constraint. Golfed:

 m: sub (-->Nil) { fail "{42}"; }()
 rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤  in sub  at 
 line 1␤␤  in sub  at  line 1␤  in block  at  line 
1␤␤Actually thrown at:␤  in block  at  line 1␤␤»


On Thu Oct 13 18:31:07 2016, c...@zoffix.com wrote:
> 
>  Hm. Found a strange bug in core that I can't reproduce.
>  m: Bag.new-from-pairs: 1 => -1;
>rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤
> in
>   block  at  line 1␤Use of Nil in string context␤  in block
>at  line 1␤Found negative values for  in ␤  in block
>at  line 1␤␤Actually thrown at:␤  in block  at
> 
> l…»
>Those Nils? It's the two interpolated blocks on this line:
> https://github.com/rakudo/rakudo/blob/a09c8dc99ef7ae60876ad7a7cc478f7e303eb804/src/core/Baggy.pm#L48
>If I change it to this: my $wat = @toolow.join:  ' '; my
>   $name = self.^name; fail "Found negative values for $wat in $name"
> if
> @toolow;  then the bug goes away.
>m: role Foo { method !meow { my @meows = ;
> fail
>   "some {@meows}" if @meows; }; method moo { self!meow; 42 } }; class
> ::
> does Foo {}.moo
>rakudo-moar a09c8d: OUTPUT«some foo bar ber␤  in method
> meow
>   at  line 1␤  in method moo at  line 1␤  in block  at
>line 1␤␤Actually thrown at:␤  in method moo at  line 1␤
> in
> block  at  line 1␤␤»
>  But can't reproduce it ^ :/
> 
> https://irclog.perlgeek.de/perl6-dev/2016-10-14#i_13399643

[perl #129894] 1**NaN is 1, but any numeric operation with NaN should be NaN (say 1**NaN)

[Zoffix Znet via RT]

More, at nqp level:

 m: use nqp; dd nqp::pow_n(NaN, 0e0)
 rakudo-moar 2b5226: OUTPUT«1e0␤»
 m: use nqp; dd nqp::pow_n(1e0, NaN)
 rakudo-moar 2b5226: OUTPUT«1e0␤»

[perl #129894] 1**NaN is 1, but any numeric operation with NaN should be NaN (say 1**NaN)

[Zoffix Znet via RT]

So that leaves nqp::pow_n(1e0, NaN) == 1e0. Is that also part of IEEE?

I see that Perl 5 gives a NaN for NaN**0, but 1 for 1**NaN:

zoffix@VirtualBox:~$ perl -wlE 'say -sin(9**9**9)**0'   


   
NaN
zoffix@VirtualBox:~$ perl -wlE 'say 1**-sin(9**9**9)'   


   
1




On Mon Oct 17 00:25:15 2016, barto...@gmx.de wrote:
> On Sun Oct 16 11:07:16 2016, alex.jakime...@gmail.com wrote:
> > Just for the record, another case:
> >
> > Code:
> > say NaN**0
> >
> > Output:
> > 1
> 
> There was an earlier RT for this one (coming to the conclusion that 1
> is a reasonable answer here):
> https://rt.perl.org/Ticket/Display.html?id=124450. It has a link to a
> discussion from stackoverflow -- to me the following comment
> was interesting: http://stackoverflow.com/a/17865226

[perl #129894] 1**NaN is 1, but any numeric operation with NaN should be NaN (say 1**NaN)

[Zoffix Znet via RT]

I took a gander at 2008 IEEE 754 standard and section "9.2.1 Special values" 
has this to say:

pow (x, ±0) is 1 for any x (even a zero, quiet NaN, or infinity)
pow (+1, y) is 1 for any y (even a quiet NaN)

So our behaviour is correct. Rejecting.


On Mon Oct 17 03:05:33 2016, c...@zoffix.com wrote:
> So that leaves nqp::pow_n(1e0, NaN) == 1e0. Is that also part of IEEE?
> 
> I see that Perl 5 gives a NaN for NaN**0, but 1 for 1**NaN:
> 
> zoffix@VirtualBox:~$ perl -wlE 'say -sin(9**9**9)**0'
> NaN
> zoffix@VirtualBox:~$ perl -wlE 'say 1**-sin(9**9**9)'
> 1
> 
> 
> 
> 
> On Mon Oct 17 00:25:15 2016, barto...@gmx.de wrote:
> > On Sun Oct 16 11:07:16 2016, alex.jakime...@gmail.com wrote:
> > > Just for the record, another case:
> > >
> > > Code:
> > > say NaN**0
> > >
> > > Output:
> > > 1
> >
> > There was an earlier RT for this one (coming to the conclusion that 1
> > is a reasonable answer here):
> > https://rt.perl.org/Ticket/Display.html?id=124450. It has a link to a
> > discussion from stackoverflow -- to me the following comment
> > was interesting: http://stackoverflow.com/a/17865226

[perl #60490] Rakudo doesn't report an error on log(0)

[Zoffix Znet via RT]

Looks like this bug re-appeared and Rakudo's function all come down to 
nqp::log_n():

 m: say log 0
 rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
 m: use nqp; say nqp::log_n(0e0)
 rakudo-moar 2dd0dd: OUTPUT«-Inf␤»

2008 IEEE 754[^1], in section 9.2, says log(0) needs to give a divideByZero 
exception.

[1] http://www.csee.umbc.edu/~tsimo1/CMSC455/IEEE-754-2008.pdf



On Wed Nov 12 07:53:52 2008, pmichaud wrote:
> On Tue, Nov 11, 2008 at 11:57:02PM -0800, Carl Mäsak wrote:
> > Rakudo r32568:
> >
> > $ ./perl6 -e 'my $result = log(0); say "Still alive after getting
> > $result"'
> > Still alive after getting -inf
> 
> Now fixed in r32574:
> 
> $ ./parrot perl6.pbc -e 'my $result = log(0); say $result;'
> Can't take log of 0
> 
> $
> 
> 
> Note that instead of throwing an exception immediately, log(0)
> returns a Failure that then throws an exception if it is used.
> 
> Pm

[perl #60490] Rakudo doesn't report an error on log(0)

[Zoffix Znet via RT]

I should've read more:

"Section 7.3 Division by zero", says 'For logB(0) when logBFormat is a 
floating-point format, the sign of the infinity is minus (−∞).'

And I'm guessing this case matches it, because JVM and C standard lib too give 
-Inf and nqp just maps the operations to VM's operations.

Reclosing :)




On Mon Oct 17 05:58:14 2016, c...@zoffix.com wrote:
> Looks like this bug re-appeared and Rakudo's function all come down to
> nqp::log_n():
> 
>  m: say log 0
>  rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
>  m: use nqp; say nqp::log_n(0e0)
>  rakudo-moar 2dd0dd: OUTPUT«-Inf␤»
> 
> 2008 IEEE 754[^1], in section 9.2, says log(0) needs to give a
> divideByZero exception.
> 
> [1] http://www.csee.umbc.edu/~tsimo1/CMSC455/IEEE-754-2008.pdf
> 
> 
> 
> On Wed Nov 12 07:53:52 2008, pmichaud wrote:
> > On Tue, Nov 11, 2008 at 11:57:02PM -0800, Carl Mäsak wrote:
> > > Rakudo r32568:
> > >
> > > $ ./perl6 -e 'my $result = log(0); say "Still alive after getting
> > > $result"'
> > > Still alive after getting -inf
> >
> > Now fixed in r32574:
> >
> > $ ./parrot perl6.pbc -e 'my $result = log(0); say $result;'
> > Can't take log of 0
> >
> > $
> >
> >
> > Note that instead of throwing an exception immediately, log(0)
> > returns a Failure that then throws an exception if it is used.
> >
> > Pm

[perl #129915] [LTA] ∞ as literal Inf not recognized in signatures

[Zoffix Znet via RT]

Another case: fancy pants −

 m: sub foo (−42) {say "got it"}(−42)
 rakudo-moar b1f77c: OUTPUT«===SORRY!=== Error while compiling 
␤Missing block␤at :1␤--> sub foo (⏏−42) {say "got it"}(−42)␤»

 m: sub foo (−Inf) {say "got it"}(−Inf)
 rakudo-moar b1f77c: OUTPUT«===SORRY!=== Error while compiling 
␤Missing block␤at :1␤--> sub foo (⏏−Inf) {say "got it"}(−Inf)␤»

[perl #129911] [BUG] Rat literals Misinterpreted as regex in signatures

[Zoffix Znet via RT]

>From what I understand, this syntax produces 1 divided by 3, which gets later 
>interpreted into something plague-baring.

To specify a literal Rat, use angled brackets, which works without requiring 
any fixes:

 m: multi foo (<1/3>) {say "Rat!" }; multi foo ($) { say "something 
else" }; foo 1/3; foo 42
 rakudo-moar 127b3b: OUTPUT«Rat!␤something else␤»

Rejecting.


On Tue Oct 18 08:58:29 2016, c...@zoffix.com wrote:
> I kinda thought this would work:
> 
>   m: multi foo (1/3) {}
>   rakudo-moar 20d37a: OUTPUT«===SORRY!=== Error while  
> compiling ␤Unable to parse regex; couldn't find final '/'␤at  
> :1␤--> multi foo (1/3⏏) {}␤expecting any of:␤ 
> infix stopper␤»
> 
> Given this works:
> 
>   m: multi foo (1.3) {}
>   rakudo-moar 20d37a: ( no output )
>   m: multi foo (1e3) {}
>   rakudo-moar 20d37a: ( no output )
>   m: multi foo (1) {}
>   rakudo-moar 20d37a: ( no output )
> 

[perl #129956] [BUG] Inconsistent behavior of .Int

[Zoffix Znet via RT]

Thanks for the report,

First to clarify: Nil.Int is *not* an error as you state, it's a warning and 
you can suppress it with `quietly` block. A numeric Nil is 0, which is what you 
get in return.

As for the problem you're trying to solve, you can use the following code. If a 
Nil is returned from
prompt(), the `//` operator will change it to a `NaN`. Attempting to coerce a 
NaN to a Nil is a Failure,
and so the `when Int` block won't match it.

given (prompt('int: ')//'NaN').Int {
   when Int { say "you just entered the integer $_" }
   default { say "that was totally not an integer" }
}

There's also val() routine: https://docs.perl6.org/routine/val with a caveat 
that an empty string is 0.

With that said, there's no bug here, so I'm rejecting the ticket.

Thanks,
ZZ


On Mon Oct 24 08:19:21 2016, jkra...@mark17.net wrote:
> For most (all I've tested) types the method .Int works pretty much the
> same and as I'd expect: it either returns an Int or, if not possible
> because the invocant can't be converted to Int in a useful way or the
> invocant is not defined, it throws an exception. However Cool and
> classes that inherit from it and don't override the .Int method (namely
> Nil) behave differently in a potential harmful way: instead of throwing
> an exception, .Int here prints an error and returns 0. The problem with
> this is a) I can't check if a problem occured with try/CATCH, b) I can't
> check if the conversion succeeded by checking the return value, since 0
> is a valid and defined Int and c) it's very inconsistent with other
> types and makes me have to write extra checks prior to calling .Int.
> Random example:
> 
> 
> given try prompt('int: ').Int {
>   when Int { say "you just entered the integer $_" }
>   default { say "that was totally not an integer" }
> }
> 
> 
> This would normally allow me to prompt for a number and easily check if
> the input indeed was a valid number. The only problem is Nil (returned
> by prompt in case of EOF), which becomes 0, which is rather unexpected
> behavior in my opinion.
> 
> Also finally, since .Int on Nil/Cool:U is already printing an error, I
> think it's obvious that calling .Int on them indeed *is* an error, so
> instead of printing that but continuing normally by returning 0 it
> should actually behave like there was an error, i.e. throw and exception
> so the programmer can deal with it using regular control flow
> (try/CATCH) and not make guesses about whether the invocant contained
> some value that was successfully converted to 0 or if the conversion
> failed.

[perl #129956] [BUG] Inconsistent behavior of .Int

[Zoffix Znet via RT]

Actually, this is a better version, since it takes care to not consider, say, 
4.4 as a Int:

given quietly val prompt('int: ') || NaN {
when Int { say "you just entered the integer $_"; }
default { say "that was totally not an integer" }
}



On Tue Oct 25 10:15:56 2016, c...@zoffix.com wrote:
> Thanks for the report,
> 
> First to clarify: Nil.Int is *not* an error as you state, it's a
> warning and you can suppress it with `quietly` block. A numeric Nil is
> 0, which is what you get in return.
> 
> As for the problem you're trying to solve, you can use the following
> code. If a Nil is returned from
> prompt(), the `//` operator will change it to a `NaN`. Attempting to
> coerce a NaN to a Nil is a Failure,
> and so the `when Int` block won't match it.
> 
> given (prompt('int: ')//'NaN').Int {
>when Int { say "you just entered the integer $_" }
>default { say "that was totally not an integer" }
> }
> 
> There's also val() routine: https://docs.perl6.org/routine/val with a
> caveat that an empty string is 0.
> 
> With that said, there's no bug here, so I'm rejecting the ticket.
> 
> Thanks,
> ZZ
> 
> 
> On Mon Oct 24 08:19:21 2016, jkra...@mark17.net wrote:
> > For most (all I've tested) types the method .Int works pretty much
> > the
> > same and as I'd expect: it either returns an Int or, if not possible
> > because the invocant can't be converted to Int in a useful way or the
> > invocant is not defined, it throws an exception. However Cool and
> > classes that inherit from it and don't override the .Int method
> > (namely
> > Nil) behave differently in a potential harmful way: instead of
> > throwing
> > an exception, .Int here prints an error and returns 0. The problem
> > with
> > this is a) I can't check if a problem occured with try/CATCH, b) I
> > can't
> > check if the conversion succeeded by checking the return value, since
> > 0
> > is a valid and defined Int and c) it's very inconsistent with other
> > types and makes me have to write extra checks prior to calling .Int.
> > Random example:
> >
> >
> > given try prompt('int: ').Int {
> >   when Int { say "you just entered the integer $_" }
> >   default { say "that was totally not an integer" }
> > }
> >
> >
> > This would normally allow me to prompt for a number and easily check
> > if
> > the input indeed was a valid number. The only problem is Nil
> > (returned
> > by prompt in case of EOF), which becomes 0, which is rather
> > unexpected
> > behavior in my opinion.
> >
> > Also finally, since .Int on Nil/Cool:U is already printing an error,
> > I
> > think it's obvious that calling .Int on them indeed *is* an error, so
> > instead of printing that but continuing normally by returning 0 it
> > should actually behave like there was an error, i.e. throw and
> > exception
> > so the programmer can deal with it using regular control flow
> > (try/CATCH) and not make guesses about whether the invocant contained
> > some value that was successfully converted to 0 or if the conversion
> > failed.

[perl #129906] Error when role stubbed as class

[Zoffix Znet via RT]

There's another couple of LTA errors for this, such us when a stubbed class is 
attempted to be `does` with or when a stubbed role is `does` with before it's 
defined:

 m: class A { ... }; class B does A { }; class A { }
 rakudo-moar a581bf: OUTPUT«Unhandled exception: No such method 'item' 
for invocant of type 'A'␤   at :1  
(/home/camelia/rakudo-m-inst-1/share/perl6/runtime/CORE.setting.moarvm:print_exception)␤
 from gen/moar/m-CORE.setting:26858  (/home/camelia/rakudo-m-inst-1/share/per…»
 m: role A { ... }; class B does A { }; role A { }
 rakudo-moar a581bf: OUTPUT«Use of uninitialized value of type Any in 
string context.␤Methods .^name, .perl, .gist, or .say can be used to stringify 
it to something meaningful.␤  in any try_select at gen/moar/m-Metamodel.nqp 
line 2647␤===SORRY!=== Error while compiling  One line example of the problem:
> 
> % perl6 -e 'class A { ... }; class B does A { }; role A { }'
> Unhandled exception: No such method 'item' for invocant of type 'A'
>at :1
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:print_exception)
>  from gen/moar/m-CORE.setting:24949
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:)
>  from gen/moar/stage2/NQPHLL.nqp:1559
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
>  from src/Perl6/Compiler.nqp:27
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
>  from gen/moar/stage2/NQPHLL.nqp:1499
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:command_line)
>  from gen/moar/m-main.nqp:47
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:MAIN)
>  from gen/moar/m-main.nqp:38
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:)
>  from :1
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:)
>  from :1
>  (/Users/sterling/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:)
> 
> Clearly, it would be better for there to be a nice error like "type A
> stubbed as class on line X but implemented as role on line Y".

[perl #129909] [RFC] cannot compile to jar files for client use using --target=jvm

[Zoffix Znet via RT]

There are plans to make that a possibility eventually, but as far as I know 
that's not a priority of what the developers are focusing on at the moment.


On Wed, 19 Oct 2016 13:55:47 -0700, data...@gmail.com wrote:
> Thank you for the prompt response.
> 
> I'll review the JVM script provided, it may run!
> 
> Since the feature isn't finished, is there a way to generate a MOAR
> file I
> can provide my users which "just runs" but doesn't include the secret
> sauce?
> 
> or is this an unreasonable expectation?
> 
> 
> 
> On Wed, Oct 19, 2016 at 12:00 PM, Pepe Schwarz via RT <
> perl6-bugs-follo...@perl.org> wrote:
> 
> > On Tue Oct 18 18:07:05 2016, data...@gmail.com wrote:
> > > perl6 --target=jvm  --ll-exception --output=guess.jar guess.p6
> > >
> > >
> > > java.lang.NullPointerException
> > >
> > > in command_eval (gen/jvm/stage2/NQPHLL.nqp:1217)
> > >
> > > in command_eval (src/Perl6/Compiler.nqp:27)
> > >
> > > in command_line (gen/jvm/stage2/NQPHLL.nqp:1181)
> > >
> > > in MAIN (gen/jvm/main.nqp:47)
> > >
> > > in  (gen/jvm/main.nqp:38)
> > >
> > > in  (gen/jvm/main.nqp)
> > >
> > >
> > >
> > > On Tue, Oct 18, 2016 at 4:43 PM, Elizabeth Mattijsen via RT <
> > > perl6-bugs-follo...@perl.org> wrote:
> > >
> > > > What happens if you add --ll-exception to the command line?
> > > >
> > > > > On 18 Oct 2016, at 05:42, Felipe Valdes (via RT) <
> > > > perl6-bugs-follo...@perl.org> wrote:
> > > > >
> > > > > # New Ticket Created by  Felipe Valdes
> > > > > # Please include the string:  [perl #129909]
> > > > > # in the subject line of all future correspondence about this
> > > > > issue.
> > > > > # https://rt.perl.org/Ticket/Display.html?id=129909 >
> > > > >
> > > > >
> > > > > I want my clients to be able to run jar files
> > > > > generated by the perl6 command:
> > > > >
> > > > > The program:
> > > > >
> > > > > my $num = (1..100).pick;
> > > > >
> > > > > my $guess_count = 0;
> > > > >
> > > > >
> > > > > loop {
> > > > >
> > > > > my $guess = prompt("guess");
> > > > >
> > > > > if $guess == $num {
> > > > >
> > > > > say "Well done";
> > > > >
> > > > > last;
> > > > >
> > > > > }
> > > > >
> > > > > if $guess > $num {
> > > > >
> > > > > say "Lower";
> > > > >
> > > > > }
> > > > >
> > > > > if $guess < $num {
> > > > >
> > > > > say "Higher";
> > > > >
> > > > > }
> > > > >
> > > > > if $guess_count == 7 {
> > > > >
> > > > > say "you suck!";
> > > > >
> > > > > last;
> > > > >
> > > > > }
> > > > >
> > > > > $guess_count++;
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > > the compilation command:
> > > > >
> > > > > perl6 --target=jvm --output=guess.jar guess.p6
> > > > >
> > > > >
> > > > > the result:
> > > > >
> > > > > ===SORRY!===
> > > > >
> > > > > java.lang.NullPointerException
> > > > >
> > > > >
> > > > > The version:
> > > > >
> > > > > This is Rakudo version 2016.10-9-g906719c built on JVM
> > > > >
> > > > > implementing Perl 6.c.
> > > > >
> > > > >
> > > > > I think the error message is less than awesome.
> > > > >
> > > > >
> > > > > Felipes-MacBook-Pro:backend2 a$ perl6 --stagestats --target=jvm
> > > > > --output=guess.jar guess.p6
> > > > >
> > > > > Stage start  :   0.000
> > > > >
> > > > > Stage parse  :   3.405
> > > > >
> > > > > Stage syntaxcheck:   0.001
> > > > >
> > > > > Stage ast:   0.001
> > > > >
> > > > > Stage optimize   :   0.140
> > > > >
> > > > > Stage jast   :   0.395
> > > > >
> > > > > Stage classfile  :   0.081
> > > > >
> > > > > Stage jar:   0.000
> > > > >
> > > > > Stage jvm:   0.006
> > > > >
> > > > > ===SORRY!===
> > > > >
> > > > > java.lang.NullPointerException
> > > > >
> > > > > Felipes-MacBook-Pro:backend2 a$
> > > >
> > > >
> > > >
> >
> > The feature you're asking for does not exist at the moment.
> >
> > You can get the precompiled compilation unit of a Perl 6 program as a
> > .jar
> > with C<--target=jar>, but that doesn't help you, because it a
> > compilation
> > unit that can be understood by a Rakudo executable, not a jar file
> > that can
> > be understood by any JVM.
> >
> > The file at [1] is a shell script that includes the step that will
> > eventually be integrated into the perl6 binary to generate a self-
> > contained
> > jar file from Perl 6 code, albeit in the simplest way possible. That
> > is,
> > bundle the whole interpreter and make that run a predefined
> > compilation
> > unit. There is a corresponding Rakudo branch
> >
> > Note though that the branch hasn't been updated in quite a while and
> > might
> > not necessarily merge cleanly against current HEAD.
> >
> > [1] https://github.com/perl6/nqp/blob/standalone-jar/tools/jvm/
> > one-jar-script.sh
> >

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

Here's a link to the above IRC conversation, which continued after the quoted 
part: https://irclog.perlgeek.de/perl6/2016-11-04#i_13517260

To expand, it's not just Hashes that have this issue; Arrays, SetHash, and 
Complex also do, and probably many others. And the issue is not just about not 
setting default values for attributes when instantiating the object, but use of 
attributes as well.

 m: class Foo does Setty { has %.elems;  }
 rakudo-moar a581bf: OUTPUT«===SORRY!=== Error while compiling
␤Attribute '%!elems' already exists in the class 'Foo', but a role 
also
wishes to compose it␤at :1␤»

Above, if we imagine %.elems as some new internal attribute we added to Setty, 
you can see it now breaks some user's code.

So I think it would be useful to create some sort of convention where we're 
less likely to impact changes to users' code by making some internal change. 
For attributes, we can prefix the names with 'rak-' or something short and 
consistent to mark them as internal. For the .new() issue with Hashes and 
others, I think lizmat proposed doing something similar to what we do in 
Date/DateTime classes.

[perl #130039] [BUG] Can't represent Num literals close to the representable maximum in Rakudo

[Zoffix Znet via RT]

On Mon, 07 Nov 2016 03:50:49 -0800, masak wrote:
>  Wondering what the highest number is below Inf and lowest
> above -Inf
>  MARTIMM: for the Num type, there's a highest representable
> number below Inf
>  m: say 1e308
>  rakudo-moar 1c425f: OUTPUT«1e+308␤»
>  this is the largest Num below Inf I can get Rakudo to
> represent.
>  1.7976931348623157081e+308 on x86_64
>  (and probably x86)
>  I expected it to be something like that, but the cutoff in
> Rakudo was at exactly 1.000e308
>  maybe some artificial limit has been put in somewhere for
> safety reasons
>  m: say 1.7976931348623157081e200 * 1e108
>  rakudo-moar 1c425f: OUTPUT«1.79769313486232e+308␤»
>  a-ha :)
>  so Rakudo can represent them, just not with
> scientific-notation number literals
>  I... would be tempted to call that a bug.
> * masak submits rakudobug

The issue was due to calculations involved during the number's parsing, where 
the base
value was first multiplied by enough powers of 10 to make it fraction-less and 
then
multiplied by "e" powers of 10. For numbers close to the limit, this caused 
overflow to
Inf before the final step (of dividing the number back) could be done.

So 1.1e307 overflown, 1.1e306 wouldn't, but 1.11e306 would, because 1.11 was 
turned into 111 in mid-step.

Fixed in 
https://github.com/rakudo/rakudo/commit/​729d7e34124827a4e0b772b049be95cf911dd7cf
Tests added in https://rt.perl.org/Public/Bug/Display.html?id=130039

[perl #130034] A andthen B orelse C leaks some internal Block

[Zoffix Znet via RT]

On Sun, 06 Nov 2016 20:25:50 -0800, lloyd.fo...@gmail.com wrote:
> 15:18 < llfourn_> m: say (Str andthen .uc orelse "foo") # more golfed
> 15:18 <+camelia> rakudo-moar 1c425f: OUTPUT«-> ;; $_ is raw {
> #`(Block|81391040) ... }␤»
> 15:23 < llfourn_>  m: say (Str andthen .uc orelse "foo")("wee")
> 15:23 <+camelia> rakudo-moar 1c425f: OUTPUT«foo␤»
> 
> unless I totally missed what these are meant to do a Block is not what
> should be returned from this expression.

The issue is due to `andthen` (and `notandthen`) actually returning Empty 
instead of the advertized "first undefined value" and since Empty is a Slip, it 
causes an issue with `orelse`.

While the fix is trivial, it causes fallout with `with` operator and right now 
we're waiting for TimToady to chime in on how things should be done. IRC 
conversation: https://irclog.perlgeek.de/perl6-dev/2016-11-09#i_13539174

[perl #129363] duckmap doesn't retain structure types

[Zoffix Znet via RT]

On Tue, 08 Nov 2016 06:31:15 -0800, c...@fastmail.co.uk wrote:
> Pull requests raised for discussion:
> 
> https://github.com/rakudo/rakudo/pull/915
> https://github.com/perl6/roast/pull/180

Merged. Thanks.

[perl #129906] Error when role stubbed as class

[Zoffix Znet via RT]

Thanks for the report.

Fixed in https://github.com/rakudo/rakudo/commit/a822bcf9cf
Tests added in https://github.com/perl6/roast/commit/1e5a081bed

[perl #130034] A andthen B orelse C leaks some internal Block

[Zoffix Znet via RT]

Empty isn't passed as an arg. It's just an empty slip that gets flattened, so 
`orelse` ends up with a single block as the arg (the thunked "foo"), which gets 
returned.

I don't know whether it should be evaluated first.


On Wed, 09 Nov 2016 15:52:35 -0800, lloyd.fo...@gmail.com wrote:
> Thanks for the update. As viki hinted at, isn't this a bug in itself
> (andthen problems aside). Why does Empty as the first arg to orelse return
> a block?
> 
> say (Empty orelse "foo")
> 
> -> ;; $_ is raw { #`(Block|140421623865904) ... }
> 
> Where as
> 
> say (Any orelse "foo")
> 
> returns the correct value.
> 
> On Thu, Nov 10, 2016 at 1:51 AM Zoffix Znet via RT <
> perl6-bugs-follo...@perl.org> wrote:
> 
> > On Sun, 06 Nov 2016 20:25:50 -0800, lloyd.fo...@gmail.com wrote:
> > > 15:18 < llfourn_> m: say (Str andthen .uc orelse "foo") # more golfed
> > > 15:18 <+camelia> rakudo-moar 1c425f: OUTPUT«-> ;; $_ is raw {
> > > #`(Block|81391040) ... }␤»
> > > 15:23 < llfourn_>  m: say (Str andthen .uc orelse "foo")("wee")
> > > 15:23 <+camelia> rakudo-moar 1c425f: OUTPUT«foo␤»
> > >
> > > unless I totally missed what these are meant to do a Block is not what
> > > should be returned from this expression.
> >
> > The issue is due to `andthen` (and `notandthen`) actually returning Empty
> > instead of the advertized "first undefined value" and since Empty is a
> > Slip, it causes an issue with `orelse`.
> >
> > While the fix is trivial, it causes fallout with `with` operator and right
> > now we're waiting for TimToady to chime in on how things should be done.
> > IRC conversation:
> > https://irclog.perlgeek.de/perl6-dev/2016-11-09#i_13539174
> >
> >

[perl #130031] [BUG][BUILD] gmake install step fails under Windows for 2016.10 with the Strawberry Perl buildchain

[Zoffix Znet via RT]

This has been fixed by https://github.com/MoarVM/MoarVM/commit/404ed261be00e2
I see an already-existing test for mkdir in S32-io/mkdir_rmdir.t, so I think 
this one just slipped through due to being Windows-specific.



On Mon, 07 Nov 2016 05:18:43 -0800, 1parr...@gmail.com wrote:
> I've also encountered a problem with "make" blowing up, on a Raspberry
> Pi, which I haven't yet investigated in enough detail to report
> formally. I first attributed it to some peculiarity of the
> environment, but this sounds an awful lot like the same problem.
> 
> On 11/6/16, Steve Mynott  wrote:
> > # New Ticket Created by  Steve Mynott
> > # Please include the string:  [perl #130031]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=130031 >
> >
> >
> > Although discovered while trying to create Rakudo Star 2016.10
> > binaries for
> > Windows I also see the same error with the plain Rakudo 2016.10
> > release. I
> > had no problems doing the same with 2016.07.
> >
> > Using the gcc and gmake supplied with Strawberry Perl the final
> > "gmake
> > install" step fails with
> >
> > C:\Strawberry\perl\bin\perl.exe -MExtUtils::Command -e cp
> > perl6.moarvm
> > perl6-debug.moarvm C:\rakudo/share/perl6/runtime
> > C:\Strawberry\perl\bin\perl.exe -MExtUtils::Command -e mkpath
> > C:\rakudo/share/perl6/runtime/dynext
> > C:\Strawberry\perl\bin\perl.exe -MExtUtils::Command -e cp
> > dynext/perl6_ops_moar.dll C:\rakudo/share/perl6/runtime/dynext
> > .\perl6-m.bat tools/build/upgrade-repository.pl C:\rakudo/share/perl6
> > Failed to create directory 'C:\rakudo\share\perl6\resources' with
> > mode
> > '0o777': Failed to mkdir: 2
> >  in any  at ././CORE.setting.moarvm line 1
> >  in block  at tools/build/upgrade-repository.pl line 1
> >
> > Actually thrown at:
> >  in block  at tools/build/upgrade-repository.pl line 1
> >
> > makefile:553: recipe for target 'm-install' failed
> > gmake[1]: *** [m-install] Error 1
> > gmake[1]: Leaving directory
> > 'C:/Users/steve/Downloads/rakudo-star-2016.10/rakudo'
> > makefile:53: recipe for target 'rakudo-install' failed
> > gmake: *** [rakudo-install] Error 2
> >
> > --
> > 4096R/EA75174B Steve Mynott 
> >

[perl #130099] .defined doesn't work with junctions

[Zoffix Znet via RT]

Thanks for the report.

Fixed in https://github.com/rakudo/rakudo/commit/189cb23e84
Tests added in https://github.com/perl6/roast/commit/6b84580ecc


On Mon, 14 Nov 2016 04:37:49 -0800, lloyd.fo...@gmail.com wrote:
> < llfourn> m: say defined all(Any,"foo") # Why is this true? Shouldn't it
> autothread?
> <+camelia> rakudo-moar 59bb1b: OUTPUT«True␤»
> < lizmat> llfourn: that feels like a bug
> 
> Expected behaviour is that it should autothread and call .defined on the
> values in the junction.
> 
> https://irclog.perlgeek.de/perl6/2016-11-14#i_13563873
> ^ Lizmat++ tried a quickfix but it didn't work so rakudobugging so it can
> be addressed later.

[perl #130095] MAST::Frame error encountered.

[Zoffix Znet via RT]

Thanks for the report.

Would you provide a working example we can reproduce with? For example, with 
the repo you linked, I'm getting "Could not find XML::LibXML::CStructs at line 
5 in:" and no such module in the ecosystem.

Also, what Perl 6 version are you using? (perl6 -v)




On Sun, 13 Nov 2016 23:16:43 -0800, clifton.w...@gmail.com wrote:
> While working on a Perl project, I ran into an odd error trying to
> create a
> test script.
> 
> You can find the entire project, here: https://github.com/Xliff/p6-
> xslt
> 
> I have attached the relevant scripts to this message.
> 
> The error message follows:
> 
> cbwood@infinity:~/projects/p6-xml-xslt$ perl6 --ll-exception -I
> ../p6-XML-LibXML-work/lib -I lib t/01-basic.t
> Expected MAST::Frame, but didn't get one
>at gen/moar/stage2/QAST.nqp:6644
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/QAST.moarvm:assemble_to_file)
>  from gen/moar/stage2/NQPHLL.nqp:407
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:mbc)
>  from gen/moar/stage2/NQPHLL.nqp:1677
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:compile)
>  from gen/moar/stage2/NQPHLL.nqp:1410
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:eval)
>  from gen/moar/stage2/NQPHLL.nqp:1631
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:evalfiles)
>  from gen/moar/stage2/NQPHLL.nqp:1525
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
>  from src/Perl6/Compiler.nqp:27
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
>  from gen/moar/stage2/NQPHLL.nqp:1499
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:command_line)
>  from gen/moar/m-main.nqp:47
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:MAIN)
>  from gen/moar/m-main.nqp:38
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:)
>  from :1
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:)
>  from :1
>  (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/perl6.moarvm:)
> 
> at gen/moar/m-CORE.setting:26689
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:throw)
> from gen/moar/m-CORE.setting:800
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:die)
> from gen/moar/m-CORE.setting:788
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:die)
> from gen/moar/m-CORE.setting:42965
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:precompile)
> from gen/moar/m-CORE.setting:42887
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:precompile)
> from gen/moar/m-CORE.setting:42727
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:try-load)
> from gen/moar/m-CORE.setting:43668
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:)
> from gen/moar/m-CORE.setting:43661
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:need)
> from gen/moar/m-CORE.setting:43688
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/perl6/runtime/CORE.setting.moarvm:need)
> from src/Perl6/World.nqp:1199
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/World.moarvm:load_module)
> from src/Perl6/World.nqp:1129
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/World.moarvm:do_pragma_or_load_module)
> from src/Perl6/Grammar.nqp:1565
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement_control:sym)
> from gen/moar/stage2/QRegex.nqp:1371
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/QRegex.moarvm:!protoregex)
> from :1
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement_control)
> from src/Perl6/Grammar.nqp:1251
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement)
> from src/Perl6/Grammar.nqp:1180
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statementlist)
> from gen/moar/stage2/NQPHLL.nqp:1011
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/NQPHLL.moarvm:LANG)
> from src/Perl6/Grammar.nqp:1579
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG)
> from src/Perl6/Grammar.nqp:1164
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit)
> from src/Perl6/Grammar.nqp:467
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/Perl6/Grammar.moarvm:TOP)
> from gen/moar/stage2/QRegex.nqp:2093
> (/home/cbwood/.rakudobrew/moar-
> nom/install/share/nqp/lib/QRegex.moarvm:parse)
> from gen/moar/stage2/NQPHLL.nqp:1718
> (/home/cbwood/.rakud

[perl #130081] [@LARRY] Grammar.parse DWIMs only if your TOP rule has $ on the end

[Zoffix Znet via RT]

My personal two cents from someone who knows very little about the workings of 
grammars and regexes is this is quite a bit of a WAT. `regex` is meant to 
backtrack and it does, for example here:

 m: say grammar { regex TOP {  'foo' }; regex foo { [ ‘a’ || 
‘abc’ ] } }.parse: 'abcfoo'
 rakudo-moar dfb58d: OUTPUT«｢abcfoo｣␤ foo => ｢abc｣␤»
 m: say grammar { regex TOP {  'foo' }; token foo { [ ‘a’ || 
‘abc’ ] } }.parse: 'abcfoo'
 rakudo-moar dfb58d: OUTPUT«Nil␤»

However, if the `regex` is a top-level rule, then we add an extra requirement 
that to enable backtracking the user also needs an anchor to the end of string.

It's a special exception to the rule and would need to be documented in Traps, 
but why do we have it?


On Sat, 12 Nov 2016 18:36:15 -0800, alex.jakime...@gmail.com wrote:
> To demonstrate how it works, let's say we have this grammar:
> 
> grammar G { regex TOP { ‘a’ || ‘abc’ } };
> 
> So you might think that it will match either “a” or “abc”, but no,
> “abc”
> will never work.
> 
> *Code:*
> grammar G { regex TOP { ‘a’ || ‘abc’ } };
> say G.parse(‘abc’)
> 
> *Result:*
> Nil
> 
> Why? Well, see this:
> https://github.com/rakudo/rakudo/blob/cb8f783eeb8ab25a5090fdc4e5cc318c36ee1afa/src/core/Grammar.pm#L23
> 
> Basically, TOP will first match ‘a’, and given that it is a good
> enough
> result it will bail out without trying anything else. Then, .parse
> method
> will see that it did not parse the whole string, so it fails.
> 
> I am not sure how this behavior could be useful or even how could
> anyone
> expect this, to me it feels like the top rule should always have an
> implicit $ on the end so that it knows that it should keep trying to
> find a
> better solution.
> 
> But yes, we can close our eyes on this issue and add yet another trap
> to
> the documentation.
> 
> Another closely related issue is method .subparse. As it seems,
> subparse is
> supposed to return partial results (.partial-parse ?), but for some
> reason
> instead of returning Nil it returns a failed Match, unlike .parse.

[perl #130114] IO::Path.resolve on windows prefixed with \

[Zoffix Znet via RT]

On Wed, 16 Nov 2016 03:01:30 -0800, mt1...@gmail.com wrote:
> Hi,
> 
> On windows the path created by method resolve on windows is prefixed 
> with a '\' which is wrong
> 
> e.g. in project config-datalang-refine on appveyor the statement
> 
>say 'Resolve: ', '.'.IO.resolve.Str;
> 
> displays
> 
> Resolve: \C:\projects\config-datalang-refine
> 
> It shows a backslash before the volumename
> 
> 
> Regards,
> 
> Marcel
> 
> 

That's probably not the only thing broken. The comment in the method (and the 
docs) says "# : Not portable yet; assumes POSIX semantics"

[perl #130072] [SEGV] when using uninitialized native str attribute as a hash key

[Zoffix Znet via RT]

This has been fixed in MoarVM in 
https://github.com/MoarVM/MoarVM/commit/28179938434035b425e66ead5e1bd4193ab31a53
Tests added in https://github.com/perl6/roast/commit/bfd9438d68


On Fri, 11 Nov 2016 08:18:43 -0800, cole...@yahoo.com wrote:
> m: my %h; %h{class { has str $.s }.new.s} = 1
> rakudo-moar c541b3: OUTPUT«(signal SEGV)»
> 
> while this works...
> m: my str $a; my %h; %h{$a} = 1rakudo-moar c541b3: ( no output )
> 
> I was running R* 2016.07 when I noticed it.
> 
> J.

[perl #128897] [LTA] [MATH] "-0".Num isn't negative

[Zoffix Znet via RT]

On Thu, 11 Aug 2016 09:32:31 -0700, zef...@fysh.org wrote:
> > "-0".Num.perl
> 0e0
> 
> It's surprising that that's producing a floating-point positive zero,
> rather than the negative zero that is also available:
> 
> > (-("0".Num)).perl
> -0e0
> 
> -zefram


Thanks for the report. Are you able to describe any usecases where the string 
cast resulting in a positive zero as opposed to negative zero creates a problem?

The reason we have a negative floating point zero at all is more due to 
underlying implementations at whose level such zeros are used to signal various 
exceptions. But such usage isn't needed on Perl 6 level.

Looking at the current implementation, fixing the described issue would involve 
special-casing the .Num string
conversion AND special-casing the negative zero numeric case. This would result 
in extra maintenance burden and performance loss in a very hot spot of the 
codebase, so I'm trying to see what the justification for that is.

-

As for what's happening: "-0" gets converted to Numeric under the hood, and the 
containing numeric is an Int, and there's no Int negative zeros, so you end up 
with a plain 'ol zero that then gets converted to a Num, without the
negative sign.

In the second case you present, the string coersion ends up with an Int, which 
then is converted to a Num; when
you apply the prefix minus, it gets converted to a negative zero, since those 
exist in Nums.

So this issue gives us first special-casing: that we need to notify the Numeric 
conversion that we explicitly want a Num at the end.

Now, if you try, you'll notice that '-0e0' also results in a positive zero. 
This is because that Numeric conversion parses the string in parts, each part 
being an Int and is parsed using radix_I nqp op, and Ints ain't got negative 
zeros, so even though the code asks the radix_I op to negate the result if we 
have a minus, we still end up with a positive zero.

So this is the second special case, where we have to check whether we've got a 
minus and a zero result and we explicitly want a Num as the end result.

-

So considering the impact of the end result that fixes this bug, I'm willing to 
sacrifice minor inconsistency of string casts never resulting in negative 
zeros, for the sake of clearer and more performant code, but perhaps I'm 
missing some viable usecase where string cast to numeric losing the sign of the 
zero is a problem at the high level that Perl 6 operates in?

[perl #128897] [LTA] [MATH] "-0".Num isn't negative

[Zoffix Znet via RT]

More discussion on IRC: 
https://irclog.perlgeek.de/perl6-dev/2016-11-17#i_13584755

So it seems a fix is indeed needed.

[perl #128785] [MATH] Zero to the zeroeth power: Complex numbers not consistent with others.

[Zoffix Znet via RT]

On Sat, 10 Sep 2016 23:17:33 -0700, sml...@gmail.com wrote:
> Comparison table of the different cases of "zero to the zeroeth power"
> in Rakudo:
> 
> nn**00**nn**n
> -   -   -   -
> 0   1   1   1
> 0.0   1   1   1
> FatRat.new(0)   1   1   1
> 0e0   1   1   1
> 0+0i   NaN+NaN\i   NaN+NaN\i0+0i
> 
> I think that's a pretty clear indication that the Complex case is in
> need of fixing.
> I'm just not sure which way:
> 
> - either make all entries in the bottom row produce 1+0i   (like
> Perl 5, Python, Ruby)
> - or make all entries in the bottom row produce NaN+NaN\i  (like
> C++)
> 
> Again, input from someone well versed in math programming would be
> great.

Thanks for the report.

The 0+0i case was returned because the case that does "zero to any power is 
zero" did not consider the power of zero. The NaNs in our case (and I suspect 
in C's case) are due to intermediary math operations involving logs and log(0) 
is a -Inf, which the rest of operations mangled further into a NaN

Fixed for all cases to return 1+0i in: 
https://github.com/rakudo/rakudo/commit/7f322436c9
Tests added in: https://github.com/perl6/roast/commit/6cf2e012c2

[perl #126016] [MATH] Rat.Str incorrectly rounds in the part after the decimal dot

[Zoffix Znet via RT]

On Tue, 08 Sep 2015 05:22:21 -0700, moritz.l...@gmail.com wrote:
> 14:16 < moritz> m: say 0.99.Str
> 14:16 <+camelia> rakudo-moar cbf85b: OUTPUT«0.10␤»
> 
> Clearly this is wrong. If the intent is to round up, it should produce 
> 1.0, not 0.10.
> 
> The Rat object itself is constructed correctly:
> 
> 14:16 < moritz> m: say 0.99.nude
> 14:16 <+camelia> rakudo-moar cbf85b: OUTPUT«(99
>   100)␤»


Thanks for the report.
Fixed in 
https://github.com/rakudo/rakudo/commit/b5aa3c591e4f0fdf6ccf9e5132fdf6a15618151d
Tests in https://github.com/perl6/roast/commit/b1a305a489

PS.: the .perl not roundtripping correctly was fixed as well in the above 
commit.

[perl #125524] [MATH] exponentiation overflows to 0 under MoarVM

[Zoffix Znet via RT]

On Wed, 01 Jul 2015 13:22:39 -0700, brad wrote:
> 
> $ perl6-m -e 'say 10 ** 10 ** 10'
> 0
> 
> While it does come to the conclusion very quickly, the result doesn't
> make any sense.
> 
> The JVM backend at least returns a sensible value, even if it does
> take
> quite a bit longer to figure out.
> 
> $ perl6-j -e 'say 10 ** 10 ** 10'
> Inf

This now throws on MoarVM, but on JVM still gives Inf Does the result need 
to be the same?

 r: say 10 ** 100
 rakudo-moar b5aa3c: OUTPUT«Numeric overflow␤  in block  at 
 line 1␤␤Actually thrown at:␤  in block  at  line 1␤␤»
 ..rakudo-jvm 76b061: OUTPUT«Inf␤»

[perl #125524] [MATH] exponentiation overflows to 0 under MoarVM

[Zoffix Znet via RT]

On Fri, 18 Nov 2016 10:20:43 -0800, c...@zoffix.com wrote:
> On Wed, 01 Jul 2015 13:22:39 -0700, brad wrote:
> >
> > $ perl6-m -e 'say 10 ** 10 ** 10'
> > 0
> >
> > While it does come to the conclusion very quickly, the result doesn't
> > make any sense.
> >
> > The JVM backend at least returns a sensible value, even if it does
> > take
> > quite a bit longer to figure out.
> >
> > $ perl6-j -e 'say 10 ** 10 ** 10'
> > Inf
> 
> This now throws on MoarVM, but on JVM still gives Inf Does the
> result need to be the same?
> 
>  r: say 10 ** 100
>  rakudo-moar b5aa3c: OUTPUT«Numeric overflow␤  in block
>  at  line 1␤␤Actually thrown at:␤  in block  at 
> line 1␤␤»
>  ..rakudo-jvm 76b061: OUTPUT«Inf␤»


Actually, I spot more inconsistencies between the way our math ops behave. For 
example `*` returns Inf instead of throwing on overflow. So does the `**` on 
other numerics, BUT it throws on underflow instead, but the Int `**` just gives 
the division-by-zero error:

IRC: https://irclog.perlgeek.de/perl6-dev/2016-11-18#i_13591836


18:17   vikir: say 10 ** 10 ** 10
18:17   camelia rakudo-jvm 76b061: OUTPUT«Inf␤»
18:17   ..rakudo-moar b5aa3c: OUTPUT«Numeric overflow␤  in block  
at  line 1␤␤Actually thrown at:␤  in block  at  line 1␤␤»
18:22   vikim: say 1e200 * 10e200
18:22   camelia rakudo-moar b5aa3c: OUTPUT«Inf␤»
18:23   vikiSeems like it'd make sense to return Inf instead of throwing 
for ** too?
18:23   And that would align the results between JVM and MoarVM too
18:25   m: say 10e0 ** 100e0
18:25   camelia rakudo-moar b5aa3c: OUTPUT«Inf␤»
18:25   viki:)
18:26   m: say <10/1> ** <100/1>
18:26   camelia rakudo-moar b5aa3c: OUTPUT«Inf␤»
18:28   vikioh heh and in the Num case we throw for Underflow instead
18:28   m: say 10e0 ** -100e0
18:28   camelia rakudo-moar b5aa3c: OUTPUT«Numeric underflow␤  in block 
 at  line 1␤␤Actually thrown at:␤  in block  at  line 1␤␤»
18:28   vikim: say 10 ** -100
18:28   camelia rakudo-moar b5aa3c: OUTPUT«Attempt to divide 1 by zero 
using div␤  in block  at  line 1␤␤Actually thrown at:␤  in block 
 at  line 1␤␤»

[perl #126992] [BUG] t\spec\S17-supply\throttle.t hangs on Windows 10

[Zoffix Znet via RT]

This passes now on latest Rakudo per 
https://irclog.perlgeek.de/perl6/2016-11-18#i_13592286


On Tue, 22 Dec 2015 07:41:52 -0800, na...@cpan.org wrote:
> This is from a fresh clone. There is no perl6 on the %PATH%.
> 
> First, no options. Killed after moar.exe CPU use fell to 0, and Task
> Manager showed moar.exe waiting on two threads.
> 
> D:\Src\rakudo> perl t\harness t\spec\S17-supply\throttle.t
> t\spec\S17-supply\throttle.t .. Dubious, test returned 1 (wstat 256,
> 0x100)
> Failed 34/47 subtests
> 
> Test Summary Report
> ---
> t\spec\S17-supply\throttle.t (Wstat: 256 Tests: 13 Failed: 0)
>   Non-zero exit status: 1
>   Parse errors: Bad plan.  You planned 47 tests but ran 13.
> Files=1, Tests=13, 65 wallclock secs ( 0.11 usr +  0.00 sys =  0.11
> CPU)
> Result: FAIL
> 
> This time with verbosity to print progress. Again, kill after moar.exe
> cpu use falls to 0, and Task Manager showed moar.exe waiting on two
> threads. Note that the number of tests run in this case is 11:
> 
> D:\Src\rakudo> perl t\harness t\spec\S17-supply\throttle.t
> --verbosity=3
> t\spec\S17-supply\throttle.t ..
> 1..47
> ok 1 - can not be called as a class method
> #  scheduling with ThreadPoolScheduler
> ok 2 - did we see all of the element
> ok 3 - difference between each at least .5 seconds
> ok 4 - difference between each at most .8 seconds
> ok 5 - did we see all of the element
> ok 6 - difference between each at least something
> ok 7 - difference between each at most .5 seconds
> ok 8 - ok with 1 at a time
> ok 9 - ok with 2 at a time
> ok 10 - ok with 3 at a time
> ok 11 - ok with 4 at a time
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 36/47 subtests
> 
> Test Summary Report
> ---
> t\spec\S17-supply\throttle.t (Wstat: 256 Tests: 11 Failed: 0)
>   Non-zero exit status: 1
>   Parse errors: Bad plan.  You planned 47 tests but ran 11.
> Files=1, Tests=11, 249 wallclock secs ( 0.09 usr +  0.00 sys =  0.09
> CPU)
> Result: FAIL
> 
> Whether the actual number of tests run is 11 or 13, the triggering
> code seems to be this block starting on line 51:
> 
> for 1..10 -> $n {
> my @a; @a[9] = 0; # pre-size array to allow seamless multi-thread
> updates
> (1..10).Supply.throttle( $n, { @a[$_] = 1 } ).wait;
> is @a.sum, 10, "ok with $n at a time";
> }
> 
> Let's try one more time:
> 
> D:\Src\rakudo> perl t\harness t\spec\S17-supply\throttle.t
> --verbosity=3
> t\spec\S17-supply\throttle.t ..
> 1..47
> ok 1 - can not be called as a class method
> #  scheduling with ThreadPoolScheduler
> ok 2 - did we see all of the element
> ok 3 - difference between each at least .5 seconds
> ok 4 - difference between each at most .8 seconds
> ok 5 - did we see all of the element
> ok 6 - difference between each at least something
> ok 7 - difference between each at most .5 seconds
> ok 8 - ok with 1 at a time
> ok 9 - ok with 2 at a time
> ok 10 - ok with 3 at a time
> ok 11 - ok with 4 at a time
> ok 12 - ok with 5 at a time
> ok 13 - ok with 6 at a time
> ok 14 - ok with 7 at a time
> ok 15 - ok with 8 at a time
> ok 16 - ok with 9 at a time
> ok 17 - ok with 10 at a time
> ok 18 - parallelism as expected with 1
> ok 19 - ok with 1 at a time with random delay
> ok 20 - parallelism as expected with 2
> ok 21 - ok with 2 at a time with random delay
> ok 22 - parallelism as expected with 3
> ok 23 - ok with 3 at a time with random delay
> ok 24 - parallelism as expected with 4
> ok 25 - ok with 4 at a time with random delay
> ok 26 - parallelism as expected with 5
> ok 27 - ok with 5 at a time with random delay
> ok 28 - parallelism as expected with 6
> ok 29 - ok with 6 at a time with random delay
> ok 30 - parallelism as expected with 7
> ok 31 - ok with 7 at a time with random delay
> ok 32 - parallelism as expected with 8
> ok 33 - ok with 8 at a time with random delay
> ok 34 - parallelism as expected with 9
> ok 35 - ok with 9 at a time with random delay
> ok 36 - parallelism as expected with 10
> ok 37 - ok with 10 at a time with random delay
> ok 38 - Nothing should be seen yet
> ok 39 - did we see all in the right order?
> ok 40 - did we get the final status?
> ok 41 - currently allowed to run
> ok 42 - no bleeds done
> ok 43 - none left in buffer
> ok 44 - number of results emitted
> ok 45 - correct status ID
> ok 46 - maximally allowed to run
> ok 47 - none are running still
> ok
> All tests successful.
> Files=1, Tests=47, 33 wallclock secs ( 0.08 usr +  0.02 sys =  0.09
> CPU)
> Result: PASS
> 
> One more time:
> 
> D:\Src\rakudo> perl t\harness t\spec\S17-supply\throttle.t
> t\spec\S17-supply\throttle.t .. ok
> All tests successful.
> Files=1, Tests=47, 32 wallclock secs ( 0.06 usr +  0.01 sys =  0.08
> CPU)
> Result: PASS
> 
> So, what we have here is a Heisenbug related to threads. Sorry I can't
> be of more help right now.
> 
> Here's my environment and build info:
> 
> C:\> ver
> Microsoft Windows [Version 10.0.10586]
> 
> C:\> cl
> Microsoft (R) C/C++ Optimizing C

[perl #130131] [LTA][BUG] sub MAIN cannot accept enum argument

[Zoffix Znet via RT]

I'm re-opening this, as the Enum conversion is too eager now: 
https://irclog.perlgeek.de/perl6-dev/2016-11-19#i_13595331

Basically, now MAIN can never take strings False or True, because those get 
converted to Bools and any other enums will fail to match, unless they're 
expected.

[perl #130042] [CONC] t/04-nativecall/20-concurrent.t flops

[Zoffix Znet via RT]

Based on AppVeyor, this test still flops, but only on Windows: 
https://ci.appveyor.com/project/moritz/rakudo/build/1.0.1552/job/3009q95at2axp4i7

I'm re-fudging the test and re-opening this ticket.


On Thu, 10 Nov 2016 05:09:35 -0800, c...@zoffix.com wrote:
> This is fixed in
> https://github.com/rakudo/rakudo/commit/84eaff47f2
> https://github.com/rakudo/rakudo/commit/0134132dab
> https://github.com/rakudo/rakudo/commit/49fd82517f

[perl #130150] [JVM] Failing test in S32-str/numeric.t: trying to convert malformed number in scientific notation dies instead of returning a Failure

[Zoffix Znet via RT]

Thanks.

Fixed in 
https://github.com/rakudo/rakudo/commit/17604e3e4643442ba84ab5670ad7438ef04a5c31
Test unfuddged in 
https://github.com/perl6/roast/commit/2836648481af39f5bc1474b056133b545372a02c


On Mon, 21 Nov 2016 23:22:04 -0800, barto...@gmx.de wrote:
> The following code dies with StringIndexOutOfBoundsException on
> rakudo-j:
> 
> $ ./perl6-j -e '+"120e"'
> WARNINGS for -e:
> Useless use of "+" in expression "+\"120e\"" in sink context (line 1)
> java.lang.StringIndexOutOfBoundsException: String index out of range:
> 4
>   in sub parse-int-frac-exp at gen/jvm/CORE.setting line 30717
>   in sub parse-simple-number at gen/jvm/CORE.setting line 30841
>   in sub parse-real at gen/jvm/CORE.setting line 30847
>   in sub val at gen/jvm/CORE.setting line 30868
>   in method Numeric at gen/jvm/CORE.setting line 12738
>   in sub prefix:<+> at gen/jvm/CORE.setting line 10006
>   in block  at -e line 1
> 
> It is supposed to return a Failure like that:
> 
> $ ./perl6-m -e 'say +"120e" ~~ Failure'
> True
> 
> It looks like this was introduced with commit cb9df2bd40 (if I revert
> that commit,
> the code works as expected).
> 
> I'm going to fudge (skip) the test, since I don't have time to look
> for a fix
> at the moment.

[perl #130160] [BUG] Flattened list iteration

[Zoffix Znet via RT]

On Wed, 23 Nov 2016 17:15:41 -0800, TimTom wrote:
> It appears that when iterating lazily through a list that's been
> flattened (the first time), sometimes certain elements are not
> reached.

Thanks for the report.

Fixed in 
https://github.com/rakudo/rakudo/commit/61a18c064695cfa16f31187abed62d1fe4e2cb5e
Tests added in https://github.com/perl6/roast/commit/10f39438be

[perl #128821] sprintf %f on -0e0 omits sign

[Zoffix Znet via RT]

On Tue, 02 Aug 2016 11:20:19 -0700, zef...@fysh.org wrote:
> > 0e0.perl
> 0e0
> > (-0e0.perl)
> -0
> > sprintf("%f", 0e0)
> 0.00
> > sprintf("%f", -0e0)
> 0.00
> 
> The Num type is correctly distinguishing between positive and negative
> zero, but sprintf %f is not representing the sign bit in its output.
> sprintf %f on negative zero should produce output starting with a "-".
> 
> -zefram


Thanks for the report. This is now fixed \o/

nqp:https://github.com/perl6/nqp/commit/ddebbfa959
rakudo: https://github.com/rakudo/rakudo/commit/f1263abc27
tests:  https://github.com/perl6/roast/commit/795fc1f3b3 / 
https://github.com/rakudo/rakudo/commit/2efeda0597

Cheers,
ZZ

[perl #128897] [LTA] [MATH] "-0".Num isn't negative

[Zoffix Znet via RT]

On Thu, 11 Aug 2016 09:32:31 -0700, zef...@fysh.org wrote:
> > "-0".Num.perl
> 0e0
> 
> It's surprising that that's producing a floating-point positive zero,
> rather than the negative zero that is also available:
> 
> > (-("0".Num)).perl
> -0e0
> 
> -zefram


Thank you for the report. This is now fixed \o/

rakudo:
https://github.com/rakudo/rakudo/commit/e2587cd012
https://github.com/rakudo/rakudo/commit/a9654c0d8e
tests:
https://github.com/perl6/roast/commit/7fed1c00a0 
https://github.com/perl6/roast/commit/cbc959fc22

[perl #130170] sleep with huge values does not sleep (sleep 9999999999999999999)

[Zoffix Znet via RT]

On Fri, 25 Nov 2016 21:54:14 -0800, c...@zoffix.com wrote:
> On Thu, 24 Nov 2016 10:46:58 -0800, alex.jakime...@gmail.com wrote:
> > *Code:*
> > sleep 999;
> > say ‘awww, that was some good sleep!’
> >
> > *Result:*
> > awww, that was some good sleep!
> 
> Fixed in:
> https://github.com/rakudo/rakudo/commit/c797d3ff5082c6738e069517e402af6f418e192e
> Tests in: https://github.com/perl6/roast/commit/0fc0919c7f

Actually, that fix is broken; doesn't sleep for correct amount of time.
Correct fix pushed in https://github.com/rakudo/rakudo/commit/7c5ea31800

[perl #128395] [BUG] -0 breaks value identity comparison

[Zoffix Znet via RT]

On Mon, 13 Jun 2016 03:20:34 -0700, zef...@fysh.org wrote:
> > my $a = 0.Num
> 0
> > my $b = -$a
> -0
> > $a
> 0
> > $b
> -0
> > $a.WHICH
> Num|0
> > $b.WHICH
> Num|-0
> > atan2($a, -1)
> 3.14159265358979
> > atan2($b, -1)
> -3.14159265358979
> > $a === $b
> True
> 
> These two values, the two floating point zeroes, are distinct values, as
> shown by their stringification, .WHICH, and atan2 branch cut behaviour.
> The === comparison is producing the wrong answer, claiming that they're
> the same value.  They are of course correctly ==, but === is making a
> different kind of comparison.  In the related case of NaN compared to
> NaN, === correctly says that NaN is the same value as itself, despite
> it not being == to itself.
> 
> -zefram


Thank you for the report. This is now fixed \o/

rakudo: https://github.com/rakudo/rakudo/commit/085145f3a5
tests:  https://github.com/perl6/roast/commit/f67de6cf58

[perl #128546] [BUG] [UNI] Version comparison confused by digit with diacritics

[Zoffix Znet via RT]

On Tue, 05 Jul 2016 09:52:46 -0700, zef...@fysh.org wrote:
> The Version class accepts numeric components that contain digits with
> diacritics, and faithfully preserves the grapheme string just as it
> preserves non-ASCII digits.  But these components then behave badly
> in comparisons:
> 
> > Version.new("34\x[308]5") leg Version.new("4")
> Less
> 
> The digit with diacritic effectively terminates the digit sequence,
> for the purpose of finding a numeric value.  This is probably due to
> [perl #128542].  This implies that fixing that bug, making the coercion
> reject such modified digits (as appears to be the intent), would cause
> the Version comparison to signal an error.  That would also be buggy
> behaviour, so Version has a problem distinct from the problem with
> Str.Int.
> 
> -zefram
 
Thanks for the report, however, there's no bug here, as strings are valid
version parts, which is what the diaeresis causes the part to parse as
(as opposed to numbers).

The `leg` operator coerces Versions to strings, and in this case string
`"34\x[308]5"` is Less than `"4"`. The more appropriate operator to compare
versions is `cmp`.

With `cmp`, string parts are always Order::Less than number parts, so to
see the comparison working properly, we'd need to compare versions with 
both of those parts being stringy:

 m: say Version.new("34\x[308]5") cmp Version.new("34\x[308]4")
 rakudo-moar 2f72fa: OUTPUT«More␤»
 m: say Version.new("34\x[308]5") cmp Version.new("34\x[308]5")
 rakudo-moar 2f72fa: OUTPUT«Same␤»
 m: say Version.new("34\x[308]5") cmp Version.new("34\x[308]6")
 rakudo-moar 2f72fa: OUTPUT«Less␤»

This also works with Version literals:
 m: say v34̈5 cmp v34̈6
 rakudo-moar 2f72fa: OUTPUT«Less␤»
 m: say v34̈5 cmp v34̈5
 rakudo-moar 2f72fa: OUTPUT«Same␤»
 m: say v34̈5 cmp v34̈4
 rakudo-moar 2f72fa: OUTPUT«More␤»

Cheers,
ZZ

[perl #130184] [BUG] All digit words in angle-bracket word quoting don't come out the same as the literally quoted word

[Zoffix Znet via RT]

On Sat, 26 Nov 2016 15:47:38 -0800, comdog wrote:
> Adapted from the Stackoverflow answer at:
> http://stackoverflow.com/a/40824226/2766176
> 
> I'm using moar (2016.10) on macosx (10.10.5) darwin (14.5.0) (These
> variables are quite nice!)
> 
> This came out of a problem I had with set membership. It turns out
> that the way you make the set matters, and the way you make the
> candidate member matters. In my case, there's a bug with angle-bracket
> word quoting.
> 
> I used the [angle-brackets form of the quote
> words](https://docs.perl6.org/language/quoting#Word_quoting:_qw). The
> quote words form is supposed to be equivalent to the quoting version
> (that is, True under `eqv`). Here's the doc example:
> 
>  eqv ('a', 'b', 'c')
> 
> But, when I try this with a word that is all digits, this is not equivalent:
> 
> $ perl6
> > < a b 137 > eqv ( 'a', 'b', '137' )
> False
> 
> But, the other forms of word quoting are!
> 
> > qw/ a b 137 / eqv ( 'a', 'b', '137' )
> True
> > Q:w/ a b 137 / eqv ( 'a', 'b', '137' )
> True
> 
> The angle-bracket word quoting uses
> [IntStr](https://docs.perl6.org/type/IntStr):
> 
> > my @n = < a b 137 >
> [a b 137]
> > @n.perl
> ["a", "b", IntStr.new(137, "137")]
> 
> Without the word quoting, the digits word comes out as [Str]:
> 
> > ( 'a', 'b', '137' ).perl
> ("a", "b", "137")
> > ( 'a', 'b', '137' )[*-1].perl
> "137"
> > ( 'a', 'b', '137' )[*-1].WHAT
> (Str)
> > my @n = ( 'a', 'b', '137' );
> [a b 137]
> > @n[*-1].WHAT
> (Str)


Thanks for the reqport, however, what you describe is not a bug, as the angle 
brackets
have special feature to construct IntStr, NumStr, RatStr, and ComplexStr 
allomorphs as
well as specify Rat and Complex literals.

The documention was just misleading. I corrected it in:
https://github.com/perl6/doc/commit/fa0b8f643356a3db1e5e59fda4f153f48f90ee90

[perl #128546] [BUG] [UNI] Version comparison confused by digit with diacritics

[Zoffix Znet via RT]

A fair point. Re-opening with the intent to make synthetic digits match the 
same way as punctuation.

I tried a few implementations, like changing the .comb to 

 .comb(/:r ‘*’ || [(\d)  
]+ || <.alpha>+ /) 

But all of them ended up being 10 to 64 times slower than just regular \d+.

By defining a token that matches only non-synthetic Nd chars, the slowdown is 
only 2x, so I'll see if we can make that token available somewhere in the guts, 
since we needed it in the Perl6/Grammar.nqp too.

[perl #121940] [@LARRY] say True but False # should be 'True' (advent2010-day19)

[Zoffix Znet via RT]

On Thu, 11 Aug 2016 06:14:52 -0700, sml...@gmail.com wrote:
> You're right, that one *is* inconsistent with `True but False`.
> 
> `$bool1 but $bool2` and `$int1 but $int2` should either both override
> the value, or both *not* override the value.


There's actually no inconsistency and the infix: is much less magical:

The infix: operator with the RHS that isn't a role *creates* a role with a 
single method
that is the .^name of the RHS value which returns that value, and uses that 
role to perform the mixin:

 m: my $s = 0 but class { method ^name ($) { 'warbles' } }.new; say 
$s.warbles
 rakudo-moar e0c0ae: OUTPUT«warbles.new␤»

So the results you claim are inconsistent actually are:

% perl6 -e'my $s = False but True; say $s; say $s.so;'
True
True

- `but True` mixes in a role with method called `Bool` that returns `True`
- `say` uses `.gist`, which for Bool objects evaluates the object in Bool 
context (so, calls .Bool), and so we end up with .Bool from our role that gives 
True
- The `.so` method uses `.Bool` under the hood, which we overrode to True
= both outputs match

In this example:

   % perl6 -e'my $s = 0 but True; say $s; say $s.so;'
   0
   True

- Everything is the same as in the previous example, except the original object 
is an Int
- `say` uses `.gist`, which for Int objects calls .Str method, which we did not 
override with our mix in, hence why we still get `0` in the output
= outputs differ

And since we know that .gist on Ints calls .Str, we can predict that mixing in 
a Str object will change the output of `say`:

 m: my $s = 0 but 'meows'; say $s; say $s.so;
 rakudo-moar e0c0ae: OUTPUT«meows␤False␤»

Indeed it did change the output of `say` and since we did not override .Bool 
this time, the `.so` output gives False now.

So then, if we mixin both a Str and a Bool, we'll affect both outputs:

 m: my $s = (0 but 'meows') but True; say $s; say $s.so;
 rakudo-moar e0c0ae: OUTPUT«meows␤True␤»


So as far as I can see, there's no bug or inconsistency. Closing the ticket.

Cheers,
ZZ

[perl #130222] Sets (and Bags and Mixes) are exposing allomorphs and are generally very type sensitive

[Zoffix Znet via RT]

On Wed, 30 Nov 2016 10:18:50 -0800, david.warring wrote:
> One example from this stack overflow question: question
> http://stackoverflow.com/questions/40814933/how-do-the-perl-6-set-
> operations-compare-elements
> 
> my $num_set = set( < 1 2 3 4 > );
> say "set: ", $num_set.perl;
> say "4 is in set: ", 4 ∈ $num_set; # False
> say "IntStr 4 is in set: ", IntStr.new(4, "Four") ∈ $num_set; $ True
> 
> As noted is the thread it's unexpected and a likely trap that's
> difficult to explain to beginners.
> 
> The current implementation is supposed to make it easy to form sets of
> general objects. But in practice even that's fragile. Consider:
> 
> my $v = 42;
> my $s = set($v);
> $v does role {};
> say $v ∈ $s; # False
> 
> I suspect the general idea of using .WHICH as a discriminator between
> elements isn't working well in practice.
> 
> Maybe we should pull this back and use something simpler and more
> inclusive such as .Str?

Thanks for taking time writing this up, however, I'm going to reject this 
ticket. 

There's little reason to make a major, breaking change to a large feature of 
the language, making it much less powerful, just because a single beginner used 
poor documentation and got confused.

The author of that SO question created another ticket (RT#130184) and the 
documentation has since been amended to explain that `< ... >` quoters differ 
from qw// quoters and that they create allomorphs. Feel free to submit further 
improvements to either allomorphs or set bag mixes page 
(https://github.com/perl6/doc/blob/master/doc/Language/setbagmix.pod6 )

I'd even argue the allomorphs alone are the cause of that person's confusion 
and not setties and baggies using object identity to discern their elements. 
And aside from edge case where the angle brackets double as numeric literals, 
they're pretty easy to explain to beginners: for numbers, you get a subclass of 
Str and a particular Numeric, since the parser doesn't know which one you meant 
and making them all Str would make the feature less useful. If you meant a 
specific numeric type, coerce the stuff you get, if you meant always Str, use 
qw// quoters instead (there's also 
http://modules.perl6.org/dist/Quantum::Collapse module).

If a set based on .Str is needed, one can use set <1 2 3 4>».Str. The proposal 
to use .Str instead of object identity would make ['a', 'b', 'c'] be equivalent 
to element ['a', ['b', ['c']]], or [[['a'], 'b',] 'c'], or string 'a b c', or 
class Foo { method Str { 'a b c '} }. In fact, it'll also treat all of these as 
the same object: class { method bar {} }, class {}, class { has $!foo }; class 
A {}; class B is A {} because all of their .Str is an empty string.

This would make the feature rather error prone.

> Applying a role to the object has had the side effect. Its no longer
> recognized as being an element in the set.

That's because it's a completely different object. Even with the .Str proposal 
that can be effected, since `"foo"` and `"foo" but "bar"` would not be 
considered the same items in the set, since their .Str values are different.

In summation, I don't think power should be stripped from features for the sole 
reason of making them more palatable to absolute beginners. Improved 
documentation is the correct solution.

Cheers,
ZZ

[perl #130207] [SITE] directory "/downloads/rakudo" needs a "latest" entry to ease automating installation procedures

[Zoffix Znet via RT]

On Wed, 30 Nov 2016 10:49:43 -0800, tbrowder wrote:
> On Wed, Nov 30, 2016 at 12:21 PM, Zoffix Znet via RT
>  wrote:
> > According to our records, your request regarding
> >   "[SITE] directory "/downloads/rakudo" needs a "latest" entry to
> > ease automating installation procedures"
> > has been resolved.
> >
> > If you have any further questions or concerns, please respond to this
> > message.
> 
> Zoffix, for some reason, the link
> 
> <http://rakudo.org/downloads/rakudo/rakudo-latest.tar.gz>
> 
> actually resolves to
> 
> 
> 
> All the others seem to work ok.

Thanks for checking. Fixed now.

[perl #130231] [LTA] Nil.chrs complains about the use of Nil in numeric context, but isn't it a string context? (Nil.chrs)

[Zoffix Znet via RT]

On Thu, 01 Dec 2016 15:11:31 -0800, alex.jakime...@gmail.com wrote:
> Code:
> Nil.chrs
> 
> Result:
> Use of Nil in numeric context
>   in block  at -e line 1
> 
> 
> At the same time:
> 
> Code:
> Nil.ords
> 
> Result:
> Use of Nil in string context
>   in block  at -e line 1
> 
> 
> I think that both should say that it is in string context.


.chrs takes a list of numbers. The Nil is used in numeric context, resulting in 
a 0, which after being .chr'ed results in a null string:

m: quietly say Nil.chrs eq "\x[0]"; # True
rakudo-moar abc643: OUTPUT«True␤» 

The warning is accurate.