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

2016-07-09 Thread Zoffix Znet via RT
The `is` sub uses `eq` operator for comparison, which coerces items to Str. 

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

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

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



[perl #128589] [BUG] Parser confused by two s/// or S/// in a subroutine call with parentheses

2016-07-09 Thread via RT
# 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

2016-07-09 Thread Daniel Green
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

2016-07-09 Thread Daniel Green
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

2016-07-09 Thread via RT
# 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

2016-07-09 Thread via RT
# 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

2016-07-09 Thread Patrick R. Michaud via RT
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

2016-07-09 Thread Patrick R. Michaud
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

2016-07-09 Thread jn...@jnthn.net via RT
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

2016-07-09 Thread via RT
# 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

2016-07-09 Thread Christian Bartolomaeus via RT
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