tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] ttk::style configure TMenu -background has no effect

[Youness A. <kak...@ka...>]

On Sun, May 17, 2009 at 07:56:38AM +0100, Donal K. Fellows wrote:
> Ivica Ico Bukvic wrote:
> > I am wondering why following has no effect on the theme (this is with
> > 8.5):
> > 
> > ttk::style configure TMenu -background "#aa0000"
> > #the above doesn't work on Ubuntu Jaunty with 8.5
> > ttk::style configure TButton -background "#aa0000"
> > #the button one does
> 
> Menus aren't styled. On Windows and OSX, they're fully native widgets,
> and on X11 they're old-style classic widgets, neither of which respond
> to style changes.
> 
> Donal.
> 
Hi,

I think that menus should definitely be styled at some point
(as well as 'toplevel').. the reason is simple, if you use a
style that is for example 'orange', then you'd get grey
menus that won't fit with the rest of the widgets.. same
thing for unused space in a toplevel...
I remember doing some hacks on chameleon to fix this where I
would try to guess the native color of the style's widgets
and add an option to Tk's db to change the default
background color, then loop through all windows/frames/menus
and change their color so that when you switch from one
style to another, it would look ok instead of having two
color schemes all over your windows...

What do you think?

KaKaRoTo

Re: [TCLCORE] [MACTCL] Merging TkAqua Cocoa port into Tk HEAD

[Kevin W. <kw...@co...>]

Daniel A. Steffen wrote:
> Hi All,
> 
> as you may know, I have been working on a port of TkAqua to the Cocoa
> API for some time, with the goal to get TkAqua to run on 64bit, and to
> move away from Mac OS X Carbon API that has been deprecated.
> 
> The Cocoa port has now been feature complete for about a month and I
> believe is of equal or better quality than the existing TkAqua
> implementation, it has been built, tested and is already being used
> successfully by various parties, and IMO is now ready to be merged
> into the Tk mainline.
> 
> The port is available as patches against HEAD (large!)
> 	http://www.categorifiedcoder.info/tcltk/patches/tk-de-carbon.diff.bz2
> 	http://www.categorifiedcoder.info/tcltk/patches/tcl-de-carbon.diff.bz2
> or from github with full history:
> 	http://github.com/das/tcltk/commits/de-carbon
> 
> The patch to Tcl only touches the macosx README and the Xcode
> projects, related generally applicable changes to Tcl (in particular
> the revised macosx notifier) have already gone in a few weeks ago for
> 8.5.7.
> 
> The principal new constraint of the TkAqua Cocoa port is that it
> requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X
> 10.3).
> 
> After discussion with Jeff and other TkAqua maintainers and
> distributors, we have decided that the Tk 8.6 release is a reasonable
> moment to drop support for pre-10.5 OS X, as users who still need to
> run on earlier OS versions should be able to remain with 8.5 for some
> time.
> 
> There is a 8.5 backport of TkAqua Cocoa, which I will continue to
> maintain as a fork at github (to avoid a system requirements jump in a
> 8.5 point release):
> 	http://github.com/das/tcltk/commits/de-carbon-8-5
> 
> There should be no script-visible changes to standard Tk functionality
> introduced by the Cocoa port; there are some additions of
> TkAqua-specific functionality (c.f. excerpt from tk/macosx/README
> below) and a few removals of obsolete unsupported Carbon-specific bits
> in the tk::mac namespace.
> Various longstanding missing features have been implemented (e.g. [wm
> aspect]) and a number of bugs tightly tied to the old implementation
> are fixed by the rewrite. Drawing performance is also significantly
> improved (e.g. >2x speedup of a benchmark that draws many short lines
> on a canvas).
> 
> At the public Tk C API level, there is a tiny signature change to
> macosx-specific API in the public plat stubs table (replacing two
> Carbon pointer types that should never have entered a public x-plat
> header by void*).
> Otherwise, public API is unchanged and extensions that use only public
> Tk API are unaffected and should continue to work unchanged (verified
> with extensions like TkImg and TkTable).
> Thus I believe there is no requirement for a TIP for the integration
> of the Cocoa port changes.
> 
> There are also no additions/removals to the private plat stubs table,
> but a significant number of signature changes (mostly turning more
> Carbon pointer types into void*).
> However, many of the macosx private stubs API calls had unfortunately
> exposed details of the internal Carbon implementation that could not
> be preserved, such calls had to be neutered and are now just NOPs. Tk
> extensions that rely on these or make other assumptions about TkAqua
> internals (like the presence of QuickDraw and QD ports) will have to
> be ported to support TkAqua Cocoa (e.g. Treectrl and Tile are known to
> be affected).
> 
> I am planning to move forward with the merge tonight (CEST), so if you
> have objections, please speak up soon!
> 
> Cheers,
> 
> Daniel

Daniel,

Congratulations on this major accomplishment. It ensures that Tk will 
remain viable on OS X for years to come. All of us developing in Tk on 
the Mac thank you.

Best,
Kevin


-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [TCLCORE] [MACTCL] Merging TkAqua Cocoa port into Tk HEAD

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

On May 17, 2009, at 4:54 PM, Daniel A. Steffen wrote:

>> One functionality question: two major gaps in the aqua-Carbon  
>> functionality
>> were support for Services and support for Asian language text  
>> input.  Are
>> these remedied in Cocoa
>
> services, no, were you thinking of a Tk app as a service consumer? for
> what kind of services, modification of text selection in a text
> widget?
> there is no provision for that sort of thing in the generic tk text
> widget code ATM, so it would need generic (TIPable) changes, feel free
> to write something up (e.g. [clipboard] based), it would probably not
> be very hard to add once a design is nailed down (services API is
> pasteboard based and very similar to the pasteboard use in the
> clipboard code in TkAqua Cocoa).

