Oh, good point!
Yes, but works --
my @lines;
$*OUT = $*OUT but role { method print($str) { @lines.push($str) } };
note "stderr is ok";
use Test;
say "hello";
is @lines[0], "hello\n", 'stdout is wrapped'
stderr is ok
ok 1 - stdout is wrapped
On Thu, Oct 25, 2018 at 9:39 PM Brandon A
I didn't phrase that quite right.
pyanfar Z$ 6 'my @lines; $*OUT.^find_method("print").wrap: -> $self, $str {
@lines.push($str) }; use Test; note "hello"; is @lines[0], "hello\n",
"wrapped err too"'
ok 1 - wrapped err too
This wraps it for every IO::Handle, not just for the IO::Handle in $*OUT.
Y
On Thursday, October 25, Brandon Allbery wrote:
> You can't actually wrap print that way, can you? Or rather, if that works
> it wouldn't be specific to $*ERR.
Um, you definitely can, and yes it's not specific to $*ERR, e.g.
my @lines;
$*OUT.^find_method('print').wrap: -> $self, $str { @
You can't actually wrap print that way, can you? Or rather, if that works
it wouldn't be specific to $*ERR.
On Thu, Oct 25, 2018 at 6:16 PM Brian Duggan wrote:
> On Thursday, October 25, Richard Hainsworth wrote:
> > >&exit.wrap: -> $status { $exit-args = $status; fail }
> >
> > Is the call to '
On Thursday, October 25, Richard Hainsworth wrote:
> >&exit.wrap: -> $status { $exit-args = $status; fail }
>
> Is the call to 'fail' replicating the original action of &exit?
No -- the call to fail is throwing an exception. The idea
is that the exception could then be caught in the test.
> >¬e
I'm trying to understand this. Would someone provide a bit more explanation?
On 25/10/2018 10:47, Brian Duggan wrote:
On Sunday, October 21, Richard Hainsworth wrote:
so .. either I use your suggestion of 'exit note $message' which I find
elegant, but so far difficult to test.
You could always
On Sunday, October 21, Richard Hainsworth wrote:
> so .. either I use your suggestion of 'exit note $message' which I find
> elegant, but so far difficult to test.
You could always wrap things, e.g. something like --
my ( $exit-args, $note-args );
&exit.wrap: -> $status { $exit-args = $status;
It seems to me that a role would be a far better idea.
Further if the role could check an environment variable, eg.
%*ENV, then it could only stop the default Exception
handler providing backtrace when the environment is set.
May be compiler developers could consider making this part of the
Better implementation idea
A. A role "X-no-trace" to compose into any exception class,
B. which at BEGIN installs into the outermost scope CATCH block for
anything that does X-no-trace,
C. 3-6 as before :-)
that way, no need for COMPOSE block and $?CLASS variable. And as a bonus,
can add the X-no
Richard seems to be close to a workable answer, but now I am wondering
about this issue.
Imagine writing a configuration-checking class (or role) to be sure all the
files and directories exist at startup. The goal is to use exceptions, so
the consumer of the checker can use standard exception hand
And that is the way to test it.
but then I cant work out how to get the message. I've been looking at
Zoffix's Test::Output, but not
Incomplete sentence there. I guess it doesn't work for you? Tell
us how you tried to use it, what you were expecting, and what happened
instead.
On Sun, Oct 21, 2018, 12:09 Richard Hainsworth
wrote:
> I am trying to find a way to send a message via STDERR to a user, and to
> exit, but to eliminate the backtrace printing.
>
> so .. either I use your suggestion of 'exit note $message' which I find
> elegant, but so far difficult to test.
>
I am trying to find a way to send a message via STDERR to a user, and to
exit, but to eliminate the backtrace printing.
so .. either I use your suggestion of 'exit note $message' which I find
elegant, but so far difficult to test.
(I tried timo's suggestion of &*EXIT = -> | { die 'exited' }
I’m not sure what you mean by: "How do I attach a default CATCH to all methods
in the class.”. What are you trying to achieve?
> On 21 Oct 2018, at 10:35, Richard Hainsworth wrote:
>
> This sounds great.
>
> So I am writing a class verifies conditions, and dies when conditions are not
> met.
This sounds great.
So I am writing a class verifies conditions, and dies when conditions
are not met.
How do I attach a default CATCH to all methods in the class.
Or do I need to define my own Exception.
On 04/09/18 04:48, Curt Tilmes wrote:
On Mon, Sep 3, 2018 at 4:28 PM Parrot Raiser <
Hi all,
On Mon, 3 Sep 2018 11:09:35 -0700
Larry Wall wrote:
> On Mon, Sep 03, 2018 at 11:45:58AM -0500, Stephen Wilcoxon wrote:
> : Why the change in die handling between Perl 5 and 6? Suppressing line
> : numbers with newline was very handy. Alternatively, adding some sort of
> : directive wo
FWIW, that’s because the True returned by the “note” gets coerced to Int: True
-> 1
> On 4 Sep 2018, at 15:32, Parrot Raiser <1parr...@gmail.com> wrote:
>
> exit note "message";
> seems to work well as a substitute. "note" outputs the message, and
> exit sends the return code (1) to the OS, mark
exit note "message";
seems to work well as a substitute. "note" outputs the message, and
exit sends the return code (1) to the OS, marking a failure.
On Mon, Sep 3, 2018 at 10:50 PM Curt Tilmes wrote:
> On Mon, Sep 3, 2018 at 4:28 PM Parrot Raiser <1parr...@gmail.com> wrote:
>
>> If I understand that correctly, "die" needs to be documented as always
>> outputting the line number, and that for user-oriented messages, one
>> of the other techniq
On Mon, Sep 3, 2018 at 4:28 PM Parrot Raiser <1parr...@gmail.com> wrote:
> If I understand that correctly, "die" needs to be documented as always
> outputting the line number, and that for user-oriented messages, one
> of the other techniques should be used.
>
die throws the Exception -- you can
If I understand that correctly, "die" needs to be documented as always
outputting the line number, and that for user-oriented messages, one
of the other techniques should be used.
Otherwise, this question is likely to come up a lot.
On Mon, Sep 03, 2018 at 11:45:58AM -0500, Stephen Wilcoxon wrote:
: Why the change in die handling between Perl 5 and 6? Suppressing line
: numbers with newline was very handy. Alternatively, adding some sort of
: directive would be more straight-forward (at least for Perl 5 users moving
: to Per
Why the change in die handling between Perl 5 and 6? Suppressing line
numbers with newline was very handy. Alternatively, adding some sort of
directive would be more straight-forward (at least for Perl 5 users moving
to Perl 6).
On Mon, Sep 3, 2018 at 11:32 AM, Elizabeth Mattijsen wrote:
> not
note “message”; exit
> On 3 Sep 2018, at 18:03, Parrot Raiser <1parr...@gmail.com> wrote:
>
> perl6 -v
> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> implementing Perl 6.c.
>
> In Perl 5:
> die "Message"; outputs Message, followed by the program line number.
> die "Mes
24 matches
Mail list logo
