# New Ticket Created by Christoph Otto
# Please include the string: [perl #60556]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60556 >
If an exception handler catches an exception from a MULTI function implemented
in C,
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
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
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 hand
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 en
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 :
Patrick R. Michaud wrote:
What I'm trying to do is to test the ability to resume after
exceptions thrown by C. The C sub above sets up
a handler to catch exceptions, then calls C. The handler
simply resumes any exception that is caught. The C sub
prints 'ok 1', throws an ex
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:3
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'()
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
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
tifies 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 execut
hat 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.
ion. Instead, the
exception crashes pdb. Fixing pdb to catch exceptions cleanly would
make pdb significantly more useful as a debugger, I think.
Mark
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
ally...). This issue is actually more
> > general and *any* ResizeableArray 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, i
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* ResizeableArray needs the
exceptions-related tests
3 >
>
>
> 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 implemen
rly 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.
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, sin
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 a
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 concurr
nt = 0; /* TODO 1 - Exceptions !!! */
I think this means to handle exceptions wrt reference counts correctly, but
I'm really not sure.
> 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 a
# New Ticket Created by Jerry Gay
# Please include the string: [perl #44139]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44139 >
the api for opcodes needs review, especially with regard to the
response to exceptional beh
bsequently.
>
>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
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 g
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40824]
# in the subject line of all future correspondence about this issue.
# 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
hould catch exceptions in the code and return the error message"
This ticket is in response to cage task #39704.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40714]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40714 >
The procedure eval_is() in languages/tcl/lib/test_more.tcl needs to be
able to handle t
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 cle
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 all of the uses of exceptions in the
source code (to
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40218]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40218 >
So sayeth the docs for the get_*_hll global opcodes:
If the global doesn't exist,
tions:
Bob, could you briefly write up the problem and proposed solution as a
[PDD] ticket for the extending, embedding, and external C API PDDs
(10-12, and possibly 2 and 23)? How we handle exceptions and
control-flow across C/Parrot boundaries is an important question, and I
want to make sure we address it.
Thanks,
Allison
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 21:58:36 +0200
Am Sonntag, 30. Juli 2006 04:50 schrieb Bob Rogers:
> The attached patch detects cases where a continuation tries to enter a
> runloop different from the one that is executing, and prints a warning
>
Am Sonntag, 30. Juli 2006 04:50 schrieb Bob Rogers:
> The attached patch detects cases where a continuation tries to enter a
> runloop different from the one that is executing, and prints a warning
> to stderr.
Looks very sane and appliable to me.
Thanks,
leo
From: chromatic <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2006 21:52:59 -0700
You should be able to replace this with pir_output_is( ..., todo => '...' );
Good idea; thank you. (I had forgotten about that syntax.)
-- Bob
On Saturday 29 July 2006 19:50, Bob Rogers wrote:
> +local $TODO = 'runloop shenanigans';
> +# stringification is handled by a vtable method, which runs in a second
> +# runloop. when an error in the method tries to go to a Error_Handler
> defined +# outside it, it winds up going to the inner runl
+#ifdef RUNLOOP_TRACE
+fprintf(stderr, "[entering loop %d, level %d]\n",
+interpreter->current_runloop_id, our_runloop_level);
+#endif
/*
* STACKED_EXCEPTIONS are necessary to catch exceptions in reentered
* run loops, e.g. if a delegate methods throws an
ion is implemented by
entering a secondary runloop (see src/pmc/delegate.pmc). The C code and the
extra runloop is acting as a Continuation barrier . . .
Ouch.
I've experimented some time ago to get at least exceptions working by
rewinding runloops also, but have failed so
implemented by
entering a secondary runloop (see src/pmc/delegate.pmc). The C code and the
extra runloop is acting as a Continuation barrier. There are also some notes
about that in dan's blog.
I've experimented some time ago to get at least exceptions working by
rewinding runloops a
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39988]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39988 >
The example:
.sub main :main
$P0 = get_hll_global ['Foo'], 'load'
$P0()
From: Allison Randal <[EMAIL PROTECTED]>
Date: Sat, 22 Jul 2006 17:34:45 -0700
Bob Rogers wrote:
> Two weeks ago I started writing something I had been thinking about for
> a year now, tentatively called "Continuations, Coroutines, And All That:
> An informal introduction to cre
Bob Rogers wrote:
Two weeks ago I started writing something I had been thinking about for
a year now, tentatively called "Continuations, Coroutines, And All That:
An informal introduction to creating advanced control structures in
Parrot." It is still mostly an outline, though -- it's hard to w
(And my apologies to chromatic for not replying sooner; the original
post got buried, and I lost track of the fact that I hadn't replied.)
I would ultimately like to see exceptions head down that road. But an
exceptions stack is a good first approximation, and is at least safer
ontinuations to handle exceptional flow control?
I would ultimately like to see exceptions head down that road. But an
exceptions stack is a good first approximation, and is at least safer
than the current combined control+exceptions stack.
(CPS is, BTW, a part of Parrot internals in need of mor
Applied as r13307.
Still needs some tweaking, e.g. fix the failing past.t, but good enough
for now.
leo
On Friday 14 July 2006 16:07, Bob Rogers wrote:
> One way to ensure that a handler is not in scope
> when invoked (though possibly not the only way) is to keep the list of
> active handlers in a dynamic variable binding.
Here's what I don't understand. Why is there talk of a stack to keep track
On Sat, Jul 08, 2006 at 04:51:38PM -0700, Allison Randal wrote:
> Chip did a fantastic job on the Exceptions PDD. With a few refinements,
> I'm pronouncing it "ready to implement".
Excellent.
Mad properties to Allison for creating the first draft (updating is so much
easi
ow).
3. If the above pseudocode is implemented in PIR as a library
routine (as it easily could be), then the C substrate doesn't have to
keep track of exceptions that are in the process of being thrown.
4. In fact, and unless I have missed something additional that Perl
6 require
a chat about other possible API's which could be
added in future. Some e.g.
1. To throw Parrot exceptions instead of the String **error.
2. Possibly using Compiler PMC. (not sure on that yet)
Your suggestion is good and I will keep in mind.
These two functions are just a start for def
On Wednesday 12 July 2006 22:02, Vishal Soni via RT wrote:
> This patch also introduces a Parrot API for the calling programs to
> compile the code. Currently pugs uses immc_compile() call into IMCC.
> Ideally Pugs should not be communicating with IMCC but with Parrot. This
> new API will try to h
Chip did a fantastic job on the Exceptions PDD. With a few refinements,
I'm pronouncing it "ready to implement". We'll certainly work out more
details as we go along, but the best way to test the design is to start
on the code.
Allison
Hi,
I would like to throw a Parrot Exception from IMCC to the calling
program instead of terminating IMCC when a parse error occurs.
Are there some example in Parrot as to how to throw a Parrot exception
and how to catch it?
-Vishal
# New Ticket Created by Audrey Tang
# Please include the string: [perl #39715]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39715 >
Currently, if you use IMCC inside embedded parrot (eg. when compiling
via PGE), when a sy
> So, yes, I could install the equivalent of an UNDO block around the Lisp
> code that does whatever Parrot maintenance is required on the Parrot
> exception object (which, it now occurs to me, may need to be distinct
> from the Lisp condition object). But would I really need to do any
arge grain of salt. It might be possible to create a
conforming Scheme implementation without CPS, but on the other hand,
every time I encounter CWCC I learn something new, so what do I know?
One question about push_dynscope, though: Is the
sub_to_call_when_scope_is_finally_inaccessible calle
good model for scope and continuation
handling, wouldn't a Scheme compiler want to take advantage of that?
And getting back to exceptions, I'm seeing something that's pretty much like
the CL model, where the 'push_eh' opcode takes a _closure_, and the list of
handlers is its o
I was involved in the C++ standardization process, and argued for
resumption as opposed to termination only in exceptions. I was somewhat
of a pioneer, implementing C++ exceptions for my team to use before
commercial compilers had them. After all, why start a new project with
an old paradigm
the terminate-only camp.
: I don't remember what the "killer" argument was. But I do remember bits
: and pieces: people with real-world experience on systems that have
: resumable exceptions in some form ended up never using them; it
: complicates the implementation; it is not
On Wed, Jun 14, 2006 at 08:59:02PM -0700, Chip Salzenberg wrote:
: Are Parrot exceptions now, in fact, resumable? If they are, is that
: important? Is anyone actually resuming execution after exception handlers
: are called? I think we _can_ keep resumability, but I'm not sure I want us
Are Parrot exceptions now, in fact, resumable? If they are, is that
important? Is anyone actually resuming execution after exception handlers
are called? I think we _can_ keep resumability, but I'm not sure I want us
to, and I definitely don't want to bother if no one wants it
e developer, and it's easy to get it wrong.
Seems to me that this is unavoidable. Exceptions are useful mainly
because they allow these drastic changes to normal control flow.
Writers of HLL code are relieved of at least some of this responsibility
by their compiler, but writers of PIR are ex
> [guest - Sat Apr 22 18:25:09 2006]:
>
> The attached patch implements and tests divide by zero exceptions for
> BigInt and Complex PMCs.
>
> It also tests divide by zero exceptions for float PMCs. float and
> integer PMCs are already properly handling divide by zer
d exit-and-reenter
behavior of coroutines, and there is no mechanism to specify a thunk
that gets called when *entering* a dynamic context . . .
That too.
=back
=head1 IMPLEMENTATION
[I'm not convinced the control stack is the right way to handle
exceptions. Most of Parrot is
rate
for the current state of Parrot, but is something you always intended
to write out later? What thoughts have you had on how exceptions
should work? All comments, suggestions, and contributions cheerfully
welcomed.
Allison
Here&
r? What thoughts have you had on how exceptions
should work? All comments, suggestions, and contributions cheerfully
welcomed.
Allison
[EMAIL PROTECTED]>
Date: Jan 10, 2006 3:57 PM
Subject: divide by zero exceptions
To: Perl 6 Internals
The integer and floatval opcodes div, fdiv, and cmod now all throw a
E_ZeroDivisionError exception with the text "Divide by zero". JIT/i386
and JIT/ppc are also adapted accordingly.
The integer and floatval opcodes div, fdiv, and cmod now all throw a
E_ZeroDivisionError exception with the text "Divide by zero". JIT/i386
and JIT/ppc are also adapted accordingly.
Updates for Integer, Float, Complex, BigInt PMCs are welcome.
leo
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37287]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37287 >
Subject: Re: [perl #22343] pdb + internal_exception = segfault
Date: Wed, 21 Sep 2005
On Mon, 19 Sep 2005, Will Coleda wrote:
> Good! [inline] isn't real Tcl, it's specific to partcl.
>
> That test consists of the code:
>
> inline PASM {
>print "ok\n"
> }
>
> which should do the obvious thing. Odd that it's squawking about MMD_add.
It's very strange. It copied that snip
Good! [inline] isn't real Tcl, it's specific to partcl.
That test consists of the code:
inline PASM {
print "ok\n"
}
which should do the obvious thing. Odd that it's squawking about
MMD_add.
Can you 1) try this PIR, and 2) if that *works*, copy that tcl
snippet to "examples/foo.tcl"
On Thu, 15 Sep 2005, Will Coleda wrote:
> Done. All tests pass for tcl in leo-ctx5. (And with leo's recent fixes,
> hopefully this means on all platforms for real this time. =-)
>
> This should also fix the problem on windows, as the missing functions have
> been uncommented, and are now availabl
;TCL_RETURN, TCL_BREAK, TCL_ERROR) will be handled with 'throw'.
> >
> >This should
> > - improve future interoperability in some ways (no longer odd two-
> >value return system; [error]s are now exceptions)
> > - simplify quite a few cases where I can
This should
- improve future interoperability in some ways (no longer odd two-
value return system; [error]s are now exceptions)
- simplify quite a few cases where I can now simply let an
exception propagate instead of checking and branching;
- break future interoperability in other ways (wha
eroperability in some ways (no longer odd two-
value return system; [error]s are now exceptions)
- simplify quite a few cases where I can now simply let an
exception propagate instead of checking and branching;
- break future interoperability in other ways (what do you mean,
return is an excepti
On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote:
> Missing MMD default functions
> Dan was somewhat bemused to find that the MMD functions' defaults had
> disappeared when he did a sync with subversion. He wondered whether this
> was deliberate. Turns out that it
Jerry Gay <[EMAIL PROTECTED]> wrote:
> On 5/12/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> Just curious: what's the difference between these two:
>>
>>E_IndexError,
>> E_IndexOutOfBoundsError,
>>
> the difference is very subtle ;)
Though so ;-)
> ... E_IndexOutOfBou
On 5/12/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Jerry Gay <[EMAIL PROTECTED]> wrote:
>
> > i'm converting many of the remaining internal_exception() calls to
> > real_exception() (except unimplemented ops, and other valid internal
> > exception
Jerry Gay <[EMAIL PROTECTED]> wrote:
> i'm converting many of the remaining internal_exception() calls to
> real_exception() (except unimplemented ops, and other valid internal
> exceptions)
Fine, thanks - applied.
Just curious: what's the difference between these two:
xception() (except unimplemented ops, and other valid internal
exceptions)
before i send a list of patches for various files to the list, i'd
like to make sure this first patch is agreeable. i added a new
exception type (E_IndexOutOfBoundsError,) converted exceptions for the
array pmc, and modified i
At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... A scope exit
action is put in place on the control stack with:
pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the r
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... A scope exit
> action is put in place on the control stack with:
> pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the relationship to the C opcode?
Thanks,
leo
a constant singleton
throw e
That ought to be enough for heavily used exception and for Perl6
control exceptions.
OTOH
e = new Exception
setattribute e, "message", Pmsg
setattribute e, "language", PLang
...
throw e
construct a full exception object.
Currently
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, a
w) raising just a C or a
: C ought to be fast as its used heavily.
And Perl 6 would like control exceptions to be fast. We won't use
ordinary exceptions as heavily as Python does for normal control flow,
since we believe in undef. Or rather, we'll generate exceptions,
but instead of throw
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
code to jump to if an exception's thrown. The
exception pushing code should take care of building whatever
structure's needed to call into it. (Though other than making a
return continuation and changing the address to the address used in
the push_eh instruction I'm not sure we n
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
I just noticed some test failures in the tcl suite.
Looks like the following code:
print "HERE?\n"
set_eh ignore
find_lex lexical, -1, var
clear_eh
Does the following at runtime:
3713 print "HERE?\n"
HERE?
3715 set_eh P20 - P20=Exception_Handler=PMC(0xf8eb30)
3717 find_lex P18, -1,
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
y generic. If the documentation and comments use it
consistently only for exceptions, though, it could work.
Throwcatch, so
push_catcher ?
I guess the HLL compiler needs to ensure that for every push the
control flow will always pass through a matching pop.
Otherwise that'll be another hard
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
1 - 100 of 194 matches
Mail list logo
