tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Jeff H. <je...@ac...>]

Koen Danckaert wrote:
> Joe English wrote:
>> TIP#306: NO.
>> 
>> This one does not play nicely with third-party widget sets or with
>> megawidget packages.  For the former, it places additional 
>> constraints on widget constructors.  I have no idea how it will
>> interact with the latter, though I suspect the answer is "not very
>> well".
> 
> The TIP describes how mega-widget packages can support the
> auto-naming scheme. It's really a minor effort.
> 
> When the TIP was first discussed on this list, Will Duquette (the
> author of Snit) said he would like to see it happen.
> 
> Note that the TIP doesn't break compatibility: any application that
> works today (which obviously doesn't use auto-naming), will continue
> to work in the future.

This is so blatantly wrong with a 30 second glance at what's important 
that anyone who voted yes deserves a right spanking.  This TIP would 
break BWidgets, and I don't need to look any further.  The TIP blatantly 
warns on this issue.  Stop the insanity and poor thinking - you break 
something as basic as that, you will _not_ make a happy community.

Jeff

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Joe E. <jen...@fl...>]

Donal K. Fellows wrote:

> The way in which [try] works has got to be this:
>
>    set code [catch $firstbody $msgVar $optVar]
>    set handler [pick handler based on $code [set $msgVar] [set $optVar]]
>    set code2 [catch $handler msg2 opt2]
>    eval $finallybody
>    if {$code2 != 0} {		<== this isn't right
>    ^^^^^^^^^^^^^^^^^^
>       set code $code2; set $msgVar $msg2; set $optVar $opt2
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       # This part (^^^) should be unconditional
>    }
>    return -code $code -options [set $optVar] [set $msgVar]
>
> Or something like that. I've spent as long on that as it took to type.

The result of [try] should be the result of the handler clause,
regardless of whether it succeeds or not.

It should be:

	set code [catch $mainScript value opts]
	if {some clause '{XXX resultVar optsVar} handlerScript' matches} {
	    set $resultVar $value ; set $optsVar $opts
	    set code [catch $handlerScript value opts]
	}
	eval $finallyScript	;# exceptions propagate
	# here: $finallyScript yielded TCL_OK
	return -code $code -options $opts $value


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

On Tue, Nov 25, 2008 at 07:44:32PM +0200, Twylite wrote:
> >If you think, that embedding switches is a good idiom, then 
> >why not just match the [lindex $errorCode 0] ...

> Because that's so unspecific as to be worthless in most cases.  This 
> would allow you to distinguish between (say) POSIX errors and ARITH 
> errors, but in most cases where you need to branch based on the type of 
> error you are distinguishing between two very similar errors (an IO 
> timeout error versus an IO read error, ...

Ok. Agreed.  That is common enough to justify an idiom
more concise than a nested switch.

Even  {CHILDKILLED * SIGSEGV *} may have its use. The errorCodes
thrown from core appear to have been carefully crafted to be
reasonably glob-able.  At this point in time, glob appears like
the perfect hammer for the nail, but nails are likely going to
change when programmers get more into the habit of creating new
errorCodes for their applications, and introducing ambiguities,
that could have been avoided by list patterns in the first place.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Joe E. <jen...@fl...>]

Magentus asked:
> Donal K. Fellows wrote:
> > Subtype descriptors are separate words, as you would know if you'd
> > ever actually looked at them! Here's a couple of real examples:
>
> Could you, then, post right here a formal specification (or link to
> same on the tcl.tk site) of what the errorcode looks like, just as a
> marker point to set this part of the discussion straight.

See return(3tcl), section "RETURN OPTIONS", subsection
"-errorcode".  See also tclvars(3tcl), section 'errorCode'.
See also error(3tcl), section "DESCRIPTION", last paragraph.
Or grep the source code.


> I think without a formal description of what errorcodes actually are,
> this sub-thread has been chasing its own tail just a little.

Yes.  If the participants in the thread better understood
the nature of the problem to be solved we could maybe
get some focus here.


