Why does shimmering occur, when ...
in [TCL]
|
Prev: Is there a IPTC and/or XMP tcl package (scripted or binary) out in the wild?
Next: How to profile a Tcl/Tk extension?
From: Kevin Kenny on 15 Jan 2010 23:02 Andreas Leitgeb wrote: > It distracted from the actual question: (why was that second > (out-of-date) representation still visible in the result of > [rep $d] *after* [append] had "destroyed" the old value?) I'd say it's a bug in the 'rep' command. The internal rep is meaningless if the type pointer is NULL, and I think we just never bother to overwrite the pointers. -- 73 de ke9tv/2, Kevin
From: Alexandre Ferrieux on 16 Jan 2010 13:13 On Jan 16, 5:02 am, Kevin Kenny <kenn...(a)acm.org> wrote: > Andreas Leitgeb wrote: > > It distracted from the actual question: (why was that second > > (out-of-date) representation still visible in the result of > > [rep $d] *after* [append] had "destroyed" the old value?) > > I'd say it's a bug in the 'rep' command. The internal rep is > meaningless if the type pointer is NULL, and I think we just > never bother to overwrite the pointers. Sorry, I got lost in the various cases mentioned here. Can one of you gentlemen describe again that case of outdated representation ? It'll be a matter of honour for me to fix [rep] accordingly if it is proved guilty ;-) -Alex
From: Kevin Kenny on 16 Jan 2010 13:32 Andreas Leitgeb wrote: >>> It distracted from the actual question: (why was that second >>> (out-of-date) representation still visible in the result of >>> [rep $d] *after* [append] had "destroyed" the old value?) I replied: >> I'd say it's a bug in the 'rep' command. The internal rep is >> meaningless if the type pointer is NULL, and I think we just >> never bother to overwrite the pointers. Alexandre Ferrieux wrote: > Sorry, I got lost in the various cases mentioned here. Can one of you > gentlemen describe again that case of outdated representation ? It'll > be a matter of honour for me to fix [rep] accordingly if it is proved > guilty ;-) The case in question was from Martin Lemburg: > > % set d [expr {1.0}]; lappend d x; rep [lindex $d 0] > > value is a pure string with a refcount of 4, object pointer at > > 00DCC428, string representation "1.0". The object pointer is meaningless if the value is a pure string. -- 73 de ke9tv/2, Kevin
From: Andreas Leitgeb on 16 Jan 2010 15:30 Kevin Kenny <kennykb(a)acm.org> wrote: > Andreas Leitgeb wrote: >>>> It distracted from the actual question: (why was that second >>>> (out-of-date) representation still visible in the result of >>>> [rep $d] *after* [append] had "destroyed" the old value?) > I replied: >>> I'd say it's a bug in the 'rep' command. The internal rep is >>> meaningless if the type pointer is NULL, and I think we just >>> never bother to overwrite the pointers. > Alexandre Ferrieux wrote: >> Sorry, I got lost in the various cases mentioned here. Can one of you >> gentlemen describe again that case of outdated representation ? It'll >> be a matter of honour for me to fix [rep] accordingly if it is proved >> guilty ;-) > The case in question was from Martin Lemburg: > > > % set d [expr {1.0}]; lappend d x; rep [lindex $d 0] > > > value is a pure string with a refcount of 4, object pointer at > > > 00DCC428, string representation "1.0". > The object pointer is meaningless if the value is a pure string. after something was [append]ed, it doesn't talk of a pure string (obviously it has a full string-rep then), but still mentions the old pointer (or inline value) among "internal representation" Don't know if it is the same thing, but at least to me the object pointer appears like a slightly different thing as the "internal representation", and for each of them there is a (different) situation, where it shows a value, but rather shouldn't. % set d [expr {double(1)}]; append d x; rep $d value is a string with a refcount of 3, object pointer at 0x8e778b8, internal representation 0x8e6a9e8:0x3ff00000, string representation "1.0x". It's the :0x3ff00000 that's no longer relevant. (Don't know exactly what the other part 0x8e6a9e8 is, but at least it changed from before the append.)
From: Alexandre Ferrieux on 17 Jan 2010 04:40
On Jan 16, 7:32 pm, Kevin Kenny <kenn...(a)acm.org> wrote: > Andreas Leitgeb wrote: > >>> It distracted from the actual question: (why was that second > >>> (out-of-date) representation still visible in the result of > >>> [rep $d] *after* [append] had "destroyed" the old value?) > > I replied: > > >> I'd say it's a bug in the 'rep' command. The internal rep is > >> meaningless if the type pointer is NULL, and I think we just > >> never bother to overwrite the pointers. > Alexandre Ferrieux wrote: > > Sorry, I got lost in the various cases mentioned here. Can one of you > > gentlemen describe again that case of outdated representation ? It'll > > be a matter of honour for me to fix [rep] accordingly if it is proved > > guilty ;-) > > The case in question was from Martin Lemburg: > > > % set d [expr {1.0}]; lappend d x; rep [lindex $d 0] > > > value is a pure string with a refcount of 4, object pointer at > > > 00DCC428, string representation "1.0". > > The object pointer is meaningless if the value is a pure string. No, the "object pointer" is the Tcl_Obj's address. So it does have a meaning even for pure strings: it is the value's identity ! [rep] pleads Not Guilty ;-) -Alex |