tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] [PATCH] unix-menus: Make Tk menu activation follow mouse movement.

[Larry M. <lm...@bi...>]

> Overall: +1, this is a definite improvement and should go in.

I don't get a vote but +1 from the sidelines.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] [PATCH] unix-menus: Make Tk menu activation follow mouse movement.

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

Pat Thoyts wrote:
>
> I am posting this to tcl-core to get some idea of how people feel about
> changing the way Tk menus work on X11. At the moment Tk menus have what
> amounts to a click-to-focus mode. However, every other current toolkit
> seems to be using a focus-follows-mouse mode. What I mean is that on
> Windows or a GNOME window, when you click on a menubar item and it drops
> down a cascade menu, then moving the mouse around will automatically
> dropdown other menus as you move around. Currently the user has to click
> to open each and every cascade menu.

The patch makes top-level menubars feel much better --
dropdown on hover instead of dragdown is definitely
the way to go.  (One minor issue with the patch: if
the mouse moves into a blank area of the menubar
it unposts the menu; this is disconcerting for clumsy
mousers like myself.  It should leave the current
menu posted.)

For cascaded submenus, it's mixed.  There ought to be a
slight (~50ms?) delay before posting the submenu when the
mouse moves over a cascade entry.  It's a small thing,
most people might not even notice, but failing to do so
can make the menu completely unusable if the menu is close
to the right edge of the screen and the submenu is wide
enough that posting it obscures the first menu.

(OTOH, this condition could equally well be considered a
bug in the application: menu too complex to be usable.
On the *other* other hand, this is very likely to affect
the "Help" menu unless we also abandon the CUA/Win95/Motif
convention of shoving that over to the right.)

(Personally, I prefer Tk's current click-to-post model
for cascaded submenus -- again, clumsy mouser -- but
concede that on the whole the proposed behavior is better.
I'll just deal with it.)

> The patch here changes how this works for popup menus and menubars but
> doesn't make any provision for the inevitable dinosaur who wants it to
> stay working the way it always has done. If we feel that a flag should
> be added to restore the old method, then what should it be called?

My usual recommendation here is "feel free to override
the bindings in your application", but given the size
and complexity of the Tk menu code that's probably not
practical advice.

Adding another option, though, would make the menu code
even bigger and more complex, and almost certainly buggier.
Not worth it IMO unless it can be implemented with low
impact to complexity.

Overall: +1, this is a definite improvement and should go in.


--Joe English

  jen...@fl...

Re: [TCLCORE] The .help menu position.

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

On 23/12/2009 14:12, Pat Thoyts wrote:
> Another request for comments on Tk menus changes...
>
> I would like to stop the ancient practice of sticking the .help menu to
> the far right of the screen on X11 as this is now an out-moded
> practice.

It should still be the right-most menubar item, but need not be
otherwise special. I think every app I've used for a long time puts it
as the last item. Mind you, that's probably where the programmer puts it
anyway since that's needed for getting the menu right on non-X11...

Donal.

Re: [TCLCORE] [PATCH] unix-menus: Make Tk menu activation follow mouse movement.

[Damon C. <da...@tc...>]

Awesome.  I've done this myself a few times but never submitted the  
code.  I agree with Jeff too, the change to the location of the .help  
menu should be tied to this as some TIP on modernizing menus in X11.

D


On Dec 23, 2009, at 5:35 AM, Pat Thoyts wrote:

>
> This patch makes Tk menus on unix follow mouse motion in the same
> way Windows and GNOME menus follow the mouse. Once a menubar dropdown
> has been activated, moving the mouse to another menu button will  
> activate
> the dropdown without needing another click.
>
> Signed-off-by: Pat Thoyts <pat...@us...>
>
> ---
>
> I am posting this to tcl-core to get some idea of how people feel  
> about
> changing the way Tk menus work on X11. At the moment Tk menus have  
> what
> amounts to a click-to-focus mode. However, every other current toolkit
> seems to be using a focus-follows-mouse mode. What I mean is that on
> Windows or a GNOME window, when you click on a menubar item and it  
> drops
> down a cascade menu, then moving the mouse around will automatically
> dropdown other menus as you move around. Currently the user has to  
> click
> to open each and every cascade menu.
>
> The patch here changes how this works for popup menus and menubars but
> doesn't make any provision for the inevitable dinosaur who wants it to
> stay working the way it always has done. If we feel that a flag should
> be added to restore the old method, then what should it be called?
>
> ---
> library/menu.tcl |    8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/library/menu.tcl b/library/menu.tcl
> index a2d9109..c25b93f 100644
> --- a/library/menu.tcl
> +++ b/library/menu.tcl
> @@ -406,6 +406,8 @@ proc ::tk::MenuUnpost menu {
>     # Unpost menu(s) and restore some stuff that's dependent on
>     # what was posted.
>
> +    unset -nocomplain Priv(menuActivated)
> +
>     catch {
> 	if {$mb ne ""} {
> 	    set menu [$mb cget -menu]
> @@ -557,7 +559,7 @@ proc ::tk::MenuMotion {menu x y state} {
> 	    GenerateMenuSelect $menu
> 	}
>     }
> -    if {($state & 0x1f00) != 0} {
> +    if {[info exists Priv(menuActivated)]} {
> 	$menu postcascade active
>     }
> }
> @@ -600,6 +602,9 @@ proc ::tk::MenuButtonDown menu {
> 		set Priv(cursor) [$menu cget -cursor]
> 		$menu configure -cursor arrow
> 	    }
> +	    if {[$menu type active] eq "cascade"} {
> +		set Priv(menuActivated) 1
> +	    }
>         }
>
> 	# Don't update grab information if the grab window isn't changing.
> @@ -1311,6 +1316,7 @@ proc ::tk_popup {menu x y {entry {}}} {
>         tk::SaveGrabInfo $menu
> 	grab -global $menu
> 	set Priv(popup) $menu
> +	set Priv(menuActivated) 1
> 	tk_menuSetFocus $menu
>     }
> }
> -- 
> 1.6.2
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast  
> and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] The .help menu position.

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

