| Ticket UUID: | 3e30dc62e0125d706c1fd1b1f0c53099c394a16d | ||
| Title: | compiled [lappend] in proc fails to fire read traces | ||
| Type: | Bug | Created on: | 2015-11-16 20:36:55 |
| Submitter: | dgp | Assigned to: | nobody |
| Subsystem: | 47. Bytecode Compiler | Severity: | Important |
| Priority: | 5 Medium | Last modified: | 2015-11-16 23:08:28 |
| Status: | Open | Closed by: | nobody |
| Resolution: | None | Closed on: | |
| Version: | trunk | ||
| Description: | ||||
% set x {}
% trace add variable x read {apply {args {puts $args}}}
% lappend x a
x {} read
a
% apply {{} {
set x {}
trace add variable x read {apply {args {puts $args}}}
lappend x a
}}
a
% apply {{} {
set x {}
trace add variable x read {apply {args {puts $args}}}
[subst lappend] x a
}}
x {} read
a
% apply {{} {
set x {}
trace add variable x read {apply {args {puts $args}}}
lappend x a b
}}
x {} read
a b
| ||||
| User Comments: | ||||
dgp added on 2015-11-16 23:08:28:
This mess is tied up with Bug 3057639, and http://core.tcl.tk/tcl/info/21b6b23 where the loss of read traces was apparently intentionally done, at least kinda sorta, with a claim that new tests append*-9.* demand the changed behavior -- no read traces from lappend Trouble is that other tests including append-7.[234] and trace-3.[12] demand that the traces be there. This continuing inconsistency is left hanging in 3057639, which is in fact still open. Now the new wrinkle is that a whole new collection of bytecodes INST_LAPPEND_LIST_*& have been invented and they adopt the "traces? YES!" side of the dilemma. So we have yet a new dimension of inconsistency, and this one appears to be wrapped up in performance differences too (the only reason I'm down this rabbit hole). | ||||