It would be good to support service provision at the script level --  
allow a script to be called when an info.plist-specified service is  
requested from the app.  On the consumer end, some sort of selection  
modification would be a good long-term goal, but most services are  
not of this type, but more along the lines of "open XX in YY", or  
"new window with selection", etc. that only need the clipboard to be  
sent.  If I get some time I'll try to propose something more specific.


> Asian language text input does not work currently, along with other
> advanced cocoa text input features, mainly because Tk text input is
> based on raw key events and we do not use the full cocoa text input
> pipeline. It is not clear to me ATM how we can preserve Tk's
> requirement to bind to raw key events (with any modifier) without
> relying on raw key events.

Multi-keystroke input methods (e.g. for Chinese characters) work in  
Tk under Windows currently, so maybe the raw vs. processed issue for  
bindings could be handled the same way as there.  Implementation- 
wise, an NSView can implement the NSTextInput protocol and have  
access to both the raw keys and the characters composed by whatever  
system input manager is active.  (The Cocoa port of emacs does this.)


-Adrian

Re: [TCLCORE] Merging TkAqua Cocoa port into Tk HEAD

[Lars H. <Lar...@re...>]

Daniel A. Steffen skrev:
> The principal new constraint of the TkAqua Cocoa port is that it
> requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X
> 10.3).
> 
> After discussion with Jeff and other TkAqua maintainers and
> distributors, we have decided that the Tk 8.6 release is a reasonable
> moment to drop support for pre-10.5 OS X, 

Ouch! And me not having a single machine running 10.5.

> as users who still need to
> run on earlier OS versions should be able to remain with 8.5 for some
> time.

8.5 won't do for me I'm afraid, but I suppose there's always the 8.6b1 
I've got running now.

Still, since /my/ 8.6 dependency is entirely in Tcl, I can't help 
wondering how much work it will be to link Tk 8.6b1 (or last pre-merge 
CVS version) against Tcl 8.6.0...

Lars Hellström

Re: [TCLCORE] [MACTCL] Merging TkAqua Cocoa port into Tk HEAD

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

Hi Adrian,

On Sun, May 17, 2009 at 11:27, Adrian Robert <adr...@gm...> wrote:

> Are there / will there be backports of the PNG and font chooser features (to
> be) introduced in 8.6 to 8.5?  It would be nice to bring those features to
> Tiger users.

8.5 is feature frozen, so not likely to happen

> Failing that, what about delaying the merge, if it is going to remove
> aqua-carbon as well,

it will

> until after 8.6b2 is released, so the PNG and zlib
> functionality can make it in to a release, albeit a beta one?  This would
> also allow for a period of wider testing of the Cocoa implementation (from
> people using CVS head) before putting it into a release.

if it goes into the CVS head now it goes into 8.6b2...

IMO delaying the merge post 8.6b2 will significantly reduce the amount
of testing the cocoa port receives before 8.6 goes final, so I'm not
too keen on that

> One functionality question: two major gaps in the aqua-Carbon functionality
> were support for Services and support for Asian language text input.  Are
> these remedied in Cocoa

services, no, were you thinking of a Tk app as a service consumer? for
what kind of services, modification of text selection in a text
widget?
there is no provision for that sort of thing in the generic tk text
widget code ATM, so it would need generic (TIPable) changes, feel free
to write something up (e.g. [clipboard] based), it would probably not
be very hard to add once a design is nailed down (services API is
pasteboard based and very similar to the pasteboard use in the
clipboard code in TkAqua Cocoa).

Asian language text input does not work currently, along with other
advanced cocoa text input features, mainly because Tk text input is
based on raw key events and we do not use the full cocoa text input
pipeline. It is not clear to me ATM how we can preserve Tk's
requirement to bind to raw key events (with any modifier) without
relying on raw key events.

Cheers,

Daniel

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

Re: [TCLCORE] [MACTCL] Merging TkAqua Cocoa port into Tk HEAD

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

On May 17, 2009, at 3:43 PM, Daniel A. Steffen wrote:

> After discussion with Jeff and other TkAqua maintainers and
> distributors, we have decided that the Tk 8.6 release is a reasonable
> moment to drop support for pre-10.5 OS X, as users who still need to
> run on earlier OS versions should be able to remain with 8.5 for some
> time.
>
> There is a 8.5 backport of TkAqua Cocoa, which I will continue to
> maintain as a fork at github (to avoid a system requirements jump in a
> 8.5 point release):
> 	http://github.com/das/tcltk/commits/de-carbon-8-5

Hi,

This is great news and thanks for the tremendous work!

However, as a Tcl/Tk-based app developer, I'm concerned about the  
dropping of support for 10.4 (Tiger), though doing it with 8.6 is  
obviously better than 8.5.x.

Are there / will there be backports of the PNG and font chooser  
features (to be) introduced in 8.6 to 8.5?  It would be nice to bring  
those features to Tiger users.

Failing that, what about delaying the merge, if it is going to remove  
aqua-carbon as well, until after 8.6b2 is released, so the PNG and  
zlib functionality can make it in to a release, albeit a beta one?   
This would also allow for a period of wider testing of the Cocoa  
implementation (from people using CVS head) before putting it into a  
release.


One functionality question: two major gaps in the aqua-Carbon  
functionality were support for Services and support for Asian  
language text input.  Are these remedied in Cocoa or are they open  
projects?

thanks,
Adrian

[TCLCORE] Merging TkAqua Cocoa port into Tk HEAD

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

Hi All,

as you may know, I have been working on a port of TkAqua to the Cocoa
API for some time, with the goal to get TkAqua to run on 64bit, and to
move away from Mac OS X Carbon API that has been deprecated.

The Cocoa port has now been feature complete for about a month and I
believe is of equal or better quality than the existing TkAqua
implementation, it has been built, tested and is already being used
successfully by various parties, and IMO is now ready to be merged
into the Tk mainline.

The port is available as patches against HEAD (large!)
	http://www.categorifiedcoder.info/tcltk/patches/tk-de-carbon.diff.bz2
	http://www.categorifiedcoder.info/tcltk/patches/tcl-de-carbon.diff.bz2
