[perl #126976] [SEGV] on "/".IO.mkdir
> 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
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.
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
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
đ Skip-fudge added in https://github.com/perl6/roast/commit/a047d78ac9 đ
[perl #127879] [BUG] map subroutine ignores the sequence in the specific case
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
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â)
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)
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
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
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
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
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
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
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
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 {}
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 {}
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
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
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
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
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)
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
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
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
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)
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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)
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)
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)
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
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
>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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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 \
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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)
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
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
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)
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.