[perl #131167] [JVM] Newly-added NQP test for catching exceptions fails on JVM
I have committed https://github.com/perl6/nqp/commit/59d7a8869c and this test passes now. As far as I understand, the right handler was missed when moving to the outside, because unwind_check sets the outer handler to 0 by default if no outer handler is passed. We do the latter now. I'm closing this ticket as 'resolved'.
Re: exceptions in threads
Oh, great! I was running the latest version I saw
listed in 'rakudobrew list-available' which is 2018.10:
~ $ perl6 -v
This is Rakudo version 2018.10 built on MoarVM version 2018.10
implementing Perl 6.c.
thanks!
Brian
On Saturday, November 10, Elizabeth Mattijsen wrote:
> In v6.d this throws the exception:
>
> $ 6 'start die("bye"); sleep 1'
> Unhandled exception in code scheduled on thread 4
> bye
> in code at -e line 1
>
>
> whereas the exception is silently ignored in 6.c:
>
> $ 6 'use v6.c; start die("bye"); sleep 1'
>
> Not sure if this answers your question, as it is unclear from your question
> on which version you are running.
>
>
>
> > On 10 Nov 2018, at 13:59, Brian Duggan wrote:
> >
> > Hi Perl 6 Users,
> >
> > What's the best way to know that an exception
> > occurred in another thread, e.g.
> >
> >$ perl6 -e 'start say("hi"); sleep 1'
> >hi
> >$
> >
> > but
> >
> >$ perl6 -e 'start die("bye"); sleep 1'
> >$
> >
> > I thought maybe $*SCHEDULER.uncaught_handler
> > would help out here, but it didn't seem to.
> >
> > thanks
> > Brian
Re: exceptions in threads
In v6.d this throws the exception:
$ 6 'start die("bye"); sleep 1'
Unhandled exception in code scheduled on thread 4
bye
in code at -e line 1
whereas the exception is silently ignored in 6.c:
$ 6 'use v6.c; start die("bye"); sleep 1'
Not sure if this answers your question, as it is unclear from your question on
which version you are running.
> On 10 Nov 2018, at 13:59, Brian Duggan wrote:
>
> Hi Perl 6 Users,
>
> What's the best way to know that an exception
> occurred in another thread, e.g.
>
>$ perl6 -e 'start say("hi"); sleep 1'
>hi
>$
>
> but
>
>$ perl6 -e 'start die("bye"); sleep 1'
>$
>
> I thought maybe $*SCHEDULER.uncaught_handler
> would help out here, but it didn't seem to.
>
> thanks
> Brian
exceptions in threads
Hi Perl 6 Users,
What's the best way to know that an exception
occurred in another thread, e.g.
$ perl6 -e 'start say("hi"); sleep 1'
hi
$
but
$ perl6 -e 'start die("bye"); sleep 1'
$
I thought maybe $*SCHEDULER.uncaught_handler
would help out here, but it didn't seem to.
thanks
Brian
Re: Catching exceptions in expressions
Yes; but then I think that something like infix: probably just ends up
as a macro somehow. I just didn't know the state of macros in Perl 6 well
enough to be able to head down that route. :)
Pm
On Fri, Aug 03, 2018 at 10:32:41PM +0200, Elizabeth Mattijsen wrote:
> Sometimes I wish we could use Thunk as a type:
>
> sub infix:(Thunk:D $block, $otherwise) { }
>
> which would then allow you to do:
>
> my $sixdivzero = divide(6,0) rescue -1; # note absence of curlies
>
>
>
> One can wish, can’t one?
>
>
> Liz
>
> > On 3 Aug 2018, at 22:18, Patrick R. Michaud wrote:
> >
> > Maybe something like...?
> >
> > $ cat t.p6
> >
> > sub infix:(Callable $block, $otherwise) {
> > CATCH { return $otherwise; }
> > $block();
> > }
> >
> > sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
> >
> > my $sixdivzero = { divide(6,0) } rescue -1;
> > say "6/0 = ", $sixdivzero;
> >
> > my $sixdivtwo = { divide(6,2) } rescue -1;
> > say "6/2 = ", $sixdivtwo;
> >
> >
> > $ perl6 t.p6
> > 6/0 = -1
> > 6/2 = 3
> >
> >
> > Or if you prefer a prefix form, just declare "rescue" as a normal sub and
> > then do:
> >
> > rescue { divide(6,2) }, -1;
> >
> > Pm
> >
> > On Fri, Aug 03, 2018 at 08:34:44PM +0100, Simon Proctor wrote:
> >> Hi Sean. I hope my second answer in stackoverflow gets closer to what you
> >> want.
> >>
> >> I am still trying to think of a more idiomatic way of handling to
> >> situation.
> >>
> >>
> >>
> >> On Fri, 3 Aug 2018, 19:29 Sean McAfee, wrote:
> >>
> >>> I posted about this subject on Stack Overflow yesterday[1], but I chose a
> >>> poor example of something that raises an exception (dividing by zero,
> >>> which
> >>> apparently doesn't necessarily do so) on which the answers have mostly
> >>> focused.
> >>>
> >>> I was looking for a way to evaluate an expression, and if the expression
> >>> threw an exception, for a default value to be provided instead. For
> >>> example, in Ruby:
> >>>
> >>>quotient = begin; a / b; rescue; -1; end
> >>>
> >>> Or in Lisp:
> >>>
> >>>(setq quotient (condition-case nil (/ a b) (error -1)))
> >>>
> >>> Not having written much exception-related code in Perl 6, I hoped that
> >>> this might work:
> >>>
> >>>sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
> >>>my $quotient = do { divide($a, $b); CATCH { default { -1 } } };
> >>>
> >>> It doesn't, though. As far as I can tell, the value to which a CATCH
> >>> block evaluates is ignored; the only useful things one can do in such a
> >>> block are things with side effects. Long story short, I eventually came
> >>> up
> >>> with this:
> >>>
> >>>my $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
> >>> = -1 } } }; $q };
> >>>
> >>> That's far more verbose than I've come to expect from Perl 6. Is there
> >>> some more concise way of expressing this logic?
> >>>
> >>> The doc page on exceptions mentions try, eg:
> >>>
> >>>my $quotient = try { divide($a, $b) } // -1;
> >>>
> >>> That works in this specific case, but it seems insufficient in general.
> >>> The function might validly return an undefined value, and this
> >>> construction
> >>> can't distinguish between that and an exception. Also, it wouldn't let me
> >>> distinguish among various exception cases. I'd have to do something like:
> >>>
> >>>class EA is Exception { }
> >>>class EB is Exception { }
> >>>sub divide($a, $b) { (EA, EB).pick.new.throw if $b == 0; $a / $b }
> >>>
> >>>my $quotient = do { my $q; { $q = divide($a, $b); CATCH { when EA { $q
> >>> = -1 }; when EB { $q = -2 } } }; $q };
> >>>
> >>>
> >>> [1]
> >>> https://stackoverflow.com/questions/51644197/returning-values-from-exception-handlers-in-perl-6/51670573
> >>>
> >> --
> >> Simon Proctor
> >> Cognoscite aliquid novum cotidie
Re: Catching exceptions in expressions
Sometimes I wish we could use Thunk as a type:
sub infix:(Thunk:D $block, $otherwise) { }
which would then allow you to do:
my $sixdivzero = divide(6,0) rescue -1; # note absence of curlies
One can wish, can’t one?
Liz
> On 3 Aug 2018, at 22:18, Patrick R. Michaud wrote:
>
> Maybe something like...?
>
> $ cat t.p6
>
> sub infix:(Callable $block, $otherwise) {
> CATCH { return $otherwise; }
> $block();
> }
>
> sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
>
> my $sixdivzero = { divide(6,0) } rescue -1;
> say "6/0 = ", $sixdivzero;
>
> my $sixdivtwo = { divide(6,2) } rescue -1;
> say "6/2 = ", $sixdivtwo;
>
>
> $ perl6 t.p6
> 6/0 = -1
> 6/2 = 3
>
>
> Or if you prefer a prefix form, just declare "rescue" as a normal sub and
> then do:
>
> rescue { divide(6,2) }, -1;
>
> Pm
>
> On Fri, Aug 03, 2018 at 08:34:44PM +0100, Simon Proctor wrote:
>> Hi Sean. I hope my second answer in stackoverflow gets closer to what you
>> want.
>>
>> I am still trying to think of a more idiomatic way of handling to situation.
>>
>>
>>
>> On Fri, 3 Aug 2018, 19:29 Sean McAfee, wrote:
>>
>>> I posted about this subject on Stack Overflow yesterday[1], but I chose a
>>> poor example of something that raises an exception (dividing by zero, which
>>> apparently doesn't necessarily do so) on which the answers have mostly
>>> focused.
>>>
>>> I was looking for a way to evaluate an expression, and if the expression
>>> threw an exception, for a default value to be provided instead. For
>>> example, in Ruby:
>>>
>>>quotient = begin; a / b; rescue; -1; end
>>>
>>> Or in Lisp:
>>>
>>>(setq quotient (condition-case nil (/ a b) (error -1)))
>>>
>>> Not having written much exception-related code in Perl 6, I hoped that
>>> this might work:
>>>
>>>sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
>>>my $quotient = do { divide($a, $b); CATCH { default { -1 } } };
>>>
>>> It doesn't, though. As far as I can tell, the value to which a CATCH
>>> block evaluates is ignored; the only useful things one can do in such a
>>> block are things with side effects. Long story short, I eventually came up
>>> with this:
>>>
>>>my $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
>>> = -1 } } }; $q };
>>>
>>> That's far more verbose than I've come to expect from Perl 6. Is there
>>> some more concise way of expressing this logic?
>>>
>>> The doc page on exceptions mentions try, eg:
>>>
>>>my $quotient = try { divide($a, $b) } // -1;
>>>
>>> That works in this specific case, but it seems insufficient in general.
>>> The function might validly return an undefined value, and this construction
>>> can't distinguish between that and an exception. Also, it wouldn't let me
>>> distinguish among various exception cases. I'd have to do something like:
>>>
>>>class EA is Exception { }
>>>class EB is Exception { }
>>>sub divide($a, $b) { (EA, EB).pick.new.throw if $b == 0; $a / $b }
>>>
>>>my $quotient = do { my $q; { $q = divide($a, $b); CATCH { when EA { $q
>>> = -1 }; when EB { $q = -2 } } }; $q };
>>>
>>>
>>> [1]
>>> https://stackoverflow.com/questions/51644197/returning-values-from-exception-handlers-in-perl-6/51670573
>>>
>> --
>> Simon Proctor
>> Cognoscite aliquid novum cotidie
Re: Catching exceptions in expressions
Maybe something like...?
$ cat t.p6
sub infix:(Callable $block, $otherwise) {
CATCH { return $otherwise; }
$block();
}
sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
my $sixdivzero = { divide(6,0) } rescue -1;
say "6/0 = ", $sixdivzero;
my $sixdivtwo = { divide(6,2) } rescue -1;
say "6/2 = ", $sixdivtwo;
$ perl6 t.p6
6/0 = -1
6/2 = 3
Or if you prefer a prefix form, just declare "rescue" as a normal sub and then
do:
rescue { divide(6,2) }, -1;
Pm
On Fri, Aug 03, 2018 at 08:34:44PM +0100, Simon Proctor wrote:
> Hi Sean. I hope my second answer in stackoverflow gets closer to what you
> want.
>
> I am still trying to think of a more idiomatic way of handling to situation.
>
>
>
> On Fri, 3 Aug 2018, 19:29 Sean McAfee, wrote:
>
> > I posted about this subject on Stack Overflow yesterday[1], but I chose a
> > poor example of something that raises an exception (dividing by zero, which
> > apparently doesn't necessarily do so) on which the answers have mostly
> > focused.
> >
> > I was looking for a way to evaluate an expression, and if the expression
> > threw an exception, for a default value to be provided instead. For
> > example, in Ruby:
> >
> > quotient = begin; a / b; rescue; -1; end
> >
> > Or in Lisp:
> >
> > (setq quotient (condition-case nil (/ a b) (error -1)))
> >
> > Not having written much exception-related code in Perl 6, I hoped that
> > this might work:
> >
> > sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
> > my $quotient = do { divide($a, $b); CATCH { default { -1 } } };
> >
> > It doesn't, though. As far as I can tell, the value to which a CATCH
> > block evaluates is ignored; the only useful things one can do in such a
> > block are things with side effects. Long story short, I eventually came up
> > with this:
> >
> > my $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
> > = -1 } } }; $q };
> >
> > That's far more verbose than I've come to expect from Perl 6. Is there
> > some more concise way of expressing this logic?
> >
> > The doc page on exceptions mentions try, eg:
> >
> > my $quotient = try { divide($a, $b) } // -1;
> >
> > That works in this specific case, but it seems insufficient in general.
> > The function might validly return an undefined value, and this construction
> > can't distinguish between that and an exception. Also, it wouldn't let me
> > distinguish among various exception cases. I'd have to do something like:
> >
> > class EA is Exception { }
> > class EB is Exception { }
> > sub divide($a, $b) { (EA, EB).pick.new.throw if $b == 0; $a / $b }
> >
> > my $quotient = do { my $q; { $q = divide($a, $b); CATCH { when EA { $q
> > = -1 }; when EB { $q = -2 } } }; $q };
> >
> >
> > [1]
> > https://stackoverflow.com/questions/51644197/returning-values-from-exception-handlers-in-perl-6/51670573
> >
> --
> Simon Proctor
> Cognoscite aliquid novum cotidie
Re: Catching exceptions in expressions
Hi Sean. I hope my second answer in stackoverflow gets closer to what you
want.
I am still trying to think of a more idiomatic way of handling to situation.
On Fri, 3 Aug 2018, 19:29 Sean McAfee, wrote:
> I posted about this subject on Stack Overflow yesterday[1], but I chose a
> poor example of something that raises an exception (dividing by zero, which
> apparently doesn't necessarily do so) on which the answers have mostly
> focused.
>
> I was looking for a way to evaluate an expression, and if the expression
> threw an exception, for a default value to be provided instead. For
> example, in Ruby:
>
> quotient = begin; a / b; rescue; -1; end
>
> Or in Lisp:
>
> (setq quotient (condition-case nil (/ a b) (error -1)))
>
> Not having written much exception-related code in Perl 6, I hoped that
> this might work:
>
> sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
> my $quotient = do { divide($a, $b); CATCH { default { -1 } } };
>
> It doesn't, though. As far as I can tell, the value to which a CATCH
> block evaluates is ignored; the only useful things one can do in such a
> block are things with side effects. Long story short, I eventually came up
> with this:
>
> my $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
> = -1 } } }; $q };
>
> That's far more verbose than I've come to expect from Perl 6. Is there
> some more concise way of expressing this logic?
>
> The doc page on exceptions mentions try, eg:
>
> my $quotient = try { divide($a, $b) } // -1;
>
> That works in this specific case, but it seems insufficient in general.
> The function might validly return an undefined value, and this construction
> can't distinguish between that and an exception. Also, it wouldn't let me
> distinguish among various exception cases. I'd have to do something like:
>
> class EA is Exception { }
> class EB is Exception { }
> sub divide($a, $b) { (EA, EB).pick.new.throw if $b == 0; $a / $b }
>
> my $quotient = do { my $q; { $q = divide($a, $b); CATCH { when EA { $q
> = -1 }; when EB { $q = -2 } } }; $q };
>
>
> [1]
> https://stackoverflow.com/questions/51644197/returning-values-from-exception-handlers-in-perl-6/51670573
>
--
Simon Proctor
Cognoscite aliquid novum cotidie
Catching exceptions in expressions
I posted about this subject on Stack Overflow yesterday[1], but I chose a
poor example of something that raises an exception (dividing by zero, which
apparently doesn't necessarily do so) on which the answers have mostly
focused.
I was looking for a way to evaluate an expression, and if the expression
threw an exception, for a default value to be provided instead. For
example, in Ruby:
quotient = begin; a / b; rescue; -1; end
Or in Lisp:
(setq quotient (condition-case nil (/ a b) (error -1)))
Not having written much exception-related code in Perl 6, I hoped that this
might work:
sub divide($a, $b) { die "Zero denominator" if $b == 0; $a / $b }
my $quotient = do { divide($a, $b); CATCH { default { -1 } } };
It doesn't, though. As far as I can tell, the value to which a CATCH block
evaluates is ignored; the only useful things one can do in such a block are
things with side effects. Long story short, I eventually came up with this:
my $quotient = do { my $q; { $q = divide($a, $b); CATCH { default { $q
= -1 } } }; $q };
That's far more verbose than I've come to expect from Perl 6. Is there
some more concise way of expressing this logic?
The doc page on exceptions mentions try, eg:
my $quotient = try { divide($a, $b) } // -1;
That works in this specific case, but it seems insufficient in general.
The function might validly return an undefined value, and this construction
can't distinguish between that and an exception. Also, it wouldn't let me
distinguish among various exception cases. I'd have to do something like:
class EA is Exception { }
class EB is Exception { }
sub divide($a, $b) { (EA, EB).pick.new.throw if $b == 0; $a / $b }
my $quotient = do { my $q; { $q = divide($a, $b); CATCH { when EA { $q
= -1 }; when EB { $q = -2 } } }; $q };
[1]
https://stackoverflow.com/questions/51644197/returning-values-from-exception-handlers-in-perl-6/51670573
[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions
On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote:
> If you `die` inside a `map/for` that is being `hyper/race`d...
>
> for (1..1).hyper { die }; sleep 1; say "Alive";
>
> ...it prints the exception's backtrace, but then resumes the program
> as if nothing had happened:
>
> Died
> in block at -e line 1
>
> Alive
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t. The new error reporting shows the backtrace of both the
thing that went wrong in a worker thread, and the place that triggered the
iteration.
[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions
On Thu, 08 Sep 2016 12:55:10 -0700, sml...@gmail.com wrote:
> If you `die` inside a `map/for` that is being `hyper/race`d...
>
> for (1..1).hyper { die }; sleep 1; say "Alive";
>
> ...it prints the exception's backtrace, but then resumes the program
> as if nothing had happened:
>
> Died
> in block at -e line 1
>
> Alive
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and
S07-hyperrace/race.t. The new error reporting shows the backtrace of both the
thing that went wrong in a worker thread, and the place that triggered the
iteration.
[perl #131504] [LTA] . form differs from foo($_) when routine throws control exceptions
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131504]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131504 >
I assumed the . form was just a nicer way of writing foo($_), however they
differ in that
the thrown control exception doesn't go far enough in . form and it doesn't
actually
return from the routine with things like . and .
m: sub { 'foo'. 42 }().^name.say
rakudo-moar 64e898: OUTPUT: «foo in sub at line 1 in
block at line 1Actually thrown at: in sub at line 1
in block at line 1»
m: sub { fail 'foo'; 42 }().^name.say
rakudo-moar 64e898: OUTPUT: «Failure»
m: sub { return 'foo'; 42 }().^name.say
rakudo-moar 64e898: OUTPUT: «Str»
m: sub { 'foo'. 42 }().^name.say
rakudo-moar 64e898: OUTPUT: «Int»
[perl #131118] [RFC][@LARRY] Implement a way to propagate exceptions in Junctions
On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote: > Consider this junction which you probably shouldn't make but you know > will happen in the hands of users: > > any( 5, 'flarg' ) == 5 > > Despite having an element that satisfies the condition, it blows up > because one of them doesn't: > > > any(5, "flarg") == 5 > Cannot convert string to number: base-10 number must begin with > valid digits or '.' in '⏏flarg' (indicated by ⏏) > in block at line 1 > > But, it should't matter that what happens with any other parts of the > junction if at least one of them satisfies the condition. You could, > for instance, evaluate that differently so the new junction looks > something like this: > > any( True, Failure ); > > But, I don't think it should evaluate to another junction at all. The > comparison operator should evaluate to a Boolean. That Failure will > never matter because it's equivalent to False. Thank you for the report. However, I'm going to reject the ticket. As previous replies mentioned, there's no problem with Failures in a Junctions, they work as any other value. The actual explosion in OP's code happens when one of the Failures—created when 'flarg' was coerced to Numeric—is used as a value for the purposes of evaluating the `==` op with it. That's when the Exception gets thrown. I'm unsure if one of the suggestions was to catch such exceptions and turn them into Failures again... If it were, it's not a good idea, since Junctions are not meant to be well-introspectable and just silencing exception like that is bound to end in tears. Some of the other suggestions were to make `try` Junctionable and stuff a Junction into $! variable. If that's possible to do at all, IMO it should be done as a trial in a module first, to evaluate usability and any issues with the compatibility with core code. Lastly, I added a 'Failures and Exceptions' section to Junction docs[^1] that explains the issues raised in this ticket as well as shows some of possible ways to attain the goals, if really necessary. [1] https://github.com/perl6/doc/commit/7628708384bdc049d74c997fc2059cf57fcf5a57
[perl #131118] [RFC][@LARRY] Implement a way to propagate exceptions in Junctions
On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote: > Consider this junction which you probably shouldn't make but you know > will happen in the hands of users: > > any( 5, 'flarg' ) == 5 > > Despite having an element that satisfies the condition, it blows up > because one of them doesn't: > > > any(5, "flarg") == 5 > Cannot convert string to number: base-10 number must begin with > valid digits or '.' in '⏏flarg' (indicated by ⏏) > in block at line 1 > > But, it should't matter that what happens with any other parts of the > junction if at least one of them satisfies the condition. You could, > for instance, evaluate that differently so the new junction looks > something like this: > > any( True, Failure ); > > But, I don't think it should evaluate to another junction at all. The > comparison operator should evaluate to a Boolean. That Failure will > never matter because it's equivalent to False. Thank you for the report. However, I'm going to reject the ticket. As previous replies mentioned, there's no problem with Failures in a Junctions, they work as any other value. The actual explosion in OP's code happens when one of the Failures—created when 'flarg' was coerced to Numeric—is used as a value for the purposes of evaluating the `==` op with it. That's when the Exception gets thrown. I'm unsure if one of the suggestions was to catch such exceptions and turn them into Failures again... If it were, it's not a good idea, since Junctions are not meant to be well-introspectable and just silencing exception like that is bound to end in tears. Some of the other suggestions were to make `try` Junctionable and stuff a Junction into $! variable. If that's possible to do at all, IMO it should be done as a trial in a module first, to evaluate usability and any issues with the compatibility with core code. Lastly, I added a 'Failures and Exceptions' section to Junction docs[^1] that explains the issues raised in this ticket as well as shows some of possible ways to attain the goals, if really necessary. [1] https://github.com/perl6/doc/commit/7628708384bdc049d74c997fc2059cf57fcf5a57
[perl #131167] [JVM] Newly-added NQP test for catching exceptions fails on JVM
# New Ticket Created by Zoffix Znet # Please include the string: [perl #131167] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131167 > I had to fudge it for the release and will unfudge after the release. The test tests if a labeled exception is uncaught by inner unlabled handler and is caught by outer labeled handler instead, but on JVM it's uncaught entirely. Fudge: https://github.com/perl6/nqp/commit/0994e33818 Output of failing test: Unhandled exception; category = 4224 in (gen/jvm/stage2/NQPHLL.nqp:1281) in (gen/jvm/stage2/NQPHLL.nqp) in catch_unlabeled_first (t/nqp/044-try-catch.t:428) in (t/nqp/044-try-catch.t:439) in eval (gen/jvm/stage2/NQPHLL.nqp:1168) in evalfiles (gen/jvm/stage2/NQPHLL.nqp:1371) in command_eval (gen/jvm/stage2/NQPHLL.nqp:1265) in command_line (gen/jvm/stage2/NQPHLL.nqp:1239) in MAIN (gen/jvm/stage2/NQP.nqp:4130) in (gen/jvm/stage2/NQP.nqp:4126) in (gen/jvm/stage2/NQP.nqp)
[perl #126787] [CONC] Promises that are not awaited or .then'd will swallow exceptions.
On Wed, 02 Dec 2015 13:52:24 -0800, timo wrote:
> just about an exception in a
> Promise that nobody is interested in (no await, no .then, ...) are
> silently nommed:
This version has a `.then` but doesn't explode. Is it meant to then?
use v6;
my $foo;
my $promise = Promise.new;
$promise.keep; # no difference with break
# note i added an "await" here.
$promise.then({
note 41;
$foo.does-not-exist; # hangs? thread dies? no error message!
note 42; # never reached!
}).then: { say "hi" };
sleep 5;
And this one explodes, but there's no location shown for where the error occurs:
use v6;
my $foo;
my $promise = Promise.new;
$promise.keep; # no difference with break
# note i added an "await" here.
await $promise.then({
note 41;
$foo.does-not-exist; # hangs? thread dies? no error message!
note 42; # never reached!
});
sleep 5;
# zoffix@VirtualBox:~/CPANPRC/rakudo$ ./perl6 test.p641
# ===SORRY!===
# No such method 'does-not-exist' for invocant of type 'Any'
# zoffix@VirtualBox:~/CPANPRC/rakudo$
This is Rakudo version 2016.11-220-g29b228c built on MoarVM version
2016.11-41-gd2139b5
[perl #125782] [CONC] Uncaught exceptions in start { } blocks get no backtrace when raised via await
On Mon Aug 10 14:20:34 2015, r...@hoelz.ro wrote: > See the attached script. > > The original backtrace of an exception seems to vanish when awaiting a > Promise throws that exception. Now we show both backtraces, and more clearly explain what happened (that we're throwing now because the result of a broken Promise was requested, followed by the original exception that broke the Promise and its location). Test in S17-promise/start.t. /jnthn
[perl #129234] [CONC] `.hyper` and `.race` resume after exceptions
# New Ticket Created by Sam S.
# Please include the string: [perl #129234]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129234 >
If you `die` inside a `map/for` that is being `hyper/race`d...
for (1..1).hyper { die }; sleep 1; say "Alive";
...it prints the exception's backtrace, but then resumes the program as if
nothing had happened:
Died
in block at -e line 1
Alive
[perl #128470] [BUG] Certain Exceptions Crash REPL
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #128470]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128470 >
Hi,
I've tracked this issue to this commit:
https://github.com/rakudo/rakudo/commit/6b935928a52be5819b6d384b1596e0125250a18b
If you try running this piece of code in REPL, it'll exit the REPL after
printing the error:
[1..99].map:{[$_%%5&&'fizz', $_%%3&&'buzz'].grep:Str}
Here's the error:
zoffix@VirtualBox:~/CPANPRC/rakudo$ ./perl6-m
To exit type 'exit' or '^D'
You may want to `panda install Readline` or `panda install Linenoise` or use
rlwrap for a line editor
> [1..99].map:{[$_%%5&&'fizz', $_%%3&&'buzz'].grep:Str}
===SORRY!===
Cannot resolve caller grep(Array: ); none of these signatures match:
($: Bool:D $t, *%_)
($: Mu $t, *%_)
zoffix@VirtualBox:~/CPANPRC/rakudo$
The issue doesn't happen with every exception and I wasn't able to golf the
above code.
[perl #127977] [BUG] Constraint on a slurpy MAIN parameter leaks out internal exceptions
For the records: There is a test for this ticket (currently fudged 'todo') in S06-other/main-usage.t
Re: [perl #127977] AutoReply: [BUG] Constraint on a slurpy MAIN parameter leaks out internal exceptions
https://github.com/rakudo/rakudo/tree/rt-127977 contains a fix for that
On 24/04/16 12:28, perl6 via RT wrote:
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"[BUG] Constraint on a slurpy MAIN parameter leaks out internal
exceptions",
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [perl #127977].
Please include the string:
[perl #127977]
in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.
Thank you,
perl6-bugs-follo...@perl.org
-
$ cat test.pl
sub MAIN(@args where sub { False }) {
say ":)"
}
$ perl6 test.pl
Usage:
test.pl
$ cat test.pl # note the slurpy
sub MAIN(*@args where sub { False }) {
say ":)"
}
$ perl6 test.pl
Constraint type check failed for parameter '@args'
in sub MAIN at test.pl line 1
in block at test.pl line 1
--
I expect USAGE in both cases, since it's both exactly invalid use of MAIN.
Patch and spectest incoming.
[perl #127977] [BUG] Constraint on a slurpy MAIN parameter leaks out internal exceptions
# New Ticket Created by Tadeusz Sośnierz
# Please include the string: [perl #127977]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127977 >
$ cat test.pl
sub MAIN(@args where sub { False }) {
say ":)"
}
$ perl6 test.pl
Usage:
test.pl
$ cat test.pl # note the slurpy
sub MAIN(*@args where sub { False }) {
say ":)"
}
$ perl6 test.pl
Constraint type check failed for parameter '@args'
in sub MAIN at test.pl line 1
in block at test.pl line 1
--
I expect USAGE in both cases, since it's both exactly invalid use of MAIN.
Patch and spectest incoming.
[perl #125621] Uncaught exceptions in Supply.tap are silenced
On Wed Jul 15 21:09:12 2015, r...@hoelz.ro wrote: > See the attached file. > > The code in the attached file should make some indication that > something in the code called provided to Supply.tap is going wrong, > but the execution completes silently. The exceptions got lost due to a thinko in the scheduler. Fixed now, and test added to S17-supply/interval.t. /jnthn
[perl #125782] Uncaught exceptions in start { } blocks get no backtrace when raised via await
# New Ticket Created by Rob Hoelz # Please include the string: [perl #125782] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=125782 See the attached script. The original backtrace of an exception seems to vanish when awaiting a Promise throws that exception.
[perl #125657] Rethrowing of exceptions by print_exception in src/core/Exception.pm doesn't preserve stacktrace
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #125657]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/Ticket/Display.html?id=125657
For an example, see the attached script.
I understand that if the if $! { ... } block is hit, there's a limited amount
of work that can be done, but I think we could probably go out of our way to
get the backtrace where the exception happened more often so that's what the
user sees.my class BadException is Exception {
method gist {
die 'nope';
}
}
sub baz {
BadException.new.throw;
}
sub bar {
baz();
}
sub foo {
bar();
}
foo();
[perl #125621] Uncaught exceptions in Supply.tap are silenced
# New Ticket Created by Rob Hoelz # Please include the string: [perl #125621] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/Ticket/Display.html?id=125621 See the attached file. The code in the attached file should make some indication that something in the code called provided to Supply.tap is going wrong, but the execution completes silently. test.p6 Description: Binary data
[perl6/specs] 0da73b: Add StubCode to exceptions
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 0da73b885f08b6d06adbeacef32ec21f1cca0da0 https://github.com/perl6/specs/commit/0da73b885f08b6d06adbeacef32ec21f1cca0da0 Author: Rob Hoelz r...@hoelz.ro Date: 2015-06-07 (Sun, 07 Jun 2015) Changed paths: M S32-setting-library/Exception.pod Log Message: --- Add StubCode to exceptions
[perl #62086] ~ in regexes shouldn't cause thrown exceptions
On Mon May 11 05:26:45 2015, pmichaud wrote: After discussion with jnthn at OSDC.no, here's what we propose: In the regex engine, the default FAILGOAL behavior should be to simply fail/backtrack. This would be the default behavior for (rakudo) Cursor as well. Grammars that wish to have the generate-an-exception behavior can override FAILGOAL to do so. The HLL::Grammar class (in NQP) will do this, meaning that Rakudo's grammar will still inherit/retain the throw-an-exception behavior. Part of our reasoning (which may be faulty) for this approach is that it's relatively easy to override FAILGOAL in a grammar but harder to do so for regexes that aren't in a grammar. In the latter case (regex), it's more likely that you want simple backtracking rather than the throw an error message, so that should be the default. This sounds very sane. +1
[perl #62086] ~ in regexes shouldn't cause thrown exceptions
masak as an author of grammars, I still find it annoying and difficult that
grammars generally fail, that is, return a failing match -- *unless* you use
the `~` combinator, in which case they nqp::die with an exception that can't be
properly caught using a CATCH.
masak in effect, that gives grammars three possible outcomes: success,
failure, or death-because-of-failgoal.
masak oh, I've kvetched about that before, it seems:
https://rt.perl.org/Ticket/Display.html?id=62086
jnthn masak: Why can't it be caught with a CATCH?
jnthn masak: Also, you're free to override FAILGOAL...
masak I don't rightly know why it can't be. I'm having trouble reproducing
the error in golfed code.
masak m: grammar G { regex TOP { a ~ c foo }; regex foo { b } }; say
?G.parse(abbc); CATCH { when X::AdHoc { say caught } }
camelia rakudo-moar 20aa85: OUTPUT«caught»
masak ok, here I *could* catch it. weird.
jnthn In all the cases we use it for in the Perl 6 grammar, it'd be useless
if it didn't throw, fwiw.
* masak adds that to the ticket
jnthn Of course, I guess we could have a default FAILGOAL that just fails and
override it with one that throws.
masak if all outcomes of a grammar return a failed Match object *except* for
FAILGOAL, then I'd like there to be a good theoretical explanation for FAILGOAL
behaving differently.
masak and not just we need to convey an error message here, so throwing an
exception feels right
jnthn panic is another example
masak categorically, it's still just a failed match. it feels like with the
current setup, we're committing a category error.
masak or rather, what precise thing is it that makes a parse failure so
severe that it promotes from falsy to die?
masak right now, from what I can see, the need to attach an error message.
jnthn That, and also wanting to give up at that point because there's no sane
way to proceed and you'd never want something further up to try another path.
masak oh, right. control flow.
masak still, a use case I mention in earlier parts of that ticket is I just
want to parse something in order to find out whether it's valid or not. having
to deal with three-valued logic in that case is just... cruft.
jnthn Then don't use ~
masak I suppose.
[perl6/specs] 2be530: (S32/Exceptions) Add X::Range::InvalidArg excepti...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 2be530687ec3e11c211d1971830b4044b5439128 https://github.com/perl6/specs/commit/2be530687ec3e11c211d1971830b4044b5439128 Author: pmichaud pmich...@pobox.com Date: 2013-03-16 (Sat, 16 Mar 2013) Changed paths: M S32-setting-library/Exception.pod Log Message: --- (S32/Exceptions) Add X::Range::InvalidArg exception.
[perl6/specs] 4d51ab: force exceptions to lc or uc
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 4d51ab7f6d4e25b03009543070fb1346ef3ef301 https://github.com/perl6/specs/commit/4d51ab7f6d4e25b03009543070fb1346ef3ef301 Author: Larry Wall la...@wall.org Date: 2012-07-24 (Tue, 24 Jul 2012) Changed paths: M S32-setting-library/Str.pod Log Message: --- force exceptions to lc or uc
[perl6/specs] a0d5a9: A couple of fixes to the exceptions spec.
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: a0d5a9eda3d378d00fea47fb0aeee634718876bb https://github.com/perl6/specs/commit/a0d5a9eda3d378d00fea47fb0aeee634718876bb Author: jnthn jn...@jnthn.net Date: 2012-03-08 (Thu, 08 Mar 2012) Changed paths: M S04-control.pod Log Message: --- A couple of fixes to the exceptions spec.
[perl #106832] [BUG] Failure objects don't expose their underlying exceptions, except by re-throwing them
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #106832]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=106832
moritz wow, it seems that nom's Failure doesn't expose the
underlying exception, except by re-throwing it :/
masak that's... a regression.
masak b: sub foo { fail ooh! }; say foo().exception.payload
p6eval b 1b7dd1: OUTPUT«ooh!»
masak nom: sub foo { fail ooh! }; say foo().exception.payload
p6eval nom 7a1925: OUTPUT«ooh! in method anon at
src/gen/CORE.setting:6930 [...]
moritz aye, I'm going to chain that
* masak submits rakudobug
moritz masak: would be .exception.Str on nom
moritz and will be
masak nom: sub foo { fail ooh! }; say foo().exception.Str
p6eval nom 7a1925: OUTPUT«ooh! in method anon at
src/gen/CORE.setting:6930 [...]
Re: [perl #106832] [BUG] Failure objects don't expose their underlying exceptions, except by re-throwing them
Now fixed, and tested in t/spec/S04-exceptions/fail.t
On 12/22/2011 04:13 PM, Carl MXXsak (via RT) wrote:
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #106832]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=106832
moritz wow, it seems that nom's Failure doesn't expose the
underlying exception, except by re-throwing it :/
masak that's... a regression.
masak b: sub foo { fail ooh! }; say foo().exception.payload
p6eval b 1b7dd1: OUTPUT«ooh!»
masak nom: sub foo { fail ooh! }; say foo().exception.payload
p6eval nom 7a1925: OUTPUT«ooh! in method anon at
src/gen/CORE.setting:6930 [...]
moritz aye, I'm going to chain that
* masak submits rakudobug
moritz masak: would be .exception.Str on nom
moritz and will be
masak nom: sub foo { fail ooh! }; say foo().exception.Str
p6eval nom 7a1925: OUTPUT«ooh! in method anon at
src/gen/CORE.setting:6930 [...]
[perl6/specs] 12c8b5: [S32::Exceptions] briefly describe the default exc...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 12c8b58f52bc05322339153e58643c4f98318321 https://github.com/perl6/specs/commit/12c8b58f52bc05322339153e58643c4f98318321 Author: Moritz Lenz mor...@faui2k3.org Date: 2011-12-19 (Mon, 19 Dec 2011) Changed paths: M S32-setting-library/Exception.pod Log Message: --- [S32::Exceptions] briefly describe the default exception printer
[perl #69991] Exceptions from io.pir not being properly thrown
chdir still isn't throwing a CATCHable error. It now lives in
src/core/IO.pm
proto sub chdir(|$) { * }
multi sub chdir($path as Str) {
try {
pir::new__PS('OS').chdir($path)
}
$! ?? fail($!) !! True
}
--
Will Coke Coleda
[perl #69160] Twin exceptions cause assertion failure and/or unrequested error message
On Wed Sep 16 02:56:54 2009, moritz wrote:
Thanks for the ticket, it's a very good catch and analysis.
I have some small comments on it:
Bruce Gray (via RT) wrote:
# New Ticket Created by Bruce Gray
# Please include the string: [perl #69160]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69160
Consider these two classes, both faulty in the same way:
class B0rk { say $.a };
class Chef { say $.b };
Failure mode changed, and is now more consistent, but worse.
$ ./perl6 -e 'class B0rk { say $.a };'
Null PMC access in find_method('a')
$ ./perl6 -e 'class Chef { say $.b };'
Null PMC access in find_method('b')
--
Will Coke Coleda
[perl6/specs] f30cc8: cmp does not throw exceptions, just fails
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: f30cc880516c7f8a85decc30f8615042bc29dbec https://github.com/perl6/specs/commit/f30cc880516c7f8a85decc30f8615042bc29dbec Author: Larry Wall la...@wall.org Date: 2011-07-06 (Wed, 06 Jul 2011) Changed paths: M S03-operators.pod Log Message: --- cmp does not throw exceptions, just fails Also discuss mass production ops that tend to pass failures through rather than throw them. Which ops are so considered is of course a matter for ongoing negotiation. Commit: 1a67e98abca16ed4bcd20a12f110eec4ed1309c6 https://github.com/perl6/specs/commit/1a67e98abca16ed4bcd20a12f110eec4ed1309c6 Author: Larry Wall la...@wall.org Date: 2011-07-06 (Wed, 06 Jul 2011) Changed paths: M S02-bits.pod Log Message: --- nail down return types of colon radix notation Compare: https://github.com/perl6/specs/compare/839c329...1a67e98
[perl6/specs] e84b11: eval() does not catch exceptions
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: e84b11137cc55ecd9f17f58976c08d361054ea05 https://github.com/perl6/specs/commit/e84b11137cc55ecd9f17f58976c08d361054ea05 Author: Moritz Lenz mor...@faui2k3.org Date: 2011-06-30 (Thu, 30 Jun 2011) Changed paths: M S29-functions.pod Log Message: --- eval() does not catch exceptions
[perl6/specs] 15b1a4: [S32/Exceptions] add a few syntax errors
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 15b1a49e67ffeaccc09cd0abbd0d311437665e7b https://github.com/perl6/specs/commit/15b1a49e67ffeaccc09cd0abbd0d311437665e7b Author: Moritz Lenz mor...@faui2k3.org Date: 2011-05-08 (Sun, 08 May 2011) Changed paths: M S32-setting-library/Exception.pod Log Message: --- [S32/Exceptions] add a few syntax errors
[perl6/specs] a29e38: [S32/Exceptions] move %.payload into a separate cl...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: a29e38794ae5a388ca25af482a851273ed103c81 https://github.com/perl6/specs/commit/a29e38794ae5a388ca25af482a851273ed103c81 Author: Moritz Lenz mor...@faui2k3.org Date: 2011-05-04 (Wed, 04 May 2011) Changed paths: M S32-setting-library/Exception.pod Log Message: --- [S32/Exceptions] move %.payload into a separate class, based on feedback by sorear++
[perl #75620] some exceptions throw you out of the rakudo shell
On Tue Jun 08 12:33:03 2010, cognominal wrote: I golfed the problematic statement to : $ perl6 lc ~$_ for Match.^methods lc ~$_ for Match.^methods get_string() not implemented in class 'ArrayIterator' $ say my mac is freaking me out # oops I was thrown out from the rakudo shell $ ./perl6 lc ~$_ for Match.^methods Method 'methods' not found for invocant of class 'P6metaclass' lc ~$_ for Match.^methods Method 'methods' not found for invocant of class 'P6metaclass' lc ~$_ for Match.^methods Method 'methods' not found for invocant of class 'P6metaclass' lc ~$_ for Match.^methods Method 'methods' not found for invocant of class 'P6metaclass' say my mac is freaking me out # oops I was thrown out from the rakudo shell my mac is freaking me out This appears to be working now: $ ./perl6 --version This is Rakudo Perl 6, version 2010.07-140-g67778a6 built on parrot 2.7.0 r48560 Copyright 2008-2010, The Perl Foundation Thanks for the report. -- Will Coke Coleda
r31691 -[S04] more bombastic utterances about not dropping pending exceptions
Author: lwall Date: 2010-07-15 01:53:05 +0200 (Thu, 15 Jul 2010) New Revision: 31691 Modified: docs/Perl6/Spec/S04-control.pod Log: [S04] more bombastic utterances about not dropping pending exceptions Modified: docs/Perl6/Spec/S04-control.pod === --- docs/Perl6/Spec/S04-control.pod 2010-07-14 23:32:07 UTC (rev 31690) +++ docs/Perl6/Spec/S04-control.pod 2010-07-14 23:53:05 UTC (rev 31691) @@ -1043,6 +1043,16 @@ never attempts to handle any exception thrown within its own dynamic scope. (Otherwise any Cdie would cause an infinite loop.) +Any attempt to throw a fatal exception past an already active exception +handler must guarantee to steal the existing fatal exception (plus +any pending exceptions it contains) and add all those to the new +exception's pending list. (This does not apply to control exceptions +described in the next section.) When the new exception is handled, +it must also deal with the list of pending exceptions, or the Cwrap-die +mentioned above will throw a Pending exceptions not handled at that point. +Even this does not discard the pending exceptions, so in the final outermost +message, all non-handled exceptions are guaranteed to be listed. + =head1 Control Exceptions All abnormal control flow is, in the general case, handled by the
[perl #75620] some exceptions throw you out of the rakudo shell
# New Ticket Created by Stephane Payrard # Please include the string: [perl #75620] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75620 I golfed the problematic statement to : $ perl6 lc ~$_ for Match.^methods lc ~$_ for Match.^methods get_string() not implemented in class 'ArrayIterator' $ say my mac is freaking me out # oops I was thrown out from the rakudo shell -- cognominal stef
[perl #75292] Exceptions make the REPL segfault
# New Ticket Created by Moritz Lenz # Please include the string: [perl #75292] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75292 Everything that produces an exception (doesn't matter if compile time or run time) makes the REPL segfault For example: foo Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f9c06b7f6f0 (LWP 499)] 0x7f9c06607b62 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x3122720) at src/gc/api.c:181 181 VTABLE_mark(interp, obj); backtrace: #0 0x7f9c06607b62 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x3122720) at src/gc/api.c:181 #1 0x7f9c066524f8 in Parrot_Exception_mark (interp=0x2c93010, _self=value optimized out) at ./src/pmc/exception.pmc:160 #2 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x31227e0) at src/gc/api.c:181 #3 0x7f9c0668b4d7 in Parrot_CallContext_mark (interp=0x2c93010, _self=0x3122040) at ./src/pmc/callcontext.pmc:349 #4 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x3122040) at src/gc/api.c:181 #5 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x3121b60) at src/gc/api.c:181 #6 0x7f9c0668b4d7 in Parrot_CallContext_mark (interp=0x2c93010, _self=0x3120f40) at ./src/pmc/callcontext.pmc:349 #7 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x3120f40) at src/gc/api.c:181 #8 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x3120ac0) at src/gc/api.c:181 #9 0x7f9c0668b4d7 in Parrot_CallContext_mark (interp=0x2c93010, _self=0x311ff40) at ./src/pmc/callcontext.pmc:349 #10 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, obj=0x311ff40) at src/gc/api.c:181 #11 0x7f9c06607b68 in Parrot_gc_mark_PMC_alive_fun (interp=0x2c93010, and so on, recursively Cheers, Mooritz
[perl #69991] Exceptions from io.pir not being properly thrown
# New Ticket Created by Mark Montague
# Please include the string: [perl #69991]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69991
Exceptions from src/builtins/io.pir (and possibly elsewhere) are not
being properly thrown:
diff --git a/src/builtins/io.pir b/src/builtins/io.pir
index 69cdf88..10fe7e8 100644
--- a/src/builtins/io.pir
+++ b/src/builtins/io.pir
@@ -172,6 +172,7 @@ true value is returned.
failure:
pop_eh
+print parrot exception for chdir caught\n
.tailcall '!FAIL'('Unable to change to directory ', newdir, '')
.end
$ ./perl6 -e 'try { chdir(/no/such/directory); CATCH { say caught; } }'
parrot exception for chdir caught
$
The above should also have said caught but did not. The same thing
happens for mkdir():
$ ./perl6 -e 'try { mkdir(/no/such/directory); CATCH { say caught; } }'
$
However, this works:
$ ./perl6 -e 'try { fail(oh noes); CATCH { say caught; } }'
caught
$
Extra info:
$ git pull
Already up-to-date.
$ git rev-parse HEAD
501b4fb08ece44433e2bbedba0ef13e3e523f883
$ parrot_config VERSION # built and installed separately from rakudo
1.7.0
Mark Montague
markm...@umich.edu
[perl #69160] Twin exceptions cause assertion failure and/or unrequested error message
# New Ticket Created by Bruce Gray
# Please include the string: [perl #69160]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69160
Consider these two classes, both faulty in the same way:
class B0rk { say $.a };
class Chef { say $.b };
Each class makes reference to a attribute that has not been declared,
and so should fail to compile:
$ ./perl6 -e 'class B0rk { say $.a }; say Done;'
Lexical 'self' not found
$ ./perl6 -e 'class Chef { say $.b }; say Done;'
Lexical 'self' not found
While the error message might not be helpful, its shortcomings are not
important to this issue.
The important thing is that *some* error is produced, and that
compilation is aborted.
All is working as expected, when the classes are directly compiled.
Either class, when evaled solo, behaves as expected. Execution
proceeds, and the error message is placed in $!.
$ ./perl6 -e 'eval q[ class B0rk { say $.a; }; ]; say Done;'
Done
$ ./perl6 -e 'eval q[ class Chef { say $.b; }; ]; say Done;'
Done
$ ./perl6 -e 'eval q[ class B0rk { say $.a; }; ]; say $!;'
Lexical 'self' not found
$ ./perl6 -e 'eval q[ class Chef { say $.b; }; ]; say $!;'
Lexical 'self' not found
All is working as expected, when the classes are evaled in isolation
from each other.
Evaling the classes together produces two different unexpected
behaviours, depending on how the code is combined.
First, we put both classes into the same string to be evaled once.
$ ./perl6 -e 'eval q[ class B0rk { say $.a; }; class Chef { say
$.b; }; ]; say Done;'
Done
Lexical 'self' not found
current instr.: 'perl6;Chef;_block43' pc -1 ((unknown file):-1)
called from Sub 'perl6;Perl6;Compiler;main' pc -1 ((unknown
file):-1)
We did not tell $! to print; the error is produced on STDERR, even
though the `eval` should have trapped it.
Next, we eval both classes in the same program, but in separate eval
statements:
$ ./perl6 -e 'eval q[ class B0rk { say $.a; }; ]; eval q[ class
Chef { say $.b; }; ]; say Done;'
Done
src/call/pcc.c:609: failed assertion 'PObj_is_PMC_TEST(sig_pmc)'
Backtrace - Obtained 24 stack frames (max trace depth is 32).
0 libparrot.dylib 0x0052836d
Parrot_do_check_events + 173
1 libparrot.dylib 0x005284d7 Parrot_confess
+ 151
2 libparrot.dylib 0x0054171b
Parrot_init_arg_op + 315
3 libparrot.dylib 0x005447c2
parrot_pass_args + 978
4 libparrot.dylib 0x00544936
parrot_pass_args + 1350
5 libparrot.dylib 0x0054a74c
Parrot_runops_fromc_args + 220
6 libparrot.dylib 0x005924d5
Parrot_ComposeRole + 3461
7 libparrot.dylib 0x0059278a
Parrot_ComposeRole + 4154
8 libparrot.dylib 0x00592a96 do_sub_pragmas
+ 406
9 libparrot.dylib 0x0059a467
PackFile_fixup_subs + 119
10 libparrot.dylib 0x00758d25 do_yylex_init
+ 1317
11 libparrot.dylib 0x00759165 do_yylex_init
+ 2405
12 libparrot.dylib 0x005595c0
Parrot_mmd_cache_destroy + 2096
13 libparrot.dylib 0x00678601
Parrot_Eval_get_isa + 2097
14 libparrot.dylib 0x004a8fa2
Parrot_str_from_int + 3650
15 libparrot.dylib 0x005a3977
enable_event_checking + 2679
16 libparrot.dylib 0x005a256a
Parrot_runcore_switch + 4058
17 libparrot.dylib 0x00549705
new_runloop_jump_point + 389
18 libparrot.dylib 0x00549a26
new_runloop_jump_point + 1190
19 libparrot.dylib 0x0054a72a
Parrot_runops_fromc_args + 186
20 libparrot.dylib 0x005251e1 Parrot_runcode
+ 337
21 perl6 0x1ba9 start + 505
22 perl6 0x19e6 start + 54
23 ??? 0x0003 0x0 + 3
Abort trap
Notice that in both of the last cases, Done *did* print, so neither
compilation nor execution were halted; the diagnostic output seems to
have been produced during program exit.
--
Hope this helps
Bruce Gray (Util on IRC)
[perl #68318] [BUG] use exceptions not handled correctly within try block
# New Ticket Created by Ben Petering
# Please include the string: [perl #68318]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=68318
# Normal exception in try {} is caught
BEGIN {
try {
widdle;
CATCH {
say caught: $!;
}
}
}
# But use is not.
BEGIN {
try {
use NonExistent; # dies, not caught.
CATCH {
say caught: $!;
}
}
}
Output (with Rakudo pulled 2009-08-08 06:40 UTC, how on earth do you
specify revisions with git?)
caught: Could not find non-existent sub widdle
Can't find ./NonExistent in @*INC
in Main (src\gen_setting.pm:445)
(I'm not sure if this is correct, but I'm struggling to imagine why
this would be useful behavior.)
Re: Exceptions question
On Wed, 25 Feb 2009, Larry Wall wrote: On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote: Does this mean that $! is a container of some sort? It's an object, which (in the abstract) can contain anything it jolly well pleases. The main question beyond that is how it responds if used like one of the standard containers. I don't see any great motivation for that offhand, but we'll have to examine the use cases as things progress. Hmm. S04 says: : That implicit topic is the current exception object, also known as C$! and also: : Because the contextual variable C$! contains all exceptions collected in : the current lexical scope... ...that implies to my mind that $! is an exception object, but that an exception object can contain more than one exception. Is that correct? But the spec also says: : Exceptions are not resumable in Perl 6unless the exception object does the : CResumable role. ...so Resumable is attached to a group of exceptions, not a single exception. Now I'm really confused :). My suggested solution would be to change $! to an exception container object. But then we have to use it in the implicit given in the CATCH block. If we used an any() Junction, would that do what we want? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Exceptions question
On Thu, 26 Feb 2009, Timothy S. Nelson wrote:
My suggested solution would be to change $! to an exception container
object. But then we have to use it in the implicit given in the CATCH block.
If we used an any() Junction, would that do what we want?
Ok, Moritz told me on IRC that this won't work. My next suggestion is
to have @! be an array that replaces $! completely (freeing it up for $!foo
things), and then have the CATCH block implicitly do:
given(any(@!)) {
...
}
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Exceptions question
Em Qui, 2009-02-26 às 22:26 +1100, Timothy S. Nelson escreveu:
given(any(@!)) {
}
using junctions on exception handling doesn't seem like a good idea to
me, because it is too much of a basic feature... but...
for @! {
}
might provide the needed semantics...
OTOH, I think it would be sane to have $! representing the last
exception, so you can still use
my $file = open 'file.txt' or die $!;
no matter how many unthrown exceptions you have in that block.
daniel
Re: Exceptions question
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every one of them? in sequence? autothreading? what happens if
one CATCH handles one of the exception but only an outer CATCH handles
the other?
I'm not sure there is a sane way of having several unthrown exceptions
at the same block, so I think the best thing we can do is to throw the
first unthrown exception if a second exception happens...
meaning... if $! is already set with an unhandled exception that
exception is thrown. If that happens to be a resumable exception, the
code can be resumed and the other exception will be stored in $! for a
later evaluation.
daniel
Re: Exceptions question
On Thu, 26 Feb 2009, Daniel Ruoso wrote:
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every one of them? in sequence? autothreading? what happens if
one CATCH handles one of the exception but only an outer CATCH handles
the other?
I'm not sure there is a sane way of having several unthrown exceptions
at the same block, so I think the best thing we can do is to throw the
first unthrown exception if a second exception happens...
meaning... if $! is already set with an unhandled exception that
exception is thrown. If that happens to be a resumable exception, the
code can be resumed and the other exception will be stored in $! for a
later evaluation.
Moritz suggested on IRC (in different words) that, as Match objects
can do the Associative role, that maybe Exception objects could do the
associative role as well. That would mean that we would retain $!, but would
still have the others there, just as $/ is the most recent Match, but can also
be a container of matches.
That doesn't answer your question about how to handle multiple
exceptions, though :).
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Exceptions question
S04 says: Because the contextual variable C$! contains all exceptions collected in the current lexical scope, saying Cdie $! will throw all exceptions, whether they were handled or not. A bare Cdie/Cfail takes C$! as the default argument. Does this mean that $! is a container of some sort? - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Exceptions question
On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote: Does this mean that $! is a container of some sort? It's an object, which (in the abstract) can contain anything it jolly well pleases. The main question beyond that is how it responds if used like one of the standard containers. I don't see any great motivation for that offhand, but we'll have to examine the use cases as things progress. Larry
[perl #57978] Implement last/redo/next/continue control exceptions
On Thu Oct 23 07:13:46 2008, pmichaud wrote: On Wed, Oct 22, 2008 at 08:27:10PM -0700, Tim Nelson via RT wrote: On Sat Aug 16 07:29:31 2008, je...@perl.org wrote: - Needs last/redo/next/continue exceptions in PCT (PCT) This is done in rakudo; does that mean that this ticket is done? Only 'next' is done in rakudo at the moment. Now all of 'last', 'next', and 'redo' are done, so closing ticket. Pm
[perl #57978] Implement last/redo/next/continue control exceptions
On Thu Oct 23 07:13:46 2008, pmichaud wrote: On Wed, Oct 22, 2008 at 08:27:10PM -0700, Tim Nelson via RT wrote: On Sat Aug 16 07:29:31 2008, je...@perl.org wrote: - Needs last/redo/next/continue exceptions in PCT (PCT) This is done in rakudo; does that mean that this ticket is done? Only 'next' is done in rakudo at the moment. Now all of 'last', 'next', and 'redo' are done, so closing ticket. Pm
[perl #60556] Exceptions from C-level MULTI functions break subs
# New Ticket Created by Christoph Otto # Please include the string: [perl #60556] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60556 If an exception handler catches an exception from a MULTI function implemented in C, passing that exception from the handler to a sub causes a segfault. Doing the same thing with a subclass of Integer with a PIR divide sub works as expected. The attached code demonstrates this. If p is an Integer, the parrot dies. If it's a MyInteger, it doesn't. #! parrot .sub main :main .local pmc p, q, int_class, myint_class int_class = get_class 'Integer' myint_class = subclass int_class, 'MyInteger' p = new 'Integer' set p, 0 push_eh handler #throw an exception from a C-level MULTI function q = p / p goto end pop_eh goto end handler: .local pmc exception .local string message .get_results (exception) message = exception['message'] cause_sf(message) end: .end .sub cause_sf .param string message say message end: .end .namespace ['MyInteger'] .sub divide :multi(MyInteger, MyInteger) .param pmc self .param pmc right .param pmc dest .local pmc ex ex = new 'Exception' ex['message'] = don't feel like dividing throw ex .end # Local Variables: # mode: pir # fill-column: 100 # End: # vim: expandtab shiftwidth=4 filetype=pir:
[perl #57978] Implement last/redo/next/continue control exceptions
On Sat Aug 16 07:29:31 2008, [EMAIL PROTECTED] wrote: - Needs last/redo/next/continue exceptions in PCT (PCT) This is done in rakudo; does that mean that this ticket is done?
Re: [perl #57978] Implement last/redo/next/continue control exceptions
On Wed, Oct 22, 2008 at 08:27:10PM -0700, Tim Nelson via RT wrote: On Sat Aug 16 07:29:31 2008, [EMAIL PROTECTED] wrote: - Needs last/redo/next/continue exceptions in PCT (PCT) This is done in rakudo; does that mean that this ticket is done? Only 'next' is done in rakudo at the moment. Pm
[perl #57610] [PATCH] Resumable exceptions
On Tue Aug 05 04:09:14 2008, tene wrote: pdd23: Exception handlers can resume execution immediately after the throw opcode by invoking the resume continuation which is stored in the exception object. That continuation must be invoked with no parameters; in other words, throw never returns a value. Exception.pmc has the following attributes: ATTR INTVALid; /* The task ID in the scheduler. */ ATTR FLOATVAL birthtime;/* The creation time stamp of the exception. */ ATTR STRING *message; /* The exception message. */ ATTR PMC *payload; /* The payload for the exception. */ ATTR INTVALseverity; /* The severity of the exception. */ ATTR INTVALtype; /* The type of the exception. */ ATTR INTVALexit_code;/* The exit code of the exception. */ ATTR PMC *stacktrace; /* The stacktrace of an exception. */ ATTR INTVALhandled; /* Whether the exception has been handled. */ ATTR PMC *handler_iter; /* An iterator of handlers (for rethrow). */ ATTR Parrot_Context *handler_ctx; /* A stored context for handler iterator. */ None of these is a continuation. The throw opcode passes the address of the next opcode to Parrot_ex_throw_from_op, but Petfo only uses it in: address= VTABLE_invoke(interp, handler, dest); and the ExceptionHandler PMC's invoke() does not use that parameter at all. This first draft of a patch adds an attribute to the exception pmc to hold a return continuation, creates a retcontinuation pmc in the throw opcode and assigns it to that attribute, and patches new_ret_continuation to initialize the new continuation's from_ctx attribute in the same way new_continuation does. This last item is there to fix a segfault. I don't understand parrot's continuations well enough yet to have any idea why they were different, so I just guessed. I don't know if it's wrong, but it doesn't seem to fail any extra tests. Added a simple test case. It looks like Allison applied your patch in r30123 but forgot to close this ticket. Now seems like a good time to resolve it. Thanks for the patch.
Re: [perl #58176] [PATCH] dotnet exceptions
On Wednesday 20 August 2008 12:48:27 Reini Urban wrote: make dotnet work with the new exceptions. I'm not sure how to return the jump_point correctly, but it looks fine. Thanks, applied as r30718. -- c
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Wed Aug 27 22:49:37 2008, cotto wrote: Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph Done.
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Thu Oct 25 00:49:38 2007, pcoch wrote: To be totally honest I wish I knew. I'm just going through converting the todo items in code into RT tickets and sometimes the todo comments aren't necessarily all that clear as to what needs to be done. I'm also (unfortunately) not familiar enough with pir to see in the code of the tests what needs fixing otherwise I might have been able to expand a little in the ticket. I'm really sorry I can't be of more help here! Paul Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph
Re: Resumable exceptions
Not long ago, Patrick R. Michaud proclaimed... Here's a simple test for resumable exceptions that I'm trying to get to work. I'm probably coding/understanding something wrong, so any suggestions or pointers would be greatly appreciated. .sub main :main push_eh catcher 'foo'() pop_eh say 'ok 4' .return () catcher: .get_results ($P0, $S0) $P1 = $P0['retcont'] $P1() .end .sub 'foo' say 'ok 1' $P0 = new 'Exception' throw $P0 say 'ok 2' $P0 = new 'Exception' throw $P0 say 'ok 3' .end What I'm trying to do is to test the ability to resume after exceptions thrown by Cfoo. The Cmain sub above sets up a handler to catch exceptions, then calls Cfoo. The handler simply resumes any exception that is caught. The Cfoo sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. Check RT #58170 for this. Let me know if you need more detail on what's happening.
Resumable exceptions
Here's a simple test for resumable exceptions that I'm trying to get to work. I'm probably coding/understanding something wrong, so any suggestions or pointers would be greatly appreciated. .sub main :main push_eh catcher 'foo'() pop_eh say 'ok 4' .return () catcher: .get_results ($P0, $S0) $P1 = $P0['retcont'] $P1() .end .sub 'foo' say 'ok 1' $P0 = new 'Exception' throw $P0 say 'ok 2' $P0 = new 'Exception' throw $P0 say 'ok 3' .end What I'm trying to do is to test the ability to resume after exceptions thrown by Cfoo. The Cmain sub above sets up a handler to catch exceptions, then calls Cfoo. The handler simply resumes any exception that is caught. The Cfoo sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. Pm
[perl #58176] [PATCH] dotnet exceptions
# New Ticket Created by Reini Urban
# Please include the string: [perl #58176]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58176
---
osname= cygwin
osvers= 1.5.25(0.15642)
arch= cygwin-thread-multi-64int
cc= gcc
---
Flags:
category=languages
severity=high
ack=no
---
make dotnet work with the new exceptions.
I'm not sure how to return the jump_point correctly, but it looks fine.
---
Summary of my parrot 0.7.0 (r0) configuration:
configdate='Wed Aug 20 18:34:46 2008 GMT'
Platform:
osname=cygwin, archname=cygwin-thread-multi-64int
jitcapable=1, jitarchname=i386-cygwin,
jitosname=CYGWIN, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl.exe
Compiler:
cc='gcc', ccflags='-U__STRICT_ANSI__ -pipe -I/usr/local/include
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC
-DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
-DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT
-falign-functions=16 -maccumulate-outgoing-args -W -Wall
-Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment
-Wdisabled-optimization -Wendif-labels -Wextra -Wformat
-Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k
-Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces
-Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare
-Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default
-Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings
-Wbad-function-cast -Wdeclaration-after-statement
-Wimplicit-function-declaration -Wimplicit-int -Wmain
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull
-DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT',
Linker and Libraries:
ld='gcc', ldflags=' -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base ',
cc_ldflags='',
libs='-L/usr/local/lib -lcrypt -lgmp -lreadline -lpcre -lglut32
-lglu32 -lopengl32 -lcrypto -lintl'
Dynamic Linking:
share_ext='.dll', ld_share_flags='-shared',
load_ext='.dll', ld_load_flags='-shared'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
Locally applied patches:
[perl #39742] [BUG] installed conflict
[perl #51944] [DOCS] Cygwin Readme
[perl #56544] [PATCH] install_files.pl
[perl #56998] [PATCH] rename cygwin dll to cygparrot$MAJ_$MIN_$P.dll
[perl #57006] [PATCH] add cygwin opengl config quirks
[perl #56554] [TODO] make install -C languages
[perl #58034] [TODO] config_args
[perl #56996] [TODO] FHS runtime paths
---
Environment:
CYGWIN =server
HOME =/home/rurban
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH
=~/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/usr/bin:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Programme/ATI
Technologies/ATI.ACE/Core-Static:/usr/local/bin:/usr/lib/gstreamer-0.8:/usr/lib/lapack
SHELL (unset)
Index: parrot-svn/languages/dotnet/ops/dotnet.ops
===
--- parrot-svn.orig/languages/dotnet/ops/dotnet.ops
+++ parrot-svn/languages/dotnet/ops/dotnet.ops
@@ -88,7 +88,10 @@ static opcode_t* dotnet_OverflowExceptio
PMC *ex_pmc = pmc_new(interp, enum_class_Exception);
VTABLE_set_string_native(interp, ex_pmc,
string_from_literal(interp, System.OverflowException));
-return (opcode_t *)throw_exception(interp, ex_pmc, ret);
+VTABLE_set_integer_keyed_str(interp, ex_pmc,
+severity, EXCEPT_error);
+Parrot_ex_throw_from_c(interp, ex_pmc);
+return ret;
}
Index: parrot-svn/languages/dotnet/pmc/dotnetassembly.pmc
===
--- parrot-svn.orig/languages/dotnet/pmc/dotnetassembly.pmc
+++ parrot-svn/languages/dotnet/pmc/dotnetassembly.pmc
@@ -1848,7 +1848,7 @@ pmclass DotNetAssembly dynpmc group dotn
free(filename);
if (!in)
-Parrot_ex_throw_from_c_args(INTERP, NULL, E_IOError,
+Parrot_ex_throw_from_c_args(INTERP, NULL, EXCEPTION_PIO_ERROR,
Unable to open file %s, filename);
/* Attempt to load the PE parts of the file; this locates the CLI
@@ -2184,12 +2184,9 @@ pmclass DotNetAssembly dynpmc group dotn
/* If we don't have an assembly or nothing is loaded, throw an
exception and leave. */
-if (ass == NULL || ass-loaded == 0)
-{
-EXCEPTION_INVALID_OPERATION(INTERP, NULL
Re: Resumable exceptions
Patrick R. Michaud wrote: What I'm trying to do is to test the ability to resume after exceptions thrown by Cfoo. The Cmain sub above sets up a handler to catch exceptions, then calls Cfoo. The handler simply resumes any exception that is caught. The Cfoo sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. The old exception system deleted a handler as soon as it was retrieved for an exception. For backward-compatibility, the new exception system replicates that mis-feature. The problem is, if you end up throwing an exception in the middle of handling another one, and didn't mark the handler somehow, you can easily get an infinite loop of thrown exceptions (when the handler gets some data it didn't expect from the second exception, and so throws another exception). In an ideal world: a) every exception handler would first check the type of the exception it was passed, and rethrow any exceptions it can't handle. b) exception handlers would only be deleted by 'pop_eh', and otherwise would simply pass out of scope after leaving the context where they were defined. Since (a) has to be in place before (b) can work, it was delayed. (And I just changed the name of the 'retcont' attribute to 'resume', to make it a little clearer.) Allison
[perl #57978] Implement last/redo/next/continue control exceptions
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #57978] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57978 - Needs last/redo/next/continue exceptions in PCT (PCT)
Re: Catching exceptions with the // operator
Thank you very much! my $bill = try ack() orelse try thpp() orelse do ppt(); This certainly does what I asked for, and it's short enough (even if we need to add a few brackets). Yes, the basic problem with the proposal is that it catches all exceptions willy nilly and uses them all for control flow whether that is appropriate or not. I have some sympathy with the proposal, however, because I'm currently using exceptions for just that purpose in the STD grammar. But it's suffering from the same difficulty, and I have to be careful to rethrow if the exception I trapped wasn't the one I expected. ... It might also be useful to have a try variant that only catches exceptions intended as benign failure to match. Or maybe try should have a way of indicating the severity of exception it wishes to trap by default. This could be a keyword variant, or an adverb, or a pragma. I'm thinking the pragma is most likely to distribute syntactic relief nicely over a lexical scope. In any case it would only set the default CATCH handler which could still be overridden in any particular try block. ... Larry I believe that ---from a usability point of view--- it's very important to: * classify exceptions by severity or other characteristics, * provide named adverbs/pragmas to modify default CATCH handlers, * make them configurable by outer scopes. Without such conventions (e.g. with just catching individually named exception classes), the programmer of a function often cannot reasonably know what exceptions he should catch and how he should handle them. There are two reasons for this and here are two examples. The first reason is: The programmer isn't supposed to know all exceptions that can be thrown by sub-routines. Otherwise, you can't add a new feature to a library function (and introduce a new exception with it) without breaking the error handling of all code that uses this library function. Also, some general functions (e.g. macro/template-expanders) can include an unspecified set of extension modules and hence can't know all the exceptions that will be needed for these extensions. This problem can be solved by grouping exceptions into meaningful groups and catching groups, not individual exceptions. For example, there are quite a lot of situations where a function cannot produce an expected result (e.g. read_file($non_existing_file)). Such exceptions just say that you can't rely on any results that depend on the output of this function. These exceptions should be catched by //. A different group of exceptions is where the user wants to terminate a computation (e.g. CTRL-C//HUP). The second problem goes into the opposite direction: Even if you have well-defined exception groups, you cannot always know how they should be handled. Take, for example, a macro processor (like LaTeX) used for typesetting a book and an exception that indicates that some required information (e.g. a reference) is not available. Should this exception be catched and a placeholder be included --- or should this exception be fatal for this job? The answer is: during proofreading, this should produce a warning and a readable result. In production scripts (process and print a few million books), this needs to be fatal. Of course, the programmer of the macro processor cannot decide whether the processor is used in proofreading or in production code. This decision must be made upstream, by callers of the processor. The same problem is: should attempts to access protected files be fatal security alerts or just missing values? This problem can be resolved by having configurable CATCH handlers that are defined by the callers of a function and only referred to by name. So, we may have three separate programmers that are responsible for separate decisions: The programmer of a low-level function or extension module throws exceptions and classifies them into meaningful severity groups. The programmer of the top-level function defines the severity of particular exception groups for this specific application by defining named CATCH handlers. The middle-ware programmer doesn't have the responsibilities of the low-level or top-level programmers, and can't make decisions for them. He just uses the appropriate named CATCH handler to do the right thing. And if we really go so far, we can have standard names for two CATCH handlers: CATCH:// and CATCH:orelse. The operators can catch the corresponding exceptions --- leaving the specification of which exceptions to handle to the programmer.
Re: Catching exceptions with the // operator
HaloO,
Yaakov Belch wrote:
I believe that ---from a usability point of view--- it's very important to:
* classify exceptions by severity or other characteristics,
* provide named adverbs/pragmas to modify default CATCH handlers,
* make them configurable by outer scopes.
[..]
The programmer of the top-level function defines the severity of
particular exception groups for this specific application by defining named
CATCH handlers.
I want to propose---possibly again ;)---to use the dispatch
semantics for this purpose. The idea is that CATCH blocks
can be made into multis first of all with the multi keyword
or with a proto which then makes inner CATCH blocks also multi
unless they are explicitly declared only.
Generally speaking I find multiple CATCH blocks with a signature
better than a big switch inside a single one. Such a CATCH without
signature would be good for low-level handling, though. It has
implicit signature :(Any) and is easily overridden from outer
scopes.
The grouping comes naturally since packages are recognized as
type names. So we can have
proto CATCH {...} # force multi
{
multi CATCH (Math::DivZero) {...}
{
multi CATCH (Math) {...}
multi CATCH (Math::Overflow) {...} # more specific
# outer catch seen here as well
{
CATCH
{
when Math {...} # never called
}
}
}
}
And if we really go so far, we can have standard names for two
CATCH handlers: CATCH:// and CATCH:orelse.
So with CATCH a magic namespace these would be CATCH::// and
CATCH::orelse respectively. Using the namespace is another
approach. But to me it doesn't feel as natural as the exception
type approach.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Catching exceptions with the // operator
In a little language that I wrote some time ago, I found it very useful to let the // operator catch exceptions: f(x) // g(y) does: * If f(x) returns a defined value, use this value. * If f(x) returns an undefined value, use the value of g(x) instead. * If f(x) throws an exception, catch and keep it in $!, use the value of g(x) * But don't catch exceptions of g(x). Similarly, f(x) // g(y) // h(z) catches exceptions of f(x) and of g(y) but not of h(z). I would like to suggest the same semantics for perl6. Let me explain why this is useful and why I think this is the right thing: First of all, it provides a very light-weight exception handling using well-known ideoms like: $file_content=read_file($filename) // $default_value; compute_statistics($data) // write_log_message(stats failed: $!); With the proposed change, these ideoms work whether the functions throw exceptions or not. But why should this be the right thing? Obviously, // is the fallback or redundancy operator: Don't despair if the first computation doesn't produce a usable result --- we have another way of getting the job done. In this context, and exception conveys the same message as an undefined value: The first step failed. You need to fall back to some other alternative or give up! As the second expression provides exactly this other alternative, there is no need to jump out of the normal processing order anymore. Best regards --- and many thanks for the continued effort on perl6! Yaakov Belch
Re: Catching exceptions with the // operator
On Wed, Aug 6, 2008 at 8:58 AM, Yaakov Belch [EMAIL PROTECTED] wrote:
In a little language that I wrote some time ago, I found it very useful to
let the // operator catch exceptions:
f(x) // g(y) does:
* If f(x) returns a defined value, use this value.
* If f(x) returns an undefined value, use the value of g(x) instead.
* If f(x) throws an exception, catch and keep it in $!, use the value of g(x)
* But don't catch exceptions of g(x).
Similarly, f(x) // g(y) // h(z) catches exceptions of f(x) and of g(y)
but not of h(z).
I would like to suggest the same semantics for perl6.
Let me explain why this is useful and why I think this is the right thing:
First of all, it provides a very light-weight exception handling using
well-known ideoms like:
$file_content=read_file($filename) // $default_value;
compute_statistics($data) // write_log_message(stats failed: $!);
With the proposed change, these ideoms work whether the functions throw
exceptions or not.
But why should this be the right thing? Obviously, // is the fallback
or redundancy operator: Don't despair if the first computation doesn't
produce a usable result --- we have another way of getting the job done.
In this context, and exception conveys the same message as an undefined
value: The first step failed. You need to fall back to some other
alternative or give up! As the second expression provides exactly this
other alternative, there is no need to jump out of the normal processing
order anymore.
i don't think this will work for perl 6. since perl 6 has resumeable
exceptions (like Cwarn), the meaning of the C// operator could be
ambiguous. given the following statement,
my $bill = ack() // thpp() // ppt();
with perl 6's current semantics, if Cack(), throws a resumable
exception that is handled in the current scope or an outer scope,
execution will resume before C// and the definedness of the result
from Cack() will be tested in order to determine whether or not to
call Cthpp().
using your semantics, if a resumable exception is thrown in Cack(),
C// will cause Cthpp() to be invoked immediately, discarding any
possible defined result from Cack(). also, the question arises that
if Cthpp() doesn't handle the type of exception thrown, should
Cppt() be called immediately, or only if Cthpp() returns an
undefined result? seems to me it would try to handle the exception
thrown by Cack(). so how do i signify that my exception has been
handled, and that i can now assign a default value to C$bill?
in my mind, this strays too far from the meaning of C// and adds
ambiguity that makes the operator unusable. perhaps there's room for
an operator that gives some sugar for
my $bill = try { ack() CATCH { thpp() } };
but to me that code is concise enough that it doesn't warrant syntactic relief.
~jerry
Re: Catching exceptions with the // operator
in my mind, this strays too far from the meaning of C// and adds
ambiguity that makes the operator unusable. perhaps there's room for
an operator that gives some sugar for
my $bill = try { ack() CATCH { thpp() } };
but to me that code is concise enough that it doesn't warrant syntactic
It seems that the following should address the issue while providing enough
indication about what is occurring:
my $bill = try { ack() } // thpp();
That seems to be closer to what the original post was desiring.
Paul
Re: Catching exceptions with the // operator
On Wed, Aug 06, 2008 at 09:36:16AM -0700, jerry gay wrote:
: i don't think this will work for perl 6. since perl 6 has resumeable
: exceptions (like Cwarn), the meaning of the C// operator could be
: ambiguous. given the following statement,
:
: my $bill = ack() // thpp() // ppt();
:
: with perl 6's current semantics, if Cack(), throws a resumable
: exception that is handled in the current scope or an outer scope,
: execution will resume before C// and the definedness of the result
: from Cack() will be tested in order to determine whether or not to
: call Cthpp().
Yes, the basic problem with the proposal is that it catches all
exceptions willy nilly and uses them all for control flow whether
that is appropriate or not. I have some sympathy with the proposal,
however, because I'm currently using exceptions for just that
purpose in the STD grammar. But it's suffering from the same
difficulty, and I have to be careful to rethrow if the exception
I trapped wasn't the one I expected.
: using your semantics, if a resumable exception is thrown in Cack(),
: C// will cause Cthpp() to be invoked immediately, discarding any
: possible defined result from Cack(). also, the question arises that
: if Cthpp() doesn't handle the type of exception thrown, should
: Cppt() be called immediately, or only if Cthpp() returns an
: undefined result? seems to me it would try to handle the exception
: thrown by Cack(). so how do i signify that my exception has been
: handled, and that i can now assign a default value to C$bill?
:
: in my mind, this strays too far from the meaning of C// and adds
: ambiguity that makes the operator unusable. perhaps there's room for
: an operator that gives some sugar for
:
: my $bill = try { ack() CATCH { thpp() } };
:
: but to me that code is concise enough that it doesn't warrant syntactic
relief.
Well, right now you can write either of:
my $bill = try { ack() } // thpp();
my $bill = try { ack() } orelse thpp();
where the latter has the advantage of setting $! on the right to the
return value of the try. We *could* go as far as making orelse
carry try semantics, but I think a more appropriate solution might be
to reduce the precedence of blockless try/do/gather etc. to below
orelse. And then you could say
my $bill =
try ack() orelse
try thpp() orelse
do ppt();
But I need to think through the ramifications of such a precedence
change. It would make blockless do rather pointless, for instance,
but maybe that's a worthwhile tradeoff. And I'm using it above
as a no-op to indicate a non-try.
It might also be useful to have a try variant that only catches
exceptions intended as benign failure to match. Or maybe try should
have a way of indicating the severity of exception it wishes to
trap by default. This could be a keyword variant, or an adverb,
or a pragma. I'm thinking the pragma is most likely to distribute
syntactic relief nicely over a lexical scope. In any case it would
only set the default CATCH handler which could still be overridden in
any particular try block.
So, basically, we could just turn blockless try/gather/do into listops
from a precedence point of view, though they'd still essentially be macros.
This seems like a good thing. At worst it means you need to use parens:
try($x if $y);
if you need a statement as an argument, where currently you could write
try $x if $y;
But staring at those two, I'd say the parens are almost a feature from
the least surprise viewpoint.
Larry
Re: Catching exceptions with the // operator
Yaakov Belch perl6-at-yaakovnet.net |Perl 6| wrote:
Let me explain why this is useful and why I think this is the right thing:
First of all, it provides a very light-weight exception handling using
well-known ideoms like:
$file_content=read_file($filename) // $default_value;
compute_statistics($data) // write_log_message(stats failed: $!);
With the proposed change, these ideoms work whether the functions throw
exceptions or not.
You can change the meaning of fail to throw exceptions or to return
the unthrown object which is an interesting value of undef. So under
use fail 'return';
your line works as intended. This is what you should do if you are
expecting failure in this case.
A macro can give you some syntactic sugar for that:
macro ttt ($x) is parsedexpression
{
return { use fail 'return'; $x; };
}
[perl #57610] [PATCH] Resumable exceptions
, CONST_STRING(INTERP, retcont))
== 0) {
+GET_ATTR_retcont(interp, SELF, value);
+}
else if (string_equal(INTERP, name, CONST_STRING(INTERP,
stacktrace)) == 0) {
GET_ATTR_stacktrace(interp, SELF, value);
}
@@ -579,6 +586,9 @@ Set an attribute value for the exception object.
else if (string_equal(INTERP, name, CONST_STRING(INTERP, payload))
== 0) {
SET_ATTR_payload(interp, SELF, value);
}
+else if (string_equal(INTERP, name, CONST_STRING(INTERP, retcont))
== 0) {
+SET_ATTR_retcont(interp, SELF, value);
+}
else if (string_equal(INTERP, name, CONST_STRING(INTERP,
stacktrace)) == 0) {
SET_ATTR_stacktrace(interp, SELF, value);
}
diff --git a/src/sub.c b/src/sub.c
index bcc7bdb..529ddc0 100644
--- a/src/sub.c
+++ b/src/sub.c
@@ -191,7 +191,7 @@ new_ret_continuation(PARROT_INTERP)
Parrot_cont * const cc = mem_allocate_typed(Parrot_cont);
cc-to_ctx = CONTEXT(interp);
-cc-from_ctx= NULL;/* filled in during a call */
+cc-from_ctx= CONTEXT(interp);/* filled in during a call */
cc-dynamic_state = NULL;
cc-runloop_id = 0;
cc-seg = interp-code;
diff --git a/t/op/exceptions.t b/t/op/exceptions.t
index e49f647..1c4aa1f 100644
--- a/t/op/exceptions.t
+++ b/t/op/exceptions.t
@@ -6,7 +6,7 @@ use strict;
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests = 29;
+use Parrot::Test tests = 30;
=head1 NAME
@@ -608,6 +608,29 @@ Exception message: Class Foo already registered!
after compile
OUTPUT
+pir_output_is( 'CODE', 'OUTPUT', Resumable exceptions );
+.sub main :main
+push_eh _handler
+new $P1, 'Exception'
+say 'Before throwing'
+throw $P1
+say 'After throwing'
+end
+_handler:
+.local pmc e
+.local string s
+.local pmc c
+.get_results (e, s)
+say 'In the exception handler'
+c = e['retcont']
+c()
+.end
+CODE
+Before throwing
+In the exception handler
+After throwing
+OUTPUT
+
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
--
1.5.5.1
[perl #56216] [PATCH] Handles parrot's exceptions in Str.substr.
# New Ticket Created by Vasily Chekalkin # Please include the string: [perl #56216] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56216 Hello. Attached patch handles parrot's exception on substr invocations and returns Failure instead. -- Bacek diff --git a/languages/perl6/src/classes/Str.pir b/languages/perl6/src/classes/Str.pir index 6195989..eb454cb 100644 --- a/languages/perl6/src/classes/Str.pir +++ b/languages/perl6/src/classes/Str.pir @@ -258,10 +284,17 @@ Returns a Perl representation of the Str. len = len - start end: +push_eh cant_substr $S0 = substr self, start, len +pop_eh s = new 'Str' s = $S0 .return (s) + cant_substr: +.get_results ($P0, $S0) +s = new 'Failure' +.return (s) + .end =back
Re: Exceptions and Concurrency Questions
Allison Randal wrote: Presumably the handled opcode will remove the exception Task from the scheduler and resume execution at the appropriate point. Presumably also the declining to handle an exception (the replacement for rethrow) will cause the scheduler to move to the next exception handler in its list? If so, how do we model this control flow? More on control flow tomorrow. I started to write this out, and then realized I already did in the Exceptions PDD. Allison
Re: Exceptions and Concurrency Questions
chromatic wrote: From the wiki at http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks : * Deprecate rethrow. The replacement seems to be that an exception handler declines to handle an exception. This is the default behavior; an exception handler explicitly notifies the scheduler that it has handled (or will handle) the exception by using the handled opcode. PDD 25 suggests that there are Task PMCs which represent or encapsulate these exceptions. Presumably the handled opcode will remove the exception Task from the scheduler and resume execution at the appropriate point. Presumably also the declining to handle an exception (the replacement for rethrow) will cause the scheduler to move to the next exception handler in its list? If so, how do we model this control flow? I planned to handle these parts of the code myself, so I only noted enough to use as a checklist when I'd finished the task. Essentially, we're ripping out the entire underpinning of the old exception system, and replacing it with the concurrency scheduler, while still preserving the same interface. The deprecation of rethrow will have to come towards the end of the transition, after exceptions are moved over to the concurrency scheduler (it can be deleted when it no longer does anything). More on control flow tomorrow. * Change 'real_exception' to use concurrency scheduler. Does this mean to change the opcode and its backing functions to create a Task PMC, an Exception PMC, or both? If so, where does control flow go with the scheduler works asynchronously? Or does the scheduler handle exceptions as they occur in real-time? A later task: Exception PMCs are polymorphically substitutable for Tasks. (Event PMCs are also.) Ultimately Exception may inherit from Task, but for now it's not necessary. * 'throw_exception' and 'rethrow_exception' change to something more like 'Parrot_cx_handle_tasks'. ... suggests that these functions may schedule the exception (if necessary) and then immediately run the scheduler in the current interpreter. Yes. * 'push_exception' changes to 'Parrot_cx_add_handler'. The latter function already exists. Merge or rename? Note that exception handling has to stop looking in interp-dynamic_env for this to work. 'push_exception' is what registers the exception handler for later lookup (terrible name for it). With the new implementation, 'Parrot_cx_add_handler' will register the exception handler (with the concurrency scheduler). IIRC, all it needs is to change the check for a valid handler type to also allow exception handlers (don't have time to verify at the moment). * 'count_exception_handlers' changes to access the concurrency scheduler (a simple method call or keyed access). There's currently no way of filtering handlers in the scheduler by parentmost type; should there be one? Yes. Allison
Exceptions and Concurrency Questions
From the wiki at http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks : * Deprecate rethrow. The replacement seems to be that an exception handler declines to handle an exception. This is the default behavior; an exception handler explicitly notifies the scheduler that it has handled (or will handle) the exception by using the handled opcode. PDD 25 suggests that there are Task PMCs which represent or encapsulate these exceptions. Presumably the handled opcode will remove the exception Task from the scheduler and resume execution at the appropriate point. Presumably also the declining to handle an exception (the replacement for rethrow) will cause the scheduler to move to the next exception handler in its list? If so, how do we model this control flow? * Change 'real_exception' to use concurrency scheduler. Does this mean to change the opcode and its backing functions to create a Task PMC, an Exception PMC, or both? If so, where does control flow go with the scheduler works asynchronously? Or does the scheduler handle exceptions as they occur in real-time? A later task: * 'throw_exception' and 'rethrow_exception' change to something more like 'Parrot_cx_handle_tasks'. ... suggests that these functions may schedule the exception (if necessary) and then immediately run the scheduler in the current interpreter. * 'push_exception' changes to 'Parrot_cx_add_handler'. The latter function already exists. Merge or rename? Note that exception handling has to stop looking in interp-dynamic_env for this to work. * 'count_exception_handlers' changes to access the concurrency scheduler (a simple method call or keyed access). There's currently no way of filtering handlers in the scheduler by parentmost type; should there be one? More later, -- c
[perl #37287] [TODO] pdb - don't die on exceptions
On Sun Mar 16 10:17:09 2008, [EMAIL PROTECTED] wrote: Friends, Doing cage cleaning today, I noticed that there has been no activity in this thread since last August. Are the issues that were under discussion still live? Should we still be considering the various patches? The issue is still valid, but my patch from last year does not help much to solve it. You can reproduce the bug with the test.pir I attached last August, and by running the following commands: $ make pdb $ ./pdb test.pir (pdb) r The issue is that pdb does not catch an exception. Instead, the exception crashes pdb. Fixing pdb to catch exceptions cleanly would make pdb significantly more useful as a debugger, I think. Mark
[perl #37287] [TODO] pdb - don't die on exceptions
Friends, Doing cage cleaning today, I noticed that there has been no activity in this thread since last August. Are the issues that were under discussion still live? Should we still be considering the various patches? Update sought. Thank you very much. kid51
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
On 25/10/2007, Allison Randal [EMAIL PROTECTED] wrote: Paul Cochrane wrote: I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented. Could you explain more fully what the problem is? Since we're currently implementing the exceptions PDD, it would be helpful to know any edge cases that need to be fixed. To be totally honest I wish I knew. I'm just going through converting the todo items in code into RT tickets and sometimes the todo comments aren't necessarily all that clear as to what needs to be done. I'm also (unfortunately) not familiar enough with pir to see in the code of the tests what needs fixing otherwise I might have been able to expand a little in the ticket. I'm really sorry I can't be of more help here! Paul
Re: [PATCH] Exceptions
Kevin Tew wrote: exceptions_ops.diff adds some simple ops needed for PDD compliance. exceptions.diff attempts to change all instances of clear_eh to pop_eh. Looks good. The exception handler stack introspection interface you added to the PDD is solid. The stack will be replaced by the concurrency scheduler in a few months, but we can preserve this same introspection interface. Let's go with 'eh_count' rather than 'eh_stack_depth', since it won't be a stack. Go ahead and apply. Thanks! Allison
Re: [PATCH] Exceptions
On 10/24/07, Allison Randal [EMAIL PROTECTED] wrote: Kevin Tew wrote: exceptions_ops.diff adds some simple ops needed for PDD compliance. exceptions.diff attempts to change all instances of clear_eh to pop_eh. Looks good. The exception handler stack introspection interface you added to the PDD is solid. The stack will be replaced by the concurrency scheduler in a few months, but we can preserve this same introspection interface. Let's go with 'eh_count' rather than 'eh_stack_depth', since it won't be a stack. Go ahead and apply. there are a few typos and pod nits that can be easily fixed before or after this is applied. i'd prefer 'count_eh', to match every other exception handler related op that has an '_eh' suffix. seems silly to have just one with a 'eh_' prefix. also, i'd suggest 'get_all_eh' rather than 'get_ehs', both to make it more visually distinct from 'get_eh' and also to make it match the '_eh' suffix of the other ops. ~jerry
Re: [PATCH] Exceptions
jerry gay wrote: i'd prefer 'count_eh', to match every other exception handler related op that has an '_eh' suffix. seems silly to have just one with a 'eh_' prefix. 'count_eh' isn't distinctive enough. Another possibility is not to provide an opcode for the number of exception handlers, since it's a relatively uncommon operation, and leave that as an 'inspect' option on the concurrency scheduler. Probably the most common use of 'eh_count' would be to find the number of elements in the array of exception handlers returned by 'get_all_eh' before performing some operation on it, in which case calling the elements vtable function on the array is good enough. also, i'd suggest 'get_all_eh' rather than 'get_ehs', both to make it more visually distinct from 'get_eh' and also to make it match the '_eh' suffix of the other ops. +1 Allison
[perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46823] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46823 In t/pmc/resizeablepmcarray.t there is the todo item: # TODO: Rewrite these properly when we have exceptions Which is to say that the tests of various error conditions and their output needs to be tested more thoroughly when exceptions are implemented.
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
On 24/10/2007, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #46823] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46823 In t/pmc/resizeablepmcarray.t there is the todo item: # TODO: Rewrite these properly when we have exceptions Which is to say that the tests of various error conditions and their output needs to be tested more thoroughly when exceptions are implemented. I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented.
Re: [perl #46823] [TODO] [Pir] Rewrite ResizeablePMCArray tests properly when exceptions are implemented
Paul Cochrane wrote: I updated the subject of this ticket to substitute PMC with * as this issue occurs more often than I first guessed (the problems one has when going through code serially...). This issue is actually more general and *any* ResizeablesomethingArray needs the exceptions-related tests updated when we have exceptions implemented. Could you explain more fully what the problem is? Since we're currently implementing the exceptions PDD, it would be helpful to know any edge cases that need to be fixed. Allison
[perl #46191] [TODO] Process exceptions properly in init_context()
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46191] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46191 In src/gc/register.c:init_context() there is the todo item: ctx-ref_count = 0; /* TODO 1 - Exceptions !!! */ I think this means to handle exceptions wrt reference counts correctly, but I'm really not sure.
Re: [perl #37287] [TODO] pdb - don't die on exceptions
This patch makes parrot stop execution of the vm when running as a debugger. This makes the pdb stop executing and shows the exception message instead of silently exiting. Hi, pancake! I have tried to update your patch to svn r20469, see attached patch. Unfortunately, it doesn't work any longer. I wrote a simple test file (see attached test.pir) that just generates an exception. Then I tried to run it under parrot, and it generated an exception, as expected. [EMAIL PROTECTED] ~/parrot $ ./parrot test.pir Null PMC access in get_string() current instr.: 'main' pc 0 (test.pir:3) Problem is, when I then ran it under pdb, it died pretty horribly. [EMAIL PROTECTED] ~/parrot $ ./pdb test.pir Parrot Debugger 0.4.x Please note: the debugger is currently under reconstruction (pdb) r Restarting Hijacked exception: Null PMC access in get_string() Restarting *** glibc detected *** ./pdb: free(): invalid pointer: 0xb6f191b8 *** === Backtrace: = /lib/libc.so.6[0xb6e4efaf] /lib/libc.so.6(__libc_free+0x89)[0xb6e4fce9] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(mem_sys_free+0x23)[0xb7c3b9b3] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(PDB_free_file+0x98)[0xb7c2eb38] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(PDB_disassemble+0x62)[0xb7c2e712] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_debug+0x65)[0xb7c31c85] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops_slow_core+0x60)[0xb7c76130] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops_int+0x190)[0xb7c46b80] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops+0xfd)[0xb7c474cd] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14[0xb7c476e6] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_runops_fromc_args+0x36)[0xb7c477f6] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_runcode+0x22f)[0xb7c31c0f] ./pdb(main+0x2d2)[0x8048f22] /lib/libc.so.6(__libc_start_main+0xe2)[0xb6dfe9d2] ./pdb[0x8048bb1] === Memory map: 08048000-0804a000 r-xp fe:03 636705 /home/paranoid/parrot/pdb 0804a000-0804b000 rw-p 1000 fe:03 636705 /home/paranoid/parrot/pdb 0804b000-0841 rw-p 0804b000 00:00 0 [heap] b5b0-b5b21000 rw-p b5b0 00:00 0 b5b21000-b5c0 ---p b5b21000 00:00 0 b5cca000-b5d0c000 rw-p b5cca000 00:00 0 b5d0c000-b5d0d000 ---p b5d0c000 00:00 0 b5d0d000-b650d000 rw-p b5d0d000 00:00 0 b650d000-b650e000 ---p b650d000 00:00 0 b650e000-b6d1 rw-p b650e000 00:00 0 b6d1-b6d18000 r-xp fe:00 292092 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 b6d18000-b6d19000 rw-p 7000 fe:00 292092 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 b6d19000-b6ddf000 r-xp fe:00 292103 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 b6ddf000-b6de4000 rw-p 000c6000 fe:00 292103 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 b6de4000-b6de9000 rw-p b6de4000 00:00 0 b6de9000-b6f16000 r-xp 03:01 40041 /lib/libc-2.6.so b6f16000-b6f17000 r--p 0012d000 03:01 40041 /lib/libc-2.6.so b6f17000-b6f19000 rw-p 0012e000 03:01 40041 /lib/libc-2.6.so b6f19000-b6f1c000 rw-p b6f19000 00:00 0 b6f1c000-b6f57000 r-xp 03:01 6397 /lib/libncurses.so.5.6 b6f57000-b6f6 rw-p 0003a000 03:01 6397 /lib/libncurses.so.5.6 b6f6-b6f8c000 r-xp 03:01 20277 /lib/libreadline.so.5.2 b6f8c000-b6f9 rw-p 0002b000 03:01 20277 /lib/libreadline.so.5.2 b6f9-b6f92000 rw-p b6f9 00:00 0 b6f92000-b6fc3000 r-xp fe:00 7746 /usr/lib/libgmp.so.3.4.1 b6fc3000-b6fc4000 rw-p 00031000 fe:00 7746 /usr/lib/libgmp.so.3.4.1 b6fc4000-b6fcb000 r-xp 03:01 35535 /lib/librt-2.6.so b6fcb000-b6fcd000 rw-p 6000 03:01 35535 /lib/librt-2.6.so b6fcd000-b6fcf000 r-xp 03:01 40037 /lib/libutil-2.6.so b6fcf000-b6fd1000 rw-p 1000 03:01 40037 /lib/libutil-2.6.so b6fd1000-b6fd6000 r-xp 03:01 40035 /lib/libcrypt-2.6.so b6fd6000-b6fd8000 rw-p 4000 03:01 40035 /lib/libcrypt-2.6.so b6fd8000-b6fff000 rw-p b6fd8000 00:00 0 b6fff000-b7001000 r-xp 03:01 40028 /lib/libdl-2.6.so b7001000-b7003000 rw-p 1000 03:01 40028 /lib/libdl-2.6.so b7003000-b7016000 r-xp 03:01 6394 /lib/libnsl-2.6.so b7016000-b7018000 rw-p 00012000 03:01 6394 /lib/libnsl-2.6.so b7018000-b701b000 rw-p b7018000 00:00 0 b701b000-b79ca000 r--p fe:00 384232 /usr/lib/libicudata.so.36.0 b79ca000-b79cb000 rw-p 009ae000 fe:00 384232 /usr/lib/libicudata.so.36.0 b79cb000-b7adc000 r-xp fe:00 403052 /usr/lib/libicuuc.so.36.0 b7adc000-b7ae3000 rw-p 00111000 fe:00 403052 /usr/lib/libicuuc.so.36.0 b7ae3000-b7ae5000 rw-p b7ae3000 00:00 0 b7ae5000-b7b08000 r-xp 03:01 40040 /lib/liAborted [EMAIL PROTECTED] ~/parrot $ It's a useful patch, and I think it *almost* works. Maybe pdb itself is broken. Also note I've created a test program[1] for pdb, at
[perl #44139] opcodes, warnings, and exceptions
# New Ticket Created by Jerry Gay # Please include the string: [perl #44139] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44139 the api for opcodes needs review, especially with regard to the response to exceptional behavior. for example, the documentation for Blength in src/ops/string.ops reads: =item Blength(out INT, in STR) Set result $1 to the length (in characters) of string $2. If $2 is NULL or zero length, zero is returned. however, if a null string is passed in to length, the user should get some notification of an exceptional condition. *at least* a warning, and possibly a fatal exception. ~jerry
resumable exceptions and LEAVE/KEEP/UNDO blocks
What happens if a resumable exception is propagated through a block with a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point. It strikes me that what we want it to do is not execute them when the exception is propagated, because we don't know whether it's going to be resumed or not. If the exception is resumed by its handler, then that's fine, as we can call the blocks at the usual time (when the blocks they are attached to exit). If the exception is caught and handled and not resumed, that would leave us with having to find all the LEAVE c. blocks and call them in the right order when the exception handler exits. In either case, it looks like you have a problem. LEAVE c. blocks will often be used for things like database transactions, where we want to ensure that some lock obtained on entering the block is released promptly regardless of how the control flow jumps about. In such a context, throwing a resumable exception that skips the LEAVE block, farts about doing some potentially long computation in a higher-up scope, and only calls the LEAVE block to release the lock at some later date, seems to be far from the best choice. Sure, we can warn programmers to make their resumable-exception handlers short, or to only throw non-resumable exceptions from blocks that are likely to be called in such circumstances. I suppose that would be an acceptable resolution, but it has an aura of non--re-entrant signal handlers about it, so it seems like the sort of thing I would like to avoid if anyone is clever enough to think of something else to do. BTW, if one is handling a resumable exception, how does one resume it? I couldn't find anything explaining how. Having a .resume method (or some cutesier name) on the Resumable role would seem to make sense. -- Customer Waiter, waiter! There's a fly in my soup! Waiter That's not a bug, it's a feature. http://surreal.istic.org/ The Answer of the Oracle Is Always Death. signature.asc Description: Digital signature
Re: resumable exceptions and LEAVE/KEEP/UNDO blocks
On Mon, Mar 05, 2007 at 01:06:46PM +, Daniel Hulme wrote: : What happens if a resumable exception is propagated through a block with : a LEAVE, KEEP, or UNDO block? S04 seems to be a bit vague on this point. : It strikes me that what we want it to do is not execute them when the : exception is propagated, because we don't know whether it's going to be : resumed or not. If the exception is resumed by its handler, then that's : fine, as we can call the blocks at the usual time (when the blocks they : are attached to exit). If the exception is caught and handled and not : resumed, that would leave us with having to find all the LEAVE c. : blocks and call them in the right order when the exception handler : exits. : : In either case, it looks like you have a problem. LEAVE c. blocks will : often be used for things like database transactions, where we want to : ensure that some lock obtained on entering the block is released : promptly regardless of how the control flow jumps about. In such a : context, throwing a resumable exception that skips the LEAVE block, : farts about doing some potentially long computation in a higher-up : scope, and only calls the LEAVE block to release the lock at some later : date, seems to be far from the best choice. Sure, we can warn : programmers to make their resumable-exception handlers short, or to only : throw non-resumable exceptions from blocks that are likely to be called : in such circumstances. I suppose that would be an acceptable resolution, : but it has an aura of non--re-entrant signal handlers about it, so it : seems like the sort of thing I would like to avoid if anyone is clever : enough to think of something else to do. I don't see a problem here. I think you maybe missed the bit that says: A CCATCH block sees the lexical scope in which it was defined, but its caller is the dynamic location that threw the exception. That is, the stack is not unwound until some exception handler chooses to unwind it by handling the exception in question. Exiting blocks are not run until the decision is made to unwind the stack, which is *after* the exception handlers are run. So all the exception trampoline has to do to resume is just return; the resume continuation doesn't really have to be a real continuation in this case. : BTW, if one is handling a resumable exception, how does one resume it? I : couldn't find anything explaining how. Having a .resume method (or some : cutesier name) on the Resumable role would seem to make sense. To resume a resumable exception the correct thing to do is very likely nothing. The outermost warning handler is what generally resumes otherwise uncaught resumables. If you catch a warning, it defaults to resuming when handled unless you rethrow it as fatal. Larry
Re: resumable exceptions and LEAVE/KEEP/UNDO blocks
On Mon, Mar 05, 2007 at 09:01:13AM -0800, Larry Wall wrote: I don't see a problem here. I think you maybe missed the bit that says: A CCATCH block sees the lexical scope in which it was defined, but its caller is the dynamic location that threw the exception. That is, the stack is not unwound until some exception handler chooses to unwind it by handling the exception in question. Yes, I did. I was grepping specifically for the bit on resumable exceptions and the quoted bit is 80 lines up so I missed it completely. Thanks for pointing me at it. [...] To resume a resumable exception the correct thing to do is very likely nothing. The outermost warning handler is what generally resumes otherwise uncaught resumables. If you catch a warning, it defaults to resuming when handled unless you rethrow it as fatal. OK, that makes sense. The reason that came up was because on Friday I had a good idea for a language feature that would have made a task I had been doing that day much easier. When I checked the spec, though, I found out it was already in. This is happening increasingly often, which should be reassuring to all concerned. -- Listen to your users, but ignore what they say. - Nathaniel Borenstein http://surreal.istic.org/ Calm down, it's only ones and zeroes. signature.asc Description: Digital signature
[perl #40824] loadlib opcode causes problems with exceptions
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40824] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40824 If a loadlib fails, it doesn't throw a catchable exception. The t/ library/pg.t test was changed because it was failing on platforms where pg wasn't available. In particular, this assertion was getting tripped on: src/inter_call.c:122: failed assertion `PObj_is_PMC_TEST(sig_pmc) sig_pmc-vtable-base_type == enum_class_FixedIntegerArray' Abort trap The fix was this patch: === t/library/pg.t == --- t/library/pg.t (revision 23578) +++ t/library/pg.t (local) @@ -32,6 +32,10 @@ test = new 'Test::Builder' test.'plan'(N_TESTS) push_eh no_pg + + # TODO: fix when exception handling works again +loadlib $P0, 'libpq' +unless $P0 goto no_pg load_bytecode 'postgres.pir' clear_eh test.'ok'(1, 'load_bytecode') -- Matt Diephouse
[perl #40824] loadlib opcode causes problems with exceptions
From: Matt Diephouse (via RT) [EMAIL PROTECTED] Date: Sat, 11 Nov 2006 16:46:20 -0800 If a loadlib fails, it doesn't throw a catchable exception. The t/ library/pg.t test was changed because it was failing on platforms where pg wasn't available. In particular, this assertion was getting tripped on: src/inter_call.c:122: failed assertion `PObj_is_PMC_TEST(sig_pmc) sig_pmc-vtable-base_type == enum_class_FixedIntegerArray' Abort trap I don't think it's loadlib itself; I believe the library :init code is trying to throw an error. If that is the case, then it's a continuation barrier problem. Before the error, do you see this oops message? [EMAIL PROTECTED] ./parrot t/library/pg.t 1..43 [oops; continuation 0x81e4d64 of type 25 is trying to jump from runloop 9 to runloop 1] not ok 1 #skip skipped not ok 2 #skip skipped not ok 3 #skip skipped not ok 4 #skip skipped not ok 5 #skip skipped . . . The :init code in runtime/parrot/library/postgres.pir is running in a separate runloop, so when it throws an error, the error doesn't actually get to the handler, and the loadlib op appears to complete normally. I don't recall seeing this failed assertion before, though. Probably we should turn this oops into an internal_exception, since memory might be getting corrupted subsequently. The fix was this patch . . . Looks good to me. I see chromatic has already committed this as r15413. -- Bob Rogers http://rgrjr.dyndns.org/
Re: [perl #40824] loadlib opcode causes problems with exceptions
On Saturday 11 November 2006 19:01, Bob Rogers wrote: I don't think it's loadlib itself; I believe the library :init code is trying to throw an error. If that is the case, then it's a continuation barrier problem. Before the error, do you see this oops message? Yes, and agreed. Matt and I discussed that just after he sent the message. I don't recall seeing this failed assertion before, though. Probably we should turn this oops into an internal_exception, since memory might be getting corrupted subsequently. The fix was this patch . . . Looks good to me. I see chromatic has already committed this as r15413. It just gets the test to pass; there are still outstanding questions with regard to exceptions and continuations and the C barrier. -- c
[perl #40748] [TODO] Tcl - catch exceptions and return appropriate error message in runtime/builtin/inline.pir
# New Ticket Created by Paul Cochrane # Please include the string: [perl #40748] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40748 From the comment in the file languages/tcl/runtime/builtin/inline.pir: Should catch exceptions in the code and return the error message This ticket is in response to cage task #39704.
