From: Alexandre Ferrieux on 21 Jul 2010 03:39 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
First
|
Prev
|
Pages: 1 2 Prev: smtp test case Next: Is there a reason that ActiveTcl does not have an 64bit distribution? |