On 2009-12-23, at 3:12 PM, Pat Thoyts wrote:
> Another request for comments on Tk menus changes...
> 
> I would like to stop the ancient practice of sticking the .help menu to
> the far right of the screen on X11 as this is now an out-moded
> practice. No other toolkit appears to be doing this anymore. Preventing
> this is trivial but it has been indicated that people might want to keep
> this as a feature. It would be possible to add a -anchor option to menu
> items for this (-anchor e) as this is not currently used. In some ways
> this would have been preferable all along avoiding the 'magic name'
> effect on .help. However I would like to see how annoyed people might
> get about this.

I would tie these items together.  I might recommend making use of something in the 'tk::classic' namespace where I placed some option theme changes for 8.5.

Jeff

[TCLCORE] The .help menu position.

[Pat T. <pat...@us...>]

Another request for comments on Tk menus changes...

I would like to stop the ancient practice of sticking the .help menu to
the far right of the screen on X11 as this is now an out-moded
practice. No other toolkit appears to be doing this anymore. Preventing
this is trivial but it has been indicated that people might want to keep
this as a feature. It would be possible to add a -anchor option to menu
items for this (-anchor e) as this is not currently used. In some ways
this would have been preferable all along avoiding the 'magic name'
effect on .help. However I would like to see how annoyed people might
get about this.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [TCLCORE] [PATCH] unix-menus: Make Tk menu activation follow mouse movement.

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

On 23/12/2009 11:35, Pat Thoyts wrote:
> I am posting this to tcl-core to get some idea of how people feel about
> changing the way Tk menus work on X11. At the moment Tk menus have what
> amounts to a click-to-focus mode. However, every other current toolkit
> seems to be using a focus-follows-mouse mode. What I mean is that on
> Windows or a GNOME window, when you click on a menubar item and it drops
> down a cascade menu, then moving the mouse around will automatically
> dropdown other menus as you move around. Currently the user has to click
> to open each and every cascade menu.
>
> The patch here changes how this works for popup menus and menubars but
> doesn't make any provision for the inevitable dinosaur who wants it to
> stay working the way it always has done. If we feel that a flag should
> be added to restore the old method, then what should it be called?

We don't need to be too subtle about the naming. I suggest:

   ::tk::brontosaurusMode