--JE

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> If you think, that embedding switches is a good idiom, then 
> why not just match the [lindex $errorCode 0] with a glob or 
> even exactly, and leave further matching to embedded switches?
> Still better than globbing a list, imho.
>   
Because that's so unspecific as to be worthless in most cases.  This 
would allow you to distinguish between (say) POSIX errors and ARITH 
errors, but in most cases where you need to branch based on the type of 
error you are distinguishing between two very similar errors (an IO 
timeout error versus an IO read error, a connect error versus a read 
error versus an authentication error, etc.). 
In addition any third-party package that wants to avoid naming conflicts 
is probably going to use the package name (or company name, or some 
other distinguished identifier) as the most general class of exception, 
which would make matching on [lindex $errorCode 0] virtually useless.

Regards,
Twylite

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

On Tue, Nov 25, 2008 at 12:57:57PM +0000, Donal K. Fellows wrote:
> Andreas Leitgeb wrote:
> >One point of "try" and it's error-filtering is to make all unhandled
> >exceptions fall through, run the finally block and then get rethrown.

> The way in which [try] works has got to be this:
>   set code [catch $firstbody $msgVar $optVar]
>   set handler [pick handler based on $code [set $msgVar] [set $optVar]]
>   set code2 [catch $handler msg2 opt2]
>   eval $finallybody
>   if {$code2 != 0} {
>      set code $code2; set $msgVar $msg2; set $optVar $opt2
>   }
>   return -code $code -options [set $optVar] [set $msgVar]

Ok, that mutes some doubt I had.  Anyway, nested switches would need
to explicitly re-throw errors not handled.  Not a big issue, but it
shrinks the advantage of [try] against old [catch {...}].

> All that is missing is the code to actually pick the handler script,
> which in turn should be kept simple as well.
> >PS: Is it really that hard to call non-inlined matcher-commands from
> >  generated bytecode?
> 
> It's even more trivial to compile a script. Guess what? You can just put
> that stuff in the script in the first place.

Well, you said, that bytecoding a more advanced matcher/picker would be
exorbitantly more complex, so I wondered if calling out to a separate
command to do the picking wouldn't help to prevent that exponential
explosion of effort bytecoding a saner check.

> So why do we need a generalized matcher architecture?
> Answer: We don't. So why are you developing one?
Here is a little difference between me and Fredderic.

I do not primarily envision all those pluggable handlers, but
I'm very unhappy with using glob-matching on lists(*). Since I do
not see any chance to stop that particular train heading wrong
direction, I do hope for some spare rails that would at least 
allow the next train (8.7 or so) to go in a better direction,
while not derailing this current train on its trip.

*:
I really thought the paradigm was to *reduce* the number of
places where lists are stringified...

If you think, that embedding switches is a good idiom, then 
why not just match the [lindex $errorCode 0] with a glob or 
even exactly, and leave further matching to embedded switches?
Still better than globbing a list, imho.

> Not "astronomer", "astronaut". With reference to
>  http://www.joelonsoftware.com/articles/fog0000000018.html
Ok, this definition doesn't suit me that well.  I may lose
ground with some visions, but hardly ever for high abstractions.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Colin M. <co...@ch...>]

Magentus wrote:
>     try script
>     as {vars}
>     handler ?-- errorcode-pattern? body
>     return ?-- returnvalue-patten? body
>     on {code ?-- returnvalue-pattern?} body
>     finally body
>   


With all due respect, that's a hairy nightmare and I wouldn't use it on 
principle (the principle is that anything with *that* many arguments is 
too hard to keep in my head while coding.)

Is there really no way you can simplify it to do one thing, that's hard 
to do without it, and do it well?

Just, perhaps, [try {} finally {}] ... that's simple, even I can 
remember that one, and have a reasonable guess at what it might do, and 
anything more complex occurs (say) in the 'finally' block.

(Oh, and before anyone asks, I don't think 
try/as/handler/return/on/finally would benefit from NULLs)

