[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)

Alright, it seems that rakudo is not entirely incorrect here. See this discussion: https://irclog.perlgeek.de/perl6-dev/2017-07-18#i_14885863 TL;DR, one should use something like this: whenever $proc.print(“one\ntwo\nthree\nfour”) { $proc.close-stdin } So it seems that it's not a bug, but a trap

[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)

$proc.print is asynchronous while $proc.close-stdin is not. In some cases $proc simply does not get the input because we closed its stdin before printing anything. If .close-stdin is meant to by synchronous, this needs a doc patch. Otherwise we'd probably need to await any outstanding write pro

[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #131764] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131764 > Code: sub get-output() { my $proc = Proc::Async.new: :w, ‘head’,

[perl #131763] Merged output of Proc::Async does not work (whenever $proc { … })

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #131763] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131763 > Code: sub get-output() { my $proc = Proc::Async.new: ‘echo’, ‘te

Re: zip mystery

-Original Message- From: ToddAndMargo [mailto:toddandma...@zoho.com] Sent: Monday, July 17, 2017 8:29 PM To: perl6-users Subject: Re: zip mystery -Original Message- From: ToddAndMargo [mailto:toddandma...@zoho.com] Sent: Monday, July 17, 2017 8:19 PM To: perl6-users Subject: zi

Re: zip mystery

On Mon, Jul 17, 2017 at 8:18 PM, ToddAndMargo > wrote: But this does not: my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile", "$DiagDir/*", :out); warning: name not matched: /opt/xxx/yyy/zzz/diags/* What am I doing wrong? On 07/17/

Re: zip mystery

On Mon, Jul 17, 2017 at 8:18 PM, ToddAndMargo wrote: > But this does not: > > my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile", > "$DiagDir/*", :out); > > warning: name not matched: /opt/xxx/yyy/zzz/diags/* > > What am I doing wrong? > run() does not use a shell. The shell is what un

RE: zip mystery

T, What happens when you do this? my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile, $DiagDir ~ '/*', :out); Mark -Original Message- From: ToddAndMargo [mailto:toddandma...@zoho.com] Sent: Monday, July 17, 2017 8:19 PM To: perl6-users Subject: zip mystery Hi All, This runs: m

Re: zip mystery

-Original Message- From: ToddAndMargo [mailto:toddandma...@zoho.com] Sent: Monday, July 17, 2017 8:19 PM To: perl6-users Subject: zip mystery Hi All, This runs: my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile", "$DiagDir/BlankFile.txt", :out); And this also works (bash)

zip mystery

Hi All, This runs: my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile", "$DiagDir/BlankFile.txt", :out); And this also works (bash) zip -j eraseme.zip /opt/xxx/yyy/zzz/diags/* But this does not: my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile", "$DiagDir/*", :out);

[perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

On Mon, 17 Jul 2017 16:12:05 -0700, allber...@gmail.com wrote: > It should not be testing, it should just try to do the operation and > complain after if it fails. Race conditions should not be a language > 'feature'. We're talking about &chdir() not &*chdir(). Aside from setting $*CWD, testing i

[perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

On Mon, 17 Jul 2017 16:12:05 -0700, allber...@gmail.com wrote: > It should not be testing, it should just try to do the operation and > complain after if it fails. Race conditions should not be a language > 'feature'. We're talking about &chdir() not &*chdir(). Aside from setting $*CWD, testing i

Re: [perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

It should not be testing, it should just try to do the operation and complain after if it fails. Race conditions should not be a language 'feature'. On Mon, Jul 17, 2017 at 6:02 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Mon, 17 Jul 2017 10:26:43 -0700, molecules wrote: >

Re: [perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

It should not be testing, it should just try to do the operation and complain after if it fails. Race conditions should not be a language 'feature'. On Mon, Jul 17, 2017 at 6:02 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Mon, 17 Jul 2017 10:26:43 -0700, molecules wrote: >

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, Jul 17, 2017 at 2:49 AM, Joachim Durchholz via RT < perl6-bugs-follo...@perl.org> wrote: > 1) It cannot handle non-runtime code that one might want to filter. > 2) It hardcodes the definition of what's interesting. > 3) You cannot have runtime code that you *want* to be included in the > b

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, Jul 17, 2017 at 2:49 AM, Joachim Durchholz via RT < perl6-bugs-follo...@perl.org> wrote: > 1) It cannot handle non-runtime code that one might want to filter. > 2) It hardcodes the definition of what's interesting. > 3) You cannot have runtime code that you *want* to be included in the > b

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

Am 17.07.2017 um 09:32 schrieb Brandon Allbery: > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz > wrote: > > I think the whole concept of defining what's "interesting" in > a backtrace by looking at the file name is pretty evil: > > So does Per

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

> See this: > https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6b8150fc6830/src/core/Backtrace.pm#L144 > > It goes like this: > > # now *that's* an evil hack > next if $file.ends-with('BOOTSTRAP.nqp') > || $file.ends-with('QRegex.nqp')

[perl #131758] [BUG] running script exit crash after update rakudo

# New Ticket Created by gfw blackcat # Please include the string: [perl #131758] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131758 > Start a running script with old rakudo(2017.06), then update rakudo version(2017.07). Th

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

Am 17.07.2017 um 11:34 schrieb jn...@jnthn.net via RT: > The code in question is implemented in NQP, which doesn't have a generalized > traits mechanism. Ahh, may bad, this being NQP files flew right by me and I didn't see it. I retract the traits idea - adding that just for this issue might be

[perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

On Mon, 17 Jul 2017 10:26:43 -0700, molecules wrote: > This doesn't seem to be a problem with Rakudo 2017.04, so was probably > fixed by Zoffix's I/O work (see > http://blogs.perl.org/users/zoffix_znet/2017/04/perl-6-io-tpf-grant- > monthly-report-april-2017.html). Thanks! > > I think that the onl

[perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

On Mon, 17 Jul 2017 10:26:43 -0700, molecules wrote: > This doesn't seem to be a problem with Rakudo 2017.04, so was probably > fixed by Zoffix's I/O work (see > http://blogs.perl.org/users/zoffix_znet/2017/04/perl-6-io-tpf-grant- > monthly-report-april-2017.html). Thanks! > > I think that the onl

[perl #131761] Error reported without line nor file

# New Ticket Created by nadim khemir # Please include the string: [perl #131761] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131761 > m: printf "%s" rakudo-moar 91be8b: OUTPUT: «Your printf-style directives specify 1 argu

[perl #130883] problem with RESOURCES and PERL6LIB env variable

The %?RESOURCES bug was fixed in: https://github.com/rakudo/rakudo/pull/1106

[perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege

This doesn't seem to be a problem with Rakudo 2017.04, so was probably fixed by Zoffix's I/O work (see http://blogs.perl.org/users/zoffix_znet/2017/04/perl-6-io-tpf-grant-monthly-report-april-2017.html). Thanks! I think that the only thing lacking is a good regression test in roast. I could ea

[perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, 17 Jul 2017 09:25:26 -0700, alex.jakime...@gmail.com wrote: > I think the purpose of the ticket was stated clearly in the first message. > > Feel free to change the comment in the source code to “This is a hack but > there's no point to improve it” and close the ticket. > > To me it felt

[perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, 17 Jul 2017 09:25:26 -0700, alex.jakime...@gmail.com wrote: > I think the purpose of the ticket was stated clearly in the first message. > > Feel free to change the comment in the source code to “This is a hack but > there's no point to improve it” and close the ticket. > > To me it felt

[perl #131757] Untodoed evil hack in Backtrace.pm

I think the purpose of the ticket was stated clearly in the first message. Feel free to change the comment in the source code to “This is a hack but there's no point to improve it” and close the ticket. To me it felt like the intention was to improve this part later, but no TODO comment was left,

[perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, 17 Jul 2017 08:33:12 -0700, alex.jakime...@gmail.com wrote: > I don't think this ticket needs so much discussion… It's basically > about > implementing the damn thing properly (and coming up with a way to do > it along > the way). What problems does the current implementation have? What pr

[perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, 17 Jul 2017 08:33:12 -0700, alex.jakime...@gmail.com wrote: > I don't think this ticket needs so much discussion… It's basically > about > implementing the damn thing properly (and coming up with a way to do > it along > the way). What problems does the current implementation have? What pr

[perl #131757] Untodoed evil hack in Backtrace.pm

I don't think this ticket needs so much discussion… It's basically about implementing the damn thing properly (and coming up with a way to do it along the way). On 2017-07-16 21:17:22, alex.jakime...@gmail.com wrote: > See this: > https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6

[perl #131755] Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code

On Mon, 17 Jul 2017 02:19:39 -0700, jn...@jnthn.net wrote: > On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote: > > The original failure was in t/spec/S32-io/open.t test that I golfed > > down to the following: > > > > ---8<- > > $*IN = IO

[perl #131755] Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code

On Mon, 17 Jul 2017 02:19:39 -0700, jn...@jnthn.net wrote: > On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote: > > The original failure was in t/spec/S32-io/open.t test that I golfed > > down to the following: > > > > ---8<- > > $*IN = IO

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

Am 17.07.2017 um 11:34 schrieb jn...@jnthn.net via RT: The code in question is implemented in NQP, which doesn't have a generalized traits mechanism. Ahh, may bad, this being NQP files flew right by me and I didn't see it. I retract the traits idea - adding that just for this issue might be a

Re: String to array problem

And this is another reason for the Grammar solution: it lets you do just what is needed, in a constrained environment so you don't have any risk (unless you do something questionable in the Grammar, but then that's on you.) On Mon, Jul 17, 2017 at 6:15 AM, Brent Laabs wrote: > Just to make it cl

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz wrote: > Am 17.07.2017 um 09:32 schrieb Brandon Allbery: > > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz > > wrote: > > > > I think the whole concept of defining what's "interesting" in > > a bac

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz wrote: > Am 17.07.2017 um 09:32 schrieb Brandon Allbery: > > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz > > wrote: > > > > I think the whole concept of defining what's "interesting" in > > a bac

Re: String to array problem

Just to make it clear, do not use EVAL() ever on untrusted user input. In the example I wrote, if the string contained a '>', anything after that point would be executed. While it works, it's a bad idea to use it. On Mon, Jul 17, 2017 at 2:17 AM, ToddAndMargo wrote: > On Sun, Jul 16, 2017 at 1

[perl #131757] Untodoed evil hack in Backtrace.pm

On Sun, 16 Jul 2017 23:49:55 -0700, j...@durchholz.org wrote: > 6) If somebody writes his own module in a different location but with > a > matching name (e.g. they might be writing a wrapper, or an emulator), > then these files will be filtered as well. > The filenames end in .nqp. A Perl 6 use

[perl #131757] Untodoed evil hack in Backtrace.pm

On Sun, 16 Jul 2017 23:49:55 -0700, j...@durchholz.org wrote: > 6) If somebody writes his own module in a different location but with > a > matching name (e.g. they might be writing a wrapper, or an emulator), > then these files will be filtered as well. > The filenames end in .nqp. A Perl 6 use

[perl #131755] Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code

On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote: > The original failure was in t/spec/S32-io/open.t test that I golfed > down to the following: > > ---8<- > $*IN = IO::Handle.new: :path('-'.IO); > $*IN.open; > $*OUT.open: :w; > > my $w

[perl #131755] Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code

On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote: > The original failure was in t/spec/S32-io/open.t test that I golfed > down to the following: > > ---8<- > $*IN = IO::Handle.new: :path('-'.IO); > $*IN.open; > $*OUT.open: :w; > > my $w

Re: String to array problem

> On 17 Jul 2017, at 11:08, Brent Laabs wrote: > All of this is to say that I wish the Str.words method had a way of applying > Perl 6 quoting rules as if it were the qww operator. Wouldn’t that be either .split or .comb? Liz

Re: String to array problem

On Sun, Jul 16, 2017 at 11:34 PM, ToddAndMargo > wrote: On 07/16/2017 07:48 PM, Brent Laabs wrote: $ perl6 > my $x='ls -al "Program Files" "Moe Curly Larry"'; ls -al "Program Files" "Moe Curly Larry" > &EVAL( "qww<$x>" ).per

Re: String to array problem

I would put it in an executable example, and I already did. But here's another one, if you like. $ perl6 -e 'my $x = q; my @y = &EVAL( "qww<$x>"); for @y.kv -> $i, $j { say " \@y[$i] = \c39$j\c39" }' @y[0] = 'ls' @y[1] = '-al' @y[2] = 'Program Files' @y[3] = 'Moe Curly Larry' The last l

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

Am 17.07.2017 um 09:32 schrieb Brandon Allbery: > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz > wrote: > > I think the whole concept of defining what's "interesting" in > a backtrace by looking at the file name is pretty evil: > > So does Perl 6,

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz wrote: > I think the whole concept of defining what's "interesting" in a backtrace >> by looking at the file name is pretty evil: > > So does Perl 6, actually; there's some discussion in the spec, and possibly in the docs for callframe. The probl

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz wrote: > I think the whole concept of defining what's "interesting" in a backtrace >> by looking at the file name is pretty evil: > > So does Perl 6, actually; there's some discussion in the spec, and possibly in the docs for callframe. The probl