miguel sofer
What's happening?
-
Comment: access violation except / compile? / ensemble?
Ensemble compiling, TclAdvanceContinuations (TIP 280) ... letting dkf and/or akupries have the first shot.
2012-02-14 09:46:44 PST in Tcl
-
Comment: Epoch does not increase when adding a trace
Fixed in core-8-5-branch and trunk.
2012-02-06 08:47:03 PST in Tcl
-
Comment: Epoch does not increase when adding a trace
Indeed - thanks. Upping prio.
2012-02-06 07:52:24 PST in Tcl
-
Comment: Epoch does not increase when adding a trace
Is this a bug in the trace, or a bug in unsupported::disassemble? I do not see a trace malfunction: % proc putargs {args} {puts $args} % proc test1 {t} {if {[string equal $t "test"]} {puts "foo"}} % test1 -; #compile % test1 test foo % trace add execution ::string enter putargs % test1 test {string trim {test1 test}} enter foo.
2012-02-06 07:26:42 PST in Tcl
-
Comment: lappend inconsistency with respect to read traces
The code is currently inconsistent - different behaviour between compiled and evaled code. This needs fixing irrespective of anything else. As for minimizing the risk of code incompats: the min is not to change behaviours at all, leave append doing one thing and lappend a different one as it was for 10 years. If the issue is instead one of reasonability, my sense tells me that read/modify ops...
2012-01-30 09:57:15 PST in Tcl
-
Comment: lack of [set] causes infinite loop through [unknown]
The infinite loop in [unknown] happens when there is an unknown command in the body of [unknown] itself. Still there. The bug in 8.6 was that that particular infinite loop was not being counted as a nesting level, so that "too many nested evaluations" was never triggered. The patch http://core.tcl.tk/tcl/ci/0c8502aa1f?sbs=1 just allows differentiating errors: is it that...
2012-01-27 07:07:09 PST in Tcl
-
Comment: lack of [set] causes infinite loop through [unknown]
The fix was for the 8.6 behaviour (busy loop at 100% cpu), which does not happen in 8.5 The deeper bug (recursive calling of unknown) is present in both ... and possibly since the dawn of time.
2012-01-27 06:37:57 PST in Tcl
-
Comment: Unexpected behavior / Panic / Tcl_Obj deletion management
sebres: could you provide a sane example? First you were editing an obj without checking if it is shared, now you are evaling it from the freeIntrepProc ...
2012-01-23 14:43:43 PST in Tcl
-
Comment: Unexpected behavior / Panic / Tcl_Obj deletion management
test.cpp uploaded to http://paste.tclers.tk/2589.
2012-01-23 14:41:45 PST in Tcl
-
Comment: Unexpected behavior / Panic / Tcl_Obj deletion management
Mmhhh ... that is a weird thing to be doing: the code calls Tcl_EvalObjEx on an object from the object's freeIntRepProc?.
2012-01-23 14:28:08 PST in Tcl