The one thing to really check is whether it keeps things working on
other platforms (e.g., OSX in X11 mode) or makes them work properly. It
might do, of course; I've not checked yet due to our end-of-year (and
preparing the house for Xmas) having somewhat higher priority.

Donal.

[TCLCORE] [PATCH] unix-menus: Make Tk menu activation follow mouse movement.

[Pat T. <pat...@us...>]

This patch makes Tk menus on unix follow mouse motion in the same
way Windows and GNOME menus follow the mouse. Once a menubar dropdown
has been activated, moving the mouse to another menu button will activate
the dropdown without needing another click.

Signed-off-by: Pat Thoyts <pat...@us...>

---

I am posting this to tcl-core to get some idea of how people feel about
changing the way Tk menus work on X11. At the moment Tk menus have what
amounts to a click-to-focus mode. However, every other current toolkit
seems to be using a focus-follows-mouse mode. What I mean is that on
Windows or a GNOME window, when you click on a menubar item and it drops
down a cascade menu, then moving the mouse around will automatically
dropdown other menus as you move around. Currently the user has to click
to open each and every cascade menu.

The patch here changes how this works for popup menus and menubars but
doesn't make any provision for the inevitable dinosaur who wants it to
stay working the way it always has done. If we feel that a flag should
be added to restore the old method, then what should it be called?

---
 library/menu.tcl |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/library/menu.tcl b/library/menu.tcl
index a2d9109..c25b93f 100644
--- a/library/menu.tcl
+++ b/library/menu.tcl
@@ -406,6 +406,8 @@ proc ::tk::MenuUnpost menu {
     # Unpost menu(s) and restore some stuff that's dependent on
     # what was posted.
 
+    unset -nocomplain Priv(menuActivated)
+
     catch {
 	if {$mb ne ""} {
 	    set menu [$mb cget -menu]
@@ -557,7 +559,7 @@ proc ::tk::MenuMotion {menu x y state} {
 	    GenerateMenuSelect $menu
 	}
     }
-    if {($state & 0x1f00) != 0} {
+    if {[info exists Priv(menuActivated)]} {
 	$menu postcascade active
     }
 }
@@ -600,6 +602,9 @@ proc ::tk::MenuButtonDown menu {
 		set Priv(cursor) [$menu cget -cursor]
 		$menu configure -cursor arrow
 	    }
+	    if {[$menu type active] eq "cascade"} {
+		set Priv(menuActivated) 1
+	    }
         }
 
 	# Don't update grab information if the grab window isn't changing.
@@ -1311,6 +1316,7 @@ proc ::tk_popup {menu x y {entry {}}} {
         tk::SaveGrabInfo $menu
 	grab -global $menu
 	set Priv(popup) $menu
+	set Priv(menuActivated) 1
 	tk_menuSetFocus $menu
     }
 }
-- 
1.6.2

[TCLCORE] TIP #359: Extended Window Manager Hint Support

[Pat T. <pat...@us...>]

 TIP #359: EXTENDED WINDOW MANAGER HINT SUPPORT 
================================================
 Version:      $Revision: 1.2 $
 Author:       Pat Thoyts <patthoyts_at_users.sourceforge.net>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Monday, 21 December 2009
 URL:          http://purl.org/tcl/tip/359.html
 WebEdit:      http://purl.org/tcl/tip/edit/359
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 The *wm attributes* command will be extended to accept a *-type* option 
 when running on the X Window system to manipulate the extended window 
 manager hints for Tk toplevel windows. 

 RATIONALE 