or from github with full history:
	http://github.com/das/tcltk/commits/de-carbon

The patch to Tcl only touches the macosx README and the Xcode
projects, related generally applicable changes to Tcl (in particular
the revised macosx notifier) have already gone in a few weeks ago for
8.5.7.

The principal new constraint of the TkAqua Cocoa port is that it
requires Mac OS X 10.5 or later (TkAqua currently requires Mac OS X
10.3).

After discussion with Jeff and other TkAqua maintainers and
distributors, we have decided that the Tk 8.6 release is a reasonable
moment to drop support for pre-10.5 OS X, as users who still need to
run on earlier OS versions should be able to remain with 8.5 for some
time.

There is a 8.5 backport of TkAqua Cocoa, which I will continue to
maintain as a fork at github (to avoid a system requirements jump in a
8.5 point release):
	http://github.com/das/tcltk/commits/de-carbon-8-5

There should be no script-visible changes to standard Tk functionality
introduced by the Cocoa port; there are some additions of
TkAqua-specific functionality (c.f. excerpt from tk/macosx/README
below) and a few removals of obsolete unsupported Carbon-specific bits
in the tk::mac namespace.
Various longstanding missing features have been implemented (e.g. [wm
aspect]) and a number of bugs tightly tied to the old implementation
are fixed by the rewrite. Drawing performance is also significantly
improved (e.g. >2x speedup of a benchmark that draws many short lines
on a canvas).

At the public Tk C API level, there is a tiny signature change to
macosx-specific API in the public plat stubs table (replacing two
Carbon pointer types that should never have entered a public x-plat
header by void*).
Otherwise, public API is unchanged and extensions that use only public
Tk API are unaffected and should continue to work unchanged (verified
with extensions like TkImg and TkTable).
Thus I believe there is no requirement for a TIP for the integration
of the Cocoa port changes.

There are also no additions/removals to the private plat stubs table,
but a significant number of signature changes (mostly turning more
Carbon pointer types into void*).
However, many of the macosx private stubs API calls had unfortunately
exposed details of the internal Carbon implementation that could not
be preserved, such calls had to be neutered and are now just NOPs. Tk
extensions that rely on these or make other assumptions about TkAqua
internals (like the presence of QuickDraw and QD ports) will have to
be ported to support TkAqua Cocoa (e.g. Treectrl and Tile are known to
be affected).

I am planning to move forward with the merge tonight (CEST), so if you
have objections, please speak up soon!

Cheers,

Daniel

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


==== From tk/macosx/README ====

- The default metrics of native buttons, radiobuttons, checkboxes and
menubuttons in the Cocoa-based Tk 8.6b2 and later preserve
compatibility with the older Carbon-based implementation, you can turn
off the compatibility metrics to get more native-looking spacing by
setting:
	set tk::mac::useCompatibilityMetrics 0

- TkAqua provides access to native OS X images via the Tk native
bitmap facility (including any image file readable by NSImage). A
native bitmap name is interpreted as follows (in order):
    - predefined builtin 32x32 Tk icon name (stop, caution, document, etc)
    - name defined by [tk::mac::iconBitmap]
    - NSImage named image name
    - NSImage url string
    - 4-char OSType of IconServices icon
the syntax of [tk::mac::iconBitmap] is as follows:
	tk::mac::iconBitmap name width height -kind value
where -kind is one of
    -file	    icon of file at given path
    -fileType	    icon of given file type
    -osType	    icon of given 4-char OSType file type
    -systemType	    icon for given IconServices 4-char OSType
    -namedImage	    named NSImage for given name
    -imageFile	    image at given path
This support was added with the Cocoa-based Tk 8.6b2.

- TkAqua cursor names are interpred as follows (in order):
    - standard or platform-specific Tk cursor name (c.f. cursors.n)
    - @path to any image file readable by NSImage
    - NSImage named image name
Support for the latter two was added with the Cocoa-based Tk 8.6b2.

- The standard Tk dialog commands [tk_getOpenFile],
[tk_chooseDirectory], [tk_getSaveFile] and [tk_messageBox] all take an
additional optional -command parameter on TkAqua. If it is present,
the given command prefix is evaluated at the global level when the
dialog closes, with the dialog command's result appended (the dialog
command itself returning an emtpy result). If the -parent option is
also present, the dialog is configured as a modeless (window-modal)
sheet attached to the parent window and the dialog command returns
immediately.
Support for -command was added with the Cocoa-based Tk 8.6b2.

- The TkAqua-specific [tk::mac::standardAboutPanel] command brings the
standard Cocoa about panel to the front, with all its information
filled in from your application bundle files (i.e. standard about
panel with no options specified). See Apple Technote TN2179 and the
AppKit documentation for -[NSApplication
orderFrontStandardAboutPanelWithOptions:] for details on the
Info.plist keys and app bundle files used by the about panel.
This support was added with the Cocoa-based Tk 8.6b2.

- TkAqua has three special menu names that give access to the standard
Application, Window and Help menus, see menu.n for details.
Support for the Window menu was added with the Cocoa-based Tk 8.6b2.

- The TkAqua-specific command [tk::unsupported::MacWindowStyle style]
is used to get and set Mac OS X-specific toplevel window class and
attributes. Note that the window class and many attributes have to be
set before the window is first mapped for the change to have any
effect.
The command has the following syntax:
	tk::unsupported::MacWindowStyle style window ?class? ?attributes?
The 2 argument form returns a list of the current class and attributes
for the given window. The 3 argument form sets the class for the given
window using the default attributes for that class. The 4 argument
form sets the class and the list of attributes for the given window.
Window class names:
    document, modal, floating, utility, toolbar, simple, help, overlay
