You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(19) |
Jul
(96) |
Aug
(144) |
Sep
(222) |
Oct
(496) |
Nov
(171) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(4) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(52) |
Aug
(47) |
Sep
(47) |
Oct
(95) |
Nov
(56) |
Dec
(34) |
2003 |
Jan
(99) |
Feb
(116) |
Mar
(125) |
Apr
(99) |
May
(123) |
Jun
(69) |
Jul
(110) |
Aug
(130) |
Sep
(289) |
Oct
(211) |
Nov
(98) |
Dec
(140) |
2004 |
Jan
(85) |
Feb
(87) |
Mar
(342) |
Apr
(125) |
May
(101) |
Jun
(60) |
Jul
(151) |
Aug
(118) |
Sep
(162) |
Oct
(117) |
Nov
(125) |
Dec
(95) |
2005 |
Jan
(141) |
Feb
(54) |
Mar
(79) |
Apr
(83) |
May
(74) |
Jun
(125) |
Jul
(63) |
Aug
(89) |
Sep
(130) |
Oct
(89) |
Nov
(34) |
Dec
(39) |
2006 |
Jan
(98) |
Feb
(62) |
Mar
(56) |
Apr
(94) |
May
(169) |
Jun
(41) |
Jul
(34) |
Aug
(35) |
Sep
(132) |
Oct
(722) |
Nov
(381) |
Dec
(36) |
2007 |
Jan
(34) |
Feb
(174) |
Mar
(15) |
Apr
(35) |
May
(74) |
Jun
(15) |
Jul
(8) |
Aug
(18) |
Sep
(39) |
Oct
(125) |
Nov
(89) |
Dec
(129) |
2008 |
Jan
(176) |
Feb
(91) |
Mar
(69) |
Apr
(178) |
May
(310) |
Jun
(434) |
Jul
(171) |
Aug
(73) |
Sep
(187) |
Oct
(132) |
Nov
(259) |
Dec
(292) |
2009 |
Jan
(27) |
Feb
(54) |
Mar
(35) |
Apr
(54) |
May
(93) |
Jun
(10) |
Jul
(36) |
Aug
(36) |
Sep
(93) |
Oct
(52) |
Nov
(45) |
Dec
(74) |
2010 |
Jan
(20) |
Feb
(120) |
Mar
(165) |
Apr
(101) |
May
(56) |
Jun
(12) |
Jul
(73) |
Aug
(306) |
Sep
(154) |
Oct
(82) |
Nov
(63) |
Dec
(42) |
2011 |
Jan
(176) |
Feb
(86) |
Mar
(199) |
Apr
(86) |
May
(237) |
Jun
(50) |
Jul
(26) |
Aug
(56) |
Sep
(42) |
Oct
(62) |
Nov
(62) |
Dec
(52) |
2012 |
Jan
(35) |
Feb
(33) |
Mar
(128) |
Apr
(152) |
May
(133) |
Jun
(21) |
Jul
(74) |
Aug
(423) |
Sep
(165) |
Oct
(129) |
Nov
(387) |
Dec
(276) |
2013 |
Jan
(105) |
Feb
(30) |
Mar
(130) |
Apr
(42) |
May
(60) |
Jun
(79) |
Jul
(101) |
Aug
(46) |
Sep
(81) |
Oct
(14) |
Nov
(43) |
Dec
(4) |
2014 |
Jan
(25) |
Feb
(32) |
Mar
(30) |
Apr
(80) |
May
(42) |
Jun
(23) |
Jul
(68) |
Aug
(127) |
Sep
(112) |
Oct
(72) |
Nov
(29) |
Dec
(69) |
2015 |
Jan
(35) |
Feb
(49) |
Mar
(95) |
Apr
(10) |
May
(70) |
Jun
(64) |
Jul
(93) |
Aug
(85) |
Sep
(43) |
Oct
(38) |
Nov
(124) |
Dec
(29) |
2016 |
Jan
(253) |
Feb
(181) |
Mar
(132) |
Apr
(419) |
May
(68) |
Jun
(90) |
Jul
(52) |
Aug
(142) |
Sep
(131) |
Oct
(80) |
Nov
(84) |
Dec
(192) |
2017 |
Jan
(329) |
Feb
(842) |
Mar
(248) |
Apr
(85) |
May
(247) |
Jun
(186) |
Jul
(37) |
Aug
(73) |
Sep
(98) |
Oct
(108) |
Nov
(143) |
Dec
(143) |
2018 |
Jan
(155) |
Feb
(139) |
Mar
(72) |
Apr
(112) |
May
(82) |
Jun
(119) |
Jul
(24) |
Aug
(33) |
Sep
(179) |
Oct
(295) |
Nov
(111) |
Dec
(34) |
2019 |
Jan
(20) |
Feb
(29) |
Mar
(49) |
Apr
(89) |
May
(185) |
Jun
(131) |
Jul
(9) |
Aug
(59) |
Sep
(30) |
Oct
(44) |
Nov
(118) |
Dec
(53) |
2020 |
Jan
(70) |
Feb
(108) |
Mar
(50) |
Apr
(9) |
May
(70) |
Jun
(24) |
Jul
(103) |
Aug
(82) |
Sep
(132) |
Oct
(119) |
Nov
(174) |
Dec
(169) |
2021 |
Jan
(75) |
Feb
(51) |
Mar
(76) |
Apr
(73) |
May
(53) |
Jun
(120) |
Jul
(114) |
Aug
(73) |
Sep
(70) |
Oct
(18) |
Nov
(26) |
Dec
|
2022 |
Jan
(26) |
Feb
(63) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(74) |
Jul
(129) |
Aug
(106) |
Sep
(238) |
Oct
(169) |
Nov
(149) |
Dec
(111) |
2023 |
Jan
(110) |
Feb
(47) |
Mar
(82) |
Apr
(106) |
May
(168) |
Jun
(101) |
Jul
(155) |
Aug
(35) |
Sep
(51) |
Oct
(55) |
Nov
(134) |
Dec
(202) |
2024 |
Jan
(103) |
Feb
(129) |
Mar
(154) |
Apr
(89) |
May
(60) |
Jun
(162) |
Jul
(201) |
Aug
(61) |
Sep
(101) |
Oct
|
Nov
|
Dec
|
From: Vasiljevic Z. <zv...@ar...> - 2007-12-05 10:28:01
|
On Dec 5, 2007, at 11:22 AM, Twylite wrote: > Is there any plan to release an updated Threads at the same time? > Threads doesn't currently build under MSVC8 (or test under Win32); I > have submitted a bug report and patch (#1835061) but it doesn't seem > to > have made it into CVS yet. Sorry for this. I'm pretty short on time lately. I will see what I can do... Zoran |
From: Twylite <tw...@cr...> - 2007-12-05 10:23:40
|
Hi, I have built Tcl 8.5.0rc1 on Windows 2000 with MSVC6 and MSVC8 (VC++ 2005 Express). Both builds were successful, but both fail the following test: ==== stack-1.1 maxNestingDepth reached on infinite recursion FAILED ==== Contents of test case: # do this in a sub process in case it segfaults exec [interpreter] << { proc recurse {} { recurse } catch { recurse } rv puts $rv } ---- Result was: out of stack space (infinite loop?) ---- Result should have been (exact matching): too many nested evaluations (infinite loop?) ==== stack-1.1 FAILED I didn't see this failure with 8.5b2, and I haven't build 8.5b3. I also get an error trying to build the winhelp docs: -- nmake /nologo /f makefile.vc winhelp OPTS==threads,symbols,unchecked (...snip...) Pass 1 -- ../doc/OpenTcp.3 Pass 1 -- ../doc/Panic.3 Pass 1 -- ../doc/ParseCmd.3 wrong # args: should be "text string" in wrong # args: should be "text string" while executing "text \u0022text '" ("eval" body line 513) invoked from within "eval [exec $man2tclprog [glob $file]]" NMAKE : fatal error U1077: '.\Debug\tclsh85t.exe' : return code '0x1' Stop. -- Again, this problem was not present in 8.5b2. I'll bypass it in my build script for now and go on with building & testing Tk. Is there any plan to release an updated Threads at the same time? Threads doesn't currently build under MSVC8 (or test under Win32); I have submitted a bug report and patch (#1835061) but it doesn't seem to have made it into CVS yet. Regards, Twylite > Subject: [TCLCORE] Countdown to Tcl/Tk 8.5.0 releases... > > Available on the Tcl ftp site are the latest RCs for Tcl/Tk 8.5.0: > > ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc1-src.tar.gz > ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.0rc1-src.tar.gz > ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc1-html.tar.gz > > |
From: Donald G P. <dg...@ni...> - 2007-12-04 19:26:58
|
Available on the Tcl ftp site are the latest RCs for Tcl/Tk 8.5.0: ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc1-src.tar.gz ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.0rc1-src.tar.gz ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc1-html.tar.gz The target date for final release is Friday, Dec. 14. I would like to make an RC on Wednesday, Dec. 12 with the intent that it becomes 8.5.0 on Friday via a simple rename after a round of smoke testing. Please plan your development with that in mind. There may or may not be another RC between the current one and the one on Dec. 12, depending on the amount and significance of HEAD churn. It would help me a bit for those folks still planning significant commits to give me an idea about what they might be and when they might appear on the HEAD. Finally, a last round of GOOBE that should be prepared is something not in the release itself, but associated resources, notably pages like: http://www.tcl.tk/software/tcltk/ http://www.tcl.tk/software/tcltk/choose.html http://www.tcl.tk/software/tcltk/8.5.html which should be significantly updated to change our recommendation to use 8.5 over 8.4 as the stable release, and which might profit from an expanded introduction to / cheering for new 8.5 features, either directly or by reference. Does anyone already have text, etc. in the works for that? -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Jeff H. <je...@ac...> - 2007-11-27 19:32:36
|
Donald G Porter wrote: > The first set of release candidates for Tcl/Tk 8.5.0 are available now: > > ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc0-src.tar.gz > ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.0rc0-src.tar.gz > > These contain significant changes even since 8.5b3 that ought to get > some testing. > > In addition, it is helpful to test some thing that actually labels > itself "8.5.0" before the real 8.5.0 releases, so those scripts that > act differently based on what version Tcl/Tk claim to be get tested > too. While the binaries still say 8.5b3, ActiveTcl 8.5.0 Beta 11 is now available based on pretty much the same sources. You can get it at: http://www.activestate.com/Products/activetcl/beta_download.plex Jeff |
From: Donald G P. <dg...@ni...> - 2007-11-26 21:52:29
|
The first set of release candidates for Tcl/Tk 8.5.0 are available now: ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.0rc0-src.tar.gz ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.0rc0-src.tar.gz These contain significant changes even since 8.5b3 that ought to get some testing. In addition, it is helpful to test some thing that actually labels itself "8.5.0" before the real 8.5.0 releases, so those scripts that act differently based on what version Tcl/Tk claim to be get tested too. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Alexandre F. <ale...@gm...> - 2007-11-26 17:58:06
|
After a rich discussion on this not-so-exciting subject, what's the status ? Why not re-vote ? If it stays in for 8.5 final, we'll have for centuries to come a "legacy" option, which has never existed before, and which will stop being useful as soon as the 2>@stderr bug is fixed. -Alex |
From: Alexandre F. <ale...@gm...> - 2007-11-24 17:38:26
|
Thanks. In case someone else goes through the same interrogations, here is the key, genially provided by miguel: arrays and dicts are not the sole clients of the Tcl_HashEntry. So it makes sense to keep the union. So my question was stupid, after all. But not the answer ! -Alex |
From: Kevin K. <ke...@ac...> - 2007-11-23 23:17:27
|
I have posted revision 1.7 of TIP #308 to http://tip.tcl.tk/308. This is a major version change with considerable new and modified functionality. Chief changes from the initial version: 2007-11-23 Expanded transaction management to have both the transaction command and explicit transaction boundaries. Added transaction isolation levels. Added lists as an alternative to dicts as a representation of rows in result sets. Added a side interface for retrieving the set of column names in the convenience procedures. Simplified introspection to return lists instead of result sets Added batch processing. Added asynchronous query processing. Added an interface for stored procedures. Added a discussion of returning refcursors. 2007-11-16 Changed the transaction management API from explicit commit and rollback to a model where a script is executed as an atomic operation. Changed the "execute" API and the convenience procedures that use it to accept an optional dictionary containing substituents, so the substituents need not pollute the local namespace. The version accepting variables is still provided, because it is useful in the case of static queries where the substitutions follow a predetermined pattern. Added reference to the author's cover letter on tcl-core. Added missing citation of the nstcl-database API. -- 73 de ke9tv/2, Kevin |
From: Will D. <wi...@wj...> - 2007-11-23 15:35:39
|
Joe, On the one hand I agree; on the other hand, if you use Snit to wrap a database handle (something I do all the time with SQLite) then you're going to get Snit's semantics for the return values for "configure"...which are at present identical to Tk's. What's proposed here is yet a *third* pattern, which is Tk-like but not Tk's. In Tcl 9 could we try to unify some of these patterns? Will On Nov 23, 2007, at 7:24 AM, Joe English wrote: > > Under "Configuring a Database Handle", TIP#308 specifies: > > | dbHandle configure ?-option ?value?? ?-option value?... > | > | This configuration process is analogous to configuring a Tk > | widget. If there are no arguments presented to configure, > | the return value MUST be a list of triples; each element of > | the list MUST comprise the name of an available configuration > | parameter, its default value, and its current value. > > > Based on experience with Tk and Tile, I'd suggest something > more straightforward: > > + [dbHandle configure] with no additional arguments returns > a dictionary of the available configuration parameters and > their current values. > > + [dbHandle configure -option] returns the current value > of the specified -option. > > + with 2 or more additional arguments, works as currently > specified. > > > In other words, [dbHandle configure] should work like [font > configure], > not like widget [$w configure] methods. Information about the default > value of each parameter could be made available through some other > mechanism (if it's needed at all). > > Tk's list-of-5/2-tuples configure result format is awkward > and somewhat painful to work with. The generalized accessor > pattern -- with 0 args return a dictionary, with 1 return > a single value, with 2 or more perform an update -- is > much more pleasant to use. > > > --Joe English > > jen...@fl... > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core ------------------------------------------------------------------ will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills |
From: Joe E. <jen...@fl...> - 2007-11-23 15:24:34
|
Under "Configuring a Database Handle", TIP#308 specifies: | dbHandle configure ?-option ?value?? ?-option value?... | | This configuration process is analogous to configuring a Tk | widget. If there are no arguments presented to configure, | the return value MUST be a list of triples; each element of | the list MUST comprise the name of an available configuration | parameter, its default value, and its current value. Based on experience with Tk and Tile, I'd suggest something more straightforward: + [dbHandle configure] with no additional arguments returns a dictionary of the available configuration parameters and their current values. + [dbHandle configure -option] returns the current value of the specified -option. + with 2 or more additional arguments, works as currently specified. In other words, [dbHandle configure] should work like [font configure], not like widget [$w configure] methods. Information about the default value of each parameter could be made available through some other mechanism (if it's needed at all). Tk's list-of-5/2-tuples configure result format is awkward and somewhat painful to work with. The generalized accessor pattern -- with 0 args return a dictionary, with 1 return a single value, with 2 or more perform an update -- is much more pleasant to use. --Joe English jen...@fl... |
From: Donal K. F. <don...@ma...> - 2007-11-23 09:49:04
|
Alexandre Ferrieux wrote: > Donal K. Fellows wrote: >> Why push on this stupid issue? > > Because I'm stupid. > Sorry to have woken you up, dear semigod. The term you're after is "demigod" even though I'm sure it's not applicable. If you wanted something that really did apply, try "irascible person having problems with work". :-) Donal. |
From: Alexandre F. <ale...@gm...> - 2007-11-22 16:58:14
|
On Nov 22, 2007 10:33 AM, Donal K. Fellows <don...@ma...> wrote: > > Alexandre Ferrieux wrote: > > On 11/22/07, miguel <ms...@us...> wrote: > >> Vanilla arrays now also have Tcl_Obj keys, so no danger there. And they > >> also use a specialized hashtable that is not exposed. > > > > Then, why keep in Tcl_HashEntry those ominous seemingly variable-sized > > union members ? And those more-than ominous comments ? > > Why push on this stupid issue? Because I'm stupid. Sorry to have woken you up, dear semigod. -Alex |
From: <dg...@ni...> - 2007-11-22 16:07:46
|
> > Then, why keep in Tcl_HashEntry those ominous seemingly variable-sized > > union members ? And those more-than ominous comments ? > > Why push on this stupid issue? FWIW, I'm happy to have another pair of skilled eyeballs looking over the C code. Thanks for that, AF. Something to keep in mind though, is that often the answer to "why is this code the way it is?" is "because that's the way it was when we inherited it, and for various reasons we haven't seen fit to change it yet." DGP |
From: Donal K. F. <don...@ma...> - 2007-11-22 09:34:19
|
Alexandre Ferrieux wrote: > On 11/22/07, miguel <ms...@us...> wrote: >> Vanilla arrays now also have Tcl_Obj keys, so no danger there. And they >> also use a specialized hashtable that is not exposed. > > Then, why keep in Tcl_HashEntry those ominous seemingly variable-sized > union members ? And those more-than ominous comments ? Why push on this stupid issue? Donal. |
From: Alexandre F. <ale...@gm...> - 2007-11-22 07:42:58
|
On 11/22/07, miguel <ms...@us...> wrote: > > Vanilla arrays now also have Tcl_Obj keys, so no danger there. And they > also use a specialized hashtable that is not exposed. Then, why keep in Tcl_HashEntry those ominous seemingly variable-sized union members ? And those more-than ominous comments ? -Alex |
From: miguel <ms...@us...> - 2007-11-21 23:20:58
|
Alexandre Ferrieux wrote: > On 11/21/07, Donal K. Fellows <don...@ma...> wrote: >> The custom hash table type I'm using is not exposed outside the >> guts of the dict implementation; it doesn't even leave the file. >> > > OK, thanks for the clarification. > > (I'm just a bit uneasy thinking that somebody may cut&paste this out > of context, e.g. to add the ordering feature to vanilla arrays, which > is not so hard... > Maybe just adding a comment could protect against this.) Vanilla arrays now also have Tcl_Obj keys, so no danger there. And they also use a specialized hashtable that is not exposed. Except to the itcl and xotcl guys, or others mucking with internals. They are careful and know where to ask. |
From: Kristoffer L. <se...@fi...> - 2007-11-21 23:16:35
|
On 22 Nov 2007, at 01:13, Alexandre Ferrieux wrote: > (I'm just a bit uneasy thinking that somebody may cut&paste this out > of context, e.g. to add the ordering feature to vanilla arrays, which > is not so hard... But the question is, why do we want to separate vanilla arrays from all of this? The separations offers virtually no benefits. / http://www.scred.com/ / http://www.fishpool.com/~setok/ |
From: Alexandre F. <ale...@gm...> - 2007-11-21 23:13:07
|
On 11/21/07, Donal K. Fellows <don...@ma...> wrote: > > The custom hash table type I'm using is not exposed outside the > guts of the dict implementation; it doesn't even leave the file. > OK, thanks for the clarification. (I'm just a bit uneasy thinking that somebody may cut&paste this out of context, e.g. to add the ordering feature to vanilla arrays, which is not so hard... Maybe just adding a comment could protect against this.) -Alex |
From: Donal K. F. <don...@ma...> - 2007-11-21 00:05:22
|
Alexandre Ferrieux wrote: > Donal, forgive the naive question but... > > In your just-committed code I see you stick the two pointers of your > doubly-chained list *behind* the Tcl_HashEntry: [...] > I don't know whether the comments still apply... However if they do > *and* somebody uses a key larger than 4 bytes, something nasty may > happen to your list. Then it might be wise to put the prevPtr and > nextPtr before the Tcl_HashEntry. A good question. However, my code is fine. Here's why. The custom hash table type I'm using is not exposed outside the guts of the dict implementation; it doesn't even leave the file. The key is stored in one of the other fields of the union which you listed (the key.objPtr field) so it is guaranteed to never overlap the official end of the Tcl_HashEntry, I totally control the code that creates and populates the structure, and you'll never see one. The code in tclDictObj.c is not generic, and nor is there any reason for it to be so; it does exactly one thing. Dicts specifically contain (references to) Tcl_Objs for keys. My alternative would have been to have cloned the *entire* hash table system, but that'd be stupid. Sometimes you don't need a generic solution. Donal. |
From: Alexandre F. <ale...@gm...> - 2007-11-20 22:54:11
|
On 11/20/07, Donal K. Fellows <don...@ma...> wrote: > > Thanks for everyone's supportive comments. I've now checked in the > order-maintaining dictionary code. (I think that's the best way to > describe them.) Donal, forgive the naive question but... In your just-committed code I see you stick the two pointers of your doubly-chained list *behind* the Tcl_HashEntry: typedef struct ChainEntry { Tcl_HashEntry entry; struct ChainEntry *prevPtr; struct ChainEntry *nextPtr; } ChainEntry; However, looking in tcl.h it seems that Tcl_HashEntry is a kind of extensible structure, at least according to the comments in the union at the end: int words[1]; /* Multiple integer words for key. The actual * size will be as large as necessary for this * table's keys. */ char string[4];/* String for key. The actual size will be as * large as needed to hold the key. */ } key; /* MUST BE LAST FIELD IN RECORD!! */ I don't know whether the comments still apply... However if they do *and* somebody uses a key larger than 4 bytes, something nasty may happen to your list. Then it might be wise to put the prevPtr and nextPtr before the Tcl_HashEntry. -Alex |
From: Donal K. F. <don...@ma...> - 2007-11-20 20:50:16
|
Joe English wrote: > Actually it would provide a canonical string rep, something > that current dicts lack. Thanks for everyone's supportive comments. I've now checked in the order-maintaining dictionary code. (I think that's the best way to describe them.) Donal. |
From: <dg...@ni...> - 2007-11-20 19:00:10
|
Tcl/Tk 8.5b3 Release Announcement November 19, 2007 The Tcl Core Team is pleased to announce the 8.5b3 releases of the Tcl dynamic language and the Tk toolkit. This is the third beta release of Tcl/Tk 8.5. More details can be found below. We would like to express our gratitude to all those who submit bug reports and patches. This information is invaluable in enabling us to identify and eliminate problems in the core. Where to get the new releases: ------------------------------ Tcl/Tk 8.5b3 sources are freely available as open source from the Tcl Developer Xchange web site at: http://www.tcl.tk/software/tcltk/8.5.html This web page also contains additional information about the releases, including new features and notes about installing and compiling the releases. Sources are always available from the Tcl SourceForge project's file distribution area: http://sourceforge.net/project/showfiles.php?group_id=10894 For additional information: --------------------------- Please visit the Tcl Developer Xchange web site: http://www.tcl.tk/ This site contains a variety of information about Tcl/Tk in general, the core Tcl and Tk distributions, Tcl development tools, and much more. Thank you for your contributions: --------------------------------- As usual, this release includes contributions from the Tcl community. We have a page honoring these contributors at: http://www.tcl.tk/software/tcltk/contributors.html Summary of Changes since Tcl/Tk 8.5b2: -------------------------------------- The following were the main changes in Tcl/Tk 8.5b3. A complete list can be found in the changes file at the root of the source tree. The more complete ChangeLog is also included with each source release. This is a beta release of 8.5. The beta designation means that the feature set for 8.5 is believed to be complete, and the focus is now on testing and bug fixing moving quickly toward an 8.5.0 release. All relevant bug fixes (and some more) up to and including 8.4.16 changes are included in 8.5b3. This release is a development release, and should only be considered for deployment use after considerable testing. * New Tk look and default fonts on X11. [tk::classic::restore] to undo. * New configure option: --disable-rpath. * Continued Tk demo enhancement and documentation improvement. * Fixed broken compile on x86_64. * Fixed crash and infinite loop in regexp engine. * Fixed [tk_getOpenFile] crash on Mac OS X Leopard. * Font adjust interface for [console]. * Arabic and Hebrew rendering on Windows. * Corrected locale for sv.msg message catalog. * Performance improvements for binary [gets], binary [string match]ing, [info exists], stack overflow checking, list indexing, interpreter state reset, and simple regular expressions. * Embed iso8859-1 encoding directly in libtcl. -- Tcl Core Team and Maintainers Don Porter, Tcl Core Release Manager |
From: Donal K. F. <don...@ma...> - 2007-11-20 11:39:06
|
Andreas Leitgeb wrote: > I'm not sure if I missed something, but does this equivalence also > hold if arranged that way: > > set mydict {key1 val1 key2 val2 ... keyn valn} > # (assuming that all keys are in fact different) > # now, first, the one and only ordering for lists: > foreach {k v} $mydict { ... } > # then: (what happens after conversion to dict?) > dict for {k v} $mydict { ... } > > I ask, because, my expectation would be that as previously asked, > the equivalence would already hold now (since the list-rep would > be obtained from the dict in the same ordering, as what the dict-for > used), but the one I offered would generally not (except for keys > that happen to be already in hash-bucket-sequence) I'm not 100% sure about what you're asking, but under the conditions stated the new dictionary code would guarantee to perform those two iterations in the same order (i.e. dictionaries are ordered by the "natural element creation order"). That most certainly wasn't the case with the old (i.e. current[*]) dict code. Donal. [* The new stuff is in my home sandbox. ] |
From: Andreas L. <av...@lo...> - 2007-11-20 11:06:33
|
On Tue, Nov 20, 2007 at 10:19:01AM +0000, Donal K. Fellows wrote: > Twylite wrote: > > Put another way, will it mean that: > > dict for {k v} $mydict { ... } > > is equivalent to > > foreach k [dict keys $mydict] v [dict values $mydict] { ... } > > is equivalent to > > foreach {k v} $mydict { ... } > > Yes; it will mean just that. (In case someone asks, the first of those > is far more efficient when the dictionary is going to continue to be > used as a dictionary afterwards.) I'm not sure if I missed something, but does this equivalence also hold if arranged that way: set mydict {key1 val1 key2 val2 ... keyn valn} # (assuming that all keys are in fact different) # now, first, the one and only ordering for lists: foreach {k v} $mydict { ... } # then: (what happens after conversion to dict?) dict for {k v} $mydict { ... } I ask, because, my expectation would be that as previously asked, the equivalence would already hold now (since the list-rep would be obtained from the dict in the same ordering, as what the dict-for used), but the one I offered would generally not (except for keys that happen to be already in hash-bucket-sequence) |
From: Donal K. F. <don...@ma...> - 2007-11-20 10:19:18
|
Twylite wrote: > Put another way, will it mean that: > dict for {k v} $mydict { ... } > is equivalent to > foreach k [dict keys $mydict] v [dict values $mydict] { ... } > is equivalent to > foreach {k v} $mydict { ... } Yes; it will mean just that. (In case someone asks, the first of those is far more efficient when the dictionary is going to continue to be used as a dictionary afterwards.) Donal. |