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

[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, actually; there's some discussion in the spec, and possibly
in the docs for callframe. The problem is, in the setting most of that
machinery is needed before it can be defined.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Brandon Allbery via RT]

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 problem is, in the setting most of that
machinery is needed before it can be defined.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Joachim Durchholz]

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, actually; there's some discussion in the spec, and
> possibly in the docs for callframe.

Do you mean that the Perl6 spec considers this to be evil, too?

> The problem is, in the setting most
> of that machinery is needed before it can be defined.

Is my understanding correct: That we're looking at a chicken-and-egg 
problem in the implementation?

Re: String to array problem

[Brent Laabs]

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 loop is just so it's printed in the way you demonstrated in the
first post.

The main point of me writing that example in the first place is because I
know that the Perl 6 language itself is very good at parsing quotes.  If
you knew what the string was at compile time, you could just write this:
 my @y = qww;
And it would know exactly how to deal with the quotes.  But I don't know
how to access this functionality of the quote language from within the Perl
6 language.  You can't use qqww directly, because the quote protection is
handled before interpolation, and we want it to happen after.  So I can
eval a qww string instead, and that does work, though it does recognize
kinds of quoting that you wouldn't expect, like dumb quotes or halfwidth
katakana quotes.

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.

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>" ).perl
>> ("ls", "-al", "Program Files", "Moe Curly Larry")
>>
>> How about this?  Obligatory: Much EVAL, very danger wow.
>>
>
> I don't understand.  Would you put this into a full executable example?
>

Re: String to array problem

[ToddAndMargo]

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>" ).perl
("ls", "-al", "Program Files", "Moe Curly Larry")

How about this?  Obligatory: Much EVAL, very danger wow.


I don't understand.  Would you put this into a full executable example?




On 07/17/2017 02:08 AM, Brent Laabs wrote:
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 loop is just so it's printed in the way you demonstrated in the 
first post.


The main point of me writing that example in the first place is because 
I know that the Perl 6 language itself is very good at parsing quotes.  
If you knew what the string was at compile time, you could just write this:

  my @y = qww;
And it would know exactly how to deal with the quotes.  But I don't know 
how to access this functionality of the quote language from within the 
Perl 6 language.  You can't use qqww directly, because the quote 
protection is handled before interpolation, and we want it to happen 
after.  So I can eval a qww string instead, and that does work, though 
it does recognize kinds of quoting that you wouldn't expect, like dumb 
quotes or halfwidth katakana quotes.


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.




Thank you!

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

Re: String to array problem

[Elizabeth Mattijsen]

> 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

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

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

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 = '-'.IO.open: :w;
> my $r = '-'.IO.open;
> $*IN.slurp(:close); #
> $w.put: 'meow  w';
> $*OUT.put: 'x';
> ---8<-
> 
> Save that code to file named open.t and then run it like this:
> 
> $ echo "x" | ./perl6 --ll-exception open.t
> 
> And it'll die with 'Reading from filehandle failed: Bad file
> descriptor'
> 
> This is on Rakudo version 2017.06-252-g83502cc built on MoarVM version
> 2017.06-91-g146c8fc.
> 
> Most notably, removing `--ll-exception` parameter or even removing the
> `#` comment on line 6 causes the bug to disappear.

I investigated this a bit, wondering if the flakiness was a MoarVM bug. It 
turns out that no, MoarVM is doing precisely what is asked of it by Rakudo. :-)

The code in question makes the original handle bound in $*IN unreachable. At 
some point GC runs and collects it. Except it doesn't right away, because 
IO::Handle has a DESTROY method. That DESTROY method runs and closes the 
underlying VM handle. However, because the standard handles don't open a new 
handle, but rather obtain the VM-level handles for stdin/stderr/stdout, we can 
end up with two IO::Handle instances pointing to the same underlying handle. 
The DESTROY closes it, busting the other handle that holds it.

The various tweaks that hide the issue are simply moving when GC takes place, 
meaning it's too early or too late to collect the object and run DESTROY at the 
time that causes the breakage.

/jnthn

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

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

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 = '-'.IO.open: :w;
> my $r = '-'.IO.open;
> $*IN.slurp(:close); #
> $w.put: 'meow  w';
> $*OUT.put: 'x';
> ---8<-
> 
> Save that code to file named open.t and then run it like this:
> 
> $ echo "x" | ./perl6 --ll-exception open.t
> 
> And it'll die with 'Reading from filehandle failed: Bad file
> descriptor'
> 
> This is on Rakudo version 2017.06-252-g83502cc built on MoarVM version
> 2017.06-91-g146c8fc.
> 
> Most notably, removing `--ll-exception` parameter or even removing the
> `#` comment on line 6 causes the bug to disappear.

