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
(92) |
Oct
|
Nov
|
Dec
|
From: miguel s. <mig...@gm...> - 2008-12-03 16:10:57
|
Donald G Porter wrote: > One of the headline features for Tcl 8.6 is the NRE engine and the > tailcall and coroutine commands it enables. > > TIP 322 is about publishing the C API so that extensions can use > these features as well. Almost, not quite. The C api allows commands defined in extensions to reduce their own stack consumption and do not block the NRE trampolining. > How should I interpret the lack of any movement to vote on it? > Is there some reason it's not ready? What are the issues? The reason is ... that I've not been doing too well, nor paying much attention to Tcl (or anything else). The issues are nothing that can't be fixed in later TIPs, I think: the API might be incomplete, some of the choices may prove not to be optimal. I can't really know if some of the suboptimalities might yet lead us to maintain deprecated APIs for longish times ... The API has not been tested very thoroughly - just the NRE-enabled core commands. As the only user besides myself (that's right, isn't it?), I think that dkf's opinion is decisive. As for me, I think that it is about ready to go. > Gives me a queasy feeling to yet again be telling extension authors > that to really use Tcl's power they'll need tclInt.h . Good point! I'd be thankful if somebody else calls and manages the vote though. Cheers Miguel |
From: Donald G P. <dg...@ni...> - 2008-12-03 15:08:30
|
One of the headline features for Tcl 8.6 is the NRE engine and the tailcall and coroutine commands it enables. TIP 322 is about publishing the C API so that extensions can use these features as well. How should I interpret the lack of any movement to vote on it? Is there some reason it's not ready? What are the issues? Gives me a queasy feeling to yet again be telling extension authors that to really use Tcl's power they'll need tclInt.h . -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Alexandre F. <ale...@gm...> - 2008-12-03 10:59:29
|
TIP #343: A BINARY SPECIFIER FOR [FORMAT/SCAN] ================================================ Version: $Revision: 1.1 $ Author: Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com> State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Wednesday, 03 December 2008 URL: http://purl.org/tcl/tip/343.html WebEdit: http://purl.org/tcl/tip/edit/343 Post-History: ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes to add a %b specifier to the *format* and *scan* commands for working with integers in base-2 representation. BACKGROUND ============ The *format* and *scan* commands already have decimal, hexadecimal, and octal support, but people wanting binary today resort to a hack, namely going hexadecimal first and then *string map*ping the hex digits to their four-bits binary representations. We also already have the "0b" notation as input for *expr*. This lack is inelegant. PROPOSED CHANGE ================= This TIP proposes to reuse the existing binary representation machinery to expose a new *%b* specifier: format %b 5 => 101 scan 000101 %b x;set x => 5 The good properties of the existing code make the addition really painless, in that it automagically combines with the size (l,ll), width (digits), and prefix (#) modifiers: format %#06b 5 => 0b0101 format %llb [expr {(2**72-1)/7}] 1001001001001001001001001001001001001001001001001001001001001001001001 RATIONALE =========== That is really low-hanging fruit. All the pieces are in place, it's just a matter of exposition. The binary representation is a nice pedagogic tool, and having it handy (rather than with a hack) is a bonus. REFERENCE IMPLEMENTATION ========================== See Patch 2368084 [<URL:https://sourceforge.net/support/tracker.php?aid=2368084>]. COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows |
From: Donal K. F. <don...@ma...> - 2008-12-03 10:48:13
|
Kevin Kenny wrote: > Exactly. There's no excuse for building Yet Another libz.so on Linux. > But of course we should have the sources available against the sort of > issue you describe. The exact setup of configure hasn't been decided yet (I favour using the system copy unless explicitly set otherwise, and I also favour allowing people to specify which system copy to use) but that's a minor issue. Donal. |
From: Donal K. F. <don...@ma...> - 2008-12-03 10:43:40
|
Andreas Leitgeb wrote: > A few minor questions about implementation (I'm just curious): > How does the byte-coded "lrange" thing deal with bad lists > (i.e. something like "{fsg fds}dsfa {" ) ? The TIP specifies > that no errors be thrown for non-list errorCodes or patterns. Ooops, missed that. I'll change that when I call the vote because it's not a good decision. The list interpretation of error codes has been assumed for well over a decade, so a non-list error code is an error itself. > Will bytecode compilation work, if the codes for "on" or > the list prefixes for "trap" are results of substitutions? > like: try {...} on $::customrc {} {...} We'll spill those cases to the interpreted version. That's normal for bytecoded commands. Donal. |
From: Alexandre F. <ale...@gm...> - 2008-12-03 10:10:16
|
On Wed, Dec 3, 2008 at 9:32 AM, Jan Nijtmans <nij...@us...> wrote: > [...] > Strictly speaking that > would need a TIP. Maybe make it a quick one, I don't think deciding on this > will be very controversy. OK, done, in Donal's box now :-) -Alex |
From: Andreas L. <av...@lo...> - 2008-12-03 08:46:19
|
"Donal K. Fellows" <don...@ma...> wrote: > 2) Is the matching algorithm this: > [lrange $pattern 0 end] eq [lrange $errcode 0 [llength $pattern]-1] > If so, that's acceptable as that's practical to implement. I'm very relieved and happy, that this globbing-a-list bungle has been replaced by something appropriate for lists. Thanks to Fredderic for not giving up so quickly and instead pushing a simpler alternative than mine. I'm (slightly) unhappy, that the "as {msgVar optsVar}" was dropped. Since these vars outlive their particular handler block (unlike with all the other languages' try-catches) a central declaration of them would have been better, and would have made the vars available to the finally block even if no specific handler matched. A few minor questions about implementation (I'm just curious): How does the byte-coded "lrange" thing deal with bad lists (i.e. something like "{fsg fds}dsfa {" ) ? The TIP specifies that no errors be thrown for non-list errorCodes or patterns. Will bytecode compilation work, if the codes for "on" or the list prefixes for "trap" are results of substitutions? like: try {...} on $::customrc {} {...} |
From: Jan N. <nij...@us...> - 2008-12-03 08:32:21
|
2008/12/1 SourceForge.net <no...@so...>: > Patches item #2368084, was opened at 2008-12-01 01:54 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=310894&aid=2368084&group_id=10894 ..... > The patch includes proper tests and documentation update. Does it really need a TIP ? Just moving the question on. I think the lack of '0b' here was an oversight when adding '0b' to expr, it should have been included in that TIP. Strictly speaking that would need a TIP. Maybe make it a quick one, I don't think deciding on this will be very controversy. Regards, Jan Nijtmans |
From: Twylite <tw...@cr...> - 2008-12-03 06:19:39
|
Hi, >> The *dict* command will get a new subcommand >> *dict getwithdefault* /dictionary/ /key/ ?/key/ ...? /value/ >> > > Now the questions: > 1) Which is best: "getwithdefault" vs. "getdefault"? > "getdefault" implies that you are getting the default; in that respect "getwithdefault" is more accurate. It may be worth considering an altogether different verb like "fetch" or "lookup". Twylite |
From: Kevin K. <kk...@ny...> - 2008-12-03 02:43:38
|
Forwarding for Larry W. Virden: > After I sent this msg to the mailing list, I got back a "denied" msg > indicating that messages from gmail were not being accepted. > > Since I attempted to send it to tcl-core originally, feel free to send > a response with my msg that way if you wish. > > > ---------- Forwarded message ---------- > From: Larry W. Virden <lv...@gm...> > Date: Tue, Dec 2, 2008 at 12:26 PM > Subject: Re: [TCLCORE] CFV: Zlib and PNG > To: tcl...@li... > > >> Simply building our own copy of zlib on platforms where it is >> universally available is not acceptable. (But we probably *do* >> need to ship it with Tcl on Windows, where zlib is *not* >> universally available. > > By this, I presume what you mean is "always building our own copy" is > something that is not acceptable?? > > Using the version of a library already on the system has the potential > of providing the user the ability to use one tuned to their OS or > hardware. However, it also provides the possibility of the user > discovering that his/her system ships with a version that is out of > date with regards to security concerns, features, etc. > > I have encountered this problem with an xml library that Sun shipped > through SPARC Solaris 9 at least. It is too old to work with some of > the Tcl xml packages. > > So perhaps the ideal solution would be to give the person doing the > configuration the possibility of specifying they wish to use the tcl > version if there is a good reason? > > -- > Tcl - The glue of a new generation. http://wiki.tcl.tk/ > Larry W. Virden http://www.purl.org/net/lvirden/ > http://www.xanga.com/lvirden/ > Even if explicitly stated to the contrary, nothing in this posting > should be construed as representing my employer's opinions. > > > Exactly. There's no excuse for building Yet Another libz.so on Linux. But of course we should have the sources available against the sort of issue you describe. -- 73 de ke9tv/2, Kevin |
From: Donal K. F. <don...@ma...> - 2008-12-02 23:27:16
|
Lars Hellström wrote: > The *dict* command will get a new subcommand > *dict getwithdefault* /dictionary/ /key/ ?/key/ ...? /value/ Now the questions: 1) Which is best: "getwithdefault" vs. "getdefault"? 2) Should the default value be before or after the keys? 3) Is a zero-length key list meaningful? (cf TIP#323) Donal. |
From: Donal K. F. <don...@ma...> - 2008-12-02 22:36:05
|
Twylite wrote: > Is it necessary for [throw] to be in the core? It's easily implemented > in Tcl and not performance critical, so I'd be happy to let it mature in > a tcllib extension first. OK. Let's not go through *another* round of changes on this! > (*) I take it that [lrange] is forcing a canonical representation of the > lists and that my current level of awakeness is not fooling me. > As a cross-check, this would be an iterative implementation of what I am > intending: > for {set i 0} {$i < [llength $pattern]} {incr i} { > if { [lindex $pattern $i] ne [lindex $errorcode $i] } { return 0 } > } > return 1 They compute the same thing. Mine just uses a different layer of Tcl to do the iteration (and is easier to bytecode by far; we have a "fixed lrange" operation already). The TIP passes my fitness checks. I'll start the vote tomorrow. :-) Donal. |
From: Twylite <tw...@cr...> - 2008-12-02 21:58:22
|
Hi, > I've a couple of clarification questions... > > 1) Is [throw] necessary? (Maybe yes...) I believe it is, to make developers think of errors as having a type first and foremost, and a description as a secondary concern (side benefit: we're likely to see more use of msgcat for error messages). If one does not think of errors in this way then there will be nothing on which to trap, and little value to the trap handler. Is it necessary for [throw] to be in the core? It's easily implemented in Tcl and not performance critical, so I'd be happy to let it mature in a tcllib extension first. > 2) Is the matching algorithm this: > [lrange $pattern 0 end] eq [lrange $errcode 0 [llength $pattern]-1] > If so, that's acceptable as that's practical to implement. Yes (*). (*) I take it that [lrange] is forcing a canonical representation of the lists and that my current level of awakeness is not fooling me. As a cross-check, this would be an iterative implementation of what I am intending: for {set i 0} {$i < [llength $pattern]} {incr i} { if { [lindex $pattern $i] ne [lindex $errorcode $i] } { return 0 } } return 1 Regards, Twylite |
From: Donal K. F. <don...@ma...> - 2008-12-02 20:55:20
|
Twylite wrote: > Final edit on TIP #329 completed - a couple of inconsistencies have been > fixed. > > There will be no further changes to the specification. Everyone has had > their say, you now either like it or you don't. > > I haven't had a chance to update the reference implementation - it has > been moved out of the TIP and onto my site where I will update it in X > (for "shortly" < X < "in due course"). This is looking much better. I've a couple of clarification questions... 1) Is [throw] necessary? (Maybe yes...) 2) Is the matching algorithm this: [lrange $pattern 0 end] eq [lrange $errcode 0 [llength $pattern]-1] If so, that's acceptable as that's practical to implement. Donal. |
From: Donal K. F. <don...@ma...> - 2008-12-02 20:11:36
|
Donal K. Fellows wrote: > Another day, another CFV: > > TIP#324: A Standard Dialog For Font Selection > TIP#332: Half-Close for Bidirectional Channels > TIP#341: Multiple 'dict filter' Patterns I suppose I ought to vote on these (I was in a hurry!) TIP#324: YES (If Pat and Dan agree, I'm happy) TIP#332: YES (Useful with sockets and pipes) TIP#341: YES (It doesn't thrill me, but I won't stand in its way) Donal. |
From: Twylite <tw...@cr...> - 2008-12-02 17:22:20
|
Final edit on TIP #329 completed - a couple of inconsistencies have been fixed. There will be no further changes to the specification. Everyone has had their say, you now either like it or you don't. I haven't had a chance to update the reference implementation - it has been moved out of the TIP and onto my site where I will update it in X (for "shortly" < X < "in due course"). Donal - if you're willing to sponsor this TIP will you please call a vote. Regards, Twylite |
From: Andreas K. <and...@ac...> - 2008-12-02 17:00:49
|
> Another day, another CFV: > > TIP#324: A Standard Dialog For Font Selection > TIP#332: Half-Close for Bidirectional Channels > TIP#341: Multiple 'dict filter' Patterns > > One week voting period, close at 12:00 GMT on 9 December. TIP#324: PRESENT TIP#332: YES TIP#341: PRESENT -- Andreas Kupries <andreask@ActiveState.com> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |
From: Donal K. F. <don...@ma...> - 2008-12-02 16:45:35
|
Another day, another CFV: TIP#324: A Standard Dialog For Font Selection TIP#332: Half-Close for Bidirectional Channels TIP#341: Multiple 'dict filter' Patterns One week voting period, close at 12:00 GMT on 9 December. Donal. |
From: Twylite <tw...@cr...> - 2008-12-02 16:00:48
|
For interest we've been using the proc below since starting work with the 8.5 betas. #** dictx get dictionary keyPath ?default? # Gets a value from a dictionary or returns a default (if the value does not # exist and a default is provided). Note that the dictionary key is given # as a path (a list of keys into a multilevel dict). proc ::dictx::get {dictionary keyPath args} { # Sanity check if { [llength $args] > 1 } { error "wrong # args: should be \"dictx get dictionary keyPath ?default?\"" } # If the caller has been naughty and not quoted keyPath as a list, then ensure # that we have at least 1 element (key) to pass to dict get if { [llength $keyPath] == 0 } { set keyPath [list $keyPath] } # Handle case where default is provided and there is no such key if { [llength $args] == 1 } { if { ! [dict exists $dictionary {*}$keyPath] } { return [lindex $args 0] } } # All other cases are as for "dict get" dict get $dictionary {*}$keyPath } This obviously treats the keys as a list (rather than separate args, as [dict] does in general), but it allowed us to combine get and getwithdefault functionality into one command (and working with [dict] get found that keypath-as-list suited us better, YMMV). I'd also offer good alcohol for a C implementation of the follow function: #** dictx pop varName key ?default? # Pops a value from a dict, unsetting the name from the dict variable and # returning the associated value. If the key does not exist in the dict then # the default is returned instead; if there is no default then an error # is thrown. proc ::dictx::pop {dictVar keyPath args} { upvar $dictVar mydict if { [llength $args] > 1 } { error "wrong # args: should be \"dictx pop varName key ?default?\"" } if { [dict exists $mydict {*}$keyPath] } { set value [dict get $mydict {*}$keyPath] } else { if { $args eq {} } { error "key \"$keyPath\" not known in dictionary" } set value [lindex $args 0] } dict unset mydict {*}$keyPath return $value } It is _ridiculously_ useful for parameter parsing, and a C implementation could give much better performance (there are at least 3 hash lookups on the same key: exists, get, unset). Example of use: proc mytoplevel {pathName args} { set title [dictx pop args -title] ;# required set copyright [dictx pop args -copyright {Copyright (C) 2008, My Company}] set bitmap [dictx pop args -bitmap {}] set quitcmd [dictx pop args -quitcmd {} ] if {$args ne {}} { error "unknown option \"[lindex $args 0]\"" } ... } ... it's too late to be asking for these things, isn't it? ;( Twylite Lars Hellström wrote: > TIP #342: DICT GET WITH DEFAULT > ================================= > Version: $Revision: 1.2 $ > Author: Lars Hellström <Lars.Hellstrom_at_residenset.net> > State: Draft > Type: Project > Tcl-Version: 8.6 > Vote: Pending > Created: Thursday, 27 November 2008 > URL: http://purl.org/tcl/tip/342.html > WebEdit: http://purl.org/tcl/tip/edit/342 > Post-History: > > ------------------------------------------------------------------------- > > ABSTRACT > ========== > > A new subcommand of *dict* is proposed, which returns a dictionary > value if it exists and returns a per-call default otherwise. > > SPECIFICATION > =============== > > The *dict* command will get a new subcommand > > *dict getwithdefault* /dictionary/ /key/ ?/key/ ...? /value/ > > (I consider the name of this subcommand very much open for discussion) > which modulo error messages behaves like > > proc dict_getwithdefault {D args} { > if {[dict exists $D {*}[lrange $args 0 end-1]]} then { > dict get $D {*}[lrange $args 0 end-1] > } else { > lindex $args end > } > } > > i.e., it returns the value from the /dictionary/ corresponding to the > sequence of /key/s if it exists, or the default /value/ otherwise. As > with *dict exists*, it is OK (and will cause the default /value/ to be > returned) if one of the /key/s is missing from its dictionary, but an > error is thrown if this path of keys cannot be traversed because the > value associated with the previous key is not a dictionary. > > RATIONALE > =========== > > It is clear that getting a value from a dictionary if it exists and > using a default otherwise is a common operation, but it is also clear > that this can be carried out with a combination of existing Tcl > commands. Hence the issue is whether a new subcommand for this improves > efficiency and convenience of this operation enough to justify the > possible bloat it brings. > > ALTERNATIVE METHODS > --------------------- > > One approach that has been suggested for providing default values is to > combine *dict get* with *dict merge*, like so: > > dict get [dict merge {-apa bar} $D] -apa > > This approach is however appropriate mainly in situations where several > keys are given fixed defaults simultaneously. Compared to *dict > getwithdefault*, it has the following disadvantages: > > * It cannot be used for keys in nested dictionaries. > > * It takes time proportional to the size of the dictionary, even > when only one value is inspected. Since *dict filter key* has an > optimisation for this kind of situation, there are apparently > maintainers which consider such differences relevant. > > * The "one *dict merge* early providing defaults for all keys" > approach cannot deal with keys that have dynamic defaults, e.g. > that the default for option -foo is the effective value of option > -bar. > > Hence although *dict merge* is sometimes appropriate for providing > defaults, it is not a universal solution. > > The basic approach is instead to, as in the *dict_getwithdefault* proc > above, first use *dict exists* and then *dict get* if the value > existed. Problems with this approach are: > > * It is redundant: already *dict exists* retrieves the value, but > doesn't return it, so *dict get* has to look it up all over > again. > > * It is bulky: if the value in dictionary /D/ of option *-apa* (or > its default *bar*) is to be passed as an argument to the command > *foo*, then the complete command is > > foo [if {[dict exists $D -apa]} then {dict get $D -apa}\ > else {return -level 0 bar}] > > or > > foo [expr {[dict exists $D -apa] ? [dict get $D -apa] : "bar"}] > > which many programmers would find objectionable. The *dict > getwithdefault* counterpart is merely > > foo [dict getwithdefault $D -apa bar] > > The only way to avoid the redundance of an extra look-up seems to be to > combine *dict get* with *catch*, like so: > > if {[catch {dict get $D -apa} value]} then {set value bar} else {set value} > > but this has the disadvantage of hiding other sources of error, such as > /D/ not being a dictionary in the first place. This kind of error in a > normal processing path is also considered poor style by some. > > IMPLEMENTATION CHOICES > ------------------------ > > Even if it is deemed appropriate to have a dedicated subcommand of > *dict* for this, it could be argued that it needn't be part of the > compiled Tcl core; since *dict* is an ensemble, anyone can extend it at > the script level and "the core can do without this bloat". However, it > turns out than an in-core implementation is very easy whereas the > alternatives are not so easy. > > Concretely, the necessary DictGetWithDefaultCmd is a trivial > modification of DictExistsCmd, to take one extra argument after the > /key/s and change the final > > Tcl_SetObjResult(interp, Tcl_NewBooleanObj(valuePtr != NULL)); > > to > > Tcl_SetObjResult(interp, valuePtr != NULL ? valuePtr : objv[objc-1]); > > It is nowhere near as easy to do this in a well-behaved extension, > since DictExistsCmd relies on TclTraceDictPath to do most of the work, > and the latter is AFAICT at best available in the internal stubs table. > > A script-level implementation is certainly possible, but the minute > details of producing core-looking error messages in this case appears > considerable both compared to the functional parts of the command and > compared to the amount of code needed to do it in the core. > > REFERENCE IMPLEMENTATION > ========================== > > An implementation is provided on SF, in patch #2370575. > [<URL:https://sourceforge.net/support/tracker.php?aid=2370575>] > > COPYRIGHT > =========== > > This document has been placed in the public domain. > > ------------------------------------------------------------------------- > > TIP AutoGenerator - written by Donal K. Fellows > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > > > |
From: Kenny, K. B (G. Research) <ke...@cr...> - 2008-12-02 15:56:00
|
TIP#234: Add Support For Zlib Compression YES TIP#244: PNG Photo Image Support for Tk YES And please, please, let's get the bundle-vs-depend issue sorted. Simply building our own copy of zlib on platforms where it is universally available is not acceptable. (But we probably *do* need to ship it with Tcl on Windows, where zlib is *not* universally available. -- 73 de ke9tv/2, Kevin |
From: Donal K. F. <don...@ma...> - 2008-12-02 15:44:44
|
Donald G Porter wrote: > Still have had no chance to review the actual substance. May not. > Note that the links to the implementation weren't working the last time I checked. I don't know what's wrong; looks like a server misconfig. (I suppose that's a good reason for encouraging people to not submit TIPs that say the implementation is on their own system...) Donal. |
From: Donald G P. <dg...@ni...> - 2008-12-02 15:37:16
|
Donal K. Fellows wrote: > Then you'd be in favour of (for example) Tcl_ZlibDeflate as a function > name (I prefer concrete examples) and no use of [package require zlib]? > That's certainly OK with me. It was a surprise to me to see that as an option, since my impression had been that distribution in bundled package form was the aim. But offered it as an option, yes, I'll gladly seize it since it's the easiest approach available. Still have had no chance to review the actual substance. May not. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
From: Donal K. F. <don...@ma...> - 2008-12-02 15:34:38
|
Donald G Porter wrote: > Routines matching Tcl_* that are part of the Tcl C interface are > available with only [package present Tcl]. No need to [package require] > anything else to get the complete Tcl interface. > > If folks won't agree to that, then my fallback position is that we > add no "phony" pacakges without an actual plan since we've botched > it so many times already. So show me the plan, and explain its value. > These details matter and are not something to toss in as an afterthought. Then you'd be in favour of (for example) Tcl_ZlibDeflate as a function name (I prefer concrete examples) and no use of [package require zlib]? That's certainly OK with me. Donal. |
From: Jan N. <nij...@us...> - 2008-12-02 15:33:48
|
2008/12/2 Jan Nijtmans <nij...@us...>: >>> or >>> dict get ?-default /value/? /dictionary/ /key/ ?/key/ ...? >> >> That's worse; forces the production of the string representation of the >> dictionary just so we can check to see if it is equal to "-default"! > > Agreed. On the other hand, we can check if the argument is already a list or a dict. A dict can never be equal to "-default" and neither can a list with >1 arguments. So we can prevent the need for generating the string representation if the argument is already a list or a dict. Regards, jan Nijtmans |
From: Jan N. <nij...@us...> - 2008-12-02 15:29:34
|
2008/12/2 Donal K. Fellows <don...@ma...>: >> How about: >> dict get /dictionary/ ?-default /value/? /key/ ?/key/ ...? > > What about if we want to use "-default" as the key? Insert "--" as the last switch. >> or >> dict get ?-default /value/? /dictionary/ /key/ ?/key/ ...? > > That's worse; forces the production of the string representation of the > dictionary just so we can check to see if it is equal to "-default"! Agreed. Regards, Jan Nijtmans |