[Tcl-bugs] [ tcl-Patches-522849 ] TIP #87 reference implementation

[<no...@so...>]

Patches item #522849, was opened at 2002-02-25 23:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=310894&aid=522849&group_id=10894

Category: 19. [interp]
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Trier (trier)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: TIP #87 reference implementation

Initial Comment:
Reference implementation for TIP #87, "Allow Tcl
Access to the Recursion Limit".  Includes tests and
documentation.



----------------------------------------------------------------------

>Comment By: Stephen Trier (trier)
Date: 2002-02-26 10:42

Message:
Logged In: YES 
user_id=372112

Very diplomatically put, Don. :-)

Here is a new version of the patch that fixes both oversights.


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2002-02-26 09:41

Message:
Logged In: YES 
user_id=80530

I didn't look with great care, but I didn't see anything
to disable this subcommand in a safe interp.


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2002-02-26 09:37

Message:
Logged In: YES 
user_id=80530

Ah.  OK.  Let's spell out that situation in the TIP
as well, so it's clear what spec folks will be voting on.

----------------------------------------------------------------------

Comment By: Stephen Trier (trier)
Date: 2002-02-26 09:35

Message:
Logged In: YES 
user_id=372112

Whoops! My mistake. The fallback error should be issued only if the current interp is changing its
own recursion limit. Otherwise, the code should let Tcl_Eval() et al error out naturally.

I'll fix it right away.


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2002-02-26 09:29

Message:
Logged In: YES 
user_id=80530


Of course I meant to ask:

Why shouldn't the current interp go on to evaluate the next
command?

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2002-02-26 09:21

Message:
Logged In: YES 
user_id=80530

I see that this implementation "falls back" if the
new limit is less than the current run level in
the interp that's having its limit changed.  It's
not clear to me that's the right thing to do if that
interp is not the interp evaluating the [interp
recursionlimit].

# Assume an evaluation in slave is in the call stack
# somewhere
interp recursionlimit slave 1

Should I really see an error in the current interp?
The limit in the current interp has not been exceeded.
Why should the current interp go on to evaluate the next
command?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=310894&aid=522849&group_id=10894