f



'lrange' differences in tcl 8.4 and 8.6

Hi,

lrange works differently in tcl versions 8.4 and 8.6, if the output has only #.


% info patch
8.4.13
% 
% set test {a "#"}
a "#"
% set testme [lrange $test 1 end]
#

% info patch
8.6.1
% set test2 {a "#"}
a "#"
% set testme [lrange $test2 1 end]
{#}


Is this an intentional change ? 
Most of our regression scripts are failing after upgrade to 8.6.1, as the regular expressions don't match, as lrange was earlier returning #, but after upgrade {#}


Regards,
Lucky
0
Lucky
6/30/2014 8:09:46 AM
comp.lang.tcl 23428 articles. 2 followers. Post Follow

3 Replies
923 Views

Similar Articles

[PageSpeed] 3

Lucky Y <ylucki@gmail.com> wrote:
> Hi,

> lrange works differently in tcl versions 8.4 and 8.6, if the output
> has only #.

> % info patch
> 8.4.13
> % 
> % set test {a "#"}
> a "#"
> % set testme [lrange $test 1 end]
> #

> % info patch
> 8.6.1
> % set test2 {a "#"}
> a "#"
> % set testme [lrange $test2 1 end]
> {#}


> Is this an intentional change ? 

Maybe, maybe not.  {#} is a valid string encoding of a list of one
element containing a # character.

> Most of our regression scripts are failing after upgrade to 8.6.1, as
> the regular expressions don't match, as lrange was earlier returning
> #, but after upgrade {#}

You've given us very little to go on to understand your true issue, but
it sounds like you were performing regular expression matching on the
string representation of a list, while relying on side effects of Tcl's
shimmering of lists to strings.

I.e., it sounds like you were doing something like this:

  regexp {#} [lrange $test2 1 end]

[lrange] returns a list, not a string, so you also had an implicit
list->string conversion before the regexp was executed.  That is where
you were relying on side effects of that conversion.  If you wanted to
perform regexp matching on lists, you should handle the conversion to
strings yourself (so you can control the output).  I.e., you should
have instead been doing this (even with 8.4) if you wanted space
separators:

  regexp {#} [join [lrange $test2 1 end]] 

Note that adding an explicit [join] fixes your 8.6 example:

% info patch
8.6.1
% set test2 {a "#"}
a "#"
% set testme [join [lrange $test2 1 end]]
#
0
Rich
6/30/2014 11:49:31 AM
On 30/06/2014 09:09, Lucky Y wrote:
> lrange works differently in tcl versions 8.4 and 8.6, if the output
> has only #.

The change was in 8.5, goes by the ID of TIP #148, is described at
http://tip.tcl.tk/148.html, and was specifically to the canonical
serialization of lists where the first character of the first word is a
“#”. The issue was that we had a long-standing guarantee(*) that [list]
would produce valid scripts such that:

     $a $b $c

would be the same as:

     eval [list $a $b $c]

It turned out that this promise, which had been around for a very long
time indeed, wasn't true if the value of $a started with a “#”. The
minimal fix was to alter the canonical serialization in this specific
case. It means that we can safely optimize the case of canonical lists
being evaluated so that reparsing is provably not necessary, which gives
a nice performance bonus (and is also definitely safe).

> Is this an intentional change ?

Entirely intentional.

> Most of our regression scripts are failing after upgrade to 8.6.1, as
> the regular expressions don't match, as lrange was earlier returning
> #, but after upgrade {#}

Sorry about that, but you'll have to update your test cases, as this was
a change that was made to fix a clear (but subtle) bug, a hole in the
definition of how lists were serialized. (Dictionaries use the same
logic, but there's formally no expectation of how they work in 8.4. :-))

Donal.
(* FYI, the guarantee is in the first edition of the Ousterhout book.)
-- 
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.
0
Donal
6/30/2014 1:27:54 PM
On Monday, June 30, 2014 6:57:54 PM UTC+5:30, Donal K. Fellows wrote:
> On 30/06/2014 09:09, Lucky Y wrote:
> 
> > lrange works differently in tcl versions 8.4 and 8.6, if the output
> 
> > has only #.
> 
> 
> 
> The change was in 8.5, goes by the ID of TIP #148, is described at
> 
> http://tip.tcl.tk/148.html, and was specifically to the canonical
> 
> serialization of lists where the first character of the first word is a
> 
> "#". The issue was that we had a long-standing guarantee(*) that [list]
> 
> would produce valid scripts such that:
> 
> 
> 
>      $a $b $c
> 
> 
> 
> would be the same as:
> 
> 
> 
>      eval [list $a $b $c]
> 
> 
> 
> It turned out that this promise, which had been around for a very long
> 
> time indeed, wasn't true if the value of $a started with a "#". The
> 
> minimal fix was to alter the canonical serialization in this specific
> 
> case. It means that we can safely optimize the case of canonical lists
> 
> being evaluated so that reparsing is provably not necessary, which gives
> 
> a nice performance bonus (and is also definitely safe).
> 
> 
> 
> > Is this an intentional change ?
> 
> 
> 
> Entirely intentional.
> 
> 
> 
> > Most of our regression scripts are failing after upgrade to 8.6.1, as
> 
> > the regular expressions don't match, as lrange was earlier returning
> 
> > #, but after upgrade {#}
> 
> 
> 
> Sorry about that, but you'll have to update your test cases, as this was
> 
> a change that was made to fix a clear (but subtle) bug, a hole in the
> 
> definition of how lists were serialized. (Dictionaries use the same
> 
> logic, but there's formally no expectation of how they work in 8.4. :-))
> 
> 
> 
> Donal.
> 
> (* FYI, the guarantee is in the first edition of the Ousterhout book.)
> 
> -- 
> 
> Donal Fellows -- Tcl user, Tcl maintainer, TIP editor.


Thanks for the detailed explanation, Rich and Donal.
Our framework is very ancient, and there are few holes like this.
[join [lrang]] has fixed the issue.

Thanks again for the quick help.

Regards,
Lucky
0
Lucky
7/1/2014 6:41:02 AM
Reply:

Similar Artilces:

Tcl 8.6 unexpected 'file exists'
I have a proc which takes a full path argument for a file. (one of the items returned from a glob) roughly: proc handlefile {path} { #puts stdout [file normalize $path] set fsize [file size $path] #...etc } Strangely... a particular file has problems with the above. The 'file size' call returns: could not read "/usr/local/xxx/www/yyy/Newsletter/050609/~ $sueme220509.htm" no such file or directory The 'file normalize' output is "/usr/local/virtual1/hosting/base/yy/ yyy/yyy/www/Newsletter/050609/~$sueme220509.htm" Both these paths are valid,...

Bug789040 came back in Tcl 8.4.6 and Tcl 8.5.
Dear All, Bug 789040 caused exec error in Windows 9x and was fixed in 10/04/03. But it came back in Tcl 8.4.6 and Tcl 8.5. Tcl Windows 9x users should be alerted to the possible failure of exec in the current Tcl 8.4.6 and 8.5 releases due to this bug. Chengye Mao http://www.geocities.com/~chengye Chengye Mao wrote: > Bug 789040 caused exec error in Windows 9x and was fixed in 10/04/03. > But it came back in Tcl 8.4.6 and Tcl 8.5. Tcl Windows 9x users > should be alerted to the possible failure of exec in the current Tcl > 8.4.6 and 8.5 releases due to this bug. Have you i...

4'8 ***Hot stuff
http://www.kaneva.com/checkout/stream.aspx?assetId=2017&free=0 ...

difference between tcl 8.4.2 & 8.4.4
% exec $env(COMSPEC) /c net config This command now fails on Tcl 8.4.4 What can I do instead? to run with either version of tcl and windows 98. "couldn't execute "C:\WINDOWS\COMMAND.COM": no such file or directory" Running on Win 98. Win XP is ok. Peter Campbell wrote: > % exec $env(COMSPEC) /c net config > > This command now fails on Tcl 8.4.4 > What can I do instead? to run with either version of tcl and windows 98. > > "couldn't execute "C:\WINDOWS\COMMAND.COM": no such file or directory" > > Running on Win 98...

package require Thread fails with error 'undefined symbol' on tcl 8.4.11
I've built tcl 8.4.11 with threads enabled on debian linux (kernel 2.6.8). I've also managed to build and install threads 2.6.2. However, when I started up tclsh and did a "package require Thread", I got the following error: couldn't load file "/opt/tcl-8.4.11/lib/thread2.6.2/libthread2.6.2.so": /opt/tcl-8.4.11/lib/thread2.6.2/libthread2.6.2.so: undefined symbol: Ns_TclDeAllocateInterp Here's my tcl installation details: % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = i686 tcl_platform(os) = Linux tcl_platfor...

Install tcl 8.4 error, Can't find a usable init.tcl in the following directories
I build tcl 8.4.10 on Solaris 8, compile ok, but get error when running "make test" I run: configure --prefix=/users/xucai --exec-prefix=/users/xucai --enable-shared --enable-gcc //ok make //ok make test // this step failed. and get following error: LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}; export LD_LIBRARY_PATH; \ TCL_LIBRARY="/users/xucai/src/tcl8.4.10/library"; export TCL_LIBRARY; \ ../tcltest ./../tests/all.tcl application-specific initialization failed: Can't find a usable init.tcl in the following directories: /users/xucai/src/tcl8.4.10/...

tcl 8.5/8.4 difference
Hi TCLers, I've found a strange behaviour in Tcl 8.5.7 and 8.5.5 (vs. 8.4.19) when working with Pgtcl (pgaccess.tcl). The effected code line is (after a successfull database select): pg_result $pgres -assign curr_tabs The variable $pgres contains the correct handle (e.g. "pgsql6.0"), but Tcl 8.5 crashes with the message: Tcl_SetIntObj called with shared object whereas Tcl 8.4 continues without any error. I know that it is hard to analyze this problem without code, examples, .... but maybe the error behaviour brings some 1st idea where to start the search. I will inv...

Question on migration from TCL 8.3 to TCL 8.6
Hi All, I am working on a EDA tool which is built on TCL 8.3 platform. I need to upgrade the platform to TCL 8.6. Is it proper to move directly from 8.3 to 8.6 version? Or should I upgrade to TCL 8.5 as TCL 8.6 is still beta version. Please suggest me precautions. Please point me to documentation/User guide related to this. Thanks for help, Divyesh On Thursday, 30 January 2014 04:47:57 UTC, Divyesh Patel wrote: > Is it proper to move directly from 8.3 to 8.6 version? Or should I upgrade to TCL 8.5 as TCL 8.6 is still beta version. > Tcl 8.6.1 is now the current ...

Re: '^=' and '~='? #8
32 libname erap 'T:\9SOW\AHRQ_E Rap\Data\E-RAP Data\December 2008'; NOTE: Libref ERAP was successfully assigned as follows: Engine: V9 Physical Name: T:\9SOW\AHRQ_E Rap\Data\E-RAP Data\December 2008 33 options nodate nonumber formdlim='-'; 34 /* Program: E-RAP Load XML to SAS with map v2.sas*/ 35 /************************************************************************* 36 Update path and file name below. 37 **************************************************************************/ 38 %let data_path = T:\9SOW\AHRQ_E Rap\Data\E-R...

=?utf-8?Q?BREAKING_NEWS_=E2=80=94=E2=80=94=3E_'ERASE_ISRAEL_?= =?utf-8?Q?FROM_INTERNET'__\__Israel_P.M._N?= =?utf-8?Q?etanyahu_Announces_Israel's_Plan?= =?utf-8?Q?_To_'WIPE'_Lebanon_From_The_Map?=
Two (2) Stories Below: 1. Israel P.M. Netanyahu Announces Israel's Plan To 'WIPE' Lebanon From The Map: ——> PRECIPITATE ARMAGEDDON <—— 2. 'Erase Israel From The Internet': Anonymous Plots Massive Cyber-Attack “ Yes, and it is not a secret that it will happen with U.S.-Gulf support and that is why they have been warned, but before you ask, you have a look at the new map of the world and see that there is no nation (Lebanon) with this name. ” ...

=?utf-8?Q?BREAKING_NEWS_=E2=80=94=E2=80=94=3E_'ERASE_ISRAEL_?= =?utf-8?Q?FROM_INTERNET'__\__Israel_P.M._N?= =?utf-8?Q?etanyahu_Announces_Israel's_Plan?= =?utf-8?Q?_To_'WIPE'_Lebanon_From_The_Map?=
Two (2) Stories Below: 1. Israel P.M. Netanyahu Announces Israel's Plan To 'WIPE' Lebanon From The Map: ——> PRECIPITATE ARMAGEDDON <—— 2. 'Erase Israel From The Internet': Anonymous Plots Massive Cyber-Attack “ Yes, and it is not a secret that it will happen with U.S.-Gulf support and that is why they have been warned, but before you ask, you have a look at the new map of the world and see that there is no nation (Lebanon) with this name. ” ...

=?utf-8?Q?BREAKING_NEWS_=E2=80=94=E2=80=94=3E_'ERASE_ISRAEL_?= =?utf-8?Q?FROM_INTERNET'__\__Israel_P.M._N?= =?utf-8?Q?etanyahu_Announces_Israel's_Plan?= =?utf-8?Q?_To_'WIPE'_Lebanon_From_The_Map?=
Two (2) Stories Below: 1. Israel P.M. Netanyahu Announces Israel's Plan To 'WIPE' Lebanon From The Map: ——> PRECIPITATE ARMAGEDDON <—— 2. 'Erase Israel From The Internet': Anonymous Plots Massive Cyber-Attack “ Yes, and it is not a secret that it will happen with U.S.-Gulf support and that is why they have been warned, but before you ask, you have a look at the new map of the world and see that there is no nation (Lebanon) with this name. ” ...

=?utf-8?Q?BREAKING_NEWS_=E2=80=94=E2=80=94=3E_'ERASE_ISRAEL_?= =?utf-8?Q?FROM_INTERNET'__\__Israel_P.M._N?= =?utf-8?Q?etanyahu_Announces_Israel's_Plan?= =?utf-8?Q?_To_'WIPE'_Lebanon_From_The_Map?=
Two (2) Stories Below: 1. Israel P.M. Netanyahu Announces Israel's Plan To 'WIPE' Lebanon From The Map: ——> PRECIPITATE ARMAGEDDON <—— 2. 'Erase Israel From The Internet': Anonymous Plots Massive Cyber-Attack “ Yes, and it is not a secret that it will happen with U.S.-Gulf support and that is why they have been warned, but before you ask, you have a look at the new map of the world and see that there is no nation (Lebanon) with this name. ” ...

My buttons look different since I've upgraded to 8.4.4 (from 8.0)
If you run this script under both tcl8.0 and tcl8.4.4, the button's border will look different: button .button -text "button" pack .button wm geometry . 100x100 .. config -bg #121212 ..button config -background #2a2a2a ..button config -highlightbackground #121212 ..button config -foreground #d5d5d5 ..button config -activeforeground #d5d5d5 ..button config -activebackground #5f5f5f Granted, these are really dark colors, but I still would expect to see some sort of shadow on the button in tcl8.4. Is there something I'm doing wrong? Is this a bug? Any help would be MUCH ...

Web resources about - 'lrange' differences in tcl 8.4 and 8.6 - comp.lang.tcl

Resources last updated: 1/26/2016 6:57:24 PM