f



Regular expressions, compilation & tcl 8.6...

Hi all,

Has anything changed noticeably in the cache Tcl uses for caching 
regular expressions?

I tried to verify a large set (thousands) of small & simple regular 
expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB 
or RAM. Is this expected?

(I remembered that the last N expression compilations were kept in 
memory...)

George

set patterns [<return a list of regexp patterns>]
## Ensure all patterns are valid!
foreach one $patterns {
   if {[catch {regexp $one {}} error]} {
     error "Invalid pattern: $one\n$error"
   }
}
0
petasis (1405)
11/12/2009 12:21:13 AM
comp.lang.tcl 23428 articles. 2 followers. Post Follow

7 Replies
602 Views

Similar Articles

[PageSpeed] 29

On Nov 12, 1:21=A0am, Georgios Petasis <peta...@iit.demokritos.gr>
wrote:
> Hi all,
>
> Has anything changed noticeably in the cache Tcl uses for caching
> regular expressions?
>
> I tried to verify a large set (thousands) of small & simple regular
> expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB
> or RAM. Is this expected?
>
> (I remembered that the last N expression compilations were kept in
> memory...)
>
> George
>
> set patterns [<return a list of regexp patterns>]
> ## Ensure all patterns are valid!
> foreach one $patterns {
> =A0 =A0if {[catch {regexp $one {}} error]} {
> =A0 =A0 =A0error "Invalid pattern: $one\n$error"
> =A0 =A0}

I don't know of a specific cache in the RE engine; however there's the
Tcl_Obj internal rep which plays the same role. Since the compiled
automaton is then attached to the pattern value, it "sticks" to each
element of $patterns, which survives well over the lifecycle of the
loop variable. To verify this theory, you can try two things:

  (1) unset $patterns and see the memory consumption drop
  (2) or, defeat the Tcl_Obj caching:

       if {[catch  {regexp [string range $one 0 end] {}} error]} {

     and see no more memory consumption than the list's storage.

-Alex

0
11/12/2009 1:13:05 AM
On 12 Nov, 00:21, Georgios Petasis <peta...@iit.demokritos.gr> wrote:
> Has anything changed noticeably in the cache Tcl uses for caching
> regular expressions?

Not for many years.

Tcl has two caches for compiled REs. There is a per-thread cache that
is indexed by the literal string form of the RE (I believe that holds
the last 20 compiled REs, but could be wrong) and compiled REs are
also cached in the internal representation of the values. If you put
all the REs in global variables (or use literal REs) and just use them
by reference then it will be those internal representation caches
which are used.

> I tried to verify a large set (thousands) of small & simple regular
> expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB
> or RAM. Is this expected?

Yes, that will trigger the building of all those internal
representations. Mostly that's a good strategy, but you've found the
case where it isn't. Congratulations.

Donal.
0
11/12/2009 9:36:34 AM
O/H Alexandre Ferrieux έγραψε:
> On Nov 12, 1:21 am, Georgios Petasis <peta...@iit.demokritos.gr>
> wrote:
>> Hi all,
>>
>> Has anything changed noticeably in the cache Tcl uses for caching
>> regular expressions?
>>
>> I tried to verify a large set (thousands) of small & simple regular
>> expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB
>> or RAM. Is this expected?
>>
>> (I remembered that the last N expression compilations were kept in
>> memory...)
>>
>> George
>>
>> set patterns [<return a list of regexp patterns>]
>> ## Ensure all patterns are valid!
>> foreach one $patterns {
>>    if {[catch {regexp $one {}} error]} {
>>      error "Invalid pattern: $one\n$error"
>>    }
> 
> I don't know of a specific cache in the RE engine; however there's the
> Tcl_Obj internal rep which plays the same role. Since the compiled
> automaton is then attached to the pattern value, it "sticks" to each
> element of $patterns, which survives well over the lifecycle of the
> loop variable. To verify this theory, you can try two things:
> 
>   (1) unset $patterns and see the memory consumption drop
>   (2) or, defeat the Tcl_Obj caching:
> 
>        if {[catch  {regexp [string range $one 0 end] {}} error]} {
> 
>      and see no more memory consumption than the list's storage.
> 
> -Alex
> 

Dear Alex,

Indeed this solves the problem (i.e. wish stabilises ~30MB no matter how 
many times I run the loop). But I cannot understand why.
There is a small cache per thread (as Donal also remembers), but the 
regular expressions are stored in the same variable. Since the string of 
the variable "one" changes, shouldn't the compiled regexp also be discarded?
Maybe there is a leak somewhere?

George
0
petasis (1405)
11/12/2009 12:01:06 PM
O/H Donal K. Fellows έγραψε:
> On 12 Nov, 00:21, Georgios Petasis <peta...@iit.demokritos.gr> wrote:
>> Has anything changed noticeably in the cache Tcl uses for caching
>> regular expressions?
> 
> Not for many years.
> 
> Tcl has two caches for compiled REs. There is a per-thread cache that
> is indexed by the literal string form of the RE (I believe that holds
> the last 20 compiled REs, but could be wrong) and compiled REs are
> also cached in the internal representation of the values. If you put
> all the REs in global variables (or use literal REs) and just use them
> by reference then it will be those internal representation caches
> which are used.
> 
>> I tried to verify a large set (thousands) of small & simple regular
>> expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB
>> or RAM. Is this expected?
> 
> Yes, that will trigger the building of all those internal
> representations. Mostly that's a good strategy, but you've found the
> case where it isn't. Congratulations.
> 
> Donal.

Dear Donal,

I am a little puzzled by this. Since the string of the variable changes 
with each loop to a new pattern, why is the old compilation of the 
regular expression kept?

George
0
petasis (1405)
11/12/2009 12:03:39 PM
O/H Georgios Petasis έγραψε:
> O/H Alexandre Ferrieux έγραψε:
>> On Nov 12, 1:21 am, Georgios Petasis <peta...@iit.demokritos.gr>
>> wrote:
>>> Hi all,
>>>
>>> Has anything changed noticeably in the cache Tcl uses for caching
>>> regular expressions?
>>>
>>> I tried to verify a large set (thousands) of small & simple regular
>>> expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB
>>> or RAM. Is this expected?
>>>
>>> (I remembered that the last N expression compilations were kept in
>>> memory...)
>>>
>>> George
>>>
>>> set patterns [<return a list of regexp patterns>]
>>> ## Ensure all patterns are valid!
>>> foreach one $patterns {
>>>    if {[catch {regexp $one {}} error]} {
>>>      error "Invalid pattern: $one\n$error"
>>>    }
>>
>> I don't know of a specific cache in the RE engine; however there's the
>> Tcl_Obj internal rep which plays the same role. Since the compiled
>> automaton is then attached to the pattern value, it "sticks" to each
>> element of $patterns, which survives well over the lifecycle of the
>> loop variable. To verify this theory, you can try two things:
>>
>>   (1) unset $patterns and see the memory consumption drop
>>   (2) or, defeat the Tcl_Obj caching:
>>
>>        if {[catch  {regexp [string range $one 0 end] {}} error]} {
>>
>>      and see no more memory consumption than the list's storage.
>>
>> -Alex
>>
> 
> Dear Alex,
> 
> Indeed this solves the problem (i.e. wish stabilises ~30MB no matter how 
> many times I run the loop). But I cannot understand why.
> There is a small cache per thread (as Donal also remembers), but the 
> regular expressions are stored in the same variable. Since the string of 
> the variable "one" changes, shouldn't the compiled regexp also be 
> discarded?
> Maybe there is a leak somewhere?
> 
> George

How stupid of me :D
Of course there in no leak, the regular expression objects are also 
referenced by the list object (they are the list elements!)...

George
0
petasis (1405)
11/12/2009 12:05:48 PM
O/H Georgios Petasis έγραψε:
> O/H Donal K. Fellows έγραψε:
>> On 12 Nov, 00:21, Georgios Petasis <peta...@iit.demokritos.gr> wrote:
>>> Has anything changed noticeably in the cache Tcl uses for caching
>>> regular expressions?
>>
>> Not for many years.
>>
>> Tcl has two caches for compiled REs. There is a per-thread cache that
>> is indexed by the literal string form of the RE (I believe that holds
>> the last 20 compiled REs, but could be wrong) and compiled REs are
>> also cached in the internal representation of the values. If you put
>> all the REs in global variables (or use literal REs) and just use them
>> by reference then it will be those internal representation caches
>> which are used.
>>
>>> I tried to verify a large set (thousands) of small & simple regular
>>> expressions, with "regexp $one {}" and Tcl resulted in occupying 800MB
>>> or RAM. Is this expected?
>>
>> Yes, that will trigger the building of all those internal
>> representations. Mostly that's a good strategy, but you've found the
>> case where it isn't. Congratulations.
>>
>> Donal.
> 
> Dear Donal,
> 
> I am a little puzzled by this. Since the string of the variable changes 
> with each loop to a new pattern, why is the old compilation of the 
> regular expression kept?
> 
> George

Dear Donal,

Forget the last e-mail. I understood that the patterns are also ref 
counted by the list object that holds all the patterns...
So, their internal representation (the compiled regexp) is cached as it 
is indexed...

George
0
petasis (1405)
11/12/2009 12:07:05 PM
On Nov 12, 1:05=C2=A0pm, Georgios Petasis <peta...@iit.demokritos.gr>
wrote:
> O/H Georgios Petasis =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
>
>
>
> > O/H Alexandre Ferrieux =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
> >> On Nov 12, 1:21 am, Georgios Petasis <peta...@iit.demokritos.gr>
> >> wrote:
> >>> Hi all,
>
> >>> Has anything changed noticeably in the cache Tcl uses for caching
> >>> regular expressions?
>
> >>> I tried to verify a large set (thousands) of small & simple regular
> >>> expressions, with "regexp $one {}" and Tcl resulted in occupying 800M=
B
> >>> or RAM. Is this expected?
>
> >>> (I remembered that the last N expression compilations were kept in
> >>> memory...)
>
> >>> George
>
> >>> set patterns [<return a list of regexp patterns>]
> >>> ## Ensure all patterns are valid!
> >>> foreach one $patterns {
> >>> =C2=A0 =C2=A0if {[catch {regexp $one {}} error]} {
> >>> =C2=A0 =C2=A0 =C2=A0error "Invalid pattern: $one\n$error"
> >>> =C2=A0 =C2=A0}
>
> >> I don't know of a specific cache in the RE engine; however there's the
> >> Tcl_Obj internal rep which plays the same role. Since the compiled
> >> automaton is then attached to the pattern value, it "sticks" to each
> >> element of $patterns, which survives well over the lifecycle of the
> >> loop variable. To verify this theory, you can try two things:
>
> >> =C2=A0 (1) unset $patterns and see the memory consumption drop
> >> =C2=A0 (2) or, defeat the Tcl_Obj caching:
>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0if {[catch =C2=A0{regexp [string range $one=
 0 end] {}} error]} {
>
> >> =C2=A0 =C2=A0 =C2=A0and see no more memory consumption than the list's=
 storage.
>
> >> -Alex
>
> > Dear Alex,
>
> > Indeed this solves the problem (i.e. wish stabilises ~30MB no matter ho=
w
> > many times I run the loop). But I cannot understand why.
> > There is a small cache per thread (as Donal also remembers), but the
> > regular expressions are stored in the same variable. Since the string o=
f
> > the variable "one" changes, shouldn't the compiled regexp also be
> > discarded?
> > Maybe there is a leak somewhere?
>
> > George
>
> How stupid of me :D
> Of course there in no leak, the regular expression objects are also
> referenced by the list object (they are the list elements!)...

No it's my fault. I miserably failed to convey that meaning with
"element of $patterns, which survives well over the lifecycle of the
loop variable"...

-Alex
0
11/12/2009 12:43:40 PM
Reply:

Similar Artilces:

Tcl 8.6, ActiveTcl 8.6 & linux Fedora 16 (64 bit)...
Hi all, Just a quick note about installing ActiveTcl 8.6 under Fedora 16, 64 bit. Downloading ActiveTcl 8.6 and trying to run the installer, fails. The reason is that libXss.so, is missing from the system, and Tk seems to need this. The problem can be "resolved" by installing the package "libXScrnSaver". But there is no such package for Fedora 16, and (thankfully) the package gets installed from Fedora 15. Maybe this is a "sign" that libXss.so will disappear in the (near?) future... George PS: Also the mysql TDBC driver crashes, as the shared library has evolved to version 18 (and the sources try to load versions 15 & 16). Changing the sources to also load .18 fixes the problem. (But I would prefer an error message than a core dump...) ...

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...

tcl 8.6.4
Hi, Using 8.3.0, compiled on AIX 6.1 with no problems. It compiles with the xlc= compiler. But when I try to build tcl 8.6.4, I notice some changes. Configure uses xl= c_r rather than xlc. But the difference that causes a problem is setting TC= L_LIBRARY snd TCL_PACKAGE_PATH.tclUnixInit.c is the only file that uses the= se extra variables in make and I get the following errors. xlcwrapper_r -c -DNDEBUG -O -DBUILD_tcl -I"." -I/tmp/xxxxxx/tcl8.6.4/un= ix -I/tmp/xxxxxx/tcl8.6.4/generic -I/tmp/xxxxxx/tcl8.6.4/libtommath -DPACK= AGE_NAME=3D\"tcl\" -DPACKAGE_TARN...

Tcl 8.6 & IncrTcl...
Hi all, It seems that Tcl 8.6 & Itcl do not cooperate any more, so I am puzzled whether applications that use Itcl are upgradable to Tcl 8.6 :-( A few months ago I have posted a few stack traces of tclsh crashing, despite the fact that I couldn't get a simple script to reproduce the problem. I just tested ActiveTcl 8.6.b2 and the bug is still there. But today I got a different crash: set WubHome E:/Tcl/wub/Wub lappend auto_path $WubHome package require Itcl ;# Itcl adds object-oriented facilities to Tcl. package require Site ;# The Wub HTTP server package. package require Nub ;# Thw Wub Domains package. itcl::class BlogProcessor { proc / {r args} { set content [Html::dict2json $r] dict set r -content $content dict set r content-type x-text/html-fragment return $r };# / };# class BlogProcessor Site init home $WubHome ini site.ini # Register domains... Nub domain /blog/ Direct namespace BlogProcessor # Start Site Server(s) Site start I know that I tried to use an Itcl namespace as a normal namespace (i.e. as expected by "Nub domain", but again tclsh crashes instead of returning an error. So, if we have to drop Itcl, what is the OO extension of nowadays? George Georgios Petasis wrote: > A few months ago I have posted a few stack traces of tclsh crashing, > despite the fact that I couldn't get a simple script to reproduce the > problem. I just tested ActiveTcl 8.6.b2 and the bug is still the...

Tcl 8.5 & Vim's Tcl interface
[Pardon the leading period, but I'm hoping the indenting is preserved to make reading easier] .. I wanted Vim on windows (x64) that was compiled with Vim's .. Tcl interface. All went fairly well, I was able to build .. Vim using window's SDK command line compiler for x64, and I .. linked against ActiveState's Tcl 8.5.11.0 for x64 using .. tclstub85.lib to allow dynamic loading of the Tcl DLL. .. .. [As an aside, I'm hoping to convince Vim's maintainer to .. build the release version of Vim containing support for all .. the language interfaces since only an error message would .. occur if the respective DLL was not found. It appears that .. the Vim maintainer last checked building against 8.4] .. .. The Tcl interface works for a simple ":tcl puts Hello" but .. when I tried anything more I get the error: .. .. wrong # args: should be "catch command ?varName?" .. .. This is because Vim creates a replacement "catch" command .. (I've attached the relevant code below. As the comments .. state, Vim needs to prevent exit() being called by Tcl. Tcl .. 8.5 has introduced a new "catch" command that takes an .. additional argument, and somewhere -- either the Tcl .. library or tcl85.dll -- uses catch with four arguments. I .. don't have 8.5's source but I see that auto.tcl, clock.tcl, .. init.tcl, (I stopped looking) all use the four-argument catch. .. .. So here's my question: what's the best way this...

Tcl 8.4.x & tcl-dp 4.0.x
Has anyone built tcl-dp 4.0.x on windows against Tcl 8.4.x ? Is it possible to get the windows dll and the source code with modifications? ...

How to compile tcl or encrypt tcl
I use TclPro1.5 to compile my tcl script with tixwish in the Solaris before. But I cannot use the same method in Linux. Why? Is there any utility for me to compile or encrypt the code by using tixwish? The following is the simple code if I use the tixwish: #!/home/albertl/local/bin/tixwish puts "haha" And after using procomp by the TclPro1.5 Error in startup script: The TclPro ByteCode Loader is not available or does not support the correct version while executing "error "The TclPro ByteCode Loader is not available or does not support the correct version""...

Binary reader speed comparison
I have a fairly simple binary reader proc that exhibits massive speed differences between Tcl 8.5.8 and Tcl8.6b1.1. Here's the proc: proc readFormatted {filename} { set fd [ open $filename r ] fconfigure $fd -encoding binary -translation binary binary scan [ read $fd 2 ] cc type nextlen if {$type != 75} { return -error "File is not in the expected format" } while {![append buffer [read $fd $nextlen] ; eof $fd]} { binary scan [read $fd 2] cc lastlen nextlen # convert to unsigned value set nextlen ...

can you run e commerce site using just tcl 8.6.2 and a pure tcl webserver?
and have decent performance? ...

Tcl OO mixins and inheritence behaviour change from version 8.6.2 to version 8.6.3
Hi, it seems that implementation of object oriented functionality in tcl8.6.3 changed in a away that breaks my existing code. My test code looks like this: oo::class create MixinClass { method helloWorld {args} { puts "[self class]" catch { next } } } oo::class create BaseClass { mixin MixinClass method helloWorld {args} { puts "[self class]" catch { next } } } oo::class create TargetClass { superclass BaseClass method helloWorld {args} { puts "[self class]" catch { next } } }...

Tcl 8.4.6 Source
Tried compiling 8.4.6 under Windows SFU. Make failed with: .../generic/tclClock.c: In function `FormatClock': .../generic/tclClock.c:314: error: `timezone' undeclared (first use in this funct ion) I know SFU is unsupported but is there anything obvious I missed? Compiled 8.4.5 with Mingw on a different machine and that worked find. However Mingw is not acceptable to Corporate Employer where as SFU is because it's fully supported by Microsoft. Details on SFU at http://www.microsoft.com/windows/sfu/default.asp. Last question - will Expect run under unix emulation on Windows?...

regsub in tcl 8.5 and 8.6
parse this row set a "123(qwe)" in tcl 8.6 # regsub -all "\\(.*" $a "" 123qwe) in tcl 8.5 # regsub -all "\\(.*" $a "" 123 What to do ? Thank you for the report. Confirmed with 8.5.16 and 8.6.2 Aparently, 8.6 is not as greedy as 8.5. I don't know if this is a bug or a feature. Could you please register a bug report at: core.tcl.tk/tcl -> Login as anonymous -> New ticket The most important people don't read clt but read bug reports... Thank you, Harald 0L/QvtC90LXQtNC10LvRjNC90LjQuiwgOCDRgdC10L3RgtG...

compiling Snack 2.2.10 vs tcl 8.6.1
I'm trying to compile snack 2.2.10 against tcl 8.6.1 on Windows 7 with Visual Studio 2010. Snack has the following in some .h #if TCL_MAJOR_VERSION == 8 && TCL_MINOR_VERSION < 4 #define TCL_SEEK Tcl_Seek #define TCL_TELL Tcl_Tell #else #define TCL_SEEK Tcl_SeekOld #define TCL_TELL Tcl_TellOld #endif and then uses TCL_SEEK(...) and TCL_TELL(...) in the C Code. Now linking the DLL fails with two unresolved externals, Tcl_SeekOld() and Tcl_TellOld(). (Linking against tcl 8.5.15 is fine). Yes, the *Old() functions are deprecated, b...

Can Tcl 8.6 be compile on VS 2010, 2012, 2013 or 2015 ?
Hi everyone, For some reason I am considering upgrading my VS 2005 to 2010, 2012, 2013 or 2015. Can Tcl 8.6 be compile on VS 2010, 2012, 2013 or 2015 ? I know now it is difficult to find 2010, 2012 and 2013 already. But there are still some 2012, 2013 packages around. Thanks for you help. Regards Chen Am 11.03.2016 um 07:38 schrieb S-Y. Chen: > Hi everyone, > > For some reason I am considering upgrading my VS 2005 to 2010, 2012, 2013 or 2015. Can Tcl 8.6 be compile on VS 2010, 2012, 2013 or 2015 ? > > I know now it is difficult to find 2010, 2012 and 2013 already. But there are still some 2012, 2013 packages around. > > Thanks for you help. > > Regards > Chen > AFAIk no problem. You may get issues with DLLs loaded by TCL but normally this should just work out of the box. -Harald --- news://freenews.netfront.net/ - complaints: news@netfront.net --- * "S-Y. Chen" <shenyeh_chen@hotmail.com> | Can Tcl 8.6 be compile on VS 2010, 2012, 2013 or 2015 ? VS 2013: definitely yes using MINGW/configure combo with bash as /bin/sh, but we also have used the makefile.vc on earlier releases with 2012 and 2013. HTH R' ...

Tcl 8.4.6 compilation issue with cygwin 1.5.11-1
Hi, I'm getting this compiler error, while compiling Tcl sh 8.4.6 with cygwin. Can someone help me with this. gcc -c -g -O -Wall -Wconversion -I"./../generic" -I"." -DBUILD_tcl -mno-cygwin "tclWin32Dll.c" -o tclWin32Dll.obj tclWin32Dll.c:58: error: initializer element is not constant tclWin32Dll.c:58: error: (near initialization for `asciiProcs.buildCommDCBProc') tclWin32Dll.c:59: error: initializer element is not constant tclWin32Dll.c:59: error: (near initialization for `asciiProcs.charLowerProc') tclWin32Dll.c:60: error: initializer element...

Tcl 8,5 tutorial errata on page "More Examples Of Regular Expressions"
Hi, In the Tcl 8.5 tutorial, a page titled "More Examples Of Regular Expressions" may contain errata in the following Tcl code: " set string "Again and again and again ..." if { [regexp {(\y\w+\y).+\1} $string => word] } { puts "The word $word occurs at least twice" } " You can see that the command 'regexp' sets a value into a variable called '=>'. This can be proved by executing the following code: " set string "Again and again and again ..." if { [regexp {(\y\w+\y).+\1} $string => word] } { puts "The word $word occurs at least twice" } upvar #0 "=>" x puts "$x" " I guess that the author meant to write something else? It doesn't make sense to have a variable named "=>". Here's a link to the relevant page in the tutorial: http://www.tcl.tk/man/tcl8.5/tutorial/Tcl20a.html Thank you. On Tuesday, 12 November 2013 08:43:08 UTC+11, dor...@gmail.com wrote: > Hi, >=20 >=20 >=20 > In the Tcl 8.5 tutorial, a page titled "More Examples Of Regular Expressi= ons" may contain errata in the following Tcl code: >=20 >=20 >=20 > " >=20 >=20 >=20 > set string "Again and again and again ..." >=20 > if { [regexp {(\y\w+\y).+\1} $string =3D> word] } { >=20 > puts "The word $word occurs at least twic...

TCL is not thread safer in TCL 8.3 or 8.4... Any plans to fix this?
It is a shame that I can't upgrade one of my applications due to this problem, though the memory leaks also intorduced in 8.3 and 8.4 are problem as well. :( I have a process that spawn a configurable number of thread with a TCL intrepeter in each one. The interps are isolated and do not communicate or share anything withe each other. Each thread is a rule processor that is handed TCL scripts based on what events occurs within a multi process enviroment rnaing across the whole itnerprize... Works great with TCL 8.2, not a single problem... But with TCL 8.3 and TCL 8.4 we get quite a f...

Tcl 8.6
Hi folks! Funny question, but when Tcl 8.6 will finally released? On 5/10/11 9:24 AM, Alexander Nusov wrote: > Hi folks! > > Funny question, but when Tcl 8.6 will finally released? Tcl release are kind of like hush puppies -- they come out when they are done. -- +------------------------------------------------------------------------+ | Gerald W. Lester, President, KNG Consulting LLC | | Email: Gerald.Lester@kng-consulting.net | +------------------------------------------------------------------------+ On May 10, 10:24=A0am, Alexander Nusov <alexander.nu...@gmail.com> wrote: > Hi folks! > > Funny question, but when Tcl 8.6 will finally released? Unfortunately, it appears to me that all previous attempts to establish a date seem to have been unsuccessful. The more of the outstanding serious bugs that get resolved before the release date, the better, right? ...

Compatibility issues of Tcl/Tk 8.6 with windows 8...
Hi all, I am facing a strange compatibility issue between tcl/tk 8.6 and the windows 8 (at least the 64 bit version) operating system. The problem as observed from the user point of view is a general "sluggishness", the application is slow and painful to use. Timing various actions, I have found that there are unexplained delays from 1,5 to 3 seconds inserted between successive tcl commands, most around calling tcloo methods from outside the object. For example, I have a tcloo class, which builds some part of a GUI. From inside a method, I create a button: ttk::button $client_area.annotate -textvariable [my msgVar Annotate] \ -command "puts \"[clock format [clock seconds]]\" ; [self] onAnnotate" This class has an "onAnnotate" method (which the button command calls): method onAnnotate {} { puts "[clock format [clock seconds]]: =============== onAnnotate" ... } When I run the application, there is *always* a time delay of 1-3 seconds inserted between the first puts statement, and the second puts, which is the first command of method onAnnotate: Mon May 27 19:56:59 EEST 2013 Mon May 27 19:58:22 EEST 2013: =============== onAnnotate Mon May 27 19:56:59 EEST 2013 Mon May 27 19:58:54 EEST 2013: =============== onAnnotate However, this happens when I run the application under windows 8. Under windows 7, I don't see this delay, everything is much much faster ...

Incr Tcl /Tk for Tcl 8.4
Hi, I am trying to download incr Tcl and incr Tk for Tcl/Tk 8.4.19. I looked at: http://sourceforge.net/projects/incrtcl/files/%5BIncr%20Tcl_Tk%5D-source/3.4.1/ But only itcl seems to be there. And the CVS doesn't have the 3.4.1 tag. Do you know where I can get incr Tk and hopefully a corresponding iwidgets? Thanks, Andres On 5 Okt., 11:16, Andres Garcia <tclc...@gmail.com> wrote: > Hi, > > I am trying to download incr Tcl and incr Tk for Tcl/Tk 8.4.19. > > I looked at: > > http://sourceforge.net/projects/incrtcl/files/%5BIncr%20Tcl_Tk%5D-sou... > > But only itcl seems to be there. And the CVS doesn't have the 3.4.1 > tag. There is no tag for this version. But you can use a date. cvs -d :pserver:anonymous@incrtcl.cvs.sourceforge.net:/cvsroot/incrtcl -z3 co -P -D 2010-10-28 incrTcl > > Do you know where I can get incr Tk and hopefully a corresponding > iwidgets? Itk is inside itcl sources. cvs -d :pserver:anonymous@incrtcl.cvs.sourceforge.net:/cvsroot/incrtcl -z3 co -P -D 2010-10-28 iwidgets HTH rene Thanks. Andres >> I am trying to download incr Tcl and incr Tk for Tcl/Tk 8.4.19. >> >> I looked at: >> >> http://sourceforge.net/projects/incrtcl/files/%5BIncr%20Tcl_Tk%5D-sou... >> >> But only itcl seems to be there. And the CVS doesn't have the 3.4.1 >> tag. The released sources for Itcl 3.4.1 were not developed in SF CVS. SF CVS got abandoned during the January...

Official Windows compiler for Tcl 8.5 (or what compiler to use for extensions)?
Are the "official" builds for Tcl 8.5 going to stick to VC++ 6.0 or move to newer versions of the compiler? I'm asking because if I want to ship a C++ DLL extension that is compatible with the official 8.4 and 8.5 binaries, do I need to worry about the compiler being used and whether the main Tcl shell and my extension land up using different C runtimes? If I'm careful about memory alloc/dealloc from the correct heap, can I assume the compiler is immaterial or are there other issues (e.g. exception handling runtime) I would need to take care of? Thanks in advance /Ashok ...

'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 Lucky Y <ylucki@gmail.com> wrote: > Hi, >...

[ANN] Registration open && 2nd Call For Papers
Hello comp.lang.tcl, fyi ... 22nd Annual Tcl/Tk Conference (Tcl'2015) http://www.tcl.tk/community/tcl2015/ October 19 - 23, 2015 Comfort Suites Manassas 7350 Williamson Blvd, 20109 Manassas, Virginia, USA Important Dates: [[ Attention! Registration is open! Please have a look at http://www.tcl.tk/community/tcl2015/register.html ]] Abstracts and proposals due August 24, 2015 Notification to authors August 31, 2015 WIP and BOF reservations open July 27, 2015 Author materials due September 28, 2015 Tutorials Start October 19, 2015 Co...

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...

Web resources about - Regular expressions, compilation & tcl 8.6... - comp.lang.tcl

Expression (sign language) - Wikipedia, the free encyclopedia
Signs with two different expressions. The pursed lips and partly closed eyes on the left, and raised lip on the right, are necessary for proper ...

Turkey setting ‘poor example’ for freedom of expression: Biden
Turkey setting ‘poor example’ for freedom of expression: Biden

Christie’s Expressions At Trump Event Under Scrutiny
Donald Trump Holds Super Tuesday Election Night Press Conf. In Palm Beach PALM BEACH, FL - MARCH 01: Republican Presidential frontrunner Donald ...

Facial Expressions and Tail Expressions
Submitted by: (via Daniel J Farrell ) Tagged: dogs , face , expression , tail , wag Share on Facebook

US: Joe Biden slams Turkey for ‘poor example’ of freedom of expression
US Vice President Joe Biden has criticised Turkey for “setting a poor example” in the region concerning freedom of expression. The damning comments ...

Decoding The Facial Expressions Of The GOP Candidates
Trump's "crooked contemptuous" smile, Rubio's sheepish grin, and Cruz's upper lip of disgust dominated the debate. For tonight's Republican ...

You enjoy freedom of expression only because army guards borders: Delhi HC to Kanhaiya Kumar
The bail granted to Kanhaiya Kumar comes with several conditions, directives to JNU faculty and some serious observations

Bernie Sanders Brought His Finest Facial Expressions to the Democratic Debate
You may not like Bernie Sanders as a presidential candidate, but you’ve gotta admit, this man’s got some pretty expressive peepers. Read more... ...

Crosswords Help You Learn Regular Expressions
Regular expressions might seem arcane, but if you do any kind of software, they are a powerful hacker tool. Obviously, if you are writing software ...

Security, the Greatest Threat to Free Expression?
Like it or not, today we are all, in one way or another, engaged in a battle between perceived security and freedom of expression. And far too ...

Resources last updated: 3/13/2016 11:10:32 AM