http://blog.gmane.org/gmane.comp.lang.tcl.core hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.tcl.core/9917 I've found several other posters with this same problem but I've never seen a solution offered. When starting any tk application (including wish) I get this: /usr/lib64/tk8.4/tk.tcl: no event type or button # or keysym no event type or button # or keysym while executing "bind Text <MouseWheel> { %W yview scroll [expr {- (%D / 120) * 4}] units }" My workaround is to comment these lines in listbox.tcl and text.tcl: --- text.tcl.orig 2008-10-07 09:01:39.000000000 -0700 +++ text.tcl 2008-10-07 10:38:57.000000000 -0700 < at >< at > -460,9 +460,9 < at >< at > %W xview scroll [expr {-10 * (%D)}] units } } else { - bind Text <MouseWheel> { - %W yview scroll [expr {- (%D / 120) * 4}] units - } +# bind Text <MouseWheel> { +# %W yview scroll [expr {- (%D / 120) * 4}] units +# } } The strange part is that only one of my two linux machines has this error (the amd64 machine) but I had the same error for awhile on my NetBSD machine. The NetBSD error fixed itself when I walt 2008-10-07T17:48:14 http://comments.gmane.org/gmane.comp.lang.tcl.core/9916 Hi I've been reviewing TIP#234 today (which describes a feature set that I'd really like to have in 8.6) and I've seen that it has a number of odd limitations and unfortunate features. This message is an attempt to write some of them down. I don't claim to have all the answers. :-) 1) Do we really want to publicise the streaming API? Maybe it would be fine to just provide a way to attach a streaming gzip/gunzip to a channel as a transformation (see [chan push]) and leave it at that. 2) The API for [zlib gzip] and [zlib gunzip] seems odd too. Why can't I control (for gzip) or discover (for gunzip) the metadata? For the gzipper, it'd probably be best to express this as a set of options (the compression level would be best done the same way) but I'm not quite so sure about for gunzip. 3) Is it necessary to give a buffer size, or is letting Tcl pick one itself "good enough"? (After all, we give a buffer growth algorithm in the TIP!) Let me be clear ag Donal K. Fellows 2008-10-07T15:42:01 http://comments.gmane.org/gmane.comp.lang.tcl.core/9915 Voting is now closed on TIPs 327 and 328, both are ACCEPTED: TIP #327: Proper tailcalls YES: Fellows, Kenny, Nijtmans, Sofer TIP #328: Coroutines YES: Fellows, Kenny, Nijtmans, Sofer Miguel ------------------------------------------------------------------------- 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=/ miguel sofer 2008-10-07T11:08:54 http://comments.gmane.org/gmane.comp.lang.tcl.core/9914 There will be a release of Tcl/Tk this Friday, October 10, 2008, but it will be labeled 8.6a3, and not 8.6b1 as previously announced. The new target date for 8.6b1, and the feature freeze that goes with it is approximately December 1, 2008. The recent flood of TIP activity has simply bitten off more than we can fully digest by Friday. And even that flood has left a number of key proposals undone. This rescheduling of feature freeze will also permit the gathering of feedback on new features from those at the conference before those features get frozen. Donald G Porter 2008-10-06T15:10:01 http://comments.gmane.org/gmane.comp.lang.tcl.core/9911 TIP 323 proposed many changes along the same theme. Most of those changes were compatible in our usual sense. Those have been committed to HEAD. A few proposed changes to [string first|last|replace] are incompatible in the handling of empty substrings. That was the whole point of the proposal, to stop the jarring special treatment of empty substrings. However, after going through the exercise of creating the patch and testing against existing code bases, it's apparent that there are at least some scripts and packages that rely on the very behavior that I find jarring. The incompatibility is not as harmless as I assumed writing those parts of the proposal. So, I will not commit the changes to [string], and I will delete those parts of the proposal from TIP 323 before marking it Final. If someone wants to bring those proposals up again as a separate TIP where we can more carefully hash out the compatibility issues, I don't object. Donald G Porter 2008-09-29T16:18:24 http://comments.gmane.org/gmane.comp.lang.tcl.core/9910 I'm worried about the interaction between TIP#327's [tailcall] and custom control structures, e.g. the likes of TIP#329's [try]. It seems to me that there is a big bunch of unspecified behaviour in this area, which could shroud breaking some fundamental principles for Tcl, even if it can be argued that it doesn't break compatibility since the new behaviour is only triggered by a new command. First, what works: If one defines proc test-foreach {prefix list} { foreach x $list { tcl::unsupported::tailcall {*}$prefix $x } } then [test-foreach {format -%s-} {foo bar baz}] returns -foo-, as one should expect from the [return [uplevel ...]] analogy in the TIP. Second, what's unclear: Suppose I want a try-finally style command with a body to be evaluated and which does some cleanup afterwards. Classically (well, post-TIP#90) that should be something like proc once {body} { # Before-code catch {uplevel 1 $body} res opt # After-code return -options $opt $res } so for test p Lars Hellström 2008-09-29T13:59:18 http://comments.gmane.org/gmane.comp.lang.tcl.core/9906 Voting is now closed on TIP's 330 and 331: Results of the ballot: TIP #330: Eliminate interp->result from the Public Headers YES: English, Fellows, Kenny, Nijtmans, Porter, Sofer TIP #331: Allow [lset] to Extend Lists YES: English, Kenny, Nijtmans, Porter, Sofer PRESENT: Fellows Both TIPs PASS. -- 73 de ke9tv/2, Kevin ------------------------------------------------------------------------- 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=/ Kenny, Kevin B (GE, Research 2008-09-30T17:09:40 http://comments.gmane.org/gmane.comp.lang.tcl.core/9905 Repeating my message from last month, I intend to release Tcl/Tk 8.6b1 on or about October 10, 2008. I received no responses to my invitation to delay that deadline, so I plan to stick to that absent some really compelling issue. Donald G Porter 2008-09-30T14:40:15 http://comments.gmane.org/gmane.comp.lang.tcl.core/9903 Trying a resend. This message didn't appear yesterday, AFAICT. -------- Original Message -------- From: Donald G Porter <dgp-R3+/ord2DXQ< at >public.gmane.org> Subject: TIP 323 (Do Nothing Gracefully) Epillogue TIP 323 proposed many changes along the same theme. Most of those changes were compatible in our usual sense. Those have been committed to HEAD. A few proposed changes to [string first|last|replace] are incompatible in the handling of empty substrings. That was the whole point of the proposal, to stop the jarring special treatment of empty substrings. However, after going through the exercise of creating the patch and testing against existing code bases, it's apparent that there are at least some scripts and packages that rely on the very behavior that I find jarring. The incompatibility is not as harmless as I assumed writing those parts of the proposal. So, I will not commit the changes to [string], and I will delete those parts of the proposal from TIP 323 before marking it Final. If someone Donald G Porter 2008-09-30T13:00:23 http://comments.gmane.org/gmane.comp.lang.tcl.core/9899 This is the call for votes on the two tips that move new NRE-enabled functionality from ::tcl::unsupported to :: TIP #327: Proper tailcalls TIP #328: Coroutines Please submit your votes by [clock format 1223344800], a week plus epsilon from now. My votes: TIP #327: YES TIP #328: YES Cheers Miguel ------------------------------------------------------------------------- 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=/ miguel sofer 2008-09-30T00:55:21 http://comments.gmane.org/gmane.comp.lang.tcl.core/9896 Also do not forget the mkstemp() bug #878333 of IRIX systems. Until now you have to manually patch tcl to create tclkit interpreters. rene ------------------------------------------------------------------------- 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=/ Rene Zaumseil 2008-09-26T06:09:43 http://comments.gmane.org/gmane.comp.lang.tcl.core/9890 TIP #332: HALF-CLOSE FOR BIDIRECTIONAL CHANNELS ================================================= Version: $Revision: 1.1 $ Author: Alexandre Ferrieux <alexandre.ferrieux_at_gmail.com> State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Thursday, 25 September 2008 URL: http://purl.org/tcl/tip/332.html WebEdit: http://purl.org/tcl/tip/edit/332 Post-History: Obsoletes: TIP #301 ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes to extend the *close*/*chan close* commands to let them perform an unidirectional "half-close" on bidirectional channels. BACKGROUND ============ Bidirectional channels (sockets and command pipelines) allow Tcl to make an efficient use of a "filter process", by exchanging data back and forth over an abstract "single" channel. However, this single channel abstraction comes with a too coarse-grained *close* primitive. In Alexandre Ferrieux 2008-09-25T15:07:46 http://comments.gmane.org/gmane.comp.lang.tcl.core/9869 The tcl-bugs mailing list that mostly just distributes commit messages is bouncing messages. Am I the only one seeing this? Any ideas for a remedy? Donald G Porter 2008-09-24T14:23:09 http://comments.gmane.org/gmane.comp.lang.tcl.core/9854 For whatever it's worth, a reference implementation for TIP #330 is available at SourceForge as patch #2125223. http://sourceforge.net/tracker/index.php?func=detail&aid=2125223&group_i d=10894&atid=310894 Kenny, Kevin B (GE, Research 2008-09-23T21:15:37 http://comments.gmane.org/gmane.comp.lang.tcl.core/9853 On Tue, Sep 23, 2008 at 5:35 PM, Donal K. Fellows <donal.k.fellows-m7QheJJv02N4oUbgFh0ZNQ< at >public.gmane.org> wrote: This one is almost completely nulled by (accepted) 304 [chan pipe]. Indeed, the initial motivation of the split was typically to close the write-side of a command pipeline so that the child gets an EOF while we're still listening to its output. With 304, it is now trivially done: lassign [chan pipe] pr pw set ch [open "|cmd << at > $pr" r] close $pr ... close $pw set final_word [read $ch] I said "almost" because there is also the important case of sockets and the shutdown() syscall, allowing to close independently halves of its duplex channel. But invoking the heavy machinery of a channel splitter for this (instead of adding a [chan shutdown] to sockets) is an overkill. Are there other similar cases ? (For example, is it meaningful to do the same to a serial device ? Can we send an EOF on the write side of COMx and still read ? Alternatively, can't we _always_ Alexandre Ferrieux 2008-09-23T20:46:16 http://comments.gmane.org/gmane.comp.lang.tcl.core/9850 I'm breaking my usual practice and calling the vote immediately on the two TIPs: TIP #330: Eliminate interp->result from the Public Headers TIP #331: Allow [lset] to Extend Lists The reason is that (a) I'd really like to have time to get these in before the 8.6 feature freeze, and (b) they're sufficiently trivial that editorial changes are unlikely to fix them if they aren't good enough to pass as they stand. Either they pass or they fail. Votes to me by [clock format 1222790400] (2008-09-30 16:00 UTC). My ballot: TIP #330: YES TIP #331: YES Kenny, Kevin B (GE, Research 2008-09-23T17:36:08 http://comments.gmane.org/gmane.comp.lang.tcl.core/9847 Now that we're through the big TIP vote, we should also consider which of the other TIPs in Draft ought to have a little TLC applied to them so we can vote them in. This is _my_ selection... #97: Moving Vertices of Canvas Items #154: Add Named Colors to Tk #160: Improvements to Terminal and Serial Channel Handling #161: Change Default for Menu's -tearoff Option to False #162: IPv6 Sockets for Tcl (possibly...) #164: Add Rotate Subcommand to the Canvas Widget #166: Reading and Writing the Photo Image Alpha Channel #180: Add a Megawidget Support Core Package #210: Add 'tempname' Subcommand to 'file' #228: Tcl Filesystem Reflection API #234: Add Support For Zlib Compression #244: PNG Photo Image Support for Tk #262: Background Images for Frames #276: Specify and Unify Variable Linking Commands #281: Improvements in System Error Handling #301: Split Bidirectional Channels For Half-Close (possibly...) #324: A Standard Dialog Donal K. Fellows 2008-09-23T15:35:22 http://comments.gmane.org/gmane.comp.lang.tcl.core/9843 In the Tcl package, there are 2 man pages which are installed with :: in their names: pkg::create.n platform::shell.n In the Tk package at least, the man pages of commands with :: in them are installed with a single _ in place of the ::. I was wondering whether there is an intentional reason for the exception in the above two man pages. If there are man commands which have problems with :: (and I can imagine that being the case - Solaris used to have problems with that, back in the day, I believe), then it would seem that all the man pages should be named without the ::. However, if there is no longer an issue using ::, then it might make the man pages a bit easier to find if the :: were present in the names. Virden, Larry W. 2008-09-23T14:25:45 http://comments.gmane.org/gmane.comp.lang.tcl.core/9840 TIP #330: ELIMINATE INTERP->RESULT FROM THE PUBLIC HEADERS ============================================================ Version: $Revision: 1.2 $ Author: Kevin B. Kenny <kennykb_at_acm.org> State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Monday, 22 September 2008 URL: http://purl.org/tcl/tip/330.html WebEdit: http://purl.org/tcl/tip/edit/330 Post-History: ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes to eliminate the long-deprecated /interp/->/result/ field from the public headers. PROPOSAL ========== The include file /tcl.h/ is to be modified so that the /result/ field of the /Tcl_Interp/ data structure will be renamed to /unused1/ unless a preprocessor symbol, *USE_INTERP_RESULT* is defined. Note that this change leaves the /result/ field in the internal /Interp/ data structure untouched, and all the code that manipulates it will s Kevin B. Kenny 2008-09-23T09:40:39 http://comments.gmane.org/gmane.comp.lang.tcl.core/9839 TIP #331: ALLOW [LSET] TO EXTEND LISTS ======================================== Version: $Revision: 1.1 $ Author: Kevin B. Kenny <kennykb_at_acm.org> State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Monday, 22 September 2008 URL: http://purl.org/tcl/tip/331.html WebEdit: http://purl.org/tcl/tip/edit/331 Post-History: ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes to modify the *lset* command to allow it to extend lists. PROPOSAL ========== The *lset* command shall be modified to allow the index /end+1/ (or any equivalent index designating the element one beyond the last element of the list). For the simple usage: lset list end+1 foo the effect is the same as if the script had evaluated the command: lappend list foo For the usage: lset list $n end+1 foo the effect is much the same as if the script had evaluated Kevin B. Kenny 2008-09-23T09:40:41 http://comments.gmane.org/gmane.comp.lang.tcl.core/9838 TIP #329: TRY/CATCH/FINALLY SYNTAX ==================================== Version: $Revision: 1.2 $ Author: Trevor Davel <twylite_at_crypt.co.za> State: Draft Type: Project Tcl-Version: 8.6 Vote: Pending Created: Monday, 22 September 2008 URL: http://purl.org/tcl/tip/329.html WebEdit: http://purl.org/tcl/tip/edit/329 Discussions-To: http://wiki.tcl.tk/21608 Post-History: Obsoletes: TIP #89 ------------------------------------------------------------------------- ABSTRACT ========== This TIP proposes the addition of new core commands to improve the exception handling mechanism. It supercedes [TIP #89] by providing support for the error options dictionary introduced in Tcl 8.5 by [TIP #90]. RATIONALE =========== See [TIP #89] for general rationale for enhancing exception handling. The *try...catch* syntax presented here is not intended to replace *catch*, but to simplify the expression of existin Trevor Davel 2008-09-23T09:40:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.tcl.core