Re: perl 5?

[Jan Ingvoldstad]

On Thu, Nov 17, 2016 at 8:08 AM, ToddAndMargo  wrote:

> Hi All,
>
> Would you guys tolerate a perl 5 question every so often?
>
>
Perl 5 questions that relate to Perl 6 would probably be on topic.

If what you want is help with Perl 5 for Perl 5's sake, though, I humbly
suggest that using one of the Perl 5 mailing lists, or IRC channels, may be
more useful to you.

See here for more information:

https://lists.perl.org/

http://www.irc.perl.org/channels.html

You may also find one of your local Perl communities helpful, see here for
more info about that:

https://www.perl.org/community.html
-- 
Jan

perl 5?

[ToddAndMargo]

Hi All,

Would you guys tolerate a perl 5 question every so often?

-T

I still do not have perl 6 support on rhel 7.2

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

[perl6/specs] a9f852: suppress mention of dormant or defunct projects

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: a9f8526c5fb8b99c4039fde80d3eb81ead232387
  
https://github.com/perl6/specs/commit/a9f8526c5fb8b99c4039fde80d3eb81ead232387
  Author: Stéphane Payrard 
  Date:   2016-11-15 (Tue, 15 Nov 2016)

  Changed paths:
M S19-commandline.pod

  Log Message:
  ---
  suppress mention of dormant or defunct projects

Update for the current state of rakudo

[perl6/specs] acc747: Be more specific about coercion being a convention

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: acc747f10f3bb6322d2d8369d273b869df3a49a5
  
https://github.com/perl6/specs/commit/acc747f10f3bb6322d2d8369d273b869df3a49a5
  Author: Stéphane Payrard 
  Date:   2016-11-16 (Wed, 16 Nov 2016)

  Changed paths:
M S13-overloading.pod

  Log Message:
  ---
  Be more specific about coercion being a convention

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

[Clifton Wood]

Zoffix,

You should be able to comment out all XML::LibXML and still duplicate the
bug. I tested that, this morning.

As to what version of Perl6 I am running:

$ perl6 -v
This is Rakudo version 2016.10-254-gd989d96 built on MoarVM version
2016.10-43-gb4cd2a6

Thanks.

On Mon, Nov 14, 2016 at 9:33 AM, Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> 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-
> > 