Window attribute names:
    standardDocument, standardFloating, resizable, fullZoom, horizontalZoom,
    verticalZoom, closeBox, collapseBox, toolbarButton, sideTitlebar,
    noTitleBar, unifiedTitleAndToolbar, metal, hud, noShadow, doesNotCycle,
    noActivates, hideOnSuspend, inWindowMenu, ignoreClicks, doesNotHide,
    canJoinAllSpaces, moveToActiveSpace, nonActivating
Note that not all attributes are valid for all window classes.
Support for the 3 argument form was added with the Cocoa-based Tk
8.6b2, at the same time support for some legacy Carbon-specific
classes and attributes was removed (they are still accepted by the
command but no longer have any effect).

- The Cocoa-based TkAqua can be distinguished from the older
Carbon-based version via the [winfo server .] command, example output
on Mac OS X 10.5.7:
    Cocoa-based:	CG409.3 Apple AppKit GC 949.46 Mac OS X 1057
    Carbon-based:	QD10R30 Apple 1057

Re: [TCLCORE] ttk::style configure TMenu -background has no effect

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

Ivica Ico Bukvic wrote:
> I am wondering why following has no effect on the theme (this is with
> 8.5):
> 
> ttk::style configure TMenu -background "#aa0000"
> #the above doesn't work on Ubuntu Jaunty with 8.5
> ttk::style configure TButton -background "#aa0000"
> #the button one does

Menus aren't styled. On Windows and OSX, they're fully native widgets,
and on X11 they're old-style classic widgets, neither of which respond
to style changes.

Donal.

[TCLCORE] question about the default tcl/tk widget colors on Linux

[Ivica I. B. <ic...@vt...>]

Greetings all,

Please pardon my ignorance, I am fairly new to the tcl/tk dev world.
Although I've made solid progress on various issues (in part thanks to a
very good online documentation--many thanks for that!), one thing I've
been stuck on for the past couple hours is following:

I am trying to alter the default background color of the "clam" theme.
Since I was at first unable to figure out how to do this on the existing
loaded theme, I decided to copy code found on the following page
http://paste.tclers.tk/618 and change its color values. While this
changes default background color of popup windows and scrollbars, it has
apparently no effect on widgets such as menu and/or frame. I suspect
this may be because menu and frame are not ttk-aware. If so, what would
be the right way to do this?

I also saw somewhere in code following statement:

. configure -background "#ece7e3"

This however has no effect either.

Any help in this matter, particularly working example code, would be
most appreciated!

Many thanks!

Ico

Re: [TCLCORE] ttk::style configure TMenu -background has no effect

[Ivica I. B. <ic...@vt...>]

On Sat, 2009-05-16 at 22:00 -0400, Ivica Ico Bukvic wrote:
> Hi all,
> 
> I am wondering why following has no effect on the theme (this is with
> 8.5):
> 
> ttk::style configure TMenu -background "#aa0000"
> #the above doesn't work on Ubuntu Jaunty with 8.5
> 
> ttk::style configure TButton -background "#aa0000"
> #the button one does

To add to this, it appears when I have 

menu .something -bg "#aa0000"

this works. However, trying to globally specify for a theme continues to
elude me. Any assistance in this matter is most appreciated (NB: I am
relatively new to the whole Tcl/Tk API so example code would be most
appreciated)!

Ico

[TCLCORE] ttk::style configure TMenu -background has no effect

[Ivica I. B. <ic...@vt...>]

Hi all,

I am wondering why following has no effect on the theme (this is with
8.5):

ttk::style configure TMenu -background "#aa0000"
#the above doesn't work on Ubuntu Jaunty with 8.5

ttk::style configure TButton -background "#aa0000"
#the button one does

Any ideas?

Ico

Re: [TCLCORE] tcl performance regressions in 8.6

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

> Be careful with bitfields, in ANSI C you have to specify signed or unsigned 
> explicitly, else the sign is undefined and you may get unexpected results 
> (e.g overflows when a refcount drops below zero).
> 
> So you want:
> 
> +    signed int refCount:31;           /* When 0 the object will be freed. 
> */

So that one I can agree with, thanks.

