From: <no...@so...> - 2002-03-29 17:17:55
|
Bugs item #219181, was opened at 2000-10-26 01:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=219181&group_id=10894 Category: 43. Parsing and Eval Group: = 8.4a2 Status: Open Resolution: Remind Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: miguel sofer (msofer) Summary: [break] at level #0: No error message Initial Comment: OriginalBugID: 2136 Bug Version: 8.1 SubmitDate: '1999-06-03' LastModified: '1999-08-14' Severity: MED Status: Assigned Submitter: techsupp ChangedBy: hobbs OS: Other Machine: NA FixedDate: '2000-10-25' ClosedDate: '2000-10-25' Name: Don Porter ReproducibleScript: # FILE: test.tcl puts stderr [info patchlevel] break ObservedBehavior: $ tclsh8.0 test.tcl 8.0.5 invoked "break" outside of a loop while executing "# FILE: test.tcl puts stderr [info patchlevel] break " (file "test.tcl" line 1) $ tclsh8.1 test.tcl 8.1.0 DesiredBehavior: Ideally, consistent error messages between 8.0.x and 8.1.x Tcl releases. At a minimum, there should be some error message reported by Tcl 8.1.x. Verified in 8.2.0. Returns an empty line. -- 08/14/1999 hobbs ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2002-03-29 12:17 Message: Logged In: YES user_id=80530 Yes, that patch fixes the console bug reported by JCW. Test suite passes too, including your new tests. I'm still concerned about possible problems with Tcl_EvalTokensStandard making multiple calls to Tcl_EvalEx in its for loop and having that 2d and later calls not respect the original ALLOW_EXCEPTIONS value. I haven't cooked up a test case for that, though. I'm pleased to see the call to Tcl_LogCommandInfo within TclCompEvalObj almost completely removed. That meshes nicely with some of my TIP 90 work. It's only still there for sort of handling errors from Tcl_AsyncInvoke. Is it doing anything close to the right thing in that case? Regarding documentation of TCL_RETURN coming back from a Tcl_*Eval* routine, rather than document current behavior, I'd rather change it so that it makes more sense. See the comments for Tcl Bug 219191 about the inconsistent mess that's currently in place. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-03-29 06:28 Message: Logged In: YES user_id=148712 New patch, as discussed in the chat. Don, could you please check if JCW's Tk issue is solved by this? Also, I'd rather let *you* describe what happens to TCL_RETURN (in doc/AllowExc.3). Actually, it is not trivial to explain: there is no library function similar to [return] (or did I miss it?), and the field iPtr->returnCode is not accessible to standard extensions (it is part of Interp but not Tcl_Interp). ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-03-28 23:04 Message: Logged In: YES user_id=80530 As discussed in the chat, that's not it either. Be sure you also test the case: foo [set a 1] [break] ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-03-28 20:56 Message: Logged In: YES user_id=148712 :( Tcl_AllowExceptions was not enabled for the new path! This new patch may solve the issue, without yet giving the correct result for Don's new test script. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-03-28 18:12 Message: Logged In: YES user_id=80530 Re-opening this one. The fix is incomplete. There's real weirdness going on with Tcl_AllowExceptions(). It can only be set, never cleared. Evaluation of an alias is one thing that sets it. Use this demo script: # FILE: demo.tcl interp alias {} patch {} info patchlevel puts stderr [patch] break $ tclsh8.0 demo.tcl 8.0.5 invoked "break" outside of a loop while executing "interp alias {} patch {} info patchlevel puts stderr [patch] break " (file "demo.tcl" line 1) $ tclsh8.3 demo.tcl 8.3.4 $ tclsh8.4 demo.tcl 8.4a5 $ ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-03-27 13:19 Message: Logged In: YES user_id=148712 Yes, but ... In 8.3 the function Tcl_EvalEx is in tclParse.c; in order to apply this fix I'd have to choose among 1. move all evaluation functions to tclBasic.c, as in 8.4 2. promote "static void ProcessUnexpectedResult" to "void TclProcessUnexpectedResult" in tclBasic.c 3. duplicate ProcessUnexpectedResult in tclParse.c For such a long-standing bug (since 8.1), I thought it wasn't worth it. I'll reconsider 2 or 3 if poked ... ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-03-27 12:47 Message: Logged In: YES user_id=80530 Can a corresponding patch work for core-8-3-1-branch ? ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-03-27 09:36 Message: Logged In: YES user_id=148712 Patch committed. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2002-03-27 09:30 Message: Logged In: YES user_id=148712 The direct evaluation path (Tcl_EvalEx) was missing the "ProcessUnexpectedResult at level 0" code. The enclosed patch fixes this. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-03-02 12:43 Message: Logged In: YES user_id=80530 Miguel, Sorry to assign this directly to you, but SF won't let me assign it to "None" as I want. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-03-02 12:41 Message: Logged In: YES user_id=80530 Dropping ownership of this bug so a maintainer can pick it up. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2001-02-26 17:55 Message: Logged In: YES user_id=80530 See also #219384 ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2001-02-26 06:44 Message: Logged In: YES user_id=79902 Hmm. The problem is not that the [break] isn't having an effect, but rather that no error message is being generated. See the following session: $ cat test.tcl # FILE: test.tcl puts stderr [info patchlevel] break puts stderr "FELL THROUGH" $ tclsh8.3 test.tcl 8.3.2 $ tclsh8.0 test.tcl 8.0.4 invoked "break" outside of a loop while executing "# FILE: test.tcl puts stderr [info patchlevel] break puts stderr "FELL THROUGH" " (file "test.tcl" line 1) $ tclsh8.3 % source test.tcl 8.3.2 invoked "break" outside of a loop Note first that neither 8.0.4 or 8.3.2 fell through to the rest of the script, so the break itself must have worked. Second, note that there is an extra blank line generated after the printing of the patchlevel under 8.3.2, so something is coming of the break. It looks to me like this is actually either a problem with Tcl_EvalFile or with the default error handler in 8.3.2, and this problem is not exercised when running interactively... ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2000-11-29 12:23 Message: Re-opened. Described bug is still present in both 8.3.2 and 8.4a2. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2000-11-13 08:25 Message: Not sure when this got fixed, but it works identically in 8.0.4 and 8.3.2, so I'm closing this one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=219181&group_id=10894 |