From: SourceForge.net <no...@so...> - 2010-01-21 04:57:00
|
Bugs item #2910748, was opened at 2009-12-08 10:17 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2910748&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: 60. NRE and coroutines Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 9 Private: No Submitted By: miguel sofer (msofer) Assigned to: Don Porter (dgp) Summary: direct eval on BC spoilage is not NRE-aware Initial Comment: See http://groups.google.co.uk/group/comp.lang.tcl/browse_frm/thread/521f924c167872a6 ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2010-01-20 23:57 Message: The execute-8.4 failure is due to the following, which for the moment I'm thinking is a flaw in the INST_EVAL_STK instruction: % proc foo0 {} { catch {error bar} m o return -options $o $m } % proc foo1 {} { catch {error bar} m o if 1 {return -options $o $m} } % proc foo2 {} { catch {error bar} m o set x 1 if $x {return -options $o $m} } % foo0 bar % set errorInfo bar while executing "error bar" (procedure "foo0" line 2) invoked from within "foo0" % foo1 bar % set errorInfo bar while executing "error bar" (procedure "foo1" line 2) invoked from within "foo1" % foo2 bar % set errorInfo bar while executing "error bar" invoked from within "if $x {return -options $o $m}" (procedure "foo2" line 4) invoked from within "foo2" ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-01-19 10:34 Message: fixed bug# refs in patch ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2010-01-17 08:41 Message: The attached patch fixes this issue, BUT it breaks execute-8.4: it was not committed The new failure may be deemed to be a lesser bug (not prio 9); requesting review by dgp ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2009-12-10 19:45 Message: On today's HEAD (after some rewrite of coro code) dkf's snippet does not crash, it causes an error instead: 'cannot yield: C stack busy' ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-12-08 10:50 Message: Relatedly, the next snippet crashes (tested in a fresh debug build) proc foo args {};foo;coro bar apply {{} {proc foo args {return ok}; foo; while 1 {yield [incr i];foo}}} (Apparently, "nasty thing, causes a recompile ... yield in one bytecode, resume in another") ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2009-12-08 10:30 Message: [12:27] dkf I think you'd get the same effect (spoilage of bytecode) by creating a command [proc assert args {}] which you use and then redefining that part way through [12:28] dkf I suspect that it is bytecode spoilage that's key, not [namespace path] which is adding nothing that is bytecoded ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2910748&group_id=10894 |