Prev: smtp test case
Next: Is there a reason that ActiveTcl does not have an 64bit distribution?
From: Prashant on 12 Jul 2010 02:59
Hi,
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.
Is it possible to disable this by setting TCL_DONT_QUOTE_HASH to 1.
This application of ours is lining statically to libtcl.

regards,
Prashant
From: Donal K. Fellows on 12 Jul 2010 04:58
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 of list quoting 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 first list element. (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 append list elements
(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.

Without knowing what issues you are encountering, it's not going to be
possible to make any more detailed suggestion.

> Is it possible to disable this by setting TCL_DONT_QUOTE_HASH to 1.
> This application of ours is lining statically to libtcl.

Changing the definition of TCL_DONT_QUOTE_HASH in the way you suggest
will break code. For one thing, that value is used to mean something
else, and for another, it's not just your code that relies on it; it's
necessary for the correct operation of Tcl itself.

Donal.
From: Prashant on 12 Jul 2010 05:15
On Jul 12, 1:58 pm, "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 of list quoting 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 first list element. (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 append list elements
> (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.
>
Hi,

We are not passing the list to eval when $a begins with #.

> Without knowing what issues you are encountering, it's not going to be
> possible to make any more detailed suggestion.

However, we are dumping the list to file during regressions and the
same is compared.
Extra set of braces when $a begins with # is causing failure.

tclsh8.5
% set a #assign
#assign
% set result [list]
% lappend result $a
{#assign}
% puts $result
{#assign}
% exit

> tclsh8.4
% set a #assign
#assign
% set result [list]
% lappend result $a
#assign
% puts $result
#assign
%

regards,
Prashant

>
> > Is it possible to disable this by setting TCL_DONT_QUOTE_HASH to 1.
> > This application of ours is lining statically to libtcl.
>
> Changing the definition of TCL_DONT_QUOTE_HASH in the way you suggest
> will break code. For one thing, that value is used to mean something
> else, and for another, it's not just your code that relies on it; it's
> necessary for the correct operation of Tcl itself.
>
> Donal.

From: MartinLemburg on 12 Jul 2010 06:30
Hi Prashant,

to have "{#assign}" or "#assign" as first element of a list is
syntactically in tcl the same.
The only difference is, that "{#assign}" is prevented to be parsed by
the tcl parser like in:

% format {%d} 1; # "{%d}" not parsed
1
% format "%d" 1; # "%d" is parsed, searched for substitutions
1

To compare the outputs of the different tcl versions and finding such
differences, like "braced" first list elements is surely annoying, but
- as said - syntactically both string representations are the same:

% set list [list]
% lappend list #assign a b
{#assign} a b
# lindex $list 0
#assign

Through the "braced" first element in the list, starting with a hash
mark, the interpreter won't parse it and find the "#" to be
interpreted e.g. as comment introducing "signal".

Perhaps you have to think over your way to write the files to be
compared, because of this complete legal tcl behavior!

Best regards,

Martin

On 12 Jul., 11:15, Prashant <prashant.tha...(a)gmail.com> wrote:
> On Jul 12, 1:58 pm, "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 of list quoting 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 first list element. (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 append list elements
> > (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.
>
> Hi,
>
>   We are not passing the list to eval when $a begins with #.
>
> > Without knowing what issues you are encountering, it's not going to be
> > possible to make any more detailed suggestion.
>
>   However, we are dumping the list to file during regressions and the
> same is compared.
>   Extra set of braces when $a begins with # is causing failure.
>
>   tclsh8.5
> % set a #assign
> #assign
> % set result [list]
> % lappend result $a
> {#assign}
> % puts $result
> {#assign}
> % exit
>
> > tclsh8.4
>
> % set a #assign
> #assign
> % set result [list]
> % lappend result $a
> #assign
> % puts $result
> #assign
> %
>
> regards,
> Prashant
>
>
>
>
>
> > > Is it possible to disable this by setting TCL_DONT_QUOTE_HASH to 1.
> > > This application of ours is lining statically to libtcl.
>
> > Changing the definition of TCL_DONT_QUOTE_HASH in the way you suggest
> > will break code. For one thing, that value is used to mean something
> > else, and for another, it's not just your code that relies on it; it's
> > necessary for the correct operation of Tcl itself.
>
> > Donal.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

From: Y.T. on 20 Jul 2010 18:55
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?
 |  Next  |  Last
Pages: 1 2
Prev: smtp test case
Next: Is there a reason that ActiveTcl does not have an 64bit distribution?