I investigated this a bit, wondering if the flakiness was a MoarVM bug. It 
turns out that no, MoarVM is doing precisely what is asked of it by Rakudo. :-)

The code in question makes the original handle bound in $*IN unreachable. At 
some point GC runs and collects it. Except it doesn't right away, because 
IO::Handle has a DESTROY method. That DESTROY method runs and closes the 
underlying VM handle. However, because the standard handles don't open a new 
handle, but rather obtain the VM-level handles for stdin/stderr/stdout, we can 
end up with two IO::Handle instances pointing to the same underlying handle. 
The DESTROY closes it, busting the other handle that holds it.

The various tweaks that hide the issue are simply moving when GC takes place, 
meaning it's too early or too late to collect the object and run DESTROY at the 
time that causes the breakage.

/jnthn

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

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

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 users will be hugely unlikely to create 
such files.

> Maybe it's smarter to have a function annotation (i.e. a trait, I
> believe) for "don't include this in backtraces"; this would deal with
> all problems except (2).

The code in question is implemented in NQP, which doesn't have a generalized 
traits mechanism.

As to disabling the filtering mechanism, that's entirely possible today with 
--ll-exception. The code in question is producing backtraces that will contain 
things relevant to a Perl 6 user, using these heuristics to filter out 
implementation guts that will almost certainly always be a distraction. Is it 
beautiful code? No. It's been a pretty good heuristic to date, however.

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

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

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 users will be hugely unlikely to create 
such files.

> Maybe it's smarter to have a function annotation (i.e. a trait, I
> believe) for "don't include this in backtraces"; this would deal with
> all problems except (2).

The code in question is implemented in NQP, which doesn't have a generalized 
traits mechanism.

As to disabling the filtering mechanism, that's entirely possible today with 
--ll-exception. The code in question is producing backtraces that will contain 
things relevant to a Perl 6 user, using these heuristics to filter out 
implementation guts that will almost certainly always be a distraction. Is it 
beautiful code? No. It's been a pretty good heuristic to date, however.

Re: String to array problem

[Brent Laabs]

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 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>" ).perl
>>> ("ls", "-al", "Program Files", "Moe Curly Larry")
>>>
>>> How about this?  Obligatory: Much EVAL, very danger wow.
>>>
>>>
>>> I don't understand.  Would you put this into a full executable
>>> example?
>>>
>>>
>>>
> On 07/17/2017 02:08 AM, Brent Laabs wrote:
>
>> 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 loop is just so it's printed in the way you demonstrated in the
>> first post.
>>
>> The main point of me writing that example in the first place is because I
>> know that the Perl 6 language itself is very good at parsing quotes.  If
>> you knew what the string was at compile time, you could just write this:
>>   my @y = qww;
>> And it would know exactly how to deal with the quotes.  But I don't know
>> how to access this functionality of the quote language from within the Perl
>> 6 language.  You can't use qqww directly, because the quote protection is
>> handled before interpolation, and we want it to happen after.  So I can
>> eval a qww string instead, and that does work, though it does recognize
>> kinds of quoting that you wouldn't expect, like dumb quotes or halfwidth
>> katakana quotes.
>>
>> 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.
>>
>>
> Thank you!
>
>
> --
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
>

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

[Brandon Allbery via RT]

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 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.
>
> Do you mean that the Perl6 spec considers this to be evil, too?
>

Yes. This is an acknowledged hack to provide the functionality when it
can't currently be done "right", and the ticket is a reminder aside from
the comment in the source that a proper solution is needed.

> The problem is, in the setting most
> > of that machinery is needed before it can be defined.
>
> Is my understanding correct: That we're looking at a chicken-and-egg
> problem in the implementation?
>

That's my read, but jnthn's observation that this lives in NQP-land also
complicates things.

(This is not the first chicken-and-egg problem we've had. The setting needs
booleans before perl 6 enums have been defined, so there's a BOOTEnum
thing. At one point it started leaking out, and because it's not a proper
perl 6 class but raw NQP it caused problems.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Brandon Allbery]

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 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.
>
> Do you mean that the Perl6 spec considers this to be evil, too?
>