> +    signed int undef:1;               /* Used by L to mark an object as 

but a one bit thing that is signed seems strange :)

But point taken, I'll tweak our source base.  Thanks for the feedback.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Finalization vs. Exit

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

On Sun, May 10, 2009 at 9:24 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
> On Fri, May 8, 2009 at 12:36 PM, Donal K. Fellows
> <don...@ma...> wrote:
>>
>> Since nobody else has commented, I offer not insight, but rather
>> encouragement. Finalization is a difficult area (to say the least) and
>> it merits much study. Part of the difficulty is probably assembling a
>> good enough set of use cases for all the things that finalization/exit
>> has to cope with. Indeed, most problems in this area can be traced back
>> to having an incomplete knowledge of what actually needs to be done.
>
> Thanks Donal.
>
> I could take a head start in that quest if specific
> extension/embedding authors (or people familiar with popular ones)
> were to step forward here and answer the following:
>
>    What could go wrong in your extension/app if we restricted
> Tcl_Exit() to just running (early) exit handlers and exiting ?
>
> -Alex
>

After a deafening lack of reaction to this, I would like to narrow the
question a bit:

 Could we do away with TclFinalizeIOSubsystem in the Tcl_Exit path ?

IOW, given that:

  (a)- TFIOS closes only the calling (exiting) thread's interps' channels
  (b)- TFIOS flushes them in blocking mode (may hang [exit])
  (c)- TFIOS may delete Pipe and Socket related event sources despite
other threads still using them (!)

... are there still compelling reasons to call it prior to exiting ?

Or maybe, should we keep (a) and (b) but remove (c) from the Exit path
(still keeping it in the Finalize path) ?

TIA,

-Alex

Re: [TCLCORE] tcl performance regressions in 8.6

[Frédéric B. <fre...@fr...>]

Larry McVoy wrote:
 > 32 vs 31 bit integer for refCount
 > ---------------------------------
 > As you may know, in BitMover's fork of tcl, we have another language
 > running on top of the tcl byte code engine.  One thing we wanted was an
 > out of band way of marking a tclobj as unset/undefined/null.  The path
 > we took was to steal one bit from refCount since it's highly unlikely
 > that anyone is going to overflow refCount (as it stood, refCount was
 > good for 31 bits, it's signed).  By squeezing refCount into a 31 bit
 > signed int (int refCount:31), we are able to free up one bit without
 > increasing the size of struct Tcl_Obj.

Be careful with bitfields, in ANSI C you have to specify signed or unsigned 
explicitly, else the sign is undefined and you may get unexpected results (e.g 
overflows when a refcount drops below zero).

So you want:

+    signed int refCount:31;           /* When 0 the object will be freed. */
+    signed int undef:1;               /* Used by L to mark an object as having


(This info I got from 
http://graphics.stanford.edu/~seander/bithacks.html#FixedSignExtend)

[TCLCORE] tcl performance regressions in 8.6

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

This is a two part mail.  The first part is about the performance impact
of taking one bit from refCount to use as an undef (NULL) marker in L.
The second part, which is more interesting, is about where we are 
compared to tcl 8.5.1 (and perl, just to get an external frame of
reference, python, ruby, L comparisons available as well but I didn't
want to make this too long).

Testing
-------
All tests were on my laptop, a dual core 2.5Ghz Intel Core 2 Duo.  The
system was idle at the time.  The test was 5 repeated runs of langbench
(http://bitmover.com/lm/langbench.shar) and the fastest result from
all 5 runs was the result used.  Logic is that the longer runs are 
likely to be so because of other system activity.

I know that not everyone here loves langbench, but it has the advantage
of measuring common language constructs.  I'm always looking for new 
things to measure, feel free to submit a patch.  I did add an obj test
which creates a million key/val pairs with all values of 0 (so lots
of refcounts on that) as well as a million element list with all 
values of 0 and then deletes them.

32 vs 31 bit integer for refCount
---------------------------------
As you may know, in BitMover's fork of tcl, we have another language
running on top of the tcl byte code engine.  One thing we wanted was an
out of band way of marking a tclobj as unset/undefined/null.  The path
we took was to steal one bit from refCount since it's highly unlikely
that anyone is going to overflow refCount (as it stood, refCount was
good for 31 bits, it's signed).  By squeezing refCount into a 31 bit 
signed int (int refCount:31), we are able to free up one bit without
increasing the size of struct Tcl_Obj.

In order to quantify the costs of doing so, I went into the code and
removed all uses of Tcl_Obj.undef (which broke L but whatever) and
ran tests on 3 different versions of tcl: 

    A - original code, 32 bit refCount
    B - int undef:1; int refCount:31;
    C - int refCount:31; int undef:1;

The B vs C tests were to see if there is a difference between using the 
top or bottom bit for the flag.

Test    cat     grep    hash    loop    proc    fib     sort    wc      obj
A	0.94	0.96	1.15	0.06	1.34	4.80	2.59	1.80	0.83
B	0.94	1.00	1.16	0.06	1.35	4.71	2.61	1.88	0.82
C	0.99	1.06	1.21	0.06	1.32	4.60	2.66	1.86	0.85

The first thing to realize is that the refcount hack isn't hurting much,
about 4% or so, and in some cases (proc/fib) it is actually faster (I
suspect we're in the noise, it can't be faster).

The second thing is that it doesn't much matter which way you do it, 
for some tests the top bit is faster and other tests the bottom bit
is faster.  Again, I think we're in the noise, I'd expect one way 
or the other to be consistently faster.  Given that obj is faster
on B and that's the one that is most refcount heavy, I'm going with 
the top bit being faster (mask vs shift).

8.6 as of May 15 vs 8.5.1
-------------------------
Miguel asked me to report back on perf results for 8.6 beta.  The 8.6
tree we're using is 8.6 plus our changes but without the refcount stuff.
I would expect these results to be identical in a vanilla 8.6 tree,
we haven't modified the core other than the refcount stuff and regexp
stuff (see grep comments).

The grep test isn't comparable because 8.5.1 uses traditional regexp and
our 8.6 fork replaces that with PCRE.  So ignore that one.

Tcl     cat     grep    hash    loop    proc    fib     sort    wc      obj     
8.5.1	0.82	3.50	1.08	0.05	1.07	3.69	2.44	1.29	0.80
8.6b1	0.93	0.95	1.18	0.06	1.34	4.79	2.59	1.81	0.83
perl5.8	0.35	0.35	0.58	0.07	0.37	3.58	2.03	1.18	1.79

OK, so what does that mean?  Short summary is that 8.6 is up to 30%
slower than 8.5.1.  Longer summary is suppose we normalize on 8.5.1
(i.e., express the results as $result / 8.5.1 result so the results
are percentages, i.e., 50 means it's twice as fast and 150 means it's
50% slower:

Tcl     cat     grep    hash    loop    proc    fib     sort    wc      obj     
8.6b1	113%	  27%	109%	120%	125%	130%	106%	91%	103%
perl5.8	 42%	  10%	 53%	140%	 34%	 97%	 83%	91%	223%

If we leave out grep, because that's not a fair comparison, then tcl8.6b1
is 112%, or 12% slower, than 8.5.1 on average.  That's not great but it
seems to be somewhat concentrated in procedure calls?  Maybe Miguel can
shed some light on this.  

Perl is 95% of 8.5.1 on average, it gets hurt badly by loop overhead and 
object creation/deletion.  The nice thing is that if some more effort was
put into the gets/puts code paths I think tcl could get pretty competitive
with perl.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TCLCORE] another mkstemp fix

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

IRIX 6.5 apparently returns randoms larger than RAND_MAX.  Which makes
this routine dump core (sometimes).  Here's a fix.

BTW, I know tcl uses floats all over the place, but when I was hacking
libc stuff it was considered a big no-no to drag floating point into
libc functions.  Lots of processors (back then, at least, can't say today)
have extra registers they saved/restored on context switches if and only
if the process was using floating point.  Many Unix utilities avoided
floating point for that reason.  Not an issue here but in general, not
so much.


--- 1.2/compat/mkstemp.c        2009-05-12 14:38:55 -07:00
+++ edited/compat/mkstemp.c     2009-05-15 11:28:58 -07:00
@@ -64,7 +64,8 @@ mkstemp(
         */
 
        for (b=a ; *b ; b++) {
-           float r = random() / ((float) RAND_MAX);
+           long int rand = random() % RAND_MAX;        // IRIX is busted.
+           float r = rand / (float)RAND_MAX;
 
            *b = alphanumerics[(int)(r * alphanumericsLen)];
        }

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] TkToplevel

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

