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: Alexandre Ferrieux on 17 Jan 2010 04:46
On Jan 16, 9:30 pm, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at>
wrote:
>
> % 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.)

Ah, I see. That's not a bug in [rep] either, it's just a consequence
of code genericity. A Tcl_Obj always holds two words for the internal
value, and it is up to the type-specific code (hooked to through the
typePtr) to interpret them. See the internalRep union in tcl.h:

union { /* The internal representation: */
long longValue; /* - an long integer value. */
double doubleValue; /* - a double-precision floating value. */
VOID *otherValuePtr; /* - another, type-specific value. */
Tcl_WideInt wideValue; /* - a long long value. */
struct { /* - internal rep as two pointers. */
VOID *ptr1;
VOID *ptr2;
} twoPtrValue;
struct { /* - internal rep as a wide int, tightly
* packed fields. */
VOID *ptr; /* Pointer to digits. */
unsigned long value;/* Alloc, used, and signum packed into a
* single word. */
} ptrAndLongRep;
} internalRep;


For some types, both words are useful (e.g. doubles); for others,
only the first, like for the "string" type where it is a pointer to
the type-specific block of data.

Then when writing [rep], the only way to be generic, is to display
both words in hex (there's no introspection info in types, saying "hey
I use only the first word").

-Alex
From: Andreas Leitgeb on 17 Jan 2010 06:42
Alexandre Ferrieux <alexandre.ferrieux(a)gmail.com> wrote:
>> 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.)

> Ah, I see. That's not a bug in [rep] either, it's just a consequence
> of code genericity. A Tcl_Obj always holds two words for the internal
> value, and it is up to the type-specific code (hooked to through the
> typePtr) to interpret them. [...]

The Defendant made a good job - The Accusant retracts this case :-)

Finally:

Is there any idiom to obtain a string-rep of some arbitrary object
without even adding a "string representation" to the original obj
(i.e. have the generated string-rep *not* stored in that object at
all, but only created and kept in a separate new object) ?

Even if a string-rep is never supposed to make a logical difference
in Tcl, it obviously can make a difference in performance(see concat)
and memory-footprint(storing the string for longer than needed).

From: Kevin Kenny on 17 Jan 2010 10:24
Alexandre Ferrieux wrote:

> 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 ;-)

Complainant withdraws the charge. :}

--
73 de ke9tv/2, Kevin
From: Donal K. Fellows on 17 Jan 2010 11:24
On 17 Jan, 11:42, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at>
wrote:
> Is there any idiom to obtain a string-rep of some arbitrary object
> without even adding a "string representation" to the original obj
> (i.e. have the generated string-rep *not* stored in that object at
>  all, but only created and kept in a separate new object) ?

You mean by duplicating the object? Apart from that, no. Why would we
want such a thing when caching the rep in case it is needed is almost
always the right thing?

> Even if a string-rep is never supposed to make a logical difference
> in Tcl, it obviously can make a difference in performance(see concat)
> and memory-footprint(storing the string for longer than needed).

That issue with [concat] has been fixed for a while. The memory
footprint issue appears real, until you remember that a representation
is only present if it was needed for some reason. Caching it until
displaced usually saves and doesn't lose except for total peak memory
consumption; there's an overall speed/space trade-off which is
acceptable for virtually all code on even vaguely modern hardware.

Donal.
From: Andreas Leitgeb on 17 Jan 2010 14:04
Donal K. Fellows <donal.k.fellows(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?

> Why would we want such a thing when caching the rep in case it is needed
> is almost always the right thing?

You already answered that question yourself by using the word "almost".

And yes, I admit it's a very narrow "almost". Even more so with the
concat-issue already fixed (which I wasn't aware of) and the issue
with format %s perhaps soon fixed, and no other such problem currently
on radar.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
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?