Yes. This is an acknowledged hack to provide the functionality when it
can't currently be done "right", and the ticket is a reminder aside from
the comment in the source that a proper solution is needed.

> The problem is, in the setting most
> > of that machinery is needed before it can be defined.
>
> Is my understanding correct: That we're looking at a chicken-and-egg
> problem in the implementation?
>

That's my read, but jnthn's observation that this lives in NQP-land also
complicates things.

(This is not the first chicken-and-egg problem we've had. The setting needs
booleans before perl 6 enums have been defined, so there's a BOOTEnum
thing. At one point it started leaking out, and because it's not a proper
perl 6 class but raw NQP it caused problems.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: String to array problem

[Brandon Allbery]

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 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 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>" ).perl
 ("ls", "-al", "Program Files", "Moe Curly Larry")

 How about this?  Obligatory: Much EVAL, very danger wow.


 I don't understand.  Would you put this into a full executable
 example?



>> On 07/17/2017 02:08 AM, Brent Laabs wrote:
>>
>>> 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 loop is just so it's printed in the way you demonstrated in the
>>> first post.
>>>
>>> The main point of me writing that example in the first place is because
>>> I know that the Perl 6 language itself is very good at parsing quotes.  If
>>> you knew what the string was at compile time, you could just write this:
>>>   my @y = qww;
>>> And it would know exactly how to deal with the quotes.  But I don't know
>>> how to access this functionality of the quote language from within the Perl
>>> 6 language.  You can't use qqww directly, because the quote protection is
>>> handled before interpolation, and we want it to happen after.  So I can
>>> eval a qww string instead, and that does work, though it does recognize
>>> kinds of quoting that you wouldn't expect, like dumb quotes or halfwidth
>>> katakana quotes.
>>>
>>> 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.
>>>
>>>
>> Thank you!
>>
>>
>> --
>> ~~
>> Computers are like air conditioners.
>> They malfunction when you open windows
>> ~~
>>
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Joachim Durchholz]

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 
bit overblown, and I'm not deep enough into NQP to make any judgement 
calls anyway.


I'd still like to see the dependency documented in the filtered files. 
People will be more confident hacking the code if they see the relevant 
ramifications documented.

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

[Zoffix Znet via RT]

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::Handle.new: :path('-'.IO);
> > $*IN.open;
> > $*OUT.open: :w;
> >
> > my $w = '-'.IO.open: :w;
> > my $r = '-'.IO.open;
> > $*IN.slurp(:close); #
> > $w.put: 'meow  w';
> > $*OUT.put: 'x';
> > ---8<-
> >
> > Save that code to file named open.t and then run it like this:
> >
> > $ echo "x" | ./perl6 --ll-exception open.t
> >
> > And it'll die with 'Reading from filehandle failed: Bad file
> > descriptor'
> >
> > This is on Rakudo version 2017.06-252-g83502cc built on MoarVM
> > version
> > 2017.06-91-g146c8fc.
> >
> > Most notably, removing `--ll-exception` parameter or even removing
> > the
> > `#` comment on line 6 causes the bug to disappear.
> 
> I investigated this a bit, wondering if the flakiness was a MoarVM
> bug. It turns out that no, MoarVM is doing precisely what is asked of
> it by Rakudo. :-)
> 
> The code in question makes the original handle bound in $*IN
> unreachable. At some point GC runs and collects it. Except it doesn't
> right away, because IO::Handle has a DESTROY method. That DESTROY
> method runs and closes the underlying VM handle. However, because the
> standard handles don't open a new handle, but rather obtain the VM-
> level handles for stdin/stderr/stdout, we can end up with two
> IO::Handle instances pointing to the same underlying handle. The
> DESTROY closes it, busting the other handle that holds it.
> 
> The various tweaks that hide the issue are simply moving when GC takes
> place, meaning it's too early or too late to collect the object and
> run DESTROY at the time that causes the breakage.
> 
> /jnthn


Thanks.

Fix:  https://github.com/rakudo/rakudo/commit/0e578c4fea72e36
Test: https://github.com/perl6/roast/commit/f739f03ff439e75a7

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

