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 17 Jan 2010 15:18 On 17/01/2010 19:04, Andreas Leitgeb wrote: > You already answered that question yourself by using the word "almost". > And yes, I admit it's a very narrow "almost". That's the other key point: when the fraction of things that are served by a mechanism are very high, pushing a bit of cost onto the rest is entirely justifiable overall. I care much more for the 99.9% case than the 0.1% case. Donal (warning: arbitrary fractions above).
From: tom.rmadilo on 17 Jan 2010 17:06 On Jan 17, 11:04 am, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> wrote: > Donal K. Fellows <donal.k.fell...(a)manchester.ac.uk> wrote: > > >> Is there any idiom to obtain a string-rep of some arbitrary object > >> without even adding a "string representation" to the original obj? > > You mean by duplicating the object? Apart from that, no. > > Is there even a way to duplicate an arbitrary obj? It seems to me the problem here is not duplicating an object, but making a copy and leaving the original object as-is. I'm guessing you do this via some interface to the object, like [dict get].
From: Alexandre Ferrieux on 17 Jan 2010 17:24 On Jan 17, 8:04 pm, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> wrote: > Donal K. Fellows <donal.k.fell...(a)manchester.ac.uk> wrote: > > >> Is there any idiom to obtain a string-rep of some arbitrary object > >> without even adding a "string representation" to the original obj? > > You mean by duplicating the object? Apart from that, no. > > Is there even a way to duplicate an arbitrary obj? Yes, though a bit contorted: # first make a second reference set obj2 $obj # then do something to the 2nd append obj2 "" If you play with [rep] on this example, you'll see that the first line did just share the reference, but the 2nd applied copy-on-write, and hence split off $obj2 just before smashing it into a string object. But fortunately at this point $obj is untouched, and now its life is well separated from $obj2's. Of course some time has been lost smashing $obj2; in cases where this matters, you can be smarter by replacing [append] by something type- specific: for a list, [lappend]: for a dict, [dict set]. (but you'll also need to revert that modification, while [append ""]'s is nil). -Alex
From: Andreas Leitgeb on 17 Jan 2010 17:52 Alexandre Ferrieux <alexandre.ferrieux(a)gmail.com> wrote: >> Is there even a way to duplicate an arbitrary obj? > Yes, though a bit contorted: > # first make a second reference > set obj2 $obj > # then do something to the 2nd > append obj2 "" Ah, appending an empty string ... I had tried just [append obj2], and it was a noop (i.e. didn't even create a string-rep). I vaguely remember the discussion about [append var] and "$var" skipping stringification, so I'm not very confident, that [append var "" "" "" ""] wouldn't someday be optimized away, as well.
From: Andreas Leitgeb on 17 Jan 2010 18:33
Donal K. Fellows <donal.k.fellows(a)manchester.ac.uk> wrote: > On 17/01/2010 19:04, Andreas Leitgeb wrote: >> You already answered that question yourself by using the word "almost". >> And yes, I admit it's a very narrow "almost". > That's the other key point: when the fraction of things that are served > by a mechanism are very high, pushing a bit of cost onto the rest is > entirely justifiable overall. I care much more for the 99.9% case than > the 0.1% case. [format %d $num] does not add a string rep to an integer $num some new [format %O $obj] could do the same for any object. In (much) later versions, there could even be optimizations for [format %*O $len $obj], that avoid generating the complete string, but only create up to $len chars of it. It could be used for stackdumps such like $::errorInfo, and probably lots of other places, where only a prefix of some stringrep is of interest, and that string-rep is not expected to be re-obtained from the same obj value anytime soon. I mean, it wouldn't need to have any extra cost for the 99.9% of cases. PS: %O is perhaps not best choice, given the similarity of O and 0 and the frequency of 0's in that context. %P ? %S ? whatever. |