[Tcl-bugs] [ tcl-Bugs-2910748 ] direct eval on BC spoilage is not NRE-aware

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

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