tcl-core — Tcl Core Team discussions about Tcl development

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.

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

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

Adrian Robert wrote:
> I have been using the implementation on Mac and Windows for some months 
> without incident and I attach it as a patch here, as the tracker listing 
> at 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1477426&group_id=12997&atid=312997 seems 
> to be protected, perhaps members-only?

It's not "members only", it's "maintainers and submitter only". That's
how SF works. Submit a new patch; we won't mind!

Donal.

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

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

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.

this is a bikeshed of course, but I'm still partial to [tk  
fontchooser], which fits better with the widget / action pattern of  
the new API, i.e. [tk fontchooser show] rather than [tk_chooseFont  
show].

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).

Cheers,

Daniel

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

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

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

Hi Adrian,

On 24/11/2008, at 20:53, Adrian Robert wrote:

> Unless someone thinks further work is warranted, could this be  
> called for vote now?

please wait for another week to call for a vote on this, that is still  
inside the Dec 10 timeframe by a week and will give me some more time  
to work on this and edit the TIP.

Thanks

Cheers,

Daniel

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

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

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

Kevin Kenny wrote:
> Kevin Kenny wrote:
>>>   TIP #238: Fire Event when Widget Created
>> YES,  but see below.
> 
> Jeff Hobbs convinced me to reread the TIP, and I've come
> to realise that the specification there is Not Quite Right.
> Since we don't have a NOT YET vote, please change mine to
> NO.
> 
> It's not as bad as Jeff's message makes out. In particular,
> it's useful primarily because there isn't any convenient way
> to find out, right now, that a window actually exists; the
> closest thing we have at script level is to find out that
> it's been made visible, had its geometry requested, or mapped.
> (<Visibility>, <Configure> and <Map> respectively). None of
> these is quite right.
> 
> Moreover, simply delivering a putative <Create> notification
> through the existing binding mechanism ought to work fine.
> It is a rare case indeed for which widget creation doesn't
> make at least one trip through the event loop before making
> the window exist. In any case, the <Create> event is conceptually
> coming through the event loop. There is therefore a chance
> for the script that defines a window to define its bindtags
> before a <Create> has a chance to be delivered.
> 
> I think 238 is salvageable, but not while it's voting.

I want to know more about the extended rationale of this tip before it 
can be determined whether any specification is correct for the problem. 
  Let's go further on the toplevel issue.  I use toplevel because it is 
mentioned in the TIP.  One classic example for toplevels is certain 
display issues like the icon.  On Windows, Tk is able to specify the 
default icon, but on unix you need to specify it per-instance still.

The traditional way to do this is override toplevel (and I recommend 
that instead of this tip).  The reason this tip would not supplant the 
need is due to basing itself off [winfo class] - many toplevels would 
escape notice.

If other examples are more appropriate, I'd really like to see them.

Jeff

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

[Magentus <mag...@gm...>]

On Sun, 23 Nov 2008 17:47:25 +0000, 
"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.

For example; Is the value a guaranteed list?  Will it ever be a nested
list? Are the text sections (those that may include spaces) guaranteed
to be quoted to preserve the list beneath?  Will they (text sections)
always only be the last word(s) of the errorcode list?  Is there
anything else to act as an indicator to separate error hierarchy from
arguments/text that may be useful to an errorcode parser?

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


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 47 days, 23:23)

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

[Magentus <mag...@gm...>]

On Sun, 23 Nov 2008 19:55:51 +0200, 
Twylite <tw...@cr...> wrote:

>> In block (1), $var holds an open file handle;
>> in block (2) it holds an error message.
> This is of course what you get from [catch] at present.

>> Personally I'd prefer having different variable names
>> in the different branches:
> Your objection has been forwarded to Fredderic and NEM.

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

My main concern was the complexity of trying to fit everything into the
one statement.  If you try to match a decent-length error message, add
two decently descriptive variable names, a level or two of indenting,
and the handler command, you can all too easily end up having to split
it over two which is going to totally frag any hope of visual clarity.

A little effort on picking purpose-neutral variable names (as you have
to do with [catch] already) allows you to define it once up front, and
keep the individual handler lines short and sweet.  How's this as an
idea to combine the "no matching is needed" thoughts...

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

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.

This allows you omit the pattern string, and divide the inevitable
embedded [switch] statement into per-code blocks with whatever matcher
you wish:

    try {
      script
    } as {
      response options
    } return {
      switch -regexp ... {
        ... different kinds of OK response ...
      }
    } handler -- "POSIX *" {
      switch -exact -- [lindex $response 1] {
        ... match the gauntlet of Posix errorx ...
      }
    } on error {
      switch -- $response {
        ... traditional (bad) error returning ...
      }
    } expr {some freaky conditional stuff} {
      ... do the jolly jumbuck ...
    } finally {
      cleanup
    }

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).

Of course, it could be -pattern in place of just --, or something like
that.  I'd rather avoid -match here, because as another post suggests,
I'd like to see that used for a generic pattern matching framework that
wold be consistent across all TCL commands, and remove the constant
expanding mass of match type options.  (If I remember correctly we've
already had a clash between a match type option and a non-matching
option already, in which it was necessary to choose a new name for the
new option.)

You could even bring back per-handler vars, if you do use -pattern or
something in place of the simple --.  And if the -- sentinel is still
allowed as purely optional, then you don't even have the barely
relevant constraint that the handler body it can't be -vars or -pattern,
or a prefix thereof, AND not taking any arguments.

As far as I can tell, that pattern fits EVERYONE's present
requirements, and shouldn't be too much trouble to compile.


As as aside; extending (user-wise) it could be tricky (although I
suspect expanding it efficiently is anyhow), my personal preference
would be for an expansion to return a list with the number of arguments
consumed, and the outcome (whether the body has been evaluated already,
should be evaluated by [try], or didn't match).  Failing that, though,
the IMHO ugly [if] syntax will fix that reducing all cases (except
"as" :( ) to merely {handler options body} by grouping everything
between keyword and body in a mandatory list (not so good for
compiling, though, as I understand it).  The extensions, I'd suggest,
should either go in a ::tcl::try namespace, or have their own handler
command "with" or something.  I like the ::tcl::try namespace better
purely because it's more built-in-friendly.  But this whole paragraph
is an issue for another day anyhow.....


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 47 days, 22:12)