Menu
▾
▴
tcl-core
|
From: Donal K. F. <don...@ma...> - 2008-09-10 15:29:11
|
The following TIPs are ready/close to votable:
Close:
#89 (drop [throw], rework [try] to take account of #90)
#97 (needs implementation, should be straight-forward)
#167 (needs minor fixes; see TIP comments for what/why)
#197 (needs implementation)
#210 (needs implementation)
#238 (needs implementation)
#262 (needs implementation)
#301 (needs implementation)
#325 (needs implementation)
Ready:
#195: A Unique Prefix Handling Command
#236: Absolute Positioning of Canvas Items
#240: An Ensemble Command to Manage Processes
#252: Add New 'string' Command Options
#265: A Convenient C-side Command Option Parser for Tcl
#308: Tcl Database Connectivity (TDBC)
#312: Add More Link Types (note that the title is in error; some minor
editorial work to do here)
#313: Inexact Searching in Sorted List
#314: Ensembles with Parameters
#315: Add pathSeparator to tcl_platform Array
#316: Portable Access Functions for Stat Buffers
#318: Extend Default Whitespace in 'string trim' Beyond ASCII
#320: Improved Variable Handling in the Core Object System
#321: Add a tk::busy Command
#323: Do Nothing Gracefully
#326: Add -group Option to lsort
I've probably missed things from this list; they're just the things that
look like low-hanging fruit. :-)
Donal.
|
|
From: Donal K. F. <don...@ma...> - 2008-11-18 16:31:32
|
Hi everyone... I've got a list of all the open TIPs that can target 8.6 still here. I'll categorize them in ways that I think are fairly natural. Note that the High/Medium/Low classification is entirely my opinion, but is based on my opinion of what is practical and/or important. Accepted and needing implementation ——————————————————————————————————— TIP #119 Angled Text on a Canvas I've almost got an implementation of this. TIP #141 Multiple Initial-Files in [tk_getOpenFile] What was the problem with this one again? Was it Windows being a PITA? TIP #150 Implement the Tk send Command for Windows This would be simultaneously "nice" and "scary". Does the latter outweigh the former, and if so, should we Withdraw this TIP? High Priority and demanding of real effort —————————————————————————————————————————— TIP #162 IPv6 Sockets for Tcl TIP #171 Change Default <MouseWheel> Bindings Behavior TIP #180 Add a Megawidget Support Core Package TIP #197 Text Widget Persistant Cursor TIP #210 Add 'tempname' Subcommand to 'file' TIP #234 Add Support For Zlib Compression TIP #238 Fire Event when Widget Created TIP #244 PNG Photo Image Support for Tk TIP #281 Improvements in System Error Handling TIP #284 New 'invoke' and 'namespace invoke' Commands TIP #306 Auto-Naming Widgets TIP #307 Make TclTransferResult() Public TIP #329 Try/Catch/Finally syntax TIP #335 Controlled Interpreter Deletion via Tcl_InterpActive TIP #336 Supported Access To interp->errorline TIP #337 Make TclBackgroundException() Public TIP #338 Embedder Access to Startup Scripts of *_Main() Medium Priority and in search of a champion ——————————————————————————————————————————— TIP #86 Improved Debugger Support TIP #106 Add Encoding Abilities to the [dde] Command TIP #154 Add Named Colors to Tk TIP #160 Improvements to Terminal and Serial Channel Handling TIP #164 Add Rotate Subcommand to the Canvas Widget TIP #166 Reading and Writing the Photo Image Alpha Channel TIP #167 Add a New Option for Context Help for Windows TIP #186 Expose the Type and Modified-State of Widget Options TIP #198 Image Command XPM Extension TIP #225 Arithmetic Series with Optimized Space Complexity TIP #228 Tcl Filesystem Reflection API TIP #239 Enhance the 'load' Command TIP #240 An Ensemble Command to Manage Processes TIP #243 Supply Find Dialog for the Text Widget TIP #246 Unify Pattern Matching TIP #259 Making 'exec' Optionally Binary Safe TIP #262 Background Images for Frames TIP #276 Specify and Unify Variable Linking Commands TIP #277 Create Namespaces as Needed TIP #278 Fix Variable Name Resolution Quirks TIP #279 Adding an Extensible Object System to the Core TIP #282 Enhanced Expression Syntax TIP #283 Modify Ensemble Command Resolution Behaviour TIP #295 Enhance Arguments to lrange TIP #297 Integer Type Introspection and Conversion TIP #302 Fix "after"'s Sensitivity To Adjustments Of System Clock TIP #309 Expose the Expression Parsing TIP #322 Publish the NRE API TIP #324 A Standard Dialog For Font Selection TIP #325 System Tray Access TIP #332 Half-Close for Bidirectional Channels TIP #333 New Variable and Namespace Resolving Interface Low Priority and in search of someone who cares ——————————————————————————————————————————————— TIP #133 Extending [expr] Operators TIP #170 Better Support for Nested Lists TIP #193 Simple Syntax Help System TIP #220 Escalate Privileges in VFS Close Callback TIP #224 Add New [array] Subcommands 'incr' and 'value' TIP #253 Consolidate Package-Related Commands TIP #288 Allow "args" Anywhere in Procedure Formal Arguments TIP #290 Registration of Custom Error Handler Scripts TIP #292 Allow Unquoted Strings in Expressions TIP #296 Enhanced Syntax for Pair-Wise Indices TIP #303 Enhance 'llength' Command to Support Nested Lists TIP #312 Add More Link Types Probable Bad Ideas likely to get rejected ————————————————————————————————————————— TIP #178 [info pid] and [info tid] Subcommands Cannot be made portable, ever. TIP #214 Add New Object Introspection Command API is wrong. Functionality is dodgy. Perhaps something along these lines could go in tcl::unsupported TIP #216 Handling Command-Line Options in Tclsh and Wish Better to have other executables for this sort of thing TIP #271 Windows-Style Open and Save File Dialog on Unix Doesn't need a TIP; just needs someone to spruce up the patch, remove the API changes, and apply it. (The API can't change as it is limited by what we can hack into the Windows side of things.) TIP #319 Implement Backwards Compatibility for ttk Themed Widgets in tk Widgets I think this is a bad idea from the off; Ttk widgets aren't the classic Tk widgets. (Better would be making sure that people distributing Tk on Unix had high quality native themes for Ttk so as to discourage this sort of thing...) Too new for me to have formed an opinion about! ——————————————————————————————————————————————— TIP #339 Case-Insensitive Package Names TIP #340 Const Qualification of Tcl_SetResult's Argument and -Wwrite-strings Well, that's about it. I make that out to be 1 real Accepted (2 sliding towards Withdrawn) and 17 strong candidates for Acceptance for 8.6. Any and all discussion welcome. Donal. |
|
From: Donald G P. <dg...@ni...> - 2008-11-18 16:38:33
|
Thanks for driving the discussion. Donal K. Fellows wrote: > Well, that's about it. I make that out to be 1 real Accepted (2 sliding > towards Withdrawn) and 17 strong candidates for Acceptance for 8.6. Any > and all discussion welcome. Before I jump in on the details, let me lay down an additional proposed constraint. I'd like all TIP voting targeting 8.6 to be completed no later than Dec. 10, 2008. Preferably that will allow all Accepted implementations to be committed by Dec. 12, and 8.6b1 could get a release the following week, that is, by Dec. 19. That's not much time, especially keeping in mind the half week or so of holiday time in the US next week. Make your priorities accordingly. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Joe E. <jen...@fl...> - 2008-11-18 19:40:09
|
Donal K. Fellows wrote: > I've got a list of all the open TIPs that can target 8.6 still here. > [...] > High Priority and demanding of real effort: > TIP #180 Add a Megawidget Support Core Package Same as before: publish this as an extension first, let it cook for a while as people use it, and if it ends up being useful *then* decide whether to integrate it into the core. Remember TIP#48! > TIP #197 Text Widget Persistant Cursor I still don't understand the motivation behind this one. > TIP #210 Add 'tempname' Subcommand to 'file' Same as before: change the order of the arguments from file tempfile ?template? ?namevar? to file tempfile ?namevar? ?template? and it's good to go. As currently specified, it forces callers to supply a template if they want to get the filename back. One of the main points of the TIP is for Tcl to take care of all the hairy platform-specific details of where temp files should go; the propsed interface defeats that. > TIP #329 Try/Catch/Finally syntax I'd really like to see this in 8.6. However, I also think it's essential that try/catch be able to dispatch based on the return code, not just $::errorCode, which the current specification does not provide for. Please fix! > TIP #307 Make TclTransferResult() Public > TIP #337 Make TclBackgroundException() Public These are no-brainers; obvious YES votes on these. > TIP #338 Embedder Access to Startup Scripts of *_Main() This one too. > TIP #238 Fire Event when Widget Created > TIP #162 IPv6 Sockets for Tcl > TIP #171 Change Default <MouseWheel> Bindings Behavior > TIP #234 Add Support For Zlib Compression > TIP #244 PNG Photo Image Support for Tk > TIP #281 Improvements in System Error Handling > TIP #284 New 'invoke' and 'namespace invoke' Commands > TIP #306 Auto-Naming Widgets > TIP #335 Controlled Interpreter Deletion via Tcl_InterpActive > TIP #336 Supported Access To interp->errorline No opinion ATM on these. > Medium Priority and in search of a champion > [...] > Low Priority and in search of someone who cares > [...] No comment on these. > Probable Bad Ideas likely to get rejected > TIP #178 [info pid] and [info tid] Subcommands > TIP #214 Add New Object Introspection Command > TIP #216 Handling Command-Line Options in Tclsh and Wish > TIP #271 Windows-Style Open and Save File Dialog on Unix Agree that these are Bad Ideas. > TIP #319 Implement Backwards Compatibility for ttk Themed Widgets > in tk Widgets And everybody gets a pony! But seriously: I tried to make this work. It didn't. The AMSN folks tried a different approach with Chameleon, and got farther than I did; suggest people look there. The approach suggested by the TIP sounds completely unworkable to me. --Joe English |
|
From: Jeff H. <je...@ac...> - 2008-11-18 19:45:44
|
Joe English wrote: > Donal K. Fellows wrote: > >> I've got a list of all the open TIPs that can target 8.6 still here. >> [...] >> High Priority and demanding of real effort: >> TIP #180 Add a Megawidget Support Core Package > > Same as before: publish this as an extension first, let it > cook for a while as people use it, and if it ends up being > useful *then* decide whether to integrate it into the core. > Remember TIP#48! ... >> TIP #319 Implement Backwards Compatibility for ttk Themed Widgets >> in tk Widgets > > And everybody gets a pony! > > But seriously: I tried to make this work. It didn't. > The AMSN folks tried a different approach with Chameleon, > and got farther than I did; suggest people look there. > The approach suggested by the TIP sounds completely unworkable > to me. I think these TIPs are tied. The core ttk widgets should operate in their ideal state, without "bogus" options. There should be a layer on top for compat should users want that. Ideally this would be done with a megawidget support layer in the core. You can do it now with snidgets, but something tcloo-based would be ideal (eating our own dogfood). Jeff |
|
From: Donal K. F. <don...@ma...> - 2008-11-18 20:55:24
|
Jeff Hobbs wrote: [Re #180 and #319] > I think these TIPs are tied. The core ttk widgets should operate in > their ideal state, without "bogus" options. There should be a layer on > top for compat should users want that. Ideally this would be done with > a megawidget support layer in the core. You can do it now with > snidgets, but something tcloo-based would be ideal (eating our own dogfood). I've already done some simple megawidgets with TclOO; it wasn't hard. See http://wiki.tcl.tk/21103 for my experiments in the area (it demonstrates the creation of both new options and new methods, and does so both on top of plain Tk widgets and Ttk widgets). FWIW, I think the aspects of #180 that are good are that it talks about providing common support for handling options. That's the sort of thing that a core class ought to give you (and which I didn't work hard on in my experimenting). Donal. |
|
From: Donal K. F. <don...@ma...> - 2008-11-19 11:18:05
|
Joe English wrote: > Donal K. Fellows wrote: > >> I've got a list of all the open TIPs that can target 8.6 still here. >> [...] >> High Priority and demanding of real effort: >> TIP #180 Add a Megawidget Support Core Package > > Same as before: publish this as an extension first, let it > cook for a while as people use it, and if it ends up being > useful *then* decide whether to integrate it into the core. I'm talking to Damon about this out-of-band. (Timezone differences slow communication a bit, but I think we're making good progress. There's a fair chance that it will end up as a pure Tcl package.) > Remember TIP#48! And the Alamo too! >> TIP #197 Text Widget Persistant Cursor > > I still don't understand the motivation behind this one. On Win and OSX, the cursor doesn't show when the focus isn't in the text widget. This is correct *most* of the time, but not always. For example, when you're using a full text editor, it can be very useful to see where you are working even when the focus is elsewhere. I'm not quite sure whether there's enough control over the look of the non-focus cursor, but that's a separate thing. >> TIP #210 Add 'tempname' Subcommand to 'file' > > Same as before: change the order of the arguments from > > file tempfile ?template? ?namevar? > to > file tempfile ?namevar? ?template? > > and it's good to go. As currently specified, it forces callers > to supply a template if they want to get the filename back. > One of the main points of the TIP is for Tcl to take care > of all the hairy platform-specific details of where temp files > should go; the propsed interface defeats that. Sounds good to me. Donal. |
|
From: Donal K. F. <don...@ma...> - 2008-11-20 10:52:33
|
Joe English wrote: >> TIP #210 Add 'tempname' Subcommand to 'file' > > Same as before: change the order of the arguments from > > file tempfile ?template? ?namevar? > to > file tempfile ?namevar? ?template? > > and it's good to go. As currently specified, it forces callers > to supply a template if they want to get the filename back. > One of the main points of the TIP is for Tcl to take care > of all the hairy platform-specific details of where temp files > should go; the propsed interface defeats that. I've revised the TIP to swap those arguments as suggested. (While the TIP previously allowed template to be blank, that was still messy and non-obvious!) I've also made it much clearer what the template format actually is, and I hope that someone can check that I've not messed it up in the process. Assuming I've not blundered, it's now good to go. Donal. |
|
From: Joe E. <jen...@fl...> - 2008-11-20 17:49:12
|
Donal K. Fellows wrote: > >> TIP #210 Add 'tempname' Subcommand to 'file' > [...] > I've revised the TIP to swap those arguments as suggested. (While the > TIP previously allowed template to be blank, that was still messy and > non-obvious!) I've also made it much clearer what the template format > actually is, and I hope that someone can check that I've not messed it > up in the process. Assuming I've not blundered, it's now good to go. Thank you! The revised synopsis looks good -- exactly right in fact -- and fixes the other complaint (namely that the interpretation of $template was underspecified). Can we issue a CFV on this one? --JE |
|
From: Brett S. <bre...@ya...> - 2008-11-18 20:51:40
|
> > Joe English wrote: > > Donal K. Fellows wrote: > > > >> I've got a list of all the open TIPs that can target 8.6 still here. > >> [...] > >> High Priority and demanding of real effort: > >> TIP #180 Add a Megawidget Support Core Package > > > > Same as before: publish this as an extension first, let it > > cook for a while as people use it, and if it ends up being > > useful *then* decide whether to integrate it into the core. > > Remember TIP#48! > ... > >> TIP #319 Implement Backwards Compatibility for ttk Themed Widgets > >> in tk Widgets > > > > And everybody gets a pony! > > > > But seriously: I tried to make this work. It didn't. > > The AMSN folks tried a different approach with Chameleon, > > and got farther than I did; suggest people look there. > > The approach suggested by the TIP sounds completely unworkable > > to me. > > I think these TIPs are tied. The core ttk widgets should operate in > their ideal state, without "bogus" options. There should be a layer on > top for compat should users want that. Ideally this would be done with > a megawidget support layer in the core. You can do it now with > snidgets, but something tcloo-based would be ideal (eating our own dogfood). > FWIW, I like this approach... ------------------------------------------------------------------------- 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: Arnulf W. <ar...@wi...> - 2008-11-18 21:19:38
|
Am Dienstag, 18. November 2008 17:31:28 schrieb Donal K. Fellows: > TIP #333 New Variable and Namespace Resolving Interface > I would volunteer to make a prototype implementation in the core for that one (for 8.7), but would need at least some help/suggestions from Miguel or others?, as I am not sure about some of the consequences/sideeffects the implementation would have. Arnulf (apw) |
|
From: Donal K. F. <don...@ma...> - 2008-11-18 21:39:46
|
Arnulf Wiedemann wrote: > Am Dienstag, 18. November 2008 17:31:28 schrieb Donal K. Fellows: >> TIP #333 New Variable and Namespace Resolving Interface >> > I would volunteer to make a prototype implementation in the core for that one > (for 8.7), but would need at least some help/suggestions from Miguel or > others?, as I am not sure about some of the consequences/sideeffects the > implementation would have. That's why it's not on the top-priority list. Being a little bit brutal, we want to push to get in what we can, but we have to focus to get done what we can. I think your TIP needs a bit more work than that to work out what the consequences are (if you can get someone to do it, great, but I'm putting my effort elsewhere). As DGP said, there's not that long left until we feature-freeze 8.6... Donal. |
|
From: David G. <dav...@po...> - 2008-11-19 00:02:23
|
Donal K. Fellows wrote: > TIP #162 IPv6 Sockets for Tcl Years back, I added IPv6 capability to a socket channel driver extension. I thought about that one quite a lot about 3 years ago. The big problem with adding v6 regards name resolution fundamentals. TCP/IP isn't the only networking layer there is, and it wouldn't be prudent to restrict the generic layer to IP naming concepts alone. It'll take me a bit to get up to speed again, but I can head this one. 1) real async multi-protocol (IP/dns,IPX/SAP,IrDA/IAS,AppleTalk,etc..) name resolver with support for all three types: static, dynamic and persistent resolution systems. Maybe fix Tcl_PosixError(), or the error message calls around it, so it can support the errors found in netdb.h so we can get back meaningful error messages that can distinguish HOST_NOT_FOUND from TRY_AGAIN instead of the current meaningless EINVAL. 2) A plugin system for extensions to insert new protocols at run-time or internally when compiled in. 3) Allow for calls such as the following: socket 3ffe:b80:185d:1::29 ftp socket -protocol spx FEDCBA98.1A2B3C5D7E9F 0453 When the IPX/SPX module has been installed -^ 4) Maybe update the windows channel driver code to use WSAEventSelect() with job pooling and get away from the ancient Win 3.1 holdover of WSAAsyncSelect() |
|
From: Donal K. F. <don...@ma...> - 2008-11-19 10:17:14
|
David Gravereaux wrote: > 1) real async multi-protocol (IP/dns,IPX/SAP,IrDA/IAS,AppleTalk,etc..) > name resolver with support for all three types: static, dynamic and > persistent resolution systems. I think that's going far more complex. Just TCP over IP/IPv6 with standard name resolution (async if you can manage it) would be good. Yes, it's a limited ambition. It's also much easier to get it all specced up and voted through by Don Porter's deadline. :-) Remember, the broad strategy is to keep Tcl 8.6 on track for a Spring 2009 final release. We took far too long with both 8.4 and 8.5... > Maybe fix Tcl_PosixError(), or the error message calls around it, so it > can support the errors found in netdb.h so we can get back meaningful > error messages that can distinguish HOST_NOT_FOUND from TRY_AGAIN > instead of the current meaningless EINVAL. That I approve of; isn't it TIP#281 (another of the high prio ones)? > 2) A plugin system for extensions to insert new protocols at run-time or > internally when compiled in. > > 3) Allow for calls such as the following: > socket 3ffe:b80:185d:1::29 ftp > socket -protocol spx FEDCBA98.1A2B3C5D7E9F 0453 > > When the IPX/SPX module has been installed -^ These things are probably complex enough that they need to be postponed until 8.7. Let's not hold up the release while waiting for perfection. > 4) Maybe update the windows channel driver code to use WSAEventSelect() > with job pooling and get away from the ancient Win 3.1 holdover of > WSAAsyncSelect() Is that something that wouldn't appear at the script or API level? If so, it's pure implementation and doesn't need to be run past the TIP process. (I forget what our minimum version is, but it's sure quite a lot later than Win3.1! :-D) Donal. |
|
From: David G. <dav...@po...> - 2008-11-20 19:38:26
|
Donal K. Fellows wrote: > Remember, the broad strategy is to keep Tcl 8.6 on track for a Spring > 2009 final release. We took far too long with both 8.4 and 8.5... Well, then IPv6 won't hit for 8.6 then... I work a real job, too :) There is just too much work to do in FIXING the broken stuff BEFORE adding new functionality. I haven't even brought up QoS yet. 1) [socket -async foo.example.com 1234] blocks on DNS rather than being async as requested. 2) proper DNS errors are lost. 3) WinSock code is in dire need of a revamp to a decade ago's methodologies. 4) Tcl_OpenTcp(Client|Server) both take an int value for the port values instead of a string. This places a network protocol understanding requirement into the generic code to resolve port names (generic/tclIOSock.c). Not a big deal really, but I'd like to see either the signatures change, or a new level of indirection so that protocol specifics don't have be in the generic side of Tcl_SocketCmd(). True, the BSD socket call getservbyname() is consistent across platforms, and was probably the reason why Scott Stanton put it there, but there was extra work on the windows side through C macros to allow it to go through the winSockProcs function table (now removed by Pat Thoyts). But a larger issue exists here that restricts Tcl_SocketCmd from being the general entry for all network stream creation and even resolution. Some network protocols use a tuple arrangement like IPX and AppleTalk, but I don't really see a problem combining network and node into the one address string. 5) What's up with UDP and message based channels? |
|
From: Harald O. <Har...@El...> - 2008-11-26 14:59:44
|
Donal K. Fellows wrote: > Medium Priority and in search of a champion > ——————————————————————————————————————————— > TIP #106 Add Encoding Abilities to the [dde] Command I have written this TIP in 2002. If DDE will not be dropped from the core soon I may care about an implementation of the TIP. IMHO this will not be ready for 8.6. Harald |
|
From: WANGNICK S. <seb...@eu...> - 2008-09-10 15:42:40
|
Dear all,
I don't see the necessity for TIP#236. Compute dx and dy, then move all
stuff by the delta. Neither tedious nor inefficient.
Kind regards,
Sebastian
--
Sebastian <dot> Wangnick <at eurocontrol dot int>
Team Leader ENG/OPE/HMI, Product Owner Controller Working Position
Systems
Eurocontrol Maastricht UAC, Horsterweg 11, NL-6199AC Maastricht-Airport,
+31-43-3661-370
-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Donal K.
Fellows
Sent: Wednesday 10 September 2008 17:29
To: Tcl Core List
Subject: [TCLCORE] TIP Roundup
The following TIPs are ready/close to votable:
Close:
#89 (drop [throw], rework [try] to take account of #90)
#97 (needs implementation, should be straight-forward)
#167 (needs minor fixes; see TIP comments for what/why)
#197 (needs implementation)
#210 (needs implementation)
#238 (needs implementation)
#262 (needs implementation)
#301 (needs implementation)
#325 (needs implementation)
Ready:
#195: A Unique Prefix Handling Command
#236: Absolute Positioning of Canvas Items
#240: An Ensemble Command to Manage Processes
#252: Add New 'string' Command Options
#265: A Convenient C-side Command Option Parser for Tcl
#308: Tcl Database Connectivity (TDBC)
#312: Add More Link Types (note that the title is in error; some
minor
editorial work to do here)
#313: Inexact Searching in Sorted List
#314: Ensembles with Parameters
#315: Add pathSeparator to tcl_platform Array
#316: Portable Access Functions for Stat Buffers
#318: Extend Default Whitespace in 'string trim' Beyond ASCII
#320: Improved Variable Handling in the Core Object System
#321: Add a tk::busy Command
#323: Do Nothing Gracefully
#326: Add -group Option to lsort
I've probably missed things from this list; they're just the things that
look like low-hanging fruit. :-)
Donal.
------------------------------------------------------------------------
-
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
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X