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
(93) |
Oct
|
Nov
|
Dec
|
From: Joe E. <jen...@fl...> - 2011-05-18 21:00:29
|
Kristoffer Lawson wrote: > > To clarify, I'm not sure we need any new syntax. [ FWIW: I am quite sure that we *don't* need any new syntax. ] > But if I was forced to choose, I'd definitely go with the $() > > Come to think of it, how much would actually be broken if we > just added () as a new quoting mechanism, similar to " and {}? > But with the internal evaluated as an expression. stooop has been mentioned. I use $() a lot in DSLs [*], often with a read-trace on "", for various purposes. It's a neat syntactic hack, I suspect I'm not the only one. [*] "DSL" == "Domain Specific Language", one of Tcl's strong suits. --JE |
From: Twylite <tw...@cr...> - 2011-05-18 20:36:32
|
On 2011/05/18 09:09 PM, Brian Griffin wrote: > Just for fun, Moore's Law by the numbers: > > % for {set speed 3; set date [clock scan 2/2/2004]} {$date< [clock seconds]} {} { > puts "speed: $speed date: [clock format $date]" > set speed [expr {$speed * 2}] > set date [clock scan "18 months" -base $date] > } > speed: 3 date: Mon Feb 02 00:00:00 PST 2004 > speed: 6 date: Tue Aug 02 00:00:00 PDT 2005 > speed: 12 date: Fri Feb 02 00:00:00 PST 2007 > speed: 24 date: Sat Aug 02 00:00:00 PDT 2008 > speed: 48 date: Tue Feb 02 00:00:00 PST 2010 > % > > So, we should have 48Ghz processors today and 96Ghz processor by August. Except that Moore's law deals with transistor density, not CPU clock ;) Tcl computations tend to be memory bound. Improvements in L1/L2 cache, FSB speed, and DRAM speed translate into significant improvements in wall-clock performance. The money that bought me a Core2 with DDR2 18 months ago, could buy an i5 with DDR3-1066 6 months ago, and will buy a faster i5 with DDR3-1366 today. Each runs a single thread somewhat faster than the previous technology. Regards, Twylite |
From: Brian G. <bri...@ea...> - 2011-05-18 19:39:23
|
On May 18, 2011, at 10:25 AM, Brian Griffin wrote: > On May 18, 2011, at 9:35 AM, Twylite wrote: > >> And Moore's law fixes a performance >> drop of 19% within 6 months anyway. > > That hasn't been true for a long time now. The only way to better performance these days is by creating threads. If your algorithm can't be split, then you are SOL. > Of course, maybe I missed the news about Intel's 9Ghz processor... > > -Brian > Just for fun, Moore's Law by the numbers: % for {set speed 3; set date [clock scan 2/2/2004]} {$date < [clock seconds]} {} { puts "speed: $speed date: [clock format $date]" set speed [expr {$speed * 2}] set date [clock scan "18 months" -base $date] } speed: 3 date: Mon Feb 02 00:00:00 PST 2004 speed: 6 date: Tue Aug 02 00:00:00 PDT 2005 speed: 12 date: Fri Feb 02 00:00:00 PST 2007 speed: 24 date: Sat Aug 02 00:00:00 PDT 2008 speed: 48 date: Tue Feb 02 00:00:00 PST 2010 % So, we should have 48Ghz processors today and 96Ghz processor by August. -Brian |
From: Twylite <tw...@cr...> - 2011-05-18 18:31:33
|
On 2011/05/18 07:54 PM, Jeff Hobbs wrote: > I agree though - threads are important, but I don't see the core or > community doing enough to push the real advantage that Tcl has in a good > true native threading layer with C APIs and all the rest that make it > possible to have fully threaded apps. That - in my experience - is because script-level threading in Tcl is painful. Tcl's greatest strength in a threaded environment is its only-one-thread-per-interp model, which frees the developer from synchronisation problems, race conditions, deadlocks, and all the other nasties that plague multi-threaded programming. But Tcl's greatest weakness is the need to initialise other interps into the correct state to perform parallel tasks. In a complex program it can be tricky to ensure that the right packages and configuration are propagated to interps in other threads. So the simple intent "run this script in another thread" requires a lot of forethought to get right, compared to Java or C. In short, Tcl is a multi-processing environment, not a multi-threaded environment. Under the hood there are some mechanisms to efficient inter-interp communication, and C extensions can leverage true multi-threading (carefully), but Tcl scripts cannot. The path to a solution - I think - is to investigate concurrency models that are a good fit for Tcl at the script level, and implement them on top of the threading layer. I don't have a lot of good thoughts to contribute along those lines at the moment. Just one dangerous one: - Create a new class of proc called "function", which is defined to be side-effect free (refer to recent discussions of side-effect free procedures for optimisation -- no traces, no uplevel/upvar, only calls out to side-effect free procs). - This has 2 immediate benefits: (i) the programmer intentionally declares side-effect free procs and can trust that they are side-effect free when reasoning about code that uses them; (ii) these procs are conducive to a range of optimisations that can't be applied to non-side-effect-free procs in Tcl. - A side-effect free proc is conducive to execution in parallel threads _that share the originating interp_. These procs don't modify global state. So long as the originating thread is the last one out, you can simply create duplicate stacks in other threads and run the script in parallel. Some commands will be required to communicate between the threads and collate the results, of course. Regards, Twylite |
From: Twylite <tw...@cr...> - 2011-05-18 18:13:02
|
Hi, On 2011/05/18 07:34 PM, Andreas Leitgeb wrote: >>> that would be syntactically certainly very nice and would >>> work perfectly for arguments-as-expression, like >>> ... lindex $x ($end - 1) > But "end" here is just a plain variable, that must have been previously set. > For an end-relative index, you'd still have to use: "end-1", and you won't > be able to combine those, as "end-( some expression )" won't work, and there > isn't yet a string-concatenation operator in expr to prepend "end-" to the > result of a calculation). > If there is no comma (or colon(outside of ?:-context) or arrows) in the > steroided expression, then one would expect a direct result, whereas if > there is at least one at top-level, then a list (of at least two elements) > would be returned. Indeed - the weakness of this paren construct is that it must maintain backward compatibility, which creates a corner-case around 1-element lists. > a) would commata in embedded parentheses also construct lists? > - except if the open-paren is immediately trailing a function's name. > e.g. [expr_on_steroids {lindex((1,2,3),1)}] -> 2 > the outer parens are the args for lindex, the inner ones > construct a list In the context of the Tcl parser, the rule is that if you encounter a "(" where a word should begin, then you enter an "expression context" that is terminated by the matching ")" _according to the parsing rules of expr_. In effect braces, double-quotes and paren nest within this context. In the context of the Expr parser, the rule is that if you encounter a "(" where you would expect an expression or sub-expression, you enter an "expression context". If you encounter a separator (, or : for example) where you expect a word or operator, it ends the current expression (as if a ")" had been encountered) and begins a new one; the results of all separated expressions are returned in a list. In this example [lindex] has been turned into tcl::mathfunc::lindex, and the rules of [expr] are that each function argument is evaluated as an expression. So the argument '(1,2,3)' is evaluated (as an expression) and returns the list {1 2 3}. > b) how would you, thereby, construct a singleton list? > Avoid the pitfall of thinking it wouldn't matter "because numbers > are typically acceptable as singleton-lists": expr can also return > other things than just numeric values! Okay, let's create a couple of examples to investigate the problem: The trivial case: set val [expr { 1 + 2 }] == ( 1 + 2 ) Expr returns a single value that can be interpreted as a list: set val [expr { "a b" }] == ( "a b" ) Expr returns a list in which "a b" is the first element set val [expr { [list "a b"] }] == ( ( "a b" ) ) A list of expressions: set values [list [expr { 1 + 2 }] [expr { "a b" }]] == ( 1+2, "a b" ) A list of one expression: set values [list [expr { "a b" }] == ( ( "a b" ) ) set values [list [expr { 1 + 2 }] == ( ( 1 + 2 ) ) The last one has me a little uneasy because of the use of parenthesis for grouping sub-expressions in [expr]. Is this saying "An expr_on_steroids with one element that is a sub-expression (1+2)", or is it saying "An expr_on_steroids with one element that is an expr_on_steroids with one element that is '1 + 2'" ? And more importantly, is there any condition in which these two questions can produce different answers? What example cases am I missing? Regards, Twylite |
From: Jeff H. <je...@ac...> - 2011-05-18 17:55:58
|
On 18/05/2011 10:25 AM, Brian Griffin wrote: > On May 18, 2011, at 9:35 AM, Twylite wrote: > >> And Moore's law fixes a performance >> drop of 19% within 6 months anyway. > > That hasn't been true for a long time now. The only way to better performance these days is by creating threads. If your algorithm can't be split, then you are SOL. > Of course, maybe I missed the news about Intel's 9Ghz processor... I found one for a Celeron overclocked to 8.2Ghz ... does that count? ;) I agree though - threads are important, but I don't see the core or community doing enough to push the real advantage that Tcl has in a good true native threading layer with C APIs and all the rest that make it possible to have fully threaded apps. Jeff |
From: Kristoffer L. <se...@sc...> - 2011-05-18 17:47:48
|
On 18 May 2011, at 19:35, Twylite wrote: > On 2011/05/18 05:11 PM, Donal K. Fellows wrote: >> On 17/05/2011 17:45, Twylite wrote: >>> Well we're 2 years down the road from 8.6b1; 3.5 years down the road >>> from 8.5.0, and well on the way to matching it's 5-year record. _This_ >>> is what is killing Tcl. 2008 features finally released in 2011 (we >>> hope). The public appearance of stagnation. >> >> The problem is that any time someone seriously proposes doing a >> release, someone else jumps up and says "but not until I've done this >> other thing". We need to start ignoring such people, whatever position >> they're in; it's better to ship and be damned for being incomplete in >> some minor aspect than to not ship at all. > I complete agree. I've been in the position of "but not until I've done > this other thing" -- that was TIP #329, and I made a significant effort > to get that in (with a final spec and functionality - even if not ideal > - implementation) before the 8.6 feature freeze in October 2008. It > irks me that there are still changes going in, while other significant > developments are being held off indefinitely (read: 8.7). Indeed. To use the famous quote: real artists ship. -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/ http://travellingsalesman.mobi - 10000km & The world's most arctic startups |
From: Andreas L. <av...@lo...> - 2011-05-18 17:35:00
|
From: Twylite <tw...@cr...> > On 2011/05/18 09:45 AM, Gustaf Neumann wrote: > > that would be syntactically certainly very nice and would > > work perfectly for arguments-as-expression, like > > ... lindex $x ($end - 1) But "end" here is just a plain variable, that must have been previously set. For an end-relative index, you'd still have to use: "end-1", and you won't be able to combine those, as "end-( some expression )" won't work, and there isn't yet a string-concatenation operator in expr to prepend "end-" to the result of a calculation). > > ... incr x ($x + $y) > > ... + 123 ($x - $y) > Yes :) > > If I understand you correctly this means to add to the > > existing 3 substitution rules (backslash, var, cmd) and 4th > > one, namely "expr". The parens could be a shortcut for [expr > > ...] in the same way as $ is a shortcut for [set ...]. > Well, first we put [expr] on steroids by allowing it to treat any > separator (possibly , : -> =>), found in the position of an operator, as > a list separator. [expr] will evaluate each list elements separately > and return a list of the results. > Then we make parens a shortcut for [expr_on_steroids]. If there is no comma (or colon(outside of ?:-context) or arrows) in the steroided expression, then one would expect a direct result, whereas if there is at least one at top-level, then a list (of at least two elements) would be returned. That raises two questions: a) would commata in embedded parentheses also construct lists? - except if the open-paren is immediately trailing a function's name. e.g. [expr_on_steroids {lindex((1,2,3),1)}] -> 2 the outer parens are the args for lindex, the inner ones construct a list b) how would you, thereby, construct a singleton list? This question may seem odd for expr_on_steroids (just wrap it in a [list ...]), but would be a bit more relevant for embedded lists (see point a), or if this expr_on_steroids at some later point turned into a new parser rule, doubling as a list-constructor. Avoid the pitfall of thinking it wouldn't matter "because numbers are typically acceptable as singleton-lists": expr can also return other things than just numeric values! There must be an explicit distinction in the expression, for whether the result will be a (possibly singleton) list or just one "element". From: "Donal K. Fellows" <don...@ma...> > The problem is that any time someone seriously proposes doing a release, > someone else jumps up and says "but not until I've done this other > thing". How about targetting 8.7 for the expr-stuff ? While I like the idea, of adding a new comma-operator into expr, I just don't do so enough to keep back 8.6 for it, until the singleton-case is sorted out. |
From: Larry M. <lm...@bi...> - 2011-05-18 17:28:03
|
On Wed, May 18, 2011 at 10:25:35AM -0700, Brian Griffin wrote: > On May 18, 2011, at 9:35 AM, Twylite wrote: > > > And Moore's law fixes a performance > > drop of 19% within 6 months anyway. > > That hasn't been true for a long time now. The only way to better > performance these days is by creating threads. If your algorithm can't > be split, then you are SOL. What he said. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |
From: Brian G. <bri...@ea...> - 2011-05-18 17:25:50
|
On May 18, 2011, at 9:35 AM, Twylite wrote: > And Moore's law fixes a performance > drop of 19% within 6 months anyway. That hasn't been true for a long time now. The only way to better performance these days is by creating threads. If your algorithm can't be split, then you are SOL. Of course, maybe I missed the news about Intel's 9Ghz processor... -Brian |
From: Joe E. <jen...@fl...> - 2011-05-18 16:59:28
|
Donal K. Fellows wrote: > This is a Call For Votes on TIP #381. TIP#381: YES. [nextto] is one of the few remaining missing pieces, this should definitely go in for 8.6. --Joe English jen...@fl... |
From: Twylite <tw...@cr...> - 2011-05-18 16:35:44
|
On 2011/05/18 05:11 PM, Donal K. Fellows wrote: > On 17/05/2011 17:45, Twylite wrote: >> Well we're 2 years down the road from 8.6b1; 3.5 years down the road >> from 8.5.0, and well on the way to matching it's 5-year record. _This_ >> is what is killing Tcl. 2008 features finally released in 2011 (we >> hope). The public appearance of stagnation. > > The problem is that any time someone seriously proposes doing a > release, someone else jumps up and says "but not until I've done this > other thing". We need to start ignoring such people, whatever position > they're in; it's better to ship and be damned for being incomplete in > some minor aspect than to not ship at all. I complete agree. I've been in the position of "but not until I've done this other thing" -- that was TIP #329, and I made a significant effort to get that in (with a final spec and functionality - even if not ideal - implementation) before the 8.6 feature freeze in October 2008. It irks me that there are still changes going in, while other significant developments are being held off indefinitely (read: 8.7). It is also rather irritating that performance keeps coming up, even when early adopters -- who are running live, production systems on 8.6 -- report real-world performance _gains_ over 8.5. And it's been a well-known fact since 199x that Tcl is not suitable for performance-critical applications. And Moore's law fixes a performance drop of 19% within 6 months anyway. Can we fix this situation by updating TIP #311 and calling a vote to get firm commitment to a timeline? Here is a complete list of outstanding TIPs for 8.6 or earlier at this point: TIP #364 Project (8.6) Accepted Threading Support: Configuration and Package TIP #383 Project (8.6) Draft Injecting Code into Suspended Coroutines TIP #381 Project (8.6) Draft Call Chain Introspection and Control TIP #376 Project (8.6) Draft Bundle sqlite3 and tdbc::sqlite3 Packages TIP #380 Project (8.6) Draft TclOO Slots for Flexible Declarations TIP #372 Project (8.6) Draft Multi-argument Yield for Coroutines TIP #375 Project (8.6) Draft Symmetric Coroutines and Yieldto TIP #365 Project (8.6) Draft Add Python Compatibility Mode TIP #377 Project (8.6) Draft Portably Determining the Number of Processors in the System TIP #150 Project (8.5) Deferred Implement the Tk send Command for Windows TIP #61 Project (8.5) Deferred Make TK_NO_SECURITY Run-Time Switchable TIP #140 Project (8.5) Deferred Tracing Namespace Modifications TIP #20 Project (8.5) Deferred Add C Locale-Exact CType Functions TIP #131 Project (8.5) Draft Read My Mind and Do What I Mean TIP #64 Project (8.4) Deferred Improvements to Windows Font Handling What still "has to" go into 8.6? Are the "has to" TIPs all ready to be voted on, with implementations ready to go into the trunk? Can we commit to a beta by (say) 1 June, after which we are in a feature frozen beta cycle doing bug fixes only until an 8.6.0 release in (say) early August? Regards, Twylite |
From: Damon C. <da...@tc...> - 2011-05-18 15:44:08
|
On May 17, 2011, at 8:51 PM, Steve Bennett wrote: > Thanks to everyone for the feedback and interesting discussion. > > To summarise the responses directly related to my original > question, I have. > > $(...) Andy Goth, Twylite, Kristoffer Lawson, Me > $[...] Donal Fellows > > Did I miss any? > > Seems like $(...) is a reasonable choice. I would like to point out again that this is already a perfectly legal syntax in Tcl. I'm not usually one to throw out the backward compatibility sticky, but some people actually use the empty array construct. I believe Donal pointed out that stooop used this extensively. $[...] may not look as nice, but it's a difference of two characters and doesn't break nearly as much going forward. That being said, I prefer the new discussion of just having ( expr ... ) be recognized as an expression in places. Also, $(expr) reminds me too much of jQuery. Not that it's a bad thing, but I already equate it with another meaning. 0-] My non-voting opinion for those who care. D |
From: Donal K. F. <don...@ma...> - 2011-05-18 15:36:35
|
On 18/05/2011 17:22, Donal K. Fellows wrote: > Votes should be sent to this list in the usual format. Close date will > be midday UK time next Friday (i.e., clock format 1306321200). My vote > follows: Next _Wednesday_! The 25th. Damn this hot meeting room for damaging proper thought! The timestamp's correct. Donal. |
From: Donal K. F. <don...@ma...> - 2011-05-18 15:22:10
|
I'm bored of debates that go nowhere. Let's do some voting! This is a Call For Votes on TIP #381. This is on a collection of features that make it easier to inspect what a method is doing when it actually hits the implementations, and to direct what is going on more precisely (useful for those diamond constructor problems which I hate introducing in the first place!) and is part of the changes arising from discussions held at Tcl 2010. Details (including a pointer to the sample implementation) at: http://www.tcl.tk/cgi-bin/tct/tip/381.html Votes should be sent to this list in the usual format. Close date will be midday UK time next Friday (i.e., clock format 1306321200). My vote follows: TIP #381: YES Donal. |
From: Donal K. F. <don...@ma...> - 2011-05-18 15:11:20
|
On 17/05/2011 17:45, Twylite wrote: > After the 8.5 debacle there was a firm intent to release 8.6 more > swiftly. The release calendar was presented in TIP #311. The first > beta was out in Dec 2008. At the Tcl conference 2008 ActiveState > predicted 8.6.0 by March 2009. > > Well we're 2 years down the road from 8.6b1; 3.5 years down the road > from 8.5.0, and well on the way to matching it's 5-year record. _This_ > is what is killing Tcl. 2008 features finally released in 2011 (we > hope). The public appearance of stagnation. The problem is that any time someone seriously proposes doing a release, someone else jumps up and says "but not until I've done this other thing". We need to start ignoring such people, whatever position they're in; it's better to ship and be damned for being incomplete in some minor aspect than to not ship at all. Donal. |
From: Twylite <tw...@cr...> - 2011-05-18 14:50:07
|
On 2011/05/18 09:45 AM, Gustaf Neumann wrote: > that would be syntactically certainly very nice and would > work perfectly for arguments-as-expression, like > > ... lindex $x ($end - 1) > ... incr x ($x + $y) > ... + 123 ($x - $y) Yes :) > If I understand you correctly this means to add to the > existing 3 substitution rules (backslash, var, cmd) and 4th > one, namely "expr". The parens could be a shortcut for [expr > ...] in the same way as $ is a shortcut for [set ...]. Well, first we put [expr] on steroids by allowing it to treat any separator (possibly , : -> =>), found in the position of an operator, as a list separator. [expr] will evaluate each list elements separately and return a list of the results. Then we make parens a shortcut for [expr_on_steroids]. Regards, Twylite |
From: Twylite <tw...@cr...> - 2011-05-18 14:47:50
|
On 2011/05/17 09:47 PM, Donald G Porter wrote: >> Which is fine while the world is 32-bit. But as the world changes to >> 64-bit the existing definitions become dangerous and need to be fixed. > > I think that explains the difference in our perspective. My world has > been (in part) 64-bit as long as I've been programming Tcl. 14+ years > ago, I was working with Tcl on the 64-bit Alpha PC. The fact that Tcl > has behaviors that are word-size-dependent is not a surprise to me. It > strikes me as completely expected and normal. My experience has included x86, PA-RISC, sparc64, 8051, x86_64, and TI DSP with a 40-bit 'long' (I got Jim up and running on that one :) ). My trust in 'int' and 'long' is minimal. > I can see an argument that a simpler, nicer model would try to reduce > that and fence it off to a few specialty commands, and I'm open to a > road map on how to get from here to there. (In fact I begged for such > a thing during 8.5 development and got no interest (TIP 297).) TIP > 347 is one step on such a map. >> Tcl scripts need to exhibit identical behaviour on all platforms, ... > > I think we can get closer to that, but as Jeff pointed out, Tcl's strong > relationship to C as an extension language ultimately limits how far > we can take that. > TIP 347 is a step in the wrong direction. The problem of integer type compatibility across platforms was addressed in C99, in the form of <inttypes.h>. Tcl is still mucking with 'int' and 'long', and wants to bring that distinction up to the script level. The TIP seeks to define a new "long" range applicable to both [expr] and [string is] - I can only assume to be a script-level equivalent of Tcl_GetLongFromObj(). This is definitely a step in the wrong direction -- it introduces a new platform-specific type at script level, and worsens the problem. That said, let's take a step back and look at how we perceive the problem. Option (A): int() is meant to truncate a floating point value to an integer, as described in the Tcl 8.4.x man pages. The 8.5 changes to use bignum - which removed arbitrary platform-specific integer overflow from Tcl - failed to correct int() and [string is integer] to behave consistently with Tcl's new size-unrestricted concept of "an integer". Option (B): int() and wide() are meant to truncate a floating point value to a platform-specific size so that subsequent use of Tcl_GetXFromObj() (X = Int, WideInt, Long) won't fail. We need corresponding long() and entier() and [string is long], and to break the meaning of int() again to mean 'int' not 'long'. Option (C): int() and wide() are meant to truncate numbers to specific bit lengths (32- and 64-bits respectively). Now let's consider the history: 2002-02-15: dkf commits changes to expr.n as part of TIP #72. The definition of int() is changes from "converts arg to integer by truncation and returns the converted value." to "converts arg to an integer (of the same size as a machine word, 32-bits on 32-bit systems, and 64-bits on 64-bit systems) by truncation and returns the converted value." http://core.tcl.tk/tcl/fdiff?v1=25011a4d8b52e3fb&v2=8b6f09fb5209ae43 <http://core.tcl.tk/tcl/fdiff?v1=25011a4d8b52e3fb&v2=8b6f09fb5209ae43> This definition is largely maintained until 2006-04-26, when dgp provides the current definition: "The integer part of arg is determined, and then the low order bits of that integer value up to the machine word size are returned as an integer value. For reference, the number of bytes in the machine word are stored in tcl_platform(wordSize)." We started in 8.4 with truncation to a Tcl integer (which at the time happened to be limited to the machine word size). In 8.5 the arbitrary integer size limit was removed, but the definition of int() was changed to truncation to "32-bits on 32-bit systems, and 64-bits on 64-bit systems". The final change redefines int() as "32-bits on 32-bit systems and LLP64 systems, and 64-bits on LP64 systems". Each time the documentation is chasing the implementation, rather than fixing the implementation to do what is documented. If you perceive the problem as Option (B), then [start ad hominem] you are beyond help [/end ad hominem]. You think that Tcl's arithmetic subsystem should exhibit platform-specific behaviour, which requires the Tcl developer to have intimate knowledge of the target platform of operation (to use a platform neutral scripting language). Under this view, the _only_ valid uses of int() and wide() are to achieve platform-specific behaviour, not to truncate to a specific size for calculation purposes (you would use & 0xffff... for that). You probably also think that you understand how things can go wrong, which almost certainly means you've never encountered a 24-bit int, or a 40-bit long. You are also making a long term commitment to the C89 mistakes that were fixed in C99. And - check the message header - it's 2011. I would argue that Option (A) is the conceptually "correct" view, but that Option (C) is necessary to maintain backwards compatibility. Statements by developers on tcl-core, and fixes applied over time in tcllib, strongly indicate that developers work under the assumption that int() truncates to 32-bits, and wide() truncates to 64-bits (it is in fact still documented to do so, but the implementation could be longer than 64 bits). So the solution involves taking the decision to break backward compatibility in favour of platform compatibility, recognising that the existing implementation is - for all except a few who understand the intricacies involves - already broken. (1) #include <inttypes.h> (2) Provide compat/inttypes.h for supported platforms that don't have the header. (3) Fix Tcl_GetIntFromObj() to return int32_t. [string is integer] relates to Tcl_GetIntFromObj() which returns int. int is 32-bit on all x86 (since 386) and x86_64 platforms. There are very few platforms on which 'int' is not signed 32-bit, and I don't believe they are officially supported. This _should not_ break anything except on _very weird_ platforms. (4) Fix TCL_WIDE_INT_TYPE to be int64_t [string is wide] relates to [expr wide()] and Tcl_GetWideIntFromObj() which returns Tcl_WideInt (TCL_WIDE_INT_TYPE). Tcl_WideInt is defined in tcl.h as being "at least 64 bits". This should be fixed now to be "exactly 64 bits" before we get a widespread 64/128 bit conflict. This _should not_ break anything on currently supported platforms. (5) Fix Tcl_GetLongFromObj() to be int64_t, and document the potential incompatibility. Tcl_GetLongFromObj() currently returns 'long'. 'long' is 32-bit on x86 and LLP64 (Windows on x86_64), but 64-bit on LP64 (*nix on x86_64 and various other architectures). By changing from 'long' to 'int64_t' we may **break code on existing 32-bit and WIN64 systems**, BUT: (a) C extensions will get compile-time errors, which are easily fixed by changing types of int64_t, or the function to Tcl_GetIntFromObj() if 32-bit is required. (b) It is a reasonable assumption that a developer using Tcl_GetLongFromObj() wanted 32-or-more-bits, and was not assuming a 32-bit limit. Code breaks should be type-related rather than logic bugs. (c) **Binary compatibility of 8.4/8.5 extensions loaded into 8.6 may be affected**. This can be handled sanely by returning errors when the extension tries to load the stubs table. This is clearly the most contentious change, but we cannot get to platform neutral behaviour at the script level without fixing it. (6) Fix tcl::mathfunc::wide() to truncate to 64-bits, consistent with the 64-bit definition of TCL_WIDE_INT_TYPE in (4) above. Document that this is a legacy function, and entier() should be used instead. (7) Fix tcl::mathfunc::int() to truncate to 32-bits, and document the potential incompatibility. Document that this is a legacy function, and entier() should be used instead. Currently int() truncates to the bit-length of 'long', which is platform specific. A script-level function that truncates to a platform-specific bit length is a gotcha for programmers who don't have intimate knowledge of the target platforms. wide() is already a 64-bit truncation, we don't need another one, but we do need a truncation for 32-bit arithmetic, and I strongly suspect there will be plenty of code that assumes int() truncates to (as little as) 32 bits. (8) Do _not_ define tcl::mathfunc::long(). It's covered by wide(). (9) Fix [string is integer] to "do the expected thing", i.e. return true iff the string can be interpreted by Tcl as an integer (of any size). This appears to be the behaviour expected by developers who haven't been caught by it yet. [string is integer] will then have the same meaning proposed for [string is entier] in the TIP. Accept that [string is] is asking "can this string be interpreted as a ... by Tcl?". If Tcl doesn't have the concept of "integer range" or "long range" at script level (which it hasn't had since bignum arithmetic ended integer/wide overflows in 8.5), then such a question is meaningless. Asking "can I convert this number into a platform-specific type" is quite meaningful though, but that isn't a string question. (10) Fix [string is wideinteger] to be an alias to [string is integer]. They mean the same thing. (11) Rename tcl::mathfunc::entier() to trunc() (maintain entier() as an alias for compatibility). The operation performed by this function is well known as "Truncate" or "Floor". There is no reason to have a name that is a continual source of WTF. (12) This roadmap fixes the problem _now_ with minimal incompatibility, and leaves Tcl dealing with "integer" and having no concept of "int" or "long" at script level. Document the potential backward compatibility issues for upgrading to Tcl 8.6. Indicate the use of [binary format] and [binary scan] for compatibility with native (platform-specific types). This will not be the first change with compatibility implications -- Tcl 8.5 math broke things for scripts that assumed arithmetic overflow, or assumed int() was 64 bits on a 64-bit platform as documented (it's 32-bit on WIN64), etc. With appropriate selection of the sizes for "int" and "long" the impact should be minimal. Regards, Twylite |
From: Gustaf N. <ne...@wu...> - 2011-05-18 08:41:24
|
On 17.05.11 19:30, Twylite wrote: > > Counter-proposal, in EBNF > (http://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form): > dynlist = "(", expr, { sep, expr }, ")" > sep = "," | ":" | "->" | "=>" > > .... > And the obligatory simple example: > > set i ($i + 1) that would be syntactically certainly very nice and would work perfectly for arguments-as-expression, like ... lindex $x ($end - 1) ... incr x ($x + $y) ... + 123 ($x - $y) If I understand you correctly this means to add to the existing 3 substitution rules (backslash, var, cmd) and 4th one, namely "expr". The parens could be a shortcut for [expr ...] in the same way as $ is a shortcut for [set ...]. -gustaf neumann |
From: Kristoffer L. <se...@sc...> - 2011-05-18 07:41:31
|
On 18 May 2011, at 10:36, Koen Danckaert wrote: > Kristoffer Lawson wrote: >> On 17 May 2011, at 19:20, Brian Griffin wrote: >>> On May 17, 2011, at 8:47 AM, Twylite wrote: >>> >>>> Hi, >>>> >>>> On 2011/05/17 05:19 PM, Koen Danckaert wrote: >>>>> For the record, you can just write [string range $string $index-1 $index+5] >>>> Yeah - again, not in Tcl 8.4, and it doesn't generalise to $index+$var. It's also an ugly hack that should never have happened, because there should be a neater way to write expressions. >>> Assuming *all* Tcl/Tk commands that are looking for numbers call Tcl_GetIntFromObj(interp, objPtr, intPtr) or similar, would it be reasonable if these calls all performed an [expr objPtr]? Then one could write: >> Wow, what a novel idea. That could actually work. Need to think about it :-) > > Novel ? See TIP #273... My bad. Thanks for the correction. -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/ http://travellingsalesman.mobi - 10000km & The world's most arctic startups |
From: Kristoffer L. <se...@sc...> - 2011-05-18 07:38:55
|
On 18 May 2011, at 10:19, Lars Hellström wrote: > Kristoffer Lawson skrev 2011-05-18 08.18: >>> Do you mean that the implicit [expr] should use a sub-dialect that only handles numeric operations and doesn't substitute [] like a regular expr? Then you can't do things like [string range $string 0 {1 + [lindex $somelist 5]} ]. > > It would seem he means that. > >> That is handled thus: >> >> [string range $string 0 "1 + [lindex $somelist 5]"] > > If you omit the spaces, then that is already supported. When arguing for a > feature, then at least find a usecase where it would add some power! Yes, admittedly this example isn't the best. Another: incr i "$a + ($b *$c)" > Note also that substitution as shown above can have funny consequences if > the text substituted is not just a number. "2 * [return -level 0 "1+3"]" > is probably the easiest example. This then requires CPP-style "add > parentheses around everything just to be safe" programming... Suddenly > [expr {...}] isn't so verbose in comparison. Not a problem if you consider that expressions are accepted as numbers. Then the returned "1+3" is just another number to evaluated, and the result multiplied by 2. -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/ http://travellingsalesman.mobi - 10000km & The world's most arctic startups |
From: Koen D. <ko...@re...> - 2011-05-18 07:36:40
|
Kristoffer Lawson wrote: > On 17 May 2011, at 19:20, Brian Griffin wrote: > >> On May 17, 2011, at 8:47 AM, Twylite wrote: >> >>> Hi, >>> >>> On 2011/05/17 05:19 PM, Koen Danckaert wrote: >>>> For the record, you can just write [string range $string $index-1 >>>> $index+5] >>> Yeah - again, not in Tcl 8.4, and it doesn't generalise to $index+$var. >>> It's also an ugly hack that should never have happened, because there >>> should be a neater way to write expressions. >> Assuming *all* Tcl/Tk commands that are looking for numbers call Tcl_GetIntFromObj(interp, objPtr, intPtr) or similar, would it be reasonable if these calls all performed an [expr objPtr]? Then one could write: > > Wow, what a novel idea. That could actually work. Need to think about it :-) > Novel ? See TIP #273... --Koen |
From: Kristoffer L. <se...@sc...> - 2011-05-18 07:23:32
|
On 18 May 2011, at 04:51, Steve Bennett wrote: > Thanks to everyone for the feedback and interesting discussion. > > To summarise the responses directly related to my original > question, I have. > > $(...) Andy Goth, Twylite, Kristoffer Lawson, Me > $[...] Donal Fellows To clarify, I'm not sure we need any new syntax. But if I was forced to choose, I'd definitely go with the $() Come to think of it, how much would actually be broken if we just added () as a new quoting mechanism, similar to " and {}? But with the internal evaluated as an expression. -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/ http://travellingsalesman.mobi - 10000km & The world's most arctic startups |
From: Lars H. <Lar...@re...> - 2011-05-18 07:19:54
|
Kristoffer Lawson skrev 2011-05-18 08.18: >> Do you mean that the implicit [expr] should use a sub-dialect that only handles numeric operations and doesn't substitute [] like a regular expr? Then you can't do things like [string range $string 0 {1 + [lindex $somelist 5]} ]. It would seem he means that. > That is handled thus: > > [string range $string 0 "1 + [lindex $somelist 5]"] If you omit the spaces, then that is already supported. When arguing for a feature, then at least find a usecase where it would add some power! Note also that substitution as shown above can have funny consequences if the text substituted is not just a number. "2 * [return -level 0 "1+3"]" is probably the easiest example. This then requires CPP-style "add parentheses around everything just to be safe" programming... Suddenly [expr {...}] isn't so verbose in comparison. Lars Hellström |
From: Kristoffer L. <se...@sc...> - 2011-05-18 06:19:00
|
On 18 May 2011, at 02:01, Twylite wrote: > But what if $n has been nefariously set to "[exit]" ? Then Tcl's parser will substitute [string range "the string value" 0 {[exit]}], and range will perform an [expr] on {[exit]} which will execute the command 'exit'. No, this is not what would happen. The proposal was to add to the Tcl "get integer from string" function (can't remember exact name, would have to look it up), to allow it to do expressions. However there is no need to implement it so that it does the full [expr], with variable and command substitution. Leave that to the interpreter to do. So if [string range $s 0 {[exit]}] is passed, then "get integer from ob" would exit and say "expected integer expression", as it would not be designed for command substitution (thus, no command execution). If it gets [string range $s 0 {1 + 1}] it converts the {1 + 1} string argument into the integer "2". If you want to do variable or command substitution, you allow the normal Tcl interpreter to do it: [string range $s 0 "$startPosition + [getEndPosition $s]"] > Do you mean that the argument is not substituted by the parser but left intact to be passed to [expr]? Tcl's parser has no special knowledge of commands that allows it to skip substitution for certain arguments. Introducing such a mechanism would utterly destroy the consistency of Tcl's syntax, making you unable to read Tcl code without knowing whether the particular command has special substitution rules. Nope, it was about changing how "get integer object from string" is implemented. It's a very clever idea. I'm not yet sure it should be the way to go, but I am very intrigued by it. > Do you mean that the implicit [expr] should use a sub-dialect that only handles numeric operations and doesn't substitute [] like a regular expr? Then you can't do things like [string range $string 0 {1 + [lindex $somelist 5]} ]. That is handled thus: [string range $string 0 "1 + [lindex $somelist 5]"] -- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/ http://travellingsalesman.mobi - 10000km & The world's most arctic startups |