[Zoffix Znet via RT]

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::Handle.new: :path('-'.IO);
> > $*IN.open;
> > $*OUT.open: :w;
> >
> > my $w = '-'.IO.open: :w;
> > my $r = '-'.IO.open;
> > $*IN.slurp(:close); #
> > $w.put: 'meow  w';
> > $*OUT.put: 'x';
> > ---8<-
> >
> > Save that code to file named open.t and then run it like this:
> >
> > $ echo "x" | ./perl6 --ll-exception open.t
> >
> > And it'll die with 'Reading from filehandle failed: Bad file
> > descriptor'
> >
> > This is on Rakudo version 2017.06-252-g83502cc built on MoarVM
> > version
> > 2017.06-91-g146c8fc.
> >
> > Most notably, removing `--ll-exception` parameter or even removing
> > the
> > `#` comment on line 6 causes the bug to disappear.
> 
> I investigated this a bit, wondering if the flakiness was a MoarVM
> bug. It turns out that no, MoarVM is doing precisely what is asked of
> it by Rakudo. :-)
> 
> The code in question makes the original handle bound in $*IN
> unreachable. At some point GC runs and collects it. Except it doesn't
> right away, because IO::Handle has a DESTROY method. That DESTROY
> method runs and closes the underlying VM handle. However, because the
> standard handles don't open a new handle, but rather obtain the VM-
> level handles for stdin/stderr/stdout, we can end up with two
> IO::Handle instances pointing to the same underlying handle. The
> DESTROY closes it, busting the other handle that holds it.
> 
> The various tweaks that hide the issue are simply moving when GC takes
> place, meaning it's too early or too late to collect the object and
> run DESTROY at the time that causes the breakage.
> 
> /jnthn


Thanks.

Fix:  https://github.com/rakudo/rakudo/commit/0e578c4fea72e36
Test: https://github.com/perl6/roast/commit/f739f03ff439e75a7

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

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/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')
> || $file.ends-with('Perl6/Ops.nqp');
>
>
> Creating a ticket so that it does not fall through the cracks.

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

[Zoffix Znet via RT]

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 problem is the ticket 
wishes to be solved?

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

[Zoffix Znet via RT]

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 problem is the ticket 
wishes to be solved?

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

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, so we have this ticket. If I am being wrong, then yeah.

On 2017-07-17 09:18:29, c...@zoffix.com wrote:
> 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 problem is
> the ticket wishes to be solved?

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

[Zoffix Znet via RT]

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 like the intention was to improve this part later, but no TODO
> comment was left, so we have this ticket. If I am being wrong, then yeah.
> 
> On 2017-07-17 09:18:29, c...@zoffix.com wrote:
> > 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 problem is
> > the ticket wishes to be solved?


We peek at the filename in many places in Backtrace class. The "evil hack"
comment was added when the full pathname was examined in the past and never
changed when code was changed. Lastly, I'm unware of any issues the current
code is causing or is predicted to be causing, so I removed[^1] the comment
and going to close the ticket.

[1] https://github.com/rakudo/rakudo/commit/91be8bc1ca

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

[Zoffix Znet via RT]

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 like the intention was to improve this part later, but no TODO
> comment was left, so we have this ticket. If I am being wrong, then yeah.
> 
> On 2017-07-17 09:18:29, c...@zoffix.com wrote:
> > 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 problem is
> > the ticket wishes to be solved?


We peek at the filename in many places in Backtrace class. The "evil hack"
comment was added when the full pathname was examined in the past and never
changed when code was changed. Lastly, I'm unware of any issues the current
code is causing or is predicted to be causing, so I removed[^1] the comment
and going to close the ticket.

[1] https://github.com/rakudo/rakudo/commit/91be8bc1ca

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

[Christopher Bottoms via RT]

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 
easily write a Unix-specific test, but I think we want something more general.