[perl #130117] [REGEX] :r does not prevent backtracking (say ‘abcz’ ~~ /:r [‘a’ || ‘abc’ ] ‘z’ /)

[via RT]

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


*Code:*
say ‘abcz’ ~~ /:r [‘a’ || ‘abc’ ] ‘z’ /

*Result:*
｢abcz｣

:r (:ratchet) should prevent backtracking (trying different ways to match a
string). However, it seems like it does not work as intended (or even at
all?).

To make the example above as clear as possible: || does not do LTM (longest
token matching), so it will match things from left to right. ‘a’ matches
just fine, so it proceeds. Then ‘z’ will not match, at which point it
should give up because of :r. However, it goes back and tries ‘abc’, which
is exactly what somebody would expect from backtracking, but we are trying
to turn it off.

There are several ways to make it clear that backtracking actually happens
when using || with :r (if example above is not enough):

*Code:*
grammar G { token TOP { [ ‘a’ {say $/.CURSOR.pos} || {say $/.CURSOR.pos}
‘abc’ ] {say ‘here’} ‘z’ } }; say G.parse(‘abcz’)

*Result:*
1
here
0
here
｢abcz｣

*Code:*
say ‘abcdefghij’ ~~ /:r [.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.]
[.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.]
[.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.]
[.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.] [.||.||.||.||.||.||.||.]
 /

*Result:*
(Takes a really long time to finish because it attempts to try all of the
paths, even though “token” has implicit :r)


According to committable, this behavior has been there since the beginning
( https://gist.github.com/Whateverable/814019538d89ec53fca6c09269136ebd ).
Therefore, I am not sure how much code will break because of us fixing this
bug. However, I am hoping to see some performance improvement after we fix
this.

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

[Zoffix Znet via RT]

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


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

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

[Zoffix Znet via RT]

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

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

[perl #130064] [BUG] IO::Socket::Async sometimes gives "bindexpayload needs a VMExceptio"

[jn...@jnthn.net via RT]

On Wed, 09 Nov 2016 08:51:08 -0800, c...@zoffix.com wrote:
> 
> I can only reproduce it on camelia and the issue happens when
> connecting to an IPv6 address:
> 
> m: await
> IO::Socket::Async.connect("260​0:3c03::f03c:91ff:fe91:d028", 80).then:
> -> $p { if $p.status { given $p.result { .print: "GET / HTTP/1.0\n\n";
> react { whenever .Supply { .say } } } } }
> rakudo-moar b46a62: OUTPUT«===SORRY!===␤bindexpayload needs a
> VMException␤»
> 
> On other boxes, the code either succeeds, gives "unable to resolve
> hostname" or gives "network is unreachable"
> 
> IRC conversation: https://irclog.perlgeek.de/perl6/2016-11-
> 09#i_13539836
> 
Golfed it all the way down to:

my $p = Promise.new;
$p.break("OH NOES");
await $p;

And fixed it, and added a test in S17-promise/basic.t. Seems it was a 
regression when I improved error reporting for Promises a while ago to present 
the backtraces of both the original error and the one where the result of the 
Promise was acquired. To do that I used rethrow, but that got upset and spewed 
an internal error (the one seen here) if given an exception that was never 
previously thrown. Now it just copes.

/jnthn

[perl #130107] [CONC] unkown system error 0 via Proc::Async

[jn...@jnthn.net via RT]

On Tue, 15 Nov 2016 09:46:14 -0800, timo wrote:
> The issue is that libuv will under some circumstances call the read
> callback with an nread of 0 (deliberately the number 0), which we
> interpret as an error.
> 
> The Solution™ is either to not call async_read at all when nread is 0,
> or to just return early from async_read when nread is 0.
> 
Or, even easier, to just change the incorrect `nread > 0` check to an `nread >= 
0` check, which is what I've done in MoarVM commit 20e968b.

Remaining question is if/how we should test this, short of just taking the code 
in here, adding a platform check for places that have a `find` command, and 
shoving it in as a stress test. Thoughts welcome.

[perl #129781] [CONC] [SEGV] when start()ing several times in a loop

[jn...@jnthn.net via RT]

On Sat, 01 Oct 2016 11:42:20 -0700, nicholas wrote:
> On Sat, Oct 01, 2016 at 08:14:16AM -0700, Daniel Green wrote:
> > # New Ticket Created by  Daniel Green
> > # Please include the string:  [perl #129781]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=129781 >
> >
> >
> > await (for ^7 { start ‘/etc/hostname’.IO ~~ :e })
> >
> > regular perl6-valgrind-m output here:
> > https://gist.github.com/MasterDuke17/9ab9ec5bdbc483bfe63213bf26f82316
> 
> Nice catch. ASAN has fun:
> 
> $ ./perl6-m -Ilib -e 'await (for ^7 { start ‘/etc/hostname’.IO ~~ :e
> })'
> =
> ==9674==ERROR: AddressSanitizer: attempting double-free on
> 0x603000381040 in thread T4:
> #0 0x7fb46d651417 in __interceptor_free
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x7fb46cc99075 in MVM_free src/core/alloc.h:29
> #2 0x7fb46cca388b in MVM_string_flatten src/strings/ops.c:1241
> #3 0x7fb46ca027ef in MVM_interp_run src/core/interp.c:1601
> #4 0x7fb46ca9776a in start_thread src/core/threads.c:77
> #5 0x7fb46cd6152d in uv__thread_start
> 3rdparty/libuv/src/unix/thread.c:49
> #6 0x7fb46bdcfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)
> #7 0x7fb46c2d5aac in __clone (/lib64/libc.so.6+0xe8aac)
> 
> 0x603000381040 is located 0 bytes inside of 24-byte region
> [0x603000381040,0x603000381058)
> freed by thread T1 here:
> #0 0x7fb46d651417 in __interceptor_free
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x7fb46cc99075 in MVM_free src/core/alloc.h:29
> #2 0x7fb46cca388b in MVM_string_flatten src/strings/ops.c:1241
> #3 0x7fb46ca027ef in MVM_interp_run src/core/interp.c:1601
> #4 0x7fb46ca9776a in start_thread src/core/threads.c:77
> #5 0x7fb46cd6152d in uv__thread_start
> 3rdparty/libuv/src/unix/thread.c:49
> #6 0x7fb46bdcfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0)
> 
> previously allocated by thread T0 here:
> #0 0x7fb46d65162f in __interceptor_malloc
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:72
> #1 0x7fb46cc98fef in MVM_malloc src/core/alloc.h:2
> #2 0x7fb46cc9b63c in allocate_strands src/strings/ops.c:27
> #3 0x7fb46cc9d384 in MVM_string_substring src/strings/ops.c:294
> #4 0x7fb46c9feb14 in MVM_interp_run src/core/interp.c:1467
> #5 0x7fb46ccf5bf4 in MVM_vm_run_file src/moar.c:304
> #6 0x401a4f in main src/main.c:191
> #7 0x7fb46c20bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)
> 
> Thread T4 created by T0 here:
> #0 0x7fb46d6206ea in __interceptor_pthread_create
> ../../.././libsanitizer/asan/asan_interceptors.cc:183
> #1 0x7fb46cd61632 in uv_thread_create
> 3rdparty/libuv/src/unix/thread.c:66
> #2 0x7fb46ca97b1b in MVM_thread_run src/core/threads.c:129
> #3 0x7fb46ca3b0a1 in MVM_interp_run src/core/interp.c:3964
> #4 0x7fb46ccf5bf4 in MVM_vm_run_file src/moar.c:304
> #5 0x401a4f in main src/main.c:191
> #6 0x7fb46c20bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)
> 
> Thread T1 created by T0 here:
> #0 0x7fb46d6206ea in __interceptor_pthread_create
> ../../.././libsanitizer/asan/asan_interceptors.cc:183
> #1 0x7fb46cd61632 in uv_thread_create
> 3rdparty/libuv/src/unix/thread.c:66
> #2 0x7fb46ca97b1b in MVM_thread_run src/core/threads.c:129
> #3 0x7fb46ca3b0a1 in MVM_interp_run src/core/interp.c:3964
> #4 0x7fb46ccf5bf4 in MVM_vm_run_file src/moar.c:304
> #5 0x401a4f in main src/main.c:191
> #6 0x7fb46c20bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c)
> 
> SUMMARY: AddressSanitizer: double-free
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:62
> __interceptor_free
> ==9674==ABORTING
> 
The need for string flattening is now gone, meaning the code path that caused 
this bug is also, happily, gone. In S17-promie/start.t I've added a test case 
that far more reliably provoked the bug (in fact, I've never seen it fail to 
provoke the bug).

About other notes on this ticket:

* The "Could not invoke" issue that could also sometimes be triggered by the 
same code was fixed last week in MoarVM commit b4cd2a6555 (and is test covered)

* The abort reported at exit is a `--full-cleanup` issue and unrelated to the 
original issue, so doesn't block closing this ticket. Also, since we only use 
--full-cleanup when running under valgrind, ordinary users will never see this.

Thanks,

/jnthn

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

[via RT]

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


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