Colin.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> And also:
>    http://www.acmqueue.org/modules.php?pa=showpage&pid=505&name=Content
>
> I hold architecture astronautics in contempt. Reminds me too much of
> work and of how projects can go wrong for failing to focus on critical
> details.
>   
Very well.  Here is the proposal:

--
  try tscript ?as {emvar ?optsvar?}? ?handler ...? finally fscript
where handler is one of:
  on code hscript
  trap pattern hscript

code may be any integer or the magic values ok, return, error, break, 
continue.
trap handles only return code error where pattern is a glob match 
against the -errorcode.
only one handler's hscript is executed, and it will be the first 
matching handler in left-to-right order.  If the hscript is the literal 
"-" then the hscript for the next handler (in left to right order) shall 
be used. The result of executing the hscript is the result of the [try].
exceptions in the hscript replace the original exception and propagate 
(no further handlers are searched). 
any unhandled exception is propagated.
fscript is executed regardless of success or exceptions, and is done 
after the handler (if any) is executed.  Exceptions in the fscript 
replace the original (or hscript) exception and propagate, otherwise the 
result of fscript is discarded.
If an exception is replaced (by one in hscript and/or fscript) then the 
new exception shall introduce a field to its options dict the contains 
all details of the original exception (forming a chain of exceptions).
emvar and optsvar, if specified, will always be populated with details 
of the outcome of tscript.

To complement [try] there shall also be a new command [throw] to 
encourage the use of the trap facility.

  throw type message
where type is a list that will become the -errorcode.  throw is 
equivalent to [error $message {} $type]
--

Opportunity for future extension:
- If the handlers presented are shown to be insufficient for common use 
cases, it will be possibly to add more handler types (using keywords 
other than "on", "trap"). 
- If the variables that capture exception information are insufficient, 
additional vars can be added to the "as" list without affecting 
compatibility
- If all else fails, options can be added between try and tscript (as 
with switch & friends).

Sample implementation to follow.

Sadly it will be some time before I can gain value from this function 
myself.
Not until the third-party libraries I am tied to - which require me to 
parse the (non-localised) result - are updated to produce an errorcode.
Not until I find enough time on or between projects to refactor legacy 
code (core libraries that I depend on and use in pretty much all new 
utilities and applications) to use errorcode rather than (or, for 
backwards compatibility, in addition to) a list structure in the result.
Not in places where I need to maintain code that allocates & frees more 
than 2 resources, which can be done cleanly using finally callbacks, but 
otherwise sends you to the depths of nested try/finally blocks and you 
can't see the wood for the error-and-cleanup-handling trees.

But hey, I'm an astronaut, what would I know about this real-world stuff?

Twylite

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Daniel A. S. <da...@us...>]

On 25/11/2008, at 9:12, Adrian Robert wrote:

> IMHO the API difference does not outweigh the overall similarity to  
> these other
> tk_ commands, which all deal with short-term, special purpose
> dialogs.  If the decision is to distinguish it though, I'd rather not
> do something as drastically new and different as to put it in a
> different namespace.

exporting [fontchooser] from tk:: will actually help with that of  
course, as you can then just [namespace import] it.

we're bikeshedding between a '_' and a ' ' in the syntax at this point  
though...

>  (The "tk_" prefix for the other commands is already strange enough  
> and I wish it didn't exist.)

surely inroduced out of a desire to avoid collisions with user  
commands from a pre-namespace era...
in general, I think Tk should strive to behave more like a standard  
tcl package and (with new commands) not pollute the global namespace  
unnecessarily, esp with the advent of ensembles.

> BTW, re: modeless dialogs, as far as I'm aware file open/save are  
> generally modal on OS X.  Is this not true?


no, only the legacy OS9-back-compatible file dialogs are all modal,  
the modern save dialogs are sheets (i.e. modeless or more specifically  
document-modal).

similarly with the color picker, the modern variant is modeless,  
exactly like the font panel.

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Adrian R. <adr...@gm...>]