On Mon, 31 Oct 2016 08:08:15 -0700, molecules wrote:
> I found that this is not a problem on Perl 6 with a JVM backend. So
> this is MoarVM-specific.
> 
> On Tue May 03 09:01:15 2016, molecules wrote:
> > # This is on 64-bit CentOS 7, but I have also observed this behavior
> > on
> > # CentOS 6.7. User is "test" and has its own group called "test". It
> > should
> > # therefore be possible possible to use "chdir" in Perl6 to change to
> > a
> > # directory that has full privileges for its home group "test".
> >
> > # First we see that "chdir" works when permissions are liberal
> > # The user "test" is not the user owner, but its group does own it.
> > [test@localhost tests]$ ls -ld path
> > drwxrwxr-x. 2 foo test 22 May  3 10:13 path
> > [test@localhost tests]$ perl6
> > To exit type 'exit' or '^D'
> > > chdir 'path'
> > "/home/test/tests/path".IO
> > > chdir '..'
> > "/home/test/tests".IO
> >
> > # "chdir" doesn't work after removing "other" read/execute privileges
> > > shell('sudo chmod o-rx path');
> > ...
> > > chdir 'path'
> > Failed to change the working directory to '/home/test/tests/path':
> > did
> > not pass 'd r' test
> >   in block  at  line 1
> >
> > > exit
> >
> > # But the "test" user does belong to its own "test" group
> > [test@localhost tests]$ groups
> > test
> >
> > # This is using Rakudo-Star 2016.04 on MoarVM 2016.04
> > [test@localhost tests]$ perl6 -v
> > This is Rakudo version 2016.04 built on MoarVM version 2016.04
> > implementing Perl 6.c.

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

[Nick Logan via RT]

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

[perl #131761] Error reported without line nor file

[via RT]

# 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 argument, but no argument was supplied␤␤»

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

[Zoffix Znet via RT]

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 only thing lacking is a good regression test in
> roast. I could easily write a Unix-specific test, but I think we want
> something more general.

What was "fixed" is chdir by default only does the `.d` test now (it used to do 
`.r` test too).
If that's what was needed, then there's a hole battery[^1] of tests covering 
this behaviour.

But I suspect the old behaviour is still there when doing `chdir :d, :r, 'some 
dir'`, so it does the `.r` too.
THAT should respect group privileges, right?

[1] 
https://github.com/perl6/roast/blob/9b51341b6c77bfe6f0ce045431942eadc4301d78/S32-io/chdir.t#L61-L140

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

[Zoffix Znet via RT]

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 only thing lacking is a good regression test in
> roast. I could easily write a Unix-specific test, but I think we want
> something more general.

What was "fixed" is chdir by default only does the `.d` test now (it used to do 
`.r` test too).
If that's what was needed, then there's a hole battery[^1] of tests covering 
this behaviour.

But I suspect the old behaviour is still there when doing `chdir :d, :r, 'some 
dir'`, so it does the `.r` too.
THAT should respect group privileges, right?

[1] 
https://github.com/perl6/roast/blob/9b51341b6c77bfe6f0ce045431942eadc4301d78/S32-io/chdir.t#L61-L140

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

[Joachim Durchholz via RT]

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 
bit overblown, and I'm not deep enough into NQP to make any judgement 
calls anyway.

I'd still like to see the dependency documented in the filtered files. 
People will be more confident hacking the code if they see the relevant 
ramifications documented.

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

[via RT]

# 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).

The script raised an exception when exit.


* *Command*:

$ ./setup-new-coding cpp MEM 54 "Provide placement new with properly
aligned pointers to sufficient storage capacity"

** Before update output*:

Success create directory
MEM54-CPP-Provide-placement-new-with-properly-aligned-pointers-to-sufficient-storage-capacity.
Create main.cpp.

** After update output, then quit from emacs*:

Unhandled exception: const_n32 NYI
at SeekFromEnd:9154 (/usr/share/perl6/runtime/CORE.setting.moarvm:)
from acosh:9154 (/usr/share/perl6/runtime/CORE.setting.moarvm:)
from localhost:9154
(/usr/share/perl6/runtime/CORE.setting.moarvm:THREAD-ENTRY)


*setup-new-coding source*:

#!/usr/bin/env perl6

sub touch(IO::Path:D $path) {
with $path.open(:w) {
.close;
return True;
}
False;
}

sub prompt(Str $str) {
say $str;
}

sub run-emacs(IO::Path:D $path) {
my $proc = Proc::Async.new('emacs', '-nw', $path.path);

await $proc.start;
}

proto MAIN(Str , Str , Str , Str ) { * }

multi MAIN(
'cpp',
$rule,
$id,
$descripte
) {
my $dir = "{$rule}{$id}-CPP-" ~ $descripte.subst(/\s+/, "-", :g);

if $dir.IO.mkdir() -> $dp {
prompt "Success create directory {$dir.path}.";
if $dp.add("main.cpp").&touch {
prompt "Create main.cpp.";
run-emacs $dp;
}
} else {
fail "Create directory failed: $!";
}
}

multi MAIN(
'c',
$rule,
$id,
$descripte
) {
my $dir = "{$rule}{$id}-C-" ~ $descripte.subst(/\s+/, "-", :g);

if $dir.IO.mkdir() -> $dp {
prompt "Success create directory {$dir.path}.";
if $dp.add("main.c").&touch {
prompt "Create main.c.";
run-emacs $dp;
}
} else {
fail "Create directory failed: $!";
}
}

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

[Joachim Durchholz via RT]

> 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')
>   || $file.ends-with('Perl6/Ops.nqp');

I think the whole concept of defining what's "interesting" in a 
backtrace by looking at the file name is pretty evil:

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 
backtrace.
4) It adds a design constraint about what can go into which module of 
the runtime.
5) The design constraint is nonobvious.
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.

