[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 #128589] [BUG] Parser confused by two s/// or S/// in a subroutine call with parentheses
# New Ticket Created by Zoffix Znet # Please include the string: [perl #128589] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128589 > The parse error occurs with alphabetic infix between the s/// but seems to be fine with a symbol-based infix: m: say(s/^// and s/^//) rakudo-moar 405519: OUTPUT«===SORRY!=== Error while compiling Unable to parse expression in argument list; couldn't find final ')' at :1--> say(s/^//⏏ and s/^//)expecting any of:infix infix stopper» m: say(s/^// andthen s/^//) rakudo-moar 405519: OUTPUT«===SORRY!=== Error while compiling Unable to parse expression in argument list; couldn't find final ')' at :1--> say(s/^//⏏ andthen s/^//)expecting any of:infix infix stopper» m: say(s/^// or s/^//) rakudo-moar 405519: OUTPUT«===SORRY!=== Error while compiling Unable to parse expression in argument list; couldn't find final ')' at :1--> say(s/^//⏏ or s/^//)expecting any of:infix infix stopper» m: say(S/^// or S/^//) rakudo-moar 405519: OUTPUT«===SORRY!=== Error while compiling Unable to parse expression in argument list; couldn't find final ')' at :1--> say(S/^//⏏ or S/^//)expecting any of:infix infix stopper» These are parsed fine: m: say(s/^// && s/^//) rakudo-moar 405519: OUTPUT«Method 'match' not found for invocant of class 'Any' in block at line 1» m: say(S/^// && S/^//) rakudo-moar 405519: OUTPUT«Method 'match' not found for invocant of class 'Any' in block at line 1»
Re: [perl #127973] [BUG] native strings not allowed to be as big as regular strings
Yeah, I filed the slowness as a bug (127972) a while ago. On Sat, Jul 9, 2016 at 6:23 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > Oh, my bad. I didn't wait long enough. Takes over a minute: > > zoffix@VirtualBox:~$ time perl6 -e 'my str $a = "a" x 2**30;say $a.chars' > ===SORRY!=== > String too long for string constants segment > > real1m15.794s > user0m7.408s > sys 0m9.432s > zoffix@VirtualBox:~$ > >
Re: [perl #127973] [BUG] native strings not allowed to be as big as regular strings
I still get the exact same error, it just takes 10+ seconds. This is Rakudo version 2016.06-204-g959cd3b built on MoarVM version 2016.06-11-gf9dad06 On Sat, Jul 9, 2016 at 4:55 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > This appears to hang now: > > zoffix@VirtualBox:~$ perl6 -e 'my $a = "a" x 2**30;say $a.chars' > 1073741824 > zoffix@VirtualBox:~$ perl6 -e 'my str $a = "a" x 2**30;say $a.chars' > ^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. > >
[perl #128587] [POD] need pod-to-man translator
# New Ticket Created by Tom Browder # Please include the string: [perl #128587] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128587 > Need a pod2man translator.
[perl #128586] [BUG] andthen doesn't return undefined LHS
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #128586] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128586 > Per S03, : should return the first argument indicating failure (undefined). On current Rakudo: 18:00 m: say (Int andthen 3) 18:00 rakudo-moar 959cd3: OUTPUT«()» 18:00 m: say (Int andthen 3).WHAT 18:00 rakudo-moar 959cd3: OUTPUT«(Slip)» Per S03, the answer should be OUTPUT«(Int)». Pm
Re: [perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents
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 :<**> 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
Re: [perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents
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 :<**> 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 #128553] multi method cache causes Base64 regression
On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote: > Note that the final decode-base64 candidate shows the correct results > when debugging statements are added > > This gist also shows a small change that makes it produce the correct > values but it still segfaults more often than not > https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d Having dug into it a little, I'm not sure that the new multi-caching stuff has caused this, so much as uncovered it (perhaps by moving GC collection points). The valgrind output is as follows: ok 1 - decoding the empty string ok 2 - decoding "A" not ok 3 - decoding "Ab" # Failed test 'decoding "Ab"' # at t/01-basic.t line 29 # expected: 'Ab' # got: 'A' not ok 4 - decoding "Abc" # Failed test 'decoding "Abc"' # at t/01-basic.t line 30 # expected: 'Abc' # got: 'A' ==19699== Invalid read of size 8 ==19699==at 0x4FF2B3E: gc_mark (MVMCallCapture.c:51) ==19699==by 0x4FC6BF5: process_worklist (collect.c:313) ==19699==by 0x4FC71A0: MVM_gc_collect (collect.c:129) ==19699==by 0x4FC2735: run_gc (orchestrate.c:304) ==19699==by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438) ==19699==by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32) ==19699==by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99) ==19699==by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657) ==19699==by 0x4FA8BEB: MVM_frame_capturelex (frame.c:1035) ==19699==by 0x4F98D8F: MVM_interp_run (interp.c:1070) ==19699==by 0x505E3F8: MVM_vm_run_file (moar.c:304) ==19699==by 0x401036: main (main.c:191) ==19699== Address 0x658f9d0 is 0 bytes inside a block of size 32 free'd ==19699==at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19699==by 0x4FF2CDA: MVM_free (alloc.h:29) ==19699==by 0x4FF2CDA: gc_free (MVMCallCapture.c:78) ==19699==by 0x4FC72D3: MVM_gc_collect_free_nursery_uncopied (collect.c:580) ==19699==by 0x4FC2976: run_gc (orchestrate.c:328) ==19699==by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438) ==19699==by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32) ==19699==by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99) ==19699==by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657) ==19699==by 0x4FA8D4C: MVM_frame_takeclosure (frame.c:1051) ==19699==by 0xEA66105: ??? ==19699==by 0x50342B8: MVM_jit_enter_code (compile.c:136) ==19699==by 0x4F938F0: MVM_interp_run (interp.c:5456) ==19699== ==19699== Invalid read of size 1 ==19699==at 0x4FF2A7D: gc_mark (MVMCallCapture.c:55) ==19699==by 0x4FC6BF5: process_worklist (collect.c:313) ==19699==by 0x4FC71A0: MVM_gc_collect (collect.c:129) ==19699==by 0x4FC2735: run_gc (orchestrate.c:304) ==19699==by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438) ==19699==by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32) ==19699==by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99) ==19699==by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657) ==19699==by 0x4FA8BEB: MVM_frame_capturelex (frame.c:1035) ==19699==by 0x4F98D8F: MVM_interp_run (interp.c:1070) ==19699==by 0x505E3F8: MVM_vm_run_file (moar.c:304) ==19699==by 0x401036: main (main.c:191) ==19699== Address 0xb36cc70 is 0 bytes inside a block of size 1 free'd ==19699==at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19699==by 0x4FF2CD1: MVM_free (alloc.h:29) ==19699==by 0x4FF2CD1: gc_free (MVMCallCapture.c:77) ==19699==by 0x4FC72D3: MVM_gc_collect_free_nursery_uncopied (collect.c:580) ==19699==by 0x4FC2976: run_gc (orchestrate.c:328) ==19699==by 0x4FC320D: MVM_gc_enter_from_allocator (orchestrate.c:438) ==19699==by 0x4FC3627: MVM_gc_allocate_nursery (allocation.c:32) ==19699==by 0x4FC39ED: MVM_gc_allocate_frame (allocation.c:99) ==19699==by 0x4FA749F: MVM_frame_force_to_heap (frame.c:657) ==19699==by 0x4FA8D4C: MVM_frame_takeclosure (frame.c:1051) ==19699==by 0xEA66105: ??? ==19699==by 0x50342B8: MVM_jit_enter_code (compile.c:136) ==19699==by 0x4F938F0: MVM_interp_run (interp.c:5456) ==19699== not ok 5 - decoding "Abcd" Which is suggestive of some kind of memory corruption (seemingly due to over-sharing or a premature free) inside of the argument capture. Still trying to figure out exactly what leads to this.
[perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents
# New Ticket Created by Itsuki Toyota # Please include the string: [perl #128584] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128584 > See the following results $ perl6 -e 'say -1 ** -0.1' -1 $ perl6 -e 'say reduce * ** *, -1, (-0.1)' NaN My Perl 6 version is $ perl6 --version This is Rakudo version 2016.05-4-g7a4ca4d built on MoarVM version 2016.05 implementing Perl 6.c.
[perl #128580] [JVM] wrong multi method comb selected after module loading
On Fri Jul 08 14:57:11 2016, elizabeth wrote: > Have you tried with MVM_SPESH_DISABLE=1 and friends? This only happens on JVM, so there aren't many of those friends, are there? :-) At least I tried now with 'optimize=0' and got the same error. I also tried 'RAKUDO_MODULE_DEBUG=1' but didn't something strange there: $ RAKUDO_MODULE_DEBUG=1 ./perl6-j --optimize=foo -I. -e 'use Foo; "f".comb; "o".comb("o")' 11900 RMD: Loading settings CORE 11900 RMD: Setting up default paths: . blib 11900 RMD: going to load Perl6::BOOTSTRAP 11900 RMD: Settings CORE loaded 360 11900 RMD: Attempting 'Foo' as a pragma 88 11900 RMD: 'Foo' is not a valid pragma 33 11900 RMD: Attempting to load 'Foo' 11 11900 RMD: Late loading 'Foo' 20 11900 RMD: Parsing specs: . 28 11900 RMD: Parsing specs: 16 11900 RMD: Parsing specs: . 13 11900 RMD: Parsing specs: blib 21 11900 RMD: Parsing specs: /usr/home/christian/bin/rakudo.jvm/share/nqp/lib 478 11900 RMD: try-load 7795C5BD3D21241ED31BB5DB19106B21CC622A86: /usr/home/christian/perl6/perl6-roast-data/rakudo.jvm/Foo.pm6 55 11900 RMD: Trying to load 7795C5BD3D21241ED31BB5DB19106B21CC622A86 from /usr/home/christian/perl6/perl6-roast-data/rakudo.jvm/.precomp 36 11900 RMD: Trying to load 7795C5BD3D21241ED31BB5DB19106B21CC622A86.repo-id from /usr/home/christian/perl6/perl6-roast-data/rakudo.jvm/.precomp 44 11900 RMD: Loading precompiled /usr/home/christian/perl6/perl6-roast-data/rakudo.jvm/.precomp/FCFAAA33FDBB30941CBF3561334B7DCB959F5F4F.1.468023657397E9/77/7795C5BD3D21241ED31BB5DB19106B21CC622A86 187 11900 RMD: Performing imports for 'Foo' 12 11900 RMD: Imports for 'Foo' done Type check failed in binding $pat; expected Regex but got Str ("o") in block at -e line 1