Oleg Puchinin wrote:
> I have a trouble.
[...]
> How to get @edit value after "top" is closed ?

This mailing list isn't for general user questions, but...

You can't; the widget's gone at that point. What you should do instead
is couple the entry to a variable (don't know how to do that in that
language you're using, but it must be possible) and then you can read
that variable after @top is gone. (I don't know the specifics of Ruby or
Tk's embedding into it to be able to offer more than that; it is Ruby
isn't it?)

Donal.

Re: [TCLCORE] TkToplevel

[Kevin W. <kw...@co...>]

Oleg Puchinin wrote:
> Hi !
> 
> I have a trouble.
> ###
> require "tk"
> 
> class Main
>   def initialize
>     @root = TkRoot.new { title "prog" }
> 
>     top = TkToplevel.new
>     @edit = TkEntry.new(top) {
>       pack
>     }
> 
>     cmd = proc { puts @edit.get }
> 
>     button = TkButton.new(@root) {
>       pack
>       text ""
>       command cmd
>     }
> 
>     top.grab
>     Tk.mainloop
>   end
> end
> 
> m = Main.new
> ###
> How to get @edit value after "top" is closed ?

This list is focused on the core development of Tcl/Tk--it's not a place 
to ask questions about Tcl/Tk usage. I suggest you post your questions 
on comp.lang.ruby or comp.lang.tcl.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[TCLCORE] TkToplevel

[Oleg P. <gra...@gm...>]

Hi !

I have a trouble.
###
require "tk"

class Main
  def initialize
    @root = TkRoot.new { title "prog" }

    top = TkToplevel.new
    @edit = TkEntry.new(top) {
      pack
    }

    cmd = proc { puts @edit.get }

    button = TkButton.new(@root) {
      pack
      text ""
      command cmd
    }

    top.grab
    Tk.mainloop
  end
end

m = Main.new
###
How to get @edit value after "top" is closed ?

[TCLCORE] make tests pass back status

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

In our tree we would like to include a subset of the tcl tests in our
normal builds and have it fail the build if the tests do not pass.
This patch accomplishes that for a subset or for all tests.


===== library/tcltest/tcltest.tcl 1.105 vs edited =====
--- 1.105/library/tcltest/tcltest.tcl	2008-02-11 09:34:32 -08:00
+++ edited/library/tcltest/tcltest.tcl	2009-05-12 14:13:10 -07:00
@@ -2735,6 +2735,7 @@ proc tcltest::runAllTests { {shell ""} }
 
     set timeCmd {clock format [clock seconds]}
     puts [outputChannel] "Tests began at [eval $timeCmd]"
+    set exit_status 0
 
     # Run each of the specified tests
     foreach file [lsort [GetMatchingFiles]] {
@@ -2772,6 +2773,7 @@ proc tcltest::runAllTests { {shell ""} }
 			}
 			if {$Failed > 0} {
 			    lappend failFiles $testFile
+			    set exit_status 1
 			}
 		    } elseif {[regexp [join {
 			    {^Number of tests skipped }
@@ -2799,6 +2801,7 @@ proc tcltest::runAllTests { {shell ""} }
     puts [outputChannel] "\nTests ended at [eval $timeCmd]"
     cleanupTests 1
     if {[info exists testFileFailures]} {
+	set exit_status 1
 	puts [outputChannel] "\nTest files exiting with errors:  \n"
 	foreach file $testFileFailures {
 	    puts [outputChannel] "  [file tail $file]\n"
@@ -2818,7 +2821,7 @@ proc tcltest::runAllTests { {shell ""} }
 	puts [outputChannel] ""
 	puts [outputChannel] [string repeat ~ 44]
     }
-    return
+    return $exit_status
 }
 
 #####################################################################
===== tests/all.tcl 1.18 vs edited =====
--- 1.18/tests/all.tcl	2006-11-02 16:34:52 -08:00
+++ edited/tests/all.tcl	2009-05-12 14:05:08 -07:00
@@ -16,4 +16,4 @@ package require Tcl 8.5
 package require tcltest 2.2
 namespace import tcltest::*
 configure {*}$argv -testdir [file dir [info script]]
-runAllTests
+exit [runAllTests]

Re: [TCLCORE] VWAIT documentation

[Abraham S. <ab...@ma...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thank you all for your replies.  <br>
<br>
We had gone through all the standard TCL documentation, including 8.6
beta and they were all the same.  At the end, we went into the TCL
source code for a clearer understanding.  <br>
<br>
>From what we gathered, it appears that each vwait call is added to a
stack.  As such, the last vwait on the stack must be resolved first
before the others are even processed.  Thus, our suggestion of Chris
Nelson's statement from wiki.tcl.tk.<br>
<br>
Detail description of how <b>vwaits </b>are resolved will enable
clarity and certainty in code behaviour.<br>
<br>
Thank you.<br>
<br>
Regards.<br>
Abe<br>
<br>
<hr size="2" width="100%"><br>
Donal K. Fellows wrote:
<blockquote cite="mid:4A0...@ma..." type="cite">Twylite
wrote:
  <br>
  <blockquote type="cite">On this basis I support the proposal to have
the above statement (or something similar) included in the man page.
    <br>
  </blockquote>
  <br>
It seems like a reasonable request to me, though I'm not currently sure
  <br>
what the text should actually look like. However, I think it's possible
  <br>
to offer additional remedies in 8.6, where you can use a
coroutine-based
  <br>
scheme to write code that *looks* virtually identical to the bad old
  <br>
[vwait]-based code, but which is in fact event-loop friendly. Thus it
  <br>
would be good to at least indicate that this is possible in the docs,
  <br>
making for a substantively different overall flavour...
  <br>
  <br>
If someone were to file a bug about this (top-prio) so that it gets
  <br>
sorted out in time for the next 8.5 and 8.6 releases, that would be a
  <br>
very good deed.
  <br>
  <br>
Donal.
  <br>
  <br>
  <blockquote type="cite">
    <pre wrap="">I'm not a strong voice here but Twylite's request seems pretty reasonable,
just including an example that shows the prob in the docs would be better.
At my company we have a goal: "drive towards zero support costs".  This
request seems in line with that.  If tweaking the docs means less people
ask questions, why not?

On Thu, May 07, 2009 at 09:37:52AM +0200, Twylite wrote:
    </pre>
    <pre wrap=""><span class="moz-txt-citetags">&gt; </span>Hi,
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap=""><span class="moz-txt-citetags">&gt; &gt;&gt; </span>As such, we will like to request that the following statement
<span class="moz-txt-citetags">&gt; &gt;&gt; </span>extracted from wiki.tcl.tk/1302 by Chris Nelson to be included in the
<span class="moz-txt-citetags">&gt; &gt;&gt; </span>standard documentation:
<span class="moz-txt-citetags">&gt; &gt;&gt; </span>    
<span class="moz-txt-citetags">&gt; &gt;&gt; </span>   Multiple VWAITS NEST, THEY DO NOT HAPPEN IN PARALLEL. THE
<span class="moz-txt-citetags">&gt; &gt;&gt; </span>OUTERMOST VWAIT CANNOT COMPLETE UNTIL ALL OTHERS RETURN.
<span class="moz-txt-citetags">&gt; &gt;&gt; </span>    
        </pre>
      </blockquote>
      <pre wrap=""><span class="moz-txt-citetags">&gt; &gt; </span>The standard documentation appears clear on this matter to me.
<span class="moz-txt-citetags">&gt; &gt; </span>The entire second paragraph of the DESCRIPTION section is
<span class="moz-txt-citetags">&gt; &gt; </span>devoted to discussing it.
      </pre>
    </blockquote>
    <pre wrap=""><span class="moz-txt-citetags">&gt; </span>This has historically been a source of problems for new Tcl users, and I 
<span class="moz-txt-citetags">&gt; </span>am inclined to feel (now that I have re-read it) that the 8.5 man page 
<span class="moz-txt-citetags">&gt; </span>for vwait is a little too narrative and does not succinctly explain the 
<span class="moz-txt-citetags">&gt; </span>behaviour of nested vwaits as the above proposal does. 
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>In fact it (the man page) fails completely to explain that unrelated 
<span class="moz-txt-citetags">&gt; </span>vwaits can cause blocking.  For example:
<span class="moz-txt-citetags">&gt; </span>  after 500 { vwait b; puts "b was set" }
<span class="moz-txt-citetags">&gt; </span>  after 1000 { set a 10 }
<span class="moz-txt-citetags">&gt; </span>  vwait a
<span class="moz-txt-citetags">&gt; </span>  puts "Never get here"
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>This example has nothing to do with "the event handler that sets varName 
<span class="moz-txt-citetags">&gt; </span>... not complete[ing] immediately" as described in the man page, but 
<span class="moz-txt-citetags">&gt; </span>rather that the unrelated "vwait b" creates a new event loop which 
<span class="moz-txt-citetags">&gt; </span>blocks "vwait a" until the "vwait b" returns.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>On this basis I support the proposal to have the above statement (or 
<span class="moz-txt-citetags">&gt; </span>something similar) included in the man page.
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>Regards,
<span class="moz-txt-citetags">&gt; </span>Twylite</pre>
  </blockquote>
  <blockquote type="cite">
    <div class="moz-text-flowed"
 style="font-family: -moz-fixed; font-size: 16px;" lang="x-western">Abraham
Saw <a class="moz-txt-link-rfc2396E" href="mailto:ab...@ma...">&lt;ab...@ma...&gt;</a>:
    <br>
    <blockquote type="cite"> we have recently crashed into an inherent
limitations in the VWAIT
      <br>
commands which unfortunately was not clearly documented in the
      <br>
standard documentation included in releases.
      <br>
    </blockquote>
    <br>
That same documentation is online:
    <br>
    <br>
    <a class="moz-txt-link-freetext"
 href="http://www.tcl.tk/man/tcl8.4/TclCmd/vwait.htm">http://www.tcl.tk/man/tcl8.4/TclCmd/vwait.htm</a>
    <br>
    <a class="moz-txt-link-freetext"
 href="http://www.tcl.tk/man/tcl8.5/TclCmd/vwait.htm">http://www.tcl.tk/man/tcl8.5/TclCmd/vwait.htm</a>
    <br>
    <br>
    <blockquote type="cite">As such, we will like to request that the
following statement
      <br>
extracted from wiki.tcl.tk/1302 by Chris Nelson to be included in the
      <br>
standard documentation:
      <br>
    </blockquote>
    <br>
    <blockquote type="cite">   Multiple VWAITS NEST, THEY DO NOT HAPPEN
IN PARALLEL. THE
      <br>
OUTERMOST VWAIT CANNOT COMPLETE UNTIL ALL OTHERS RETURN.
      <br>
    </blockquote>
    <br>
The standard documentation appears clear on this matter to me.
    <br>
The entire second paragraph of the DESCRIPTION section is
    <br>
devoted to discussing it.
    <br>
    <br>
What documentation are you looking at?
    <br>
    <br>
DGP
    <br>
    <br>
    <br>
    <br>
    </div>
  </blockquote>
  <br>
</blockquote>
</body>
</html>

Re: [TCLCORE] Stealing a bit in Tcl_Obj

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

On Mon, May 11, 2009 at 01:32:19AM +0100, Donal K. Fellows wrote:
> Alexandre Ferrieux wrote:
> >      (1) is stealing the high bit of refcount really an option? I
> > remember seeing objects being freed at the 0->-1 transition (instead
> > of the usual 1->0), so I'm worried by other possible uses of negative
> > values.
> 
> We deallocate on the transition to "less than 1", and we start with
> refcount 0. I remember the experimentation with refcounting schemes back
> before 8.0b1 came out; the current one *is* best, and the pain with
> changing it is quite extreme. Our API is fixed here, at least for the
> 8.* series, and you'd have to argue well to persuade me that API changes
> are a good idea even at 9.0. ("More intuitive" schemes were tried, but
> were found noisomely officious and bureaucratic for extension authors.)
> 
> If you're using negative values for flagging things that are currently
> allocated, you'll run into trouble because the refcounting scheme is
> implemented by macros and so is spread out across lots of extensions.
> I'm not keen on ABI changes if at all possible in the 8.* series. (Flags
> for unallocated objects are something else; I believe we do "clever"
> games there already so we get efficient memory management. That's also
> not exposed to extensions.)
> 
> We plan that 9.0 will not be ABI-compatible with 8.*; a recompile of the
> whole world will be needed then. :-)
> 
> >      (2) if not, would a slightly less ambitious method work ? I mean
> > reserving a few special negative values instead of Larry's suggestion
> > of 2**31 ones...
> 
> If Tcl_IncrRefCount and Tcl_DecrRefCount were functions, yes. But
> they're (simple-minded) macros, so no.
> 
> Sorry for being so negative, but refcount management is really a bit too
> widely "directly" implemented to be possible to change without a lot of
> disruption. The small error that led to this happened back in 8.0a1,
> when "recompiling everything for every release" was common, so it wasn't
> even seen as an error at the time. No sense crying over spilt milk.

Ahh, I'm starting to see the problem.  So we can muck w/ the struct all
we want but if we try and load an extension that wasn't compiled with 
our headers it will barf.  

Not a problem for us, we rebuild everything, but a problem for you as
a maintainer who has to deal with extension compat, mucking with the
headers not so much.

So fine for us, not going to go into the core, with good reason.  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] Stealing a bit in Tcl_Obj

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

Alexandre Ferrieux wrote:
>      (1) is stealing the high bit of refcount really an option? I
> remember seeing objects being freed at the 0->-1 transition (instead
> of the usual 1->0), so I'm worried by other possible uses of negative
> values.

We deallocate on the transition to "less than 1", and we start with
refcount 0. I remember the experimentation with refcounting schemes back
before 8.0b1 came out; the current one *is* best, and the pain with
changing it is quite extreme. Our API is fixed here, at least for the
8.* series, and you'd have to argue well to persuade me that API changes
are a good idea even at 9.0. ("More intuitive" schemes were tried, but
were found noisomely officious and bureaucratic for extension authors.)

If you're using negative values for flagging things that are currently
allocated, you'll run into trouble because the refcounting scheme is
implemented by macros and so is spread out across lots of extensions.
I'm not keen on ABI changes if at all possible in the 8.* series. (Flags
for unallocated objects are something else; I believe we do "clever"
games there already so we get efficient memory management. That's also
not exposed to extensions.)

We plan that 9.0 will not be ABI-compatible with 8.*; a recompile of the
whole world will be needed then. :-)

>      (2) if not, would a slightly less ambitious method work ? I mean
> reserving a few special negative values instead of Larry's suggestion
> of 2**31 ones...

If Tcl_IncrRefCount and Tcl_DecrRefCount were functions, yes. But
they're (simple-minded) macros, so no.

Sorry for being so negative, but refcount management is really a bit too
widely "directly" implemented to be possible to change without a lot of
disruption. The small error that led to this happened back in 8.0a1,
when "recompiling everything for every release" was common, so it wasn't
even seen as an error at the time. No sense crying over spilt milk.

Donal.

[TCLCORE] Stealing a bit in Tcl_Obj

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

Hi,

Recently, Larry McVoy has suggested to use the high bit of refcounts
for ... well, the goal he has in mind ;-)