Maybe it's smarter to have a function annotation (i.e. a trait, I 
believe) for "don't include this in backtraces"; this would deal with 
all problems except (2).
To address (2), the runtime could offer a setting that defines what 
traits cause backtracking exclusion.

If a trait is not the way to go, one could deal at least with (5) by 
adding a comment at the top of the filtered files:

# Functions in this file will not show up in backtraces.
# See the filename filtering logic in Backtrace::AT-POS
# of rakudo/src/core/Backtrace.pm.


I think line 148 has the same kind of evilness (decide what to do 
depending on the name of the source file), I just couldn't determine 
what the body of the "if" statement is actually doing:

 > if $file.ends-with('NQPHLL.nqp') || $file.ends-with('NQPHLL.moarvm') {

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

[Joachim Durchholz via RT]

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, actually; there's some discussion in the spec, and
 > possibly in the docs for callframe.

Do you mean that the Perl6 spec considers this to be evil, too?

 > The problem is, in the setting most
 > of that machinery is needed before it can be defined.

Is my understanding correct: That we're looking at a chicken-and-egg 
problem in the implementation?

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

[Brandon Allbery]

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
> backtrace.
> 4) It adds a design constraint about what can go into which module of
> the runtime.
> 5) The design constraint is nonobvious.
> 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.
>

7. When Perl 6 gets used on the web, someone *will* find a way to abuse
this (e.g. to obscure how they broke into something).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Brandon Allbery via RT]

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
> backtrace.
> 4) It adds a design constraint about what can go into which module of
> the runtime.
> 5) The design constraint is nonobvious.
> 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.
>

7. When Perl 6 gets used on the web, someone *will* find a way to abuse
this (e.g. to obscure how they broke into something).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Brandon Allbery]

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:
> > 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 easily write a Unix-specific test, but I think we want
> > something more general.
>
> What was "fixed" is chdir by default only does the `.d` test now (it used
> to do `.r` test too).
> If that's what was needed, then there's a hole battery[^1] of tests
> covering this behaviour.
>
> But I suspect the old behaviour is still there when doing `chdir :d, :r,
> 'some dir'`, so it does the `.r` too.
> THAT should respect group privileges, right?
>
> [1] https://github.com/perl6/roast/blob/9b51341b6c77bfe6f0ce045431942e
> adc4301d78/S32-io/chdir.t#L61-L140
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Brandon Allbery via RT]

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:
> > 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 easily write a Unix-specific test, but I think we want
> > something more general.
>
> What was "fixed" is chdir by default only does the `.d` test now (it used
> to do `.r` test too).
> If that's what was needed, then there's a hole battery[^1] of tests
> covering this behaviour.
>
> But I suspect the old behaviour is still there when doing `chdir :d, :r,
> 'some dir'`, so it does the `.r` too.
> THAT should respect group privileges, right?
>
> [1] https://github.com/perl6/roast/blob/9b51341b6c77bfe6f0ce045431942e
> adc4301d78/S32-io/chdir.t#L61-L140
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

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

[Zoffix Znet via RT]

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 
is all it does and without testing, it'll never fail.

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

[Zoffix Znet via RT]

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 
is all it does and without testing, it'll never fail.

zip mystery

[ToddAndMargo]

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