On Nov 25, 2008, at 3:26 AM, Daniel A. Steffen wrote:

> Hi Adrian,
>
> On 24/11/2008, at 20:53, Adrian Robert wrote:
>
>> - returned the implementation to use the command name given in the  
>> TIP: "tk_chooseFont"
>
> as explained before, the rationale for using a command name outside  
> of the existing tk_* naming scheme was to make it clear to the user  
> that the subcommand API is significantly different to the tk_*  
> dialog commands.

I don't feel strongly and will go along with whatever, but IMHO the  
API difference does not outweigh the overall similarity to these other  
tk_ commands, which all deal with short-term, special purpose  
dialogs.  If the decision is to distinguish it though, I'd rather not  
do something as drastically new and different as to put it in a  
different namespace.  (The "tk_" prefix for the other commands is  
already strange enough and I wish it didn't exist.)

BTW, re: modeless dialogs, as far as I'm aware file open/save are  
generally modal on OS X.  Is this not true?


-Adrian

Re: [TCLCORE] CFV on small high-prio TIPs

[Koen D. <ko...@re...>]

Joe English wrote:
> TIP#306: NO.
> 
> This one does not play nicely with third-party widget sets
> or with megawidget packages.  For the former, it places additional
> constraints on widget constructors.  I have no idea how
> it will interact with the latter, though I suspect the answer
> is "not very well".

The TIP describes how mega-widget packages can support the auto-naming scheme. It's really a minor effort.

When the TIP was first discussed on this list, Will Duquette (the author of Snit) said he would like to see it happen.

Note that the TIP doesn't break compatibility: any application that works today (which obviously doesn't use auto-naming), will continue to work in the future. 


>>   TIP #171: Change Default <MouseWheel> Bindings Behavior
> 
> Definitely need to look at this some more.  It just
> doesn't smell right to me.  One thing in particular:
> instead of going through all sorts of rigamarole at
> the scripting level to redirect MouseWheel events
> to the widget under the pointer on Windows, wouldn't
> it make more sense to simply not redirect them to
> the focus window in the first place (see tkEvent.c,
> InvokeFocusHandlers)?  That's how it's currently done
> on OSX.  I suspect it also interferes with some of
> the ttk::* widgets.

In the past, there has been some discussion about this TIP, and several potential issues were raised. For example, the current implementation goes in an infinite loop with the following simple code:

pack [text .t]
bind .t <MouseWheel> {puts "wheel"}
# Now try to scroll the text widget with the mousewheel

Part of the discussion involved promoting the <MouseWheel> event to <Tab> status, but there was no agreement on that. Nevertheless, it seems this TIP is going to be accepted now...

I agree with Joe that an alternative approach would be better: redirecting the mousewheel events to the widget under the mouse pointer. In fact, I'm already doing that (in my own Tk builds) since a long time. See below for the patch.

--Koen




Index: generic/tkEvent.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/generic/tkEvent.c,v
retrieving revision 1.37
diff -u -r1.37 tkEvent.c
--- generic/tkEvent.c	8 Nov 2008 18:44:39 -0000	1.37
+++ generic/tkEvent.c	25 Nov 2008 11:34:05 -0000
@@ -246,17 +246,7 @@
 	return 1;
     }
 
