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: Donal K. Fellows on 18 Jan 2010 09:31 On 18 Jan, 12:32, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > [format %s] fixed in HEAD 8.[56]. Thanks for making the patch. (I made a test for 8.6 so it shouldn't break in the future without warning.) Donal.
From: Andreas Leitgeb on 18 Jan 2010 10:16 Alexandre Ferrieux <alexandre.ferrieux(a)gmail.com> wrote: >> and the issue with format %s perhaps soon fixed ... > [format %s] fixed in HEAD 8.[56]. Thanks! PS: (after looking at the changes) If a "precision" is given, then the argument is still stringified. That's not much of a problem, but good to know, when one uses the "precision" for a big list [format %.30s $biglist], that here the list will still shimmer to string even after this change. And a tidbid: Out of curiosity, on line 1869 of tclStringObj.c, why is 'i' mapped to 'd' *before* the switch, and not just another "case 'i':" added to the bunch of cases already accompanying "case 'd':" (and, if at all necessary, the char mapped only in that switch-arm)?
From: Alexandre Ferrieux on 18 Jan 2010 10:28 On Jan 18, 4:16 pm, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> wrote: > Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > >> and the issue with format %s perhaps soon fixed ... > > [format %s] fixed in HEAD 8.[56]. > > Thanks! > > PS: (after looking at the changes) > > If a "precision" is given, then the argument is still stringified. > That's not much of a problem, but good to know, when one uses the > "precision" for a big list [format %.30s $biglist], that here the > list will still shimmer to string even after this change. Yes. This patch was the quick and easy part, still doing unicode conversion for character counting, but only when counting is needed (like for precision or width). A more ambitious thing I have in mind is to remove the use of the String object in [format] entirely, but I have little time for this right now. > And a tidbid: > Out of curiosity, on line 1869 of tclStringObj.c, why is 'i' mapped > to 'd' *before* the switch, and not just another "case 'i':" added > to the bunch of cases already accompanying "case 'd':" (and, if > at all necessary, the char mapped only in that switch-arm)? No idea. Try 'cvs blame' (I mean, annotate), I'm not the father, just the surgeon ;-) -Alex
From: MartinLemburg on 19 Jan 2010 07:55 Hi Alex, first - thanks for fixing these bugs! Second - one thought of mine is, that using the EIAS principle, there should never be a need to convert a value into the internal string type. If not existent, the string representation must be built and used, but that's all. And if the string representation is e.g. encoded in UTF-8 and the command using the string needs another encoding, than a conversion is needed, but the source of the string representation shouldn't change, not even the string representation! So ... % set d [expr {double(1.0)}] 1.0 % set s1 [format {%s} [expr (int($d)}]]; 1 % set s2 [string range $d 0 [string first $d "."]-1] 1 % set s3 [string range $d 0 [string length $d]-2] 1 % set s4 [format {%.0f} $d] 1 .... none of those statements above should change the internal object type of the contents of "d" stricly working on the string representation. If this is possible, I start to think not of shimmering, while developing/writing tcl code anymore. Best regards, Martin On 18 Jan., 16:28, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > On Jan 18, 4:16 pm, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> > wrote: > > > Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > > >> and the issue with format %s perhaps soon fixed ... > > > [format %s] fixed in HEAD 8.[56]. > > > Thanks! > > > PS: (after looking at the changes) > > > If a "precision" is given, then the argument is still stringified. > > That's not much of a problem, but good to know, when one uses the > > "precision" for a big list [format %.30s $biglist], that here the > > list will still shimmer to string even after this change. > > Yes. This patch was the quick and easy part, still doing unicode > conversion for character counting, but only when counting is needed > (like for precision or width). > A more ambitious thing I have in mind is to remove the use of the > String object in [format] entirely, but I have little time for this > right now. > > > And a tidbid: > > Out of curiosity, on line 1869 of tclStringObj.c, why is 'i' mapped > > to 'd' *before* the switch, and not just another "case 'i':" added > > to the bunch of cases already accompanying "case 'd':" (and, if > > at all necessary, the char mapped only in that switch-arm)? > > No idea. Try 'cvs blame' (I mean, annotate), I'm not the father, just > the surgeon ;-) > > -Alex
From: Alexandre Ferrieux on 19 Jan 2010 08:47
On Jan 19, 1:55 pm, "MartinLemburg(a)Siemens-PLM" <martin.lemburg.siemens-...(a)gmx.net> wrote: > Hi Alex, > > first - thanks for fixing these bugs! > > Second - one thought of mine is, that using the EIAS principle, there > should never be a need to convert a value into the internal string > type. If not existent, the string representation must be built and > used, but that's all. Yes, you're in line with Kevin who regrets the creation of the String type :} I haven't dived long enough in the unicode-related parts of the code to have an educated opinion on this, so what I can offer is just a bird's view: in general, the internal rep is a cache meant to speed up subsequent similar accesses to the object. When two callers compete by asking for different types, shimmering occurs, and the alternative becomes: (1) - either reconcile the callers so that they use the same type (hard) (2) - or have a two-slots internal rep with a flush-oldest policy (horrendous) (3) - or let shimmering happen, proof admitting a conversion was unavoidable at this spot anyway Usually, we live with (3) and get (1) with an effort (which can be a healthy move). And (2) makes me sick. Now, while String is certainly parasitic in the inputs to [format] (further patch soon), there *are* situations where it is the wanted type, to be stored for a long time in the cache: [puts] to a non- binary-encoded channel for example. Of course the statistical importance of this is hard to measure; that's why extreme care is due when planning such evolutions for our beloved "untyped" language's ... type system ;-) -Alex |