From: Alexandre Ferrieux on
On Jul 21, 12:55 am, "Y.T." <ytyourclot...(a)gmail.com> wrote:
> On Jul 12, 1:58 am, "Donal K. Fellows"
>
>
>
>
>
> <donal.k.fell...(a)manchester.ac.uk> wrote:
> > On Jul 12, 7:59 am, Prashant <prashant.tha...(a)gmail.com> wrote:
>
> > > We have encountered strange issues while appending strings starting
> > > with '#' using Tcl_DStringAppendElement in 8.5. On closer inspection
> > > of tclutil.c this seems to be due to TCL_DONT_QUOTE_HASH.
>
> > This was due to a bug in the definition oflistquoting being
> > discovered during 8.5 that resulted in the # character being
> > incorrectly quoted (well, not quoted at all) when it was the first
> > word of the firstlistelement. (Basically, it related to the identity
> > between [$a $b $c] and [eval [list$a $b $c]] which was not preserved
> > when $a began with #, which caused some odd behaviour.) As long as you
> > are just relying on Tcl_DStringAppendElement to appendlistelements
> > (or command words that will be handled in a substitution-free fashion)
> > then you will be unaffected. That you *are* affected indicates that
> > you are using the wrong API in some way.
>
> I am trying to understand what you are saying here with the words
> "using the wrong API".
>
> I just found this thread because I just ran into this bug that appears
> to break older, functioning code that uses images.
>
> % set tst [image create photo -width 2 -height 2]
> image3
> % $tst data
> {#000000 #000000} {#000000 #000000}
> % $tst configure -data [list [list #123456 #654321] [list #223344
> #334455]]
> couldn't recognize image data
> % set newdata [list [list #123456 #654321] [list #223344 #334455]]
> {{#123456} #654321} {{#223344} #334455}
>
> Well - I can see why it can't recognize it. As far as I can tell, this
> is the correct API to shove data into an image.
>
> As far as I can tell, this breaks 'image' so badly that I can't even
> do this:
>
> % set n2 [$tst data]
> {#0f356e #0f356e} {#0f356e #0f356e}
> % $tst config -data $n2
> couldn't recognize image data
>
> i.e. I can't even hand an image its own contents back. Huh.
> So how am I supposed to write to it?

Hmm there are two separate layers here.

(1) Your last example: you need to say "-format {}". That's a slight
asymmetry in the [$image configure -data] API: unspecified format
option means "raw" when reading, and "autodetect" when writing, and
lack of autodetection doesn't default to "raw" (sigh).

(2) Your first example: you are right, the -data bitstream is now
*different* from canonical lists. When reading this is no problem,
since noncanonical lists like {#000000 #000000} are still valid lists,
but when writing it breaks, since the -data parser is an old,
primitive beast that does not use the list parser, and hence will not
accept the (valid, canonical) list {{#000000} #000000}. I agree this
is a wart, but I'm afraid the natural fix would have performance
impacts for large data (need to build an intermediary list
representation. You might still open a bug for deeper study though...

Also, I've found that there is a workaround for (2): use [$image put
$data] instead of [$image configure -data $data -format {}].
Apparently in this case $data is really iterated over as a list of
lists.

-Alex