-    /*
-     * MouseWheel events are not focus specific on Mac OS X.
-     */
-
-#ifdef MAC_OSX_TK
-#define FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask)
-#else
-#define	FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask|MouseWheelMask)
-#endif
-
-    if (mask & FOCUS_DIRECTED_EVENT_MASK) {
+    if (mask & (KeyPressMask|KeyReleaseMask)) {
 	(*winPtrPtr)->dispPtr->lastEventTime = eventPtr->xkey.time;
 	*winPtrPtr = TkFocusKeyEvent(*winPtrPtr, eventPtr);
 	if (*winPtrPtr == NULL) {
Index: win/tkWinX.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/win/tkWinX.c,v
retrieving revision 1.58
diff -u -r1.58 tkWinX.c
--- win/tkWinX.c	27 Apr 2008 22:39:17 -0000	1.58
+++ win/tkWinX.c	25 Nov 2008 11:34:08 -0000
@@ -1006,6 +1006,16 @@
     ThreadSpecificData *tsdPtr = (ThreadSpecificData *)
 	    Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));
 
+    /* Redirect mousewheel events to the widget under the pointer. */
+    if (message == WM_MOUSEWHEEL) {
+        POINTS rootPoint = MAKEPOINTS(lParam);
+        POINT pos;
+        pos.x = rootPoint.x;
+        pos.y = rootPoint.y;
+        hwnd = WindowFromPoint(pos);
+        winPtr = (TkWindow *) Tk_HWNDToWindow(hwnd);
+    }
+
     if (!winPtr || winPtr->window == None) {
 	return;
     }
@@ -1103,11 +1113,6 @@
 	break;
 
     case WM_MOUSEWHEEL:
-	/*
-	 * The mouse wheel event is closer to a key event than a mouse event
-	 * in that the message is sent to the window that has focus.
-	 */
-
     case WM_CHAR:
     case WM_UNICHAR:
     case WM_SYSKEYDOWN:

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Donal K. F. <don...@ma...>]

Donal K. Fellows wrote:
> Not "astronomer", "astronaut". With reference to
>   http://www.joelonsoftware.com/articles/fog0000000018.html

And also:
   http://www.acmqueue.org/modules.php?pa=showpage&pid=505&name=Content

I hold architecture astronautics in contempt. Reminds me too much of
work and of how projects can go wrong for failing to focus on critical
details.

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Donal K. F. <don...@ma...>]

Andreas Leitgeb wrote:
> One point of "try" and it's error-filtering is to make all unhandled
> exceptions fall through, run the finally block and then get rethrown.

The 'finally' block gets run in all (trappable) cases.

> What would be the standard idiom with "switch inside a handler body",
> to get this behaviour from the switch's default block? 

You use [return] with right options to rethrow an exception, but you
also only trap the stuff that is appropriate in the first place. None of
which has anything to do with 'finally' processing.

The way in which [try] works has got to be this:

   set code [catch $firstbody $msgVar $optVar]
   set handler [pick handler based on $code [set $msgVar] [set $optVar]]
   set code2 [catch $handler msg2 opt2]
   eval $finallybody
   if {$code2 != 0} {
      set code $code2; set $msgVar $msg2; set $optVar $opt2
   }
   return -code $code -options [set $optVar] [set $msgVar]

Or something like that. I've spent as long on that as it took to type.
All that is missing is the code to actually pick the handler script,
which in turn should be kept simple as well.

> PS: Is it really that hard to call non-inlined matcher-commands from
>   generated bytecode?

It's even more trivial to compile a script. Guess what? You can just put
that stuff in the script in the first place. So why do we need a
generalized matcher architecture? Answer: We don't. So why are you
developing one? (That's the part I find hard...)

> PPS: I do also feel addressed by "astronomer", and I don't feel
>   insulted by this classification in this context.

Not "astronomer", "astronaut". With reference to
  http://www.joelonsoftware.com/articles/fog0000000018.html

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

"Donal K. Fellows" <don...@ma...> wrote:
> But tackling the more complex cases with code inside the handler blocks
> is exactly the right thing.

One point of "try" and it's error-filtering is to make all unhandled
exceptions fall through, run the finally block and then get rethrown.

What would be the standard idiom with "switch inside a handler body",
to get this behaviour from the switch's default block? 

PS: Is it really that hard to call non-inlined matcher-commands from
  generated bytecode?

PPS: I do also feel addressed by "astronomer", and I don't feel
  insulted by this classification in this context.

[TCLCORE] TIP#234 Status

[Donal K. F. <don...@ma...>]

Hi Pascal

Is TIP#234 ready to roll (and the implementation acceptably close)? It
doesn't look far off it to me, but I'm not close enough to the detail to
be sure.

The primary remaining question is whether the C API is sufficient for
implementing a PNG reader on top of it in short order. My guess is that
it is (i.e. we can also do TIP#244) but it'd be nice to have a reality
check. :-)

I'd be happy with monosyllabic answers, BTW. No need to spend ages on
replying if you're busy.

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Andreas L. <av...@lo...>]

