From: SourceForge.net <no...@so...> - 2009-02-28 23:20:46
|
Bugs item #2649975, was opened at 2009-02-28 18:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Kevin B KENNY (kennykb) Assigned to: Donal K. Fellows (dkf) Summary: bizarre interaction of uplevel, tailcall, method invocation Initial Comment: I'm struggling to come up with a smaller example of this problem; it's quite nasty. When the attached 'bugg.tcl' script is run, it produces the output, v should have been found at global level but was found in bar's method bravo Removing the line: proc dump args {} from the script makes it print a play-by-play analysis of what happened. It appears that everything is working fine right up to the very end, when the last [tailcall] invokes ::grill create betty That constructor runs at level 2, despite having been tailcalled from level 1, and causing [upvar 1 v w] to resolve in the wrong callframe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-03-16 13:44:22
|
Bugs item #2649975, was opened at 2009-02-28 23:20 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Kevin B KENNY (kennykb) >Assigned to: miguel sofer (msofer) Summary: bizarre interaction of uplevel, tailcall, method invocation Initial Comment: I'm struggling to come up with a smaller example of this problem; it's quite nasty. When the attached 'bugg.tcl' script is run, it produces the output, v should have been found at global level but was found in bar's method bravo Removing the line: proc dump args {} from the script makes it print a play-by-play analysis of what happened. It appears that everything is working fine right up to the very end, when the last [tailcall] invokes ::grill create betty That constructor runs at level 2, despite having been tailcalled from level 1, and causing [upvar 1 v w] to resolve in the wrong callframe. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 13:42 Message: Confirmed with HEAD. At the offending point (just before doing 'set resolution $w' in grill's constructor) doing an 'uplevel 1 dump' produces this output: 1: ::barney bravo That would seem to indicate that we're somehow managing to not stick within the constraints of the [uplevel]ed stack! I have no idea at all how that could possibly happen! Help! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-03-16 22:38:21
|
Bugs item #2649975, was opened at 2009-02-28 23:20 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Kevin B KENNY (kennykb) Assigned to: miguel sofer (msofer) Summary: bizarre interaction of uplevel, tailcall, method invocation Initial Comment: I'm struggling to come up with a smaller example of this problem; it's quite nasty. When the attached 'bugg.tcl' script is run, it produces the output, v should have been found at global level but was found in bar's method bravo Removing the line: proc dump args {} from the script makes it print a play-by-play analysis of what happened. It appears that everything is working fine right up to the very end, when the last [tailcall] invokes ::grill create betty That constructor runs at level 2, despite having been tailcalled from level 1, and causing [upvar 1 v w] to resolve in the wrong callframe. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:38 Message: Here's a simplified version that exhibits the same problem, but with less gunk in the way. Note that it does not include the puzzling code from the original that wasn't hitting the problem... File Added: bug2.tcl ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 13:42 Message: Confirmed with HEAD. At the offending point (just before doing 'set resolution $w' in grill's constructor) doing an 'uplevel 1 dump' produces this output: 1: ::barney bravo That would seem to indicate that we're somehow managing to not stick within the constraints of the [uplevel]ed stack! I have no idea at all how that could possibly happen! Help! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-03-16 22:50:28
|
Bugs item #2649975, was opened at 2009-02-28 23:20 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Kevin B KENNY (kennykb) Assigned to: miguel sofer (msofer) Summary: bizarre interaction of uplevel, tailcall, method invocation Initial Comment: I'm struggling to come up with a smaller example of this problem; it's quite nasty. When the attached 'bugg.tcl' script is run, it produces the output, v should have been found at global level but was found in bar's method bravo Removing the line: proc dump args {} from the script makes it print a play-by-play analysis of what happened. It appears that everything is working fine right up to the very end, when the last [tailcall] invokes ::grill create betty That constructor runs at level 2, despite having been tailcalled from level 1, and causing [upvar 1 v w] to resolve in the wrong callframe. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:50 Message: Evidence! In my script, in procedure 'bravo', changing uplevel 1 [list delta ::betty] to uplevel 1 delta ::betty makes the problem go away. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:38 Message: Here's a simplified version that exhibits the same problem, but with less gunk in the way. Note that it does not include the puzzling code from the original that wasn't hitting the problem... File Added: bug2.tcl ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 13:42 Message: Confirmed with HEAD. At the offending point (just before doing 'set resolution $w' in grill's constructor) doing an 'uplevel 1 dump' produces this output: 1: ::barney bravo That would seem to indicate that we're somehow managing to not stick within the constraints of the [uplevel]ed stack! I have no idea at all how that could possibly happen! Help! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-03-16 23:21:48
|
Bugs item #2649975, was opened at 2009-02-28 23:20 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Kevin B KENNY (kennykb) Assigned to: miguel sofer (msofer) Summary: bizarre interaction of uplevel, tailcall, method invocation Initial Comment: I'm struggling to come up with a smaller example of this problem; it's quite nasty. When the attached 'bugg.tcl' script is run, it produces the output, v should have been found at global level but was found in bar's method bravo Removing the line: proc dump args {} from the script makes it print a play-by-play analysis of what happened. It appears that everything is working fine right up to the very end, when the last [tailcall] invokes ::grill create betty That constructor runs at level 2, despite having been tailcalled from level 1, and causing [upvar 1 v w] to resolve in the wrong callframe. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 23:21 Message: This version also exhibits the bug and doesn't use TclOO... File Added: bug2.tcl ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:50 Message: Evidence! In my script, in procedure 'bravo', changing uplevel 1 [list delta ::betty] to uplevel 1 delta ::betty makes the problem go away. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:38 Message: Here's a simplified version that exhibits the same problem, but with less gunk in the way. Note that it does not include the puzzling code from the original that wasn't hitting the problem... File Added: bug2.tcl ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 13:42 Message: Confirmed with HEAD. At the offending point (just before doing 'set resolution $w' in grill's constructor) doing an 'uplevel 1 dump' produces this output: 1: ::barney bravo That would seem to indicate that we're somehow managing to not stick within the constraints of the [uplevel]ed stack! I have no idea at all how that could possibly happen! Help! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 |
From: SourceForge.net <no...@so...> - 2009-03-16 23:24:32
|
Bugs item #2649975, was opened at 2009-02-28 23:20 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Kevin B KENNY (kennykb) Assigned to: miguel sofer (msofer) Summary: bizarre interaction of uplevel, tailcall, method invocation Initial Comment: I'm struggling to come up with a smaller example of this problem; it's quite nasty. When the attached 'bugg.tcl' script is run, it produces the output, v should have been found at global level but was found in bar's method bravo Removing the line: proc dump args {} from the script makes it print a play-by-play analysis of what happened. It appears that everything is working fine right up to the very end, when the last [tailcall] invokes ::grill create betty That constructor runs at level 2, despite having been tailcalled from level 1, and causing [upvar 1 v w] to resolve in the wrong callframe. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 23:24 Message: problem seems to be that tailcall doesn't work right from within a procedure called by a pure-list uplevel body ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 23:21 Message: This version also exhibits the bug and doesn't use TclOO... File Added: bug2.tcl ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:50 Message: Evidence! In my script, in procedure 'bravo', changing uplevel 1 [list delta ::betty] to uplevel 1 delta ::betty makes the problem go away. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 22:38 Message: Here's a simplified version that exhibits the same problem, but with less gunk in the way. Note that it does not include the puzzling code from the original that wasn't hitting the problem... File Added: bug2.tcl ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-03-16 13:42 Message: Confirmed with HEAD. At the offending point (just before doing 'set resolution $w' in grill's constructor) doing an 'uplevel 1 dump' produces this output: 1: ::barney bravo That would seem to indicate that we're somehow managing to not stick within the constraints of the [uplevel]ed stack! I have no idea at all how that could possibly happen! Help! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2649975&group_id=10894 |