===========

 This enhancement will enable script-level support for setting the 
 extended window manager hints for Tk toplevel windows as specified in 
 [<URL:http://standards.freedesktop.org/wm-spec/wm-spec-latest.html>]. 
 The *_NET_WM_WINDOW_TYPE* hint is used to provide information to the 
 window manager about the intended use of a window so that appropriate 
 decoration and animation can be applied. Specific examples of this 
 include the dropdown listbox used with *ttk::combobox*, *tooltips*, 
 splash screens and application dialog windows. Menus also need the type 
 hint set appropriately but this has already been handled in the C code 
 in recent commits. 

 SPECIFICATION 
===============

 The *wm attributes* command (when Tk is using X11) will have a new 
 *-type* option which will return the current list of 
 *_NET_WM_WINDOW_TYPE* atoms set for this *toplevel* or allow the list 
 to be modified. The atom names as used at the script level will be all 
 lower-case and exclude any *_NET_WM_WINDOW_TYPE_* prefix. 

 As specified in the freedesktop.org document, the property is a list of 
 hints with the types specified in order of preference as window 
 managers may not implement some types. 

 When setting a hint, the provided name is converted to upper-case, 
 appended to *_NET_WM_WINDOW_TYPE_* and converted to an atom. This 
 permits new hints that may be specified in the future to be handled 
 without modification to Tk. 

 The Tk library scripts will set the type for all dialogs created by 
 library functions and will set the combo hint for the *ttk::combobox* 
 dropdown listbox. 

 The *-type* option will be accepted but have no effect on Windows and 
 MacOSX Aqua. It will always return an empty list when called with no 
 arguments. 

 This feature is actually needed on 8.5 as well. Under compiz Tk window 
 are inappropriately animated. The *combobox* dropdown in particular 
 tends to bounce on Ubuntu. 

 REFERENCE IMPLEMENTATION 
==========================

 There is a provisional patch 
 [<URL:https://sourceforge.net/support/tracker.php?aid=2918731>] which 
 implements the *-type* option but not quite as described here (the list 
 of hint names is locked-down). 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

[TCLCORE] TIP: Extended window manager hint support.

[Pat T. <pat...@us...>]

Title: Extended window manager hint support.
Author: Pat Thoyts <pat...@us...>
Type: Project
State: Draft
Tcl-Version: 8.6
Keywords: Tk, X11, ewmh, window manager

~ Abstract

The '''wm attributes''' command will be extended to accept a '''-type'''
option when running on the X Window system to manipulate the extended
window manager hints for Tk toplevel windows.

~ Rationale

This enhancement will enable script-level support for setting the
extended window manager hints for Tk toplevel windows as specified in
[http://standards.freedesktop.org/wm-spec/wm-spec-latest.html].  The
_NET_WM_WINDOW_TYPE hint is used to provide information to the window
manager about the intended use of a window so that appropriate
decoration and animation can be applied. Specific examples of this
include the dropdown listbox used with ttk::combobox, tooltips, splash
screens and application dialog windows. Menus also need the type hint
set appropriately but this has already been handled in the C code in
recent commits.

~ Specification

The '''wm attributes''' command will have a new '''-type''' option
which will return the current list of _NET_WM_WINDOW_TYPE atoms set
for this toplevel or allow the list to be modified. The atom names as
used at the script level will be all lower-case and exclude any
_NET_WM_WINDOW_TYPE prefix.

As specified in the freedesktop.org document, the property is a list
of hints with the types specified in order of preference as window
managers may not implement some types.

When setting a hint, the provided name is converted to upper-case,
appended to _NET_WM_WINDOW_TYPE with an underscore and converted to an
atom. This permits new hints that may be specified in the future to be
handled without modification to Tk.

The Tk library scripts will set the type for all dialogs created by
library functions and will set the combo hint for the ttk::combobox
dropdown listbox.

The '''-type''' option will be accepted but have no effect on Windows
and MacOSX Aqua. It will always return an empty list when called with
no arguments.

This feature is actually needed on 8.5 as well. Under compiz Tk window
are inappropriately animated. The combobox dropdown in particular tends
to bounce on Ubuntu.

~ Reference Implementation

There is a provisional patch at [http://paste.tclers.tk/1886] which
implements the '''-type''' option but not quite as described here (the
list of hint names is locked-down).

~ Copyright

This document has been placed in the public domain.

Re: [TCLCORE] Patch: fix bug in Tk where X11 displays whose names contain "::" couldn't be used (plain text this time)

[Griffin, B. <bri...@me...>]

Thanks Donal!

-Brian
(from mobile device)

On Dec 11, 2009, at 3:28 AM, "Donal K. Fellows" <don...@ma... 
 > wrote:

> On 11/12/2009 06:49, Brian Griffin wrote:
>> There's actually another bug in this routine that should probably be
>> fixed while your at it, even though it's highly unlikely to ever be  
>> hit.
> [...]
>> I've attached a patch that addresses this problem as well as the
>> original problem.
>
> That is not actually necessary because the argument to that routine  
> is a screen name, originating from ChangeScreen() in tkBind.c, and  
> is guaranteed to have the X screen number last. Those are all  
> display names there, and not screen names. So long as you avoid  
> calling tk::ScreenChanged manually (and why would you do that?) then  
> you'll be just fine.
>
> I've fixed the bug with the double colons. It's in the 8.6, 8.5 and  
> 8.4 source trees.
>
> Donal.

Re: [TCLCORE] Patch: fix bug in Tk where X11 displays whose names contain "::" couldn't be used (plain text this time)

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

On 11/12/2009 06:49, Brian Griffin wrote:
> There's actually another bug in this routine that should probably be
> fixed while your at it, even though it's highly unlikely to ever be hit.
[...]
> I've attached a patch that addresses this problem as well as the
> original problem.

That is not actually necessary because the argument to that routine is a 
screen name, originating from ChangeScreen() in tkBind.c, and is 
guaranteed to have the X screen number last. Those are all display names 
there, and not screen names. So long as you avoid calling 
tk::ScreenChanged manually (and why would you do that?) then you'll be 
just fine.

I've fixed the bug with the double colons. It's in the 8.6, 8.5 and 8.4 
source trees.

Donal.

Re: [TCLCORE] Patch: fix bug in Tk where X11 displays whose names contain "::" couldn't be used (plain text this time)

[Brian G. <bgr...@mo...>]

There's actually another bug in this routine that should probably be 
fixed while your at it, even though it's highly unlikely to ever be hit.

The line "set x [string last . $screen]" is the problem.  A perfectly 
legitimate DISPLAY value can contain an IP address or a hostname 
containing periods (.) and no screen number, for example 
"192.168.83.33:5" or "vnc.sourceforge.net:0".  In this situation, the 
code will generate a variable name that is the same for all display 
numbers as the same prefix IP address, which is clearly not the intent 
of the code; there is supposed to be a uniq variable for each uniq 
<host>:<display#>.  Here's proof:

    % info var ::tk::Priv*
    ::tk::Priv.localhost:11 ::tk::Priv
    % set env(DISPLAY)
    localhost:11.0
    % ::tk::ScreenChanged 192.168.83.33:5
    % info var ::tk::Priv*
    ::tk::Priv.localhost:11 ::tk::Priv.192.168.83 ::tk::Priv
    % ::tk::ScreenChanged 192.168.83.101:3
    % info var ::tk::Priv*
    ::tk::Priv.localhost:11 ::tk::Priv.192.168.83 ::tk::Priv


I've attached a patch that addresses this problem as well as the 
original problem.

-Brian


Tristan Schmelcher wrote:
> Sorry for the delay. I tested your patch today Jan and it works. I
> will open a bug.
>
> On Mon, Dec 7, 2009 at 5:14 AM, Tristan Schmelcher
> <tri...@al...> wrote:
>   
>> My patch should work fine with multiple "::" sequences actually
>> (perhaps not if back-to-back), but your code is shorter. I'll test it
>> later today.
>>
>> On Mon, Dec 7, 2009 at 11:18 AM, Jan Nijtmans
>> <nij...@us...> wrote:
>>     
>>> Good catch. In the past there was a bug-fix in clock.tcl, which simply
>>> fixed this by escaping the problematic character. See:
>>>  <http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/library/clock.tcl?r1=1.48&r2=1.49>
>>>
>>> Here I would fix it the same way. Your patch only handles a single "::", and
>>> in fact the original code doesn't work well when the display name would
>>> contain spaces (is that possible?). Anyway, here is a new patch, which
>>> should work with colons as well as spaces in the display name.
>>>
>>> Could you please submit a bug report for this, and test the attached
>>> patch?
>>>
>>> Regards,
>>>         Jan Nijtmans
>>>
>>> 2009/12/6 Tristan Schmelcher <tri...@al...>:
>>>       
>>>> Hello,
>>>>
>>>> I recently discovered a bug in Tk with X11 display strings. If the
>>>> display string contains "::" then Tk cannot load, because it uses the
>>>> display name as a variable name and this produces an error about the
>>>> parent namespace not being defined. This happened to me when trying to
>>>> use a Tk app (Mentor Graphics ModelSim) over XVnc, where the display
>>>> string was "::1:1.0". At least one other person has reported the same
>>>> problem: http://ubuntu-ky.ubuntuforums.org/showthread.php?p=8255492.
>>>> (That post suggests that this has only recently become a problem,
>>>> probably because until now display names never contained "::".)
>>>>
>>>> I have attached a patch that fixes the bug. I have verified that it
>>>> works in Tk 8.4, though for your convenience I have generated the patch
>>>> against Tk 8.5. Please consider incorporating it.
>>>>
>>>> Thanks!
>>>>
>>>> (Sorry about the HTML email before ...)
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>>> a free event focused on virtualization and cloud computing.
>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>
>>>>
>>>>         
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>   

Re: [TCLCORE] Patch: fix bug in Tk where X11 displays whose names contain "::" couldn't be used (plain text this time)

[Tristan S. <tri...@al...>]

Sorry for the delay. I tested your patch today Jan and it works. I
will open a bug.

On Mon, Dec 7, 2009 at 5:14 AM, Tristan Schmelcher
<tri...@al...> wrote:
> My patch should work fine with multiple "::" sequences actually
> (perhaps not if back-to-back), but your code is shorter. I'll test it
> later today.
>
> On Mon, Dec 7, 2009 at 11:18 AM, Jan Nijtmans
> <nij...@us...> wrote:
>> Good catch. In the past there was a bug-fix in clock.tcl, which simply
>> fixed this by escaping the problematic character. See:
>>  <http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/library/clock.tcl?r1=1.48&r2=1.49>
>>
>> Here I would fix it the same way. Your patch only handles a single "::", and
>> in fact the original code doesn't work well when the display name would
>> contain spaces (is that possible?). Anyway, here is a new patch, which
>> should work with colons as well as spaces in the display name.
>>
>> Could you please submit a bug report for this, and test the attached
>> patch?
>>
>> Regards,
>>         Jan Nijtmans
>>
>> 2009/12/6 Tristan Schmelcher <tri...@al...>:
>>> Hello,
>>>
>>> I recently discovered a bug in Tk with X11 display strings. If the
>>> display string contains "::" then Tk cannot load, because it uses the
>>> display name as a variable name and this produces an error about the
>>> parent namespace not being defined. This happened to me when trying to
>>> use a Tk app (Mentor Graphics ModelSim) over XVnc, where the display
>>> string was "::1:1.0". At least one other person has reported the same
>>> problem: http://ubuntu-ky.ubuntuforums.org/showthread.php?p=8255492.
>>> (That post suggests that this has only recently become a problem,
>>> probably because until now display names never contained "::".)
>>>
>>> I have attached a patch that fixes the bug. I have verified that it
>>> works in Tk 8.4, though for your convenience I have generated the patch
>>> against Tk 8.5. Please consider incorporating it.
>>>
>>> Thanks!
>>>
>>> (Sorry about the HTML email before ...)
>>>
>>> ------------------------------------------------------------------------------
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>> a free event focused on virtualization and cloud computing.
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>>>
>>
>

Re: [TCLCORE] Question on coroutines

[miguel s. <mig...@gm...>]

Joe English wrote:
> miguel sofer wrote:
> 
>> The idea is that
>>      yieldTo foo bar sum
>> will:
>>    1. suspend the currently running coro
>>    2. cause the coro's caller to invoke [foo bar sum] in the place of
>> the current coro, and take it's return value as the coro's return value
>>
>> IOW: it works EXACTLY like [tailcall] in the sense that the currently
>> running thing is removed from the call stack and replaced by a new
>> command. The difference is that where [tailcall] terminates the
>> currently running proc, [yieldTo] suspends the currently running coro.
> 
> OK, so if you have:
> 
>     proc A {...} {
> 	coroutine coro1 B ...
>     }
> 
> then in proc B:
> 
>     yieldto C args...
> 
> is the same as:
> 
>     yield [C args...]
> 
> except that:
> 
>     (a) [uplevel 1] in the body of proc C will refer to proc A,
>         not proc B; and:
>     (b) C may call coro1.
> 
> Do I have that right?

Yes. There are of course additional internal details in terms of stack 
consumption and suchlike, but irrelevant to the semantics.

Re: [TCLCORE] Question on coroutines

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

miguel sofer wrote:

> The idea is that
>      yieldTo foo bar sum
> will:
>    1. suspend the currently running coro
>    2. cause the coro's caller to invoke [foo bar sum] in the place of
> the current coro, and take it's return value as the coro's return value
>
> IOW: it works EXACTLY like [tailcall] in the sense that the currently
> running thing is removed from the call stack and replaced by a new
> command. The difference is that where [tailcall] terminates the
> currently running proc, [yieldTo] suspends the currently running coro.

OK, so if you have:

    proc A {...} {
	coroutine coro1 B ...
    }

then in proc B:

    yieldto C args...

is the same as:

    yield [C args...]

except that:

    (a) [uplevel 1] in the body of proc C will refer to proc A,
        not proc B; and:
    (b) C may call coro1.

Do I have that right?


--Joe English

  jen...@fl...

Re: [TCLCORE] Question on coroutines

[miguel s. <mig...@gm...>]

Donald G Porter wrote:
> Neil Madden wrote:
>> I'm not sure I see in what case the dispatcher needs to do more than 
>> a  > simple [eval], though. In what situation do you get a chain of 
> control > transfers with yieldTo? (My understanding is that this behaves 
> like [tailcall],
>> so there should be no chains).
> 
> Others can correct if I'm mistaken, but there's a subtle difference 
> between [tailcall] and having the caller [eval] a script that is
> returned, beyond the convenience of syntax.  [tailcall] resolves
> the command name in the context of the [tailcall] command, while
> an [eval] in the caller would resolve in the caller context.  Many
> times this does not matter, but sometimes it does.
> 
> I was assuming from the prior messages that [yieldTo] would follow
> the same pattern as [tailcall].

Your assumption is correct. Under the cover this really does use the 
tailcall machinery - the NRTailcallEval callback.

But most of that can also be done with a bit of [namespace which] or 
[namespace eval] and stuff.

The real diff is that you do not need a scheduler - be it the event loop 
or a specially code one.

Re: [TCLCORE] Question on coroutines

[Donald G P. <dg...@ni...>]

Neil Madden wrote:
> I'm not sure I see in what case the dispatcher needs to do more than a  > simple [eval], though. In what situation do you get a chain of 
control > transfers with yieldTo? (My understanding is that this behaves 
like [tailcall],
> so there should be no chains).

Others can correct if I'm mistaken, but there's a subtle difference 
between [tailcall] and having the caller [eval] a script that is
returned, beyond the convenience of syntax.  [tailcall] resolves
the command name in the context of the [tailcall] command, while
an [eval] in the caller would resolve in the caller context.  Many
times this does not matter, but sometimes it does.

I was assuming from the prior messages that [yieldTo] would follow
the same pattern as [tailcall].

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Question on coroutines

[Neil M. <Nei...@no...>]

On 7 Dec 2009, at 14:44, Kevin Kenny wrote:
> Neil Madden wrote:
>> Or perhaps "yield [list foo bar]" and have the caller do "eval [$coro]"? Isn't that exactly what yieldTo does, but hiding the [eval], or am I still missing something?
> 
> You're not missing much. It's a minor simplification; if the coro were
> always invoked with [eval [$coro]], then [yield] would behave the same
> as [yieldto] without it.  In that case, though, if the coro is actually
> ready to return a value, it would have to execute something like
> [yield [list return -level 0 $value]].  And the tangle gets more
> complicated, because the dispatcher isn't a simple [eval [$coro]];
> it has to continue evaluating a whole chain of control transfers
> (and still be able to escape with [return -level 0] or whatever at
> the end).
> 
> Equivalent power, different notation.

OK, I sort-of see now. Wrapping all the coroutine yields in an [eval] is easily accomplished:

 proc coro {name args} {
    coroutine $name.coro {*}$args
    interp alias {} $name {} dispatch $name.coro
 }
 proc dispatch {coro arg} { eval [$coro $arg] }

To yield a value, you can just do (as you say):

 proc value val { list return -level 0 $val }
 yield [value $foo]

I'm not sure I see in what case the dispatcher needs to do more than a simple [eval], though. In what situation do you get a chain of control transfers with yieldTo? (My understanding is that this behaves like [tailcall], so there should be no chains).

Not that I am antagonistic to the proposal, I'm just trying to determine if it is a lack of expressive power in the original coroutine specification, or a syntactic nicety.

NeilThis message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[TCLCORE] Tcllib 1.12 has been released

[Andreas K. <and...@ac...>]

Hello all.

	Tcllib 1.12 has been released today.

The relevant archives can be found at

	https://sourceforge.net/projects/tcllib/files/tcllib/1.12/

For a list of changes (new packages, modified packages), please see the 
attached README-1.12.txt. This README is also available at the url shown above.


All the packages of Tcllib 1.12 are also available through ActiveState's public 
TEApot repository at http://teapot.activstate.com, and the 'teacup' client for 
such repositories coming with all recent distributions of ActiveTcl.

Disclosure: I am developer at ActiveState.

-- 
Sincerely,
     Andreas Kupries <an...@ac...>
     Developer @    <http://www.activestate.com/>

Re: [TCLCORE] Question on coroutines

[miguel s. <mig...@gm...>]

miguel sofer wrote:
> Maybe the best is for me to provide the code: I'll commit it in a matter 
> of hours (within unsupported) and things should be clearer then.

Done: head has it. Patch at sf, #2910056

Re: [TCLCORE] Memory leak in try "on" handlers

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

Donald G Porter wrote:
> Cyan Ogilvie wrote:
>> There seems to be a memory leak in the result handler code of the C
>> based try command. ...
> 
> Logged as Bug 2910044.  In the future we'd prefer you do the same with
> bugs instead of posting messages here.
> 

And it's also fixed now. For bugs that are well-described (i.e. so that
we can reproduce them easily on our development systems and can craft
test cases to trigger them) we often have a very good turnaround.

Donal.

Re: [TCLCORE] Memory leak in try "on" handlers

[Donald G P. <dg...@ni...>]

Cyan Ogilvie wrote:
> There seems to be a memory leak in the result handler code of the C
> based try command. ...

Logged as Bug 2910044.  In the future we'd prefer you do the same with
bugs instead of posting messages here.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Question on coroutines

[Kevin K. <kev...@gm...>]

Neil Madden wrote:
> Or perhaps "yield [list foo bar]" and have the caller do "eval [$coro]"? 
> Isn't that exactly what yieldTo does, but hiding the [eval], or am I 
> still missing something?

You're not missing much. It's a minor simplification; if the coro were
always invoked with [eval [$coro]], then [yield] would behave the same
as [yieldto] without it.  In that case, though, if the coro is actually
ready to return a value, it would have to execute something like
[yield [list return -level 0 $value]].  And the tangle gets more
complicated, because the dispatcher isn't a simple [eval [$coro]];
it has to continue evaluating a whole chain of control transfers
(and still be able to escape with [return -level 0] or whatever at
the end).

Equivalent power, different notation.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Question on coroutines

[Kevin K. <kev...@gm...>]

Donal K. Fellows wrote:
> So, the following should be equivalent, for any [foo]?
> 
>   yieldTo foo bar
>   yield [foo bar]
> 
> Except that [foo] might see a different stack context? What will be the 
> cost of making a new short-lived context in the non-coro case? What will 
> [info coroutine] return inside the body of [foo] in the non-coro case?

As Miguel explained it to me, [yieldto] executes the yielded-to command
in place of the call to the current coroutine and in the caller's scope.
(Except that the command is resolved in the current scope before
yielding?)

So I'd expect that [info coroutine], if [foo] is not a coroutine, will
be whatever coroutine called the one that yielded.

Oh, by the way, answering your earlier question:

yieldTo the main coroutine will *not* be possible,
because you can't yield to (or otherwise call) a coroutine that is
on the stack, and the main coroutine is always there.

-- 
73 de ke9tv/2, Kevin