Fredderic <mag...@gm...> wrote:
> "Donal K. Fellows" <don...@ma...> wrote:
> > Subtype descriptors are separate words, as you would know if you'd
> > ever actually looked at them! Here's a couple of real examples:
> 
> Could you, then, post right here a formal specification (or link to
> same on the tcl.tk site) of what the errorcode looks like, just as a
> marker point to set this part of the discussion straight.

It's in the tclvars man page (and surely also in the html-pendants)

It is a list, the first element of which gives the type, and thereby
determines the interpretation of the rest. For those types thrown by
the core these interpretations are also given (ARITH,POSIX,...).

With all the changes in progress, and the global variable errorCode 
practically vanishing, it may be necessary to move it's explanation
to "error", "catch", "throw" and/or "try" docs.

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Daniel A. S. <da...@us...>]

On 25/11/2008, at 10:28, Daniel A. Steffen wrote:

> so these commands will become inoperative in a future version of Mac  
> OS X Tk

or better fallback to the pure-tcl implementation for back-compat...

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@ca...> **

Re: [TCLCORE] a meta-TIP for "NOT YET"-votes ?

[Alexandre F. <ale...@gm...>]

On Tue, Nov 25, 2008 at 10:27 AM, Andreas Leitgeb <av...@lo...> wrote:
> Kevin Kenny <ke...@ac...> wrote:
>> Since we don't have a NOT YET vote, ...
>
> I think, I read a line like this about every other CFV.
>
> What would it take to add a "NOT YET" officially, to
> remove the need for this phrase?  just curious :-)

Why not just withdraw the CFV on those TIPs, leaving them in Draft status ?

-Alex

Re: [TCLCORE] a meta-TIP for "NOT YET"-votes ?

[Donal K. F. <don...@ma...>]

Andreas Leitgeb wrote:
> What would it take to add a "NOT YET" officially, to
> remove the need for this phrase?  just curious :-)

Our official procedure in this matter is described in TIP#0.

Donal.

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Daniel A. S. <da...@us...>]

Hi Donal,

On 25/11/2008, at 10:18, Donal K. Fellows wrote:

> Daniel A. Steffen wrote:
>> it would also have the advantage to allow future additions to [tk]   
>> with the same [configure/show/hide] style for the color chooser  
>> and  file dialogs that can accommodate the modeless versions of  
>> these on  Mac OS X (the modal versions currently used by Tk are all  
>> legacy and  are likely to go away in the not too distant future).
>
> You've got to continue to support the modal operation for  
> computability
> with Windows, where the dialogs are modal.


oh definitely, but the [configure/show/hide] model can do that as  
shown by the TIP 324 implementation (where the dialog is modal on  
Windows and modeless on Mac OS X).
There is no way that the existing dialog commands like  
[tk_chooseColor] can support a modeless dialog API however, so these  
commands will become inoperative in a future version of Mac OS X Tk  
and we will need an alternative that can support both modal and modeless

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **

[TCLCORE] a meta-TIP for "NOT YET"-votes ?

[Andreas L. <av...@lo...>]

Kevin Kenny <ke...@ac...> wrote:
> Since we don't have a NOT YET vote, ...

I think, I read a line like this about every other CFV.

What would it take to add a "NOT YET" officially, to
remove the need for this phrase?  just curious :-)

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Donal K. F. <don...@ma...>]

Donal K. Fellows wrote:
> You've got to continue to support the modal operation for computability
> with Windows, where the dialogs are modal.

Aargh! I meant "compatibility". Damn you spellchecker!

Donl.

Re: [TCLCORE] TIP 324 (font chooser dialog in tk)

[Donal K. F. <don...@ma...>]

