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
hand
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 sched
Yes please!
On Oct 6, 2006, at 4:27 PM, chromatic wrote:
A thread on p5p recently brought up the idea of multi-language
exceptions.
That is, instead of throwing exceptions with English C-strings
embedded in
the source code, use a localization system.
If there'll soon be a push to clean up
On Sat, Jun 24, 2006 at 11:18:41PM -0400, Bob Rogers wrote:
>From: Chip Salzenberg <[EMAIL PROTECTED]>
>Date: Tue, 20 Jun 2006 20:59:45 -0700
>
>WRT exception handling, I think the lisp condition/handler model is a good
>starting point. It's simple enough to explain and use, and s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> pushmark 12
> popmark 12
> pushaction Psub
I've now implemented these bits. I hope it's correct, specifically, if a
return continuation in only captured, the action handler is not run.
See t/pmc/exceptions.t
Still missing is the throw opco
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:28 AM +0100 11/22/04, Leopold Toetsch wrote:
> Maybe we should name it invoke_return.
Ok. If someone grep's through the tree and just changes all, it's done.
$ find . -type f | xargs grep -w returncc
> We'd talked at one point about swapping interp
At 10:28 AM +0100 11/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Its in and named C since yesterday "return with current
continuation".
Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago t
At 8:57 AM +0100 11/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
Sure. Anything that throws an exception is more than welcome to pass
along a resume continuation if it wants, and I'm OK
On Fri, Nov 19, 2004 at 09:59:18AM +0100, Leopold Toetsch wrote:
: Allowing just one additional object doesn't properly support Python,
: which has two optional expressions for the C statement and Python
: attaches a traceback object to the exception.
:
: OTOH (again from Python's view) raising ju
William Coleda <[EMAIL PROTECTED]> wrote:
> This SHOULD trigger the exception handler in
> languages/tcl/lib/command/set.imc. Instead, the stack trace ends with:
> 3718 set_eh P20 - P20=Exception_Handler=PMC(0x401b5d8)
> 3720 find_lex P18, -1, S17- P18=Array=PMC(0x401b578), , S17="a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
>>Its in and named C since yesterday "return with current
>>continuation".
> Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago the first time.
I've asked for names of the o
I switched to local exception handler blocks, and am still getting the same
failure mode.
Of course, it works fine in a simple, single file example.
I've checked everything back in so you can take a look. Once you build tcl,
from the top level directory, try:
oolong:~/research/parrot_8075 coke$ c
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The 'invoke the current return continuation' op apparently got lost
in the blowup. That needs to go in.
Its in and named C since yesterday "return with current
continuation".
Hrm. The name's not right, since
William Coleda <[EMAIL PROTECTED]> wrote:
> I just noticed some test failures in the tcl suite.
exception syntax will change slightly.
> set P4, P5["_invoke_cc"]
especially these constructs (resumable handling).
Please use currently a local handler:
newsub ignore, .Exception_Handler, catc
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
leo
Dan Sugalski wrote:
Hmm, the first thing to take into the account is that return
continuations can be promoted to the fully blown continuations. This
should affect the handlers in the same way - so exception handlers
could have become arbitrary invokable objects at the point when the
exception
At 10:58 PM + 11/18/04, Tim Bunce wrote:
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current
> system is almost OK. What I'd like it to change to is:
>
>
At 10:03 AM +0100 11/19/04, Miroslav Silovic wrote:
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to tak
Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> Hmm, the first thing to take into the account is that return
> continuations can be promoted to the fully blown continuations.
Yes. But an exception handler is not a RetContinuation object. It's an
Exception_Handler object (also derived from Continuat
Tim Bunce <[EMAIL PROTECTED]> wrote:
> I guess the HLL compiler needs to ensure that for every push the
> control flow will always pass through a matching pop.
Not necessarily. The handler is pushed onto the control stack. During a
context change (e.g. from a subroutine return), the previous cont
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The 'invoke the current return continuation' op apparently got lost
> in the blowup. That needs to go in.
Its in and named C since yesterday "return with current
continuation".
> I'd like pushing exception handlers to remain simple -- the current
> syste
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to take into the account is that return
continuations can
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
> On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
>
> > I'd like pushing exception handlers to remain simple -- the current
> > system is almost OK. What I'd like it to change to is:
> >
> > push_eh label
> >
> > with poppin
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current
> system is almost OK. What I'd like it to change to is:
>
> push_eh label
>
> with popping the top exception handler being:
>
> pop_eh
>
> I'm up for better
Will Coleda <[EMAIL PROTECTED]> wrote:
> I'm trying to add exception handling support back in to tcl so I can
> trap references to non-existant variables. This is using a recent, but
> not just-now, cvs checkout.
> I am currently getting a segfault if I enable the exception handler.
> Running the
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Should the "raise" opcode produce resumable exceptions?
There is no problem with resuming after an opcode. E.g. when C
is:
invokecc Px # call exception handler
and the handler returns by C i.e. via the return
continuation, execution just resumes
At 11:53 AM -0400 6/30/03, Benjamin Goldberg wrote:
Brent Dax wrote:
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
# that it was nonfatal, and resume execution from just after the place
# it was thrown from.
The problem with that is that some exception
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Exception handlers really strike me as anonymous lexically scoped
>> subroutines that get called with just one parameter--the exception
>> object. As far as the engine should be concerned, when an exception
>>
Brent Dax wrote:
>
> Benjamin Goldberg:
> # Concievably, we could then examine the exception, and maybe decide
> # that it was nonfatal, and resume execution from just after the place
> # it was thrown from.
>
> The problem with that is that some exceptions are unresumable. For
> example, except
At 5:08 PM -0700 6/26/03, Brent Dax wrote:
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
that
# it was nonfatal, and resume execution from just after the place it was
# thrown from.
The problem with that is that some exceptions are unresumable. For
example
Gordon Henriksen wrote:
The most fundamental feature throwing an exception is that it transfers
program execution from the call site. Allowing the caller to resume
execution at that site is a very dangerous form of action at a distance.
I think you'd be better off a giving the caller an explicit wa
MAIL PROTECTED]
> Subject: Re: Exceptions
>
>
> Dan Sugalski wrote:
> > Piers Cawley wrote:
> >> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >>
> >>> Okay, now that we're well on our way to getting
> >>> sub/method/whateve
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
that
# it was nonfatal, and resume execution from just after the place it was
# thrown from.
The problem with that is that some exceptions are unresumable. For
example, exceptions thrown in C code are difficul
Dan Sugalski wrote:
> Piers Cawley wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> Okay, now that we're well on our way to getting
>>> sub/method/whatever calling down and working, I want to point us
>>> towards what I'm thinking of for exceptions.
>>>
>>> Exception handlers really strike
> > I'm not yet sure whether it's worth having engine support for
> > specific exception type checking
>
> I think we would have:
> - Exception handler = Continuation
> - Exception object = a new class of some type[2]. When the system throughs
> an exception, it would attach 2 properties to the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get called with just one parameter--the exception
> object. As far as the engine should be concerned, when an exception
> is taken we just take a continuation with the addr
At 8:53 AM -0400 6/23/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
Okay, now that we're well on our way to getting sub/method/whatever
calling down and working, I want to point us towards what I'm thinking
of for exceptions.
Exception handlers really strike me as anonymous
Piers Cawley:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get called with just one parameter--the exception
> object.
So, we grab another register for 'current exception continuation'?
Then when code throws an exce
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Okay, now that we're well on our way to getting sub/method/whatever
> calling down and working, I want to point us towards what I'm thinking
> of for exceptions.
>
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get
39 matches
Mail list logo