In a completely orthogonal way, I would too like to steal a bit in
that ubiquitous and tight structure, to allow for non-ckalloc'ed
streps (useful for efficient use of mmapped things like serialized
dicts).

Questions:

     (1) is stealing the high bit of refcount really an option? I
remember seeing objects being freed at the 0->-1 transition (instead
of the usual 1->0), so I'm worried by other possible uses of negative
values.

     (2) if not, would a slightly less ambitious method work ? I mean
reserving a few special negative values instead of Larry's suggestion
of 2**31 ones...

-Alex

Re: [TCLCORE] Finalization vs. Exit

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

On Fri, May 8, 2009 at 12:36 PM, Donal K. Fellows
<don...@ma...> wrote:
>
> Since nobody else has commented, I offer not insight, but rather
> encouragement. Finalization is a difficult area (to say the least) and
> it merits much study. Part of the difficulty is probably assembling a
> good enough set of use cases for all the things that finalization/exit
> has to cope with. Indeed, most problems in this area can be traced back
> to having an incomplete knowledge of what actually needs to be done.

Thanks Donal.

I could take a head start in that quest if specific
extension/embedding authors (or people familiar with popular ones)
were to step forward here and answer the following:

    What could go wrong in your extension/app if we restricted
Tcl_Exit() to just running (early) exit handlers and exiting ?

-Alex