Daniel A. Steffen wrote:
> it would also have the advantage to allow future additions to [tk]  
> with the same [configure/show/hide] style for the color chooser and  
> file dialogs that can accommodate the modeless versions of these on  
> Mac OS X (the modal versions currently used by Tk are all legacy and  
> are likely to go away in the not too distant future).

You've got to continue to support the modal operation for computability
with Windows, where the dialogs are modal.

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Donal K. F. <don...@ma...>]

Magentus wrote:
> Could you, then, post right here a formal specification (or link to
> same on the tcl.tk site) of what the errorcode looks like, just as a
> marker point to set this part of the discussion straight.

No, it was never thought necessary.

But I can point out that the function at the C level that builds the
errorcode builds a list from its arguments, and has been documented to
do so since... well, it's documented in the Ousterhout book, so that
makes it at least 15 years old. While strictly you can build it yourself
directly, nobody does.

See the 'tclvars' manual page for what formal information we have, and
'Tcl_SetErrorCode' for the constructor function.

> I think without a formal description of what errorcodes actually are,
> this sub-thread has been chasing its own tail just a little.

Yes, and you've been one of the main sources of misinformation.

Donal.

Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Donal K. F. <don...@ma...>]

Magentus wrote:
> If the vars can be shoe-horned into each branch optionally, or at least
> not too ugly, I'm all for it, personally.

I'm against it.

> My main concern was the complexity of trying to fit everything into the
> one statement.

That's a good joke. Or are you serious? You're already far too complex.

> The -- "option" here indicates there is a pattern to match, but will
> later be the place holder for the match type if there's consensus that
> "beyond-glob" matching is needed.

There is no such consensus outside the design astronautics practised on
this list over the past few days. Note that in this period "the
astronauts" have wholly failed to persuade any TCT member that such
complexity is a good idea.

Additionally, the use of "--" in this way is wholly unacceptable. The
only acceptable use of that option is to mean "end of options" to the
overall command.

> This allows you omit the pattern string, and divide the inevitable
> embedded [switch] statement

It's not inevitable at all, no matter how much you've convinced yourself
otherwise. Time to come back to earth, Mr. Astronaut.

> into per-code blocks with whatever matcher you wish:

But tackling the more complex cases with code inside the handler blocks
is exactly the right thing. Glob matching on the errorCode is the
exception to this, and only because it makes an existing feature of Tcl
far more usable than before.

> 
>     try {
[...]
>     } expr {some freaky conditional stuff} {
>       ... do the jolly jumbuck ...

Include an 'expr' clause only if you wish to guarantee that I'll vote
against it.

> Clean, minimal if you want it to be, hugely flexible when you need it,
> you can add other types of pattern matching later (the sentinel is
> there for when it's needed, AND it's actually being used so it'll
> already be there avoiding future compatibility issues), and you can
> still allow for plugging in other types of [try] keyword (in place of
> as, handler, on, expr, and finally).

It's also a wholly impractical amount of effort to implement, especially
in compiled form.

> As far as I can tell, that pattern fits EVERYONE's present
> requirements,

No it doesn't. It fails my requirement for simplicity.

> and shouldn't be too much trouble to compile.

So says the person who has never written a bytecode compiler. They're
really much more awkward to do than a normal C-implemented Tcl command,
and the more complexity there is, the worse it gets (non-linearly). In
particular, there is no chance for flexibility of matchers as we're not
exposing the bytecode compilation interface. Since it is required that
the script arguments to [try] be compiled efficiently (there's a real
chance that people will put loops inside without "declaring" the
variable outside) we will just drop the less-important flexibility
requirement. Which means that all your complexity can be thrown away
anyway since we won't support that sort of thing.

Indeed, of this entire discussion the only thing that was at all
persuasive was the idea of putting the variables to store the matched
stuff only once (the 'as' clause). Perhaps I should summarize the
non-crap bits and call a vote; after all, waiting for consensus among
the astronauts is a) going to take too long, and b) unlikely to produce
anything practical anyway.

Donal.