warning: name not matched: /opt/xxx/yyy/zzz/diags/*


What am I doing wrong?

Many thanks,
-T

Re: zip mystery

[ToddAndMargo]

-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 -j eraseme.zip /opt/xxx/yyy/zzz/diags/*


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?

Many thanks,
-T



On 07/17/2017 05:22 PM, Mark Devine wrote:

T,

What happens when you do this?

my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile,  $DiagDir ~ '/*', :out);

Mark


with  $DiagDir ~ '/*'

warning: name not matched: /opt/Cimcor/CimTrak/CimTrakServer/diags/*

RE: zip mystery

[Mark Devine]

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:

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

warning: name not matched: /opt/xxx/yyy/zzz/diags/*


What am I doing wrong?

Many thanks,
-T

Re: zip mystery

[Brandon Allbery]

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 understands that * and
expands it to a list of matching files. If you want that expansion, use
shell() or use Perl 6 to get the directory contents separately and send it
along as a list (see https://docs.perl6.org/type/IO::Path#routine_dir).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: zip mystery

[ToddAndMargo]

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/2017 05:45 PM, Brandon Allbery wrote:


run() does not use a shell. The shell is what understands that * and 
expands it to a list of matching files. If you want that expansion, use 
shell() or use Perl 6 to get the directory contents separately and send 
it along as a list (see https://docs.perl6.org/type/IO::Path#routine_dir).


Now I understand.  Thank you!

Re: zip mystery

[ToddAndMargo]

-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: 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);

warning: name not matched: /opt/xxx/yyy/zzz/diags/*


What am I doing wrong?

Many thanks,
-T



On 07/17/2017 05:22 PM, Mark Devine wrote:

T,

What happens when you do this?

my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile,  $DiagDir ~
'/*', :out);

Mark


with  $DiagDir ~ '/*'

warning: name not matched: /opt/Cimcor/CimTrak/CimTrakServer/diags/*




On 07/17/2017 05:33 PM, Mark Devine wrote:
> T,
>
> It appears to be a 'zip' error, not a Perl 6 issue.  Perhaps use 'zip 
-r' (explicit recursion) instead of '/*' (implicit "glob").

>
> Mark
>
>


Hi Mark,

-jr did the trick!

I had avoided trying it as I thought it would throw an error
as two of the requested entities were files and not
directories.  But the zip folks had already thought of
that and it worked perfectly.

Thank you!

-T

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

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

[via RT]

# 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’, ‘test’;
react {
#whenever $proc.stdout { } # ←↙ these work
#whenever $proc.stderr { } #
whenever $proc { } # ← this doesn't
whenever $proc.start { }
}
say $++;
}

loop { get-output }




The result depends on your luck. Sometimes it gets stuck on the second 
execution, sometimes it manages to do it over 20 times and then gets stuck.

According to this it is supposed to work: 
https://irclog.perlgeek.de/perl6-dev/2017-07-12#i_14862898

I don't know if there's any trap I'm getting into, or if it's just a bug. 
Anyway, I hope a ticket won't hurt.

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

[via RT]

# 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’, ‘-n’, ‘1’;
my $success;
react {
whenever $proc.stdout { $success = True }
whenever $proc.start  { die ‘FAIL!’ unless $success }

$proc.print: “one\ntwo\nthree\nfour”;
$proc.close-stdin;
}
say $++;
}

loop { get-output }


Again, the result depends on your luck. Ideally it should not “die” ever, 
because there should always be one line in the output and therefore $success 
will be set to true. However, sometimes its stdout is empty and therefore it 
fails. It may fail after 20+ executions, and sometimes  it fails almost 
immediately.

Related ticket: https://rt.perl.org/Ticket/Display.html?id=131763

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

[Stefan Seifert via RT]

$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 promises before performing 
the actual nqp::closefh.

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

[Aleks-Daniel Jakimenko-Aleksejev via RT]

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

I'll leave this for somebody else to close.

On 2017-07-17 22:45:01, alex.jakime...@gmail.com wrote:
> Code:
>
> sub get-output() {
> my $proc = Proc::Async.new: :w, ‘head’, ‘-n’, ‘1’;
> my $success;
> react {
> whenever $proc.stdout { $success = True }
> whenever $proc.start { die ‘FAIL!’ unless $success }
>
> $proc.print: “one\ntwo\nthree\nfour”;
> $proc.close-stdin;
> }
> say $++;
> }
>
> loop { get-output }
>
>
> Again, the result depends on your luck. Ideally it should not “die”
> ever, because there should always be one line in the output and
> therefore $success will be set to true. However, sometimes its stdout
> is empty and therefore it fails. It may fail after 20+ executions, and
> sometimes it fails almost immediately.
>
> Related ticket: https://rt.perl.org/Ticket/Display.html?id=131763