From: <no...@so...> - 2002-02-26 18:58:32
|
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:58 Message: Logged In: YES user_id=372112 OK, I guess I can't delete it. ---------------------------------------------------------------------- Comment By: Stephen Trier (trier) Date: 2002-02-26 10:43 Message: Logged In: YES user_id=372112 Old patch deleted. ---------------------------------------------------------------------- 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 |