info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
The Start of Tcl 9
1,023 views
Skip to first unread message
Donal K. Fellows
Nov 15, 2012, 1:07:03 PM11/15/12
to
The Tcl Core Team is pleased to say that development has started on Tcl
9.0, where we will be trying to take a more radical approach to cleaning
up our code in order to enable improved long-term code health. Our aims
are to minimize the amount of breakage at the Tcl level (unless we've
got a *really good* reason otherwise); the C level will have rather more
changes with an aim to support such things as support for much larger
data and much greater performance.
We've started a branch in our fossil repository at:
https://core.tcl.tk/tcl/timeline?r=novem
Follow along — or help! — but be aware that we've only just started on
this and there is a fair old way to go.
(Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
distant future. We'll be progressing those in parallel; we don't
anticipate the effort for 9.0 from detracting from those in any way.)
Donal Fellows (for the TCT).
9.0, where we will be trying to take a more radical approach to cleaning
up our code in order to enable improved long-term code health. Our aims
are to minimize the amount of breakage at the Tcl level (unless we've
got a *really good* reason otherwise); the C level will have rather more
changes with an aim to support such things as support for much larger
data and much greater performance.
We've started a branch in our fossil repository at:
https://core.tcl.tk/tcl/timeline?r=novem
Follow along — or help! — but be aware that we've only just started on
this and there is a fair old way to go.
(Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
distant future. We'll be progressing those in parallel; we don't
anticipate the effort for 9.0 from detracting from those in any way.)
Donal Fellows (for the TCT).
Kevin Walzer
Nov 15, 2012, 5:31:37 PM11/15/12
to
On 11/15/12 1:07 PM, Donal K. Fellows wrote:
> The Tcl Core Team is pleased to say that development has started on Tcl
> 9.0, where we will be trying to take a more radical approach to cleaning
> up our code in order to enable improved long-term code health. Our aims
> are to minimize the amount of breakage at the Tcl level (unless we've
> got a *really good* reason otherwise); the C level will have rather more
> changes with an aim to support such things as support for much larger
> data and much greater performance.
Do you envision Tcl 9 following the direction of Python 3, or Perl 6?
> The Tcl Core Team is pleased to say that development has started on Tcl
> 9.0, where we will be trying to take a more radical approach to cleaning
> up our code in order to enable improved long-term code health. Our aims
> are to minimize the amount of breakage at the Tcl level (unless we've
> got a *really good* reason otherwise); the C level will have rather more
> changes with an aim to support such things as support for much larger
> data and much greater performance.
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Joe English
Nov 16, 2012, 12:19:35 AM11/16/12
to
Kevin Walzer asked:
existing Tcl scripts will be kept to a minimum. Compatibility
is still an important factor; it's just that with Tcl 9 it will
no longer be the *most* important factor.
If a change would fix more new code than it would break old,
then the default decision will now be to make the change.
(In the 8.* series, the default decision was to keep things
the same.) Hence: no more octal integer literals, no more
creative writing, and in general no more preservation of
longstanding bugs out of fear that it might break somebody's
decades-old unmaintained codebase.
On the C side, there will probably be bigger changes. I would
not expect 1995-era extensions to continue to work under Tcl 9
without modification. (However, compatibility is important
here, too, and I don't anticipate any major breakage to the C
API that we won't have been warned about.)
--Joe English
> Donal K. Fellows wrote:
>> The Tcl Core Team is pleased to say that development has started on Tcl
>> 9.0, where we will be trying to take a more radical approach to cleaning
>> up our code in order to enable improved long-term code health. Our aims
>> are to minimize the amount of breakage at the Tcl level (unless we've
>> got a *really good* reason otherwise); the C level will have rather more
>> changes with an aim to support such things as support for much larger
>> data and much greater performance.
>
> Do you envision Tcl 9 following the direction of Python 3, or Perl 6?
I'll just echo what Donal said: I envision that the impact to
>> The Tcl Core Team is pleased to say that development has started on Tcl
>> 9.0, where we will be trying to take a more radical approach to cleaning
>> up our code in order to enable improved long-term code health. Our aims
>> are to minimize the amount of breakage at the Tcl level (unless we've
>> got a *really good* reason otherwise); the C level will have rather more
>> changes with an aim to support such things as support for much larger
>> data and much greater performance.
>
> Do you envision Tcl 9 following the direction of Python 3, or Perl 6?
existing Tcl scripts will be kept to a minimum. Compatibility
is still an important factor; it's just that with Tcl 9 it will
no longer be the *most* important factor.
If a change would fix more new code than it would break old,
then the default decision will now be to make the change.
(In the 8.* series, the default decision was to keep things
the same.) Hence: no more octal integer literals, no more
creative writing, and in general no more preservation of
longstanding bugs out of fear that it might break somebody's
decades-old unmaintained codebase.
On the C side, there will probably be bigger changes. I would
not expect 1995-era extensions to continue to work under Tcl 9
without modification. (However, compatibility is important
here, too, and I don't anticipate any major breakage to the C
API that we won't have been warned about.)
--Joe English
Georgios Petasis
Nov 16, 2012, 2:46:18 AM11/16/12
to
(Is it a good idea to use cairo in Tk?)
And perhaps look again the threads issue... :-)
George
Donal K. Fellows
Nov 16, 2012, 7:55:00 AM11/16/12
to
On 16/11/2012 01:46, Georgios Petasis wrote:
> It would be nice if we could enhance Tk a bit.
> (Is it a good idea to use cairo in Tk?)
> And perhaps look again the threads issue... :-)
Improvements to the rendering engine would definitely be welcome, as
> It would be nice if we could enhance Tk a bit.
> (Is it a good idea to use cairo in Tk?)
> And perhaps look again the threads issue... :-)
would reconsidering the nature of what a "widget" actually is in the
face of handheld touch-sensitive devices, but my time is mostly going to
be spent on Tcl. (The really big effort will be going into getting us
out of the performance rut that we've got stuck in, and that's going to
keep me very busy for a while.)
We can start a 'novem' branch for Tk any time; we just want a change
worthy of the name to kick it off. :-)
Donal.
Georgios Petasis
Nov 16, 2012, 8:33:07 AM11/16/12
to
it during an experiment for ttkgtk (porting tile-gtk to gtk 3), and was
easy to use. In addition it seemed cross-platform enough, with some
interesting capabilities, like drawing on a pdf document...
George
Kevin Walzer
Nov 16, 2012, 9:44:54 AM11/16/12
to
On 11/16/12 8:33 AM, Georgios Petasis wrote:
> I really don't know if moving to cairo is "the way to go", but I tried
> it during an experiment for ttkgtk (porting tile-gtk to gtk 3), and was
> easy to use. In addition it seemed cross-platform enough, with some
> interesting capabilities, like drawing on a pdf document...
>
> George
I've never understood this. Cairo would add a lot of complexity to Tk
> I really don't know if moving to cairo is "the way to go", but I tried
> it during an experiment for ttkgtk (porting tile-gtk to gtk 3), and was
> easy to use. In addition it seemed cross-platform enough, with some
> interesting capabilities, like drawing on a pdf document...
>
> George
(both in terms of its library dependency and licensing, which is LGPL).
Arjen Markus
Nov 16, 2012, 9:59:49 AM11/16/12
to
On Friday, November 16, 2012 2:33:33 PM UTC+1, Georgios Petasis wrote:
..., with some
to accomplish in pure Tcl. I use it myself to copy the contents of a canvas
widget into a PDF document, but it can quite probably be adopted to directly
draw into such a document.
Regards,
Arjen
..., with some
> interesting capabilities, like drawing on a pdf document...
>
> George
Well, with Peter Spjuth's pdf4tcl package available that would be relatively easy
>
> George
to accomplish in pure Tcl. I use it myself to copy the contents of a canvas
widget into a PDF document, but it can quite probably be adopted to directly
draw into such a document.
Regards,
Arjen
Christian Gollwitzer
Nov 16, 2012, 11:44:26 AM11/16/12
to
Am 15.11.12 19:07, schrieb Donal K. Fellows:
> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
> distant future. We'll be progressing those in parallel; we don't
> anticipate the effort for 9.0 from detracting from those in any way.)
For the 8.6.0 release, I have a personal wish list what should be
addressed especially in Tk:
TkCocoa: -typevariable is not implemented in file dialogs. It worked
under Carbon, but in Cocoa the UI elements are missing (native
applications like Pages have it, and it behaves exactly like
-typevariable).
X11: -typevariable returns the wrong thing (works as documented in
Windows and TkCarbon)
- non-native themes have no visual feedback for the tristate third state
in checkboxes and radiobuttons.
I'm not sure I have written bug reports for all of these issues, but I
definitely have for the last one. It's fairly low-hanging fruit, since
Jeff Hobbs posted a hotfix here for one theme.
Is there any chance to get these issues addressed before 8.6.0? For the
last two, I could possibly provide a patch.
Christian
> The Tcl Core Team is pleased to say that development has started on Tcl
> 9.0, where we will be trying to take a more radical approach to cleaning
> up our code in order to enable improved long-term code health. Our aims
> are to minimize the amount of breakage at the Tcl level (unless we've
> got a *really good* reason otherwise); the C level will have rather more
> changes with an aim to support such things as support for much larger
> data and much greater performance.
Wow, that's great!
> 9.0, where we will be trying to take a more radical approach to cleaning
> up our code in order to enable improved long-term code health. Our aims
> are to minimize the amount of breakage at the Tcl level (unless we've
> got a *really good* reason otherwise); the C level will have rather more
> changes with an aim to support such things as support for much larger
> data and much greater performance.
> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
> distant future. We'll be progressing those in parallel; we don't
> anticipate the effort for 9.0 from detracting from those in any way.)
addressed especially in Tk:
TkCocoa: -typevariable is not implemented in file dialogs. It worked
under Carbon, but in Cocoa the UI elements are missing (native
applications like Pages have it, and it behaves exactly like
-typevariable).
X11: -typevariable returns the wrong thing (works as documented in
Windows and TkCarbon)
- non-native themes have no visual feedback for the tristate third state
in checkboxes and radiobuttons.
I'm not sure I have written bug reports for all of these issues, but I
definitely have for the last one. It's fairly low-hanging fruit, since
Jeff Hobbs posted a hotfix here for one theme.
Is there any chance to get these issues addressed before 8.6.0? For the
last two, I could possibly provide a patch.
Christian
Christian Gollwitzer
Nov 16, 2012, 11:47:03 AM11/16/12
to
Am 15.11.12 19:07, schrieb Donal K. Fellows:
> The Tcl Core Team is pleased to say that development has started on Tcl
> 9.0, where we will be trying to take a more radical approach to cleaning
> up our code in order to enable improved long-term code health. Our aims
> are to minimize the amount of breakage at the Tcl level (unless we've
> got a *really good* reason otherwise); the C level will have rather more
> changes with an aim to support such things as support for much larger
> data and much greater performance.
Wow, that's great!
> 9.0, where we will be trying to take a more radical approach to cleaning
> up our code in order to enable improved long-term code health. Our aims
> are to minimize the amount of breakage at the Tcl level (unless we've
> got a *really good* reason otherwise); the C level will have rather more
> changes with an aim to support such things as support for much larger
> data and much greater performance.
> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
> distant future. We'll be progressing those in parallel; we don't
> anticipate the effort for 9.0 from detracting from those in any way.)
Gerald W. Lester
Nov 16, 2012, 12:07:24 PM11/16/12
to
On 11/16/12 10:44 AM, Christian Gollwitzer wrote:
> Am 15.11.12 19:07, schrieb Donal K. Fellows:
>>...
> Am 15.11.12 19:07, schrieb Donal K. Fellows:
> Wow, that's great!
>
>> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
>> distant future. We'll be progressing those in parallel; we don't
>> anticipate the effort for 9.0 from detracting from those in any way.)
>
> For the 8.6.0 release, I have a personal wish list what should be addressed
> especially in Tk:
8.6.0 has been feature frozen. The 8.6.0 "production" release (not alpha or
>
>> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
>> distant future. We'll be progressing those in parallel; we don't
>> anticipate the effort for 9.0 from detracting from those in any way.)
>
> For the 8.6.0 release, I have a personal wish list what should be addressed
> especially in Tk:
beta) is coming out *REAL SOON NOW* (read minutes/hours/(very very few)days).
> TkCocoa: -typevariable is not implemented in file dialogs. It worked under
> Carbon, but in Cocoa the UI elements are missing (native applications like
> Pages have it, and it behaves exactly like -typevariable).
>
> X11: -typevariable returns the wrong thing (works as documented in Windows
> and TkCarbon)
>
> - non-native themes have no visual feedback for the tristate third state in
> checkboxes and radiobuttons.
>
> I'm not sure I have written bug reports for all of these issues, but I
> definitely have for the last one. It's fairly low-hanging fruit, since Jeff
> Hobbs posted a hotfix here for one theme.
>
> Is there any chance to get these issues addressed before 8.6.0?
> For the last two, I could possibly provide a patch.
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
Les Cargill
Nov 16, 2012, 1:32:38 PM11/16/12
to
--
Les Cargill
Sp...@controlq.com
Nov 16, 2012, 6:00:59 PM11/16/12
to
On Fri, 16 Nov 2012, Georgios Petasis wrote:
> Date: Fri, 16 Nov 2012 09:46:18 +0200
> From: Georgios Petasis <pet...@iit.demokritos.gr>
> Newsgroups: comp.lang.tcl
> Subject: Re: The Start of Tcl 9
>
> ???? 15/11/2012 20:07, ?/? Donal K. Fellows ??????:
might be of some small inspiration ... They have some nice ideas in the
EFL, and if 9.x is coming, perhaps some inherent portability would be in
order (tablets etc).
Cheers,
Rob.
> Date: Fri, 16 Nov 2012 09:46:18 +0200
> From: Georgios Petasis <pet...@iit.demokritos.gr>
> Newsgroups: comp.lang.tcl
> Subject: Re: The Start of Tcl 9
>
> ???? 15/11/2012 20:07, ?/? Donal K. Fellows ??????:
>> The Tcl Core Team is pleased to say that development has started on Tcl
>> 9.0, where we will be trying to take a more radical approach to cleaning
>> up our code in order to enable improved long-term code health. Our aims
>> are to minimize the amount of breakage at the Tcl level (unless we've
>> got a *really good* reason otherwise); the C level will have rather more
>> changes with an aim to support such things as support for much larger
>> data and much greater performance.
>>
>> We've started a branch in our fossil repository at:
>>
>> https://core.tcl.tk/tcl/timeline?r=novem
>>
>> Follow along ? or help! ? but be aware that we've only just started on
>> 9.0, where we will be trying to take a more radical approach to cleaning
>> up our code in order to enable improved long-term code health. Our aims
>> are to minimize the amount of breakage at the Tcl level (unless we've
>> got a *really good* reason otherwise); the C level will have rather more
>> changes with an aim to support such things as support for much larger
>> data and much greater performance.
>>
>> We've started a branch in our fossil repository at:
>>
>> https://core.tcl.tk/tcl/timeline?r=novem
>>
>> this and there is a fair old way to go.
>>
>> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
>> distant future. We'll be progressing those in parallel; we don't
>> anticipate the effort for 9.0 from detracting from those in any way.)
>>
>> Donal Fellows (for the TCT).
>
> It would be nice if we could enhance Tk a bit.
> (Is it a good idea to use cairo in Tk?)
> And perhaps look again the threads issue... :-)
>
> George
>
Perhaps a brief glance at the EVAS canvas tool in the Enlightenment distro
>>
>> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
>> distant future. We'll be progressing those in parallel; we don't
>> anticipate the effort for 9.0 from detracting from those in any way.)
>>
>> Donal Fellows (for the TCT).
>
> It would be nice if we could enhance Tk a bit.
> (Is it a good idea to use cairo in Tk?)
> And perhaps look again the threads issue... :-)
>
> George
>
might be of some small inspiration ... They have some nice ideas in the
EFL, and if 9.x is coming, perhaps some inherent portability would be in
order (tablets etc).
Cheers,
Rob.
Googie
Nov 18, 2012, 7:54:19 AM11/18/12
to
W dniu piątek, 16 listopada 2012 08:46:45 UTC+1 użytkownik Georgios Petasis napisał:
> And perhaps look again the threads issue... :-)
I'm not sure if this "issue" is about what I'm thinking it is about. What I mean is that I strongly agree that this would be an ideal moment to reconsider the multithreading model in Tcl, so developers have *possibility* to use many threads on one interpreter, or at least an easy way to share some of resources.
> And perhaps look again the threads issue... :-)
I know, I know... it would be huge amount of work on C level, since it wasn't designed like this, but if we're talking about more radical changes, well, I believe this is an important one.
Regards,
Googie
Donal K. Fellows
Nov 18, 2012, 1:13:17 PM11/18/12
to
On Friday, 16 November 2012 10:46:31 UTC-6, Christian Gollwitzer wrote:
> Fore 8.6.0 release, I have a personal wish list what should be
> addred especially in Tk:
[...]
Donal
> Fore 8.6.0 release, I have a personal wish list what should be
> addred especially in Tk:
[...]
> Is there any chance to get these issues addressed before 8.6.0? For the
> last two, I could possibly provide a patch.
Not really. We are at an advanced stage of locking everything down, and would probably only hold for things that prevented tclsh/wish from running now. There is always 8.6.1...
> last two, I could possibly provide a patch.
Donal
Christian Gollwitzer
Nov 19, 2012, 1:51:38 AM11/19/12
to
Am 18.11.12 19:13, schrieb Donal K. Fellows:
Now problem, I'll have more time to submit a patch;)
But 8.6b3 fails to compile on Mountain Lion. Tcl works, Tk fails in the
final link step:
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_TKApplication", referenced from:
l_OBJC_$_CATEGORY_TKApplication_$_TKClipboard in tkMacOSXClipboard.o
l_OBJC_$_CATEGORY_TKApplication_$_TKDialog in tkMacOSXDialog.o
l_OBJC_$_CATEGORY_TKApplication_$_TKFontPanel in tkMacOSXDialog.o
l_OBJC_$_CATEGORY_TKApplication_$_TKEvent in tkMacOSXEvent.o
l_OBJC_$_CATEGORY_TKApplication_$_TKHLEvents in tkMacOSXHLEvents.o
objc-class-ref in tkMacOSXInit.o
l_OBJC_$_CATEGORY_TKApplication_$_TKInit in tkMacOSXInit.o
...
"_OBJC_IVAR_$_TKApplication._defaultApplicationMenu", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultApplicationMenuItems", referenced
from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultHelpMenuItems", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultMainMenu", referenced from:
-[TKApplication(TKInit) _setup:] in tkMacOSXInit.o
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultWindowsMenuItems", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._eventInterp", referenced from:
-[TKApplication(TKHLEvents) terminate:] in tkMacOSXHLEvents.o
-[TKApplication(TKHLEvents) preferences:] in tkMacOSXHLEvents.o
-[TKApplication(TKInit) _setup:] in tkMacOSXInit.o
-[TKApplication(TKInit) tkFrameworkImagePath:] in tkMacOSXInit.o
-[TKApplication(TKMenus) validateUserInterfaceItem:] in
tkMacOSXMenus.o
-[TKApplication(TKMenus) orderFrontStandardAboutPanel:] in
tkMacOSXMenus.o
-[TKApplication(TKMenus) showHelp:] in tkMacOSXMenus.o
...
"_OBJC_IVAR_$_TKApplication._servicesMenu", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [libtk8.6.dylib] Error 1
My command lines were:
# Tcl
./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
make -j4; make install
# Tk
./configure --prefix=/Users/chris/Sources/tcl86
--with-tcl=/Users/chris/Sources/tcl86/lib/ --enable-64bit --enable-aqua=yes
make -j4
Using CC=clang also does not help. I'm on OSX 10.8.2 using the newest
Xcode 4.2.5
Christian
But 8.6b3 fails to compile on Mountain Lion. Tcl works, Tk fails in the
final link step:
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_TKApplication", referenced from:
l_OBJC_$_CATEGORY_TKApplication_$_TKClipboard in tkMacOSXClipboard.o
l_OBJC_$_CATEGORY_TKApplication_$_TKDialog in tkMacOSXDialog.o
l_OBJC_$_CATEGORY_TKApplication_$_TKFontPanel in tkMacOSXDialog.o
l_OBJC_$_CATEGORY_TKApplication_$_TKEvent in tkMacOSXEvent.o
l_OBJC_$_CATEGORY_TKApplication_$_TKHLEvents in tkMacOSXHLEvents.o
objc-class-ref in tkMacOSXInit.o
l_OBJC_$_CATEGORY_TKApplication_$_TKInit in tkMacOSXInit.o
...
"_OBJC_IVAR_$_TKApplication._defaultApplicationMenu", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultApplicationMenuItems", referenced
from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultHelpMenuItems", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultMainMenu", referenced from:
-[TKApplication(TKInit) _setup:] in tkMacOSXInit.o
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._defaultWindowsMenuItems", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
-[TKApplication(TKMenus) dealloc] in tkMacOSXMenus.o
"_OBJC_IVAR_$_TKApplication._eventInterp", referenced from:
-[TKApplication(TKHLEvents) terminate:] in tkMacOSXHLEvents.o
-[TKApplication(TKHLEvents) preferences:] in tkMacOSXHLEvents.o
-[TKApplication(TKInit) _setup:] in tkMacOSXInit.o
-[TKApplication(TKInit) tkFrameworkImagePath:] in tkMacOSXInit.o
-[TKApplication(TKMenus) validateUserInterfaceItem:] in
tkMacOSXMenus.o
-[TKApplication(TKMenus) orderFrontStandardAboutPanel:] in
tkMacOSXMenus.o
-[TKApplication(TKMenus) showHelp:] in tkMacOSXMenus.o
...
"_OBJC_IVAR_$_TKApplication._servicesMenu", referenced from:
-[TKApplication(TKMenu) tkSetMainMenu:] in tkMacOSXMenu.o
-[TKApplication(TKMenus) _setupMenus] in tkMacOSXMenus.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [libtk8.6.dylib] Error 1
My command lines were:
# Tcl
./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
make -j4; make install
# Tk
./configure --prefix=/Users/chris/Sources/tcl86
--with-tcl=/Users/chris/Sources/tcl86/lib/ --enable-64bit --enable-aqua=yes
make -j4
Using CC=clang also does not help. I'm on OSX 10.8.2 using the newest
Xcode 4.2.5
Christian
Christian Gollwitzer
Nov 19, 2012, 2:01:24 AM11/19/12
to
PS: It is a regression. 8.6b2 compiles and works, 8.6b3 fails to link
Am 19.11.12 07:51, schrieb Christian Gollwitzer:
Am 19.11.12 07:51, schrieb Christian Gollwitzer:
Christian Gollwitzer
Nov 19, 2012, 3:45:33 AM11/19/12
to
Am 16.11.12 18:07, schrieb Gerald W. Lester:
records, here is the patch for X11:
--- tk8.6b3/library/tkfbox.tcl 2012-09-13 21:57:38.000000000 +0200
+++ tcl86/lib/tk8.6/tkfbox.tcl 2012-11-19 09:38:50.000000000 +0100
@@ -310,6 +310,7 @@
# 5. Parse the -filetypes option
#
+ set data(origfiletypes) $data(-filetypes)
set data(-filetypes) [::tk::FDGetFileTypes $data(-filetypes)]
if {![winfo exists $data(-parent)]} {
@@ -1119,7 +1120,7 @@
&& [info exists data(filterType)] && $data(filterType) ne ""
} then {
upvar #0 $data(-typevariable) typeVariable
- set typeVariable [lindex $data(filterType) 0]
+ set typeVariable [lindex $data(origfiletypes) [lsearch -exact
$data(-filetypes) $data(filterType)] 0]
}
}
bind $data(okBtn) <Destroy> {}
=========================
Test scrip:
package require tcltest
package require Tk
puts [tk_getSaveFile -initialfile foo -typevariable seltype -filetypes
{{TEXT *.txt}}]
puts $seltype
# old behaviour
# Tk/Carbon: TEXT
# Tk/Cocoa: seltype is undefined
# Win: TEXT
# X11: TEXT (*.txt)
Christian
>> TkCocoa: -typevariable is not implemented in file dialogs. It worked
>> under
>> Carbon, but in Cocoa the UI elements are missing (native applications
>> like
>> Pages have it, and it behaves exactly like -typevariable).
>>
>> X11: -typevariable returns the wrong thing (works as documented in
>> Windows
>> and TkCarbon)
>
>> under
>> Carbon, but in Cocoa the UI elements are missing (native applications
>> like
>> Pages have it, and it behaves exactly like -typevariable).
>>
>> X11: -typevariable returns the wrong thing (works as documented in
>> Windows
>> and TkCarbon)
>
> Please put the patch as part of your SourceForge bug.
>
I see I haven't submitted a bug for that. I'll do it soon. For the
>
records, here is the patch for X11:
--- tk8.6b3/library/tkfbox.tcl 2012-09-13 21:57:38.000000000 +0200
+++ tcl86/lib/tk8.6/tkfbox.tcl 2012-11-19 09:38:50.000000000 +0100
@@ -310,6 +310,7 @@
# 5. Parse the -filetypes option
#
+ set data(origfiletypes) $data(-filetypes)
set data(-filetypes) [::tk::FDGetFileTypes $data(-filetypes)]
if {![winfo exists $data(-parent)]} {
@@ -1119,7 +1120,7 @@
&& [info exists data(filterType)] && $data(filterType) ne ""
} then {
upvar #0 $data(-typevariable) typeVariable
- set typeVariable [lindex $data(filterType) 0]
+ set typeVariable [lindex $data(origfiletypes) [lsearch -exact
$data(-filetypes) $data(filterType)] 0]
}
}
bind $data(okBtn) <Destroy> {}
=========================
Test scrip:
package require tcltest
package require Tk
puts [tk_getSaveFile -initialfile foo -typevariable seltype -filetypes
{{TEXT *.txt}}]
puts $seltype
# old behaviour
# Tk/Carbon: TEXT
# Tk/Cocoa: seltype is undefined
# Win: TEXT
# X11: TEXT (*.txt)
Christian
Georgios Petasis
Nov 19, 2012, 4:43:37 AM11/19/12
to
with other threaded apps.
George
Kevin Walzer
Nov 19, 2012, 9:28:36 AM11/19/12
to
On 11/19/12 1:51 AM, Christian Gollwitzer wrote:
> My command lines were:
> # Tcl
> ./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
> make -j4; make install
>
> # Tk
> ./configure --prefix=/Users/chris/Sources/tcl86
> --with-tcl=/Users/chris/Sources/tcl86/lib/ --enable-64bit --enable-aqua=yes
> make -j4
>
> Using CC=clang also does not help. I'm on OSX 10.8.2 using the newest
> Xcode 4.2.5
8.6b3 builds fine for me on 10.7. Try skipping configure and using these
> My command lines were:
> # Tcl
> ./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
> make -j4; make install
>
> # Tk
> ./configure --prefix=/Users/chris/Sources/tcl86
> --with-tcl=/Users/chris/Sources/tcl86/lib/ --enable-64bit --enable-aqua=yes
> make -j4
>
> Using CC=clang also does not help. I'm on OSX 10.8.2 using the newest
> Xcode 4.2.5
flags:
make -C tcl${ver}/macosx install INSTALL_ROOT="${HOME}/"
make -C tk${ver}/macosx install INSTALL_ROOT="${HOME}/"
Feel free to substitute whatever INSTALL_ROOT you want.
Building this way uses the GNUMakefile in the macosx source tree and
generally has better outcomes than running configure from the Unix subdir.
See http://wiki.tcl.tk/12987 for more guidelines.
Donal K. Fellows
Nov 19, 2012, 9:58:29 AM11/19/12
to
On 18/11/2012 12:54, Googie wrote:
> W dniu piątek, 16 listopada 2012 08:46:45 UTC+1 użytkownik Georgios Petasis napisał:
>> And perhaps look again the threads issue... :-)
>
> I'm not sure if this "issue" is about what I'm thinking it is about.
> What I mean is that I strongly agree that this would be an ideal
> moment to reconsider the multithreading model in Tcl, so developers
> have *possibility* to use many threads on one interpreter, or at
> least an easy way to share some of resources.
And add a Global Interpreter Lock to protect all those resources from
> W dniu piątek, 16 listopada 2012 08:46:45 UTC+1 użytkownik Georgios Petasis napisał:
>> And perhaps look again the threads issue... :-)
>
> I'm not sure if this "issue" is about what I'm thinking it is about.
> What I mean is that I strongly agree that this would be an ideal
> moment to reconsider the multithreading model in Tcl, so developers
> have *possibility* to use many threads on one interpreter, or at
> least an easy way to share some of resources.
concurrent access so that we can get the memory management correct.
Of course, that ruins scalability. There was evidence presented at the
Tcl Conference that 8.5 and 8.6 scale properly as more resources are
provided (and that 8.4 *doesn't*, at least in some cases, despite being
faster for some code in the single-threaded case). By "properly" I mean
that they were indicating that they were scaling very close to the ideal
curve; doubling the number of CPUs was about halving the execution time
for the particular app (something by Mentor? I forget the details right
now). There's a considerable literature that says that that is hard to
achieve.
No, we don't want no GIL. Nor a plethora of locks ("Jefe, what is a
plethora?") where you have the lock ordering problem and I'm not
convinced that we'd be able to conceal that from users either.
> I know, I know... it would be huge amount of work on C level, since
> it wasn't designed like this, but if we're talking about more radical
> changes, well, I believe this is an important one.
shared resources well[*]. We try very hard to avoid sharing resources
between threads precisely because that is so much harder to get yourself
into a nasty mess with. Yes, this means your dirty hacks might not work
so well but it also means that you really have to work very hard to get
yourself into a deadlock or livelock, unlike with so many other languages.
Donal.
[* In any language. The only ones where things are truly easy are the
ones where there are no shared mutable state, and shared non-mutable
state isn't all that easy too unless you are in the case where that bit
of state endures until the process terminates. ]
Don Porter
Nov 19, 2012, 11:09:30 AM11/19/12
to
On 11/19/2012 01:51 AM, Christian Gollwitzer wrote:
> But 8.6b3 fails to compile on Mountain Lion.
That was out in September. When did you plan on telling somebody?
> But 8.6b3 fails to compile on Mountain Lion.
Anyhow, if Kevin Walzer's instruction do not help, please give the
Tcl/Tk 8.6.0rc1 preview releases a try. You can find them at
ftp://ftp.tcl.tk/pub/tcl/tcl8_6/
If you don't get to it right away, you may find 8.6.0rc2 previews there
instead. If so, go ahead and test those instead.
If any Release Candidate fails to build, PLEASE REPORT THAT RIGHT AWAY!
--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Christian Gollwitzer
Nov 19, 2012, 11:57:16 AM11/19/12
to
Am 19.11.12 17:09, schrieb Don Porter:
tried to recompile this morning in order to patch it.
> Anyhow, if Kevin Walzer's instruction do not help, please give the
> Tcl/Tk 8.6.0rc1 preview releases a try. You can find them at
> ftp://ftp.tcl.tk/pub/tcl/tcl8_6/
>
> If you don't get to it right away, you may find 8.6.0rc2 previews there
> instead. If so, go ahead and test those instead.
>
> If any Release Candidate fails to build, PLEASE REPORT THAT RIGHT AWAY!
>
Yes, here is my report: I tried rc1 using configure and it worked. My
command line was:
# Tcl
./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
make -j4
make install
cd ../..
cd tk8.6.0/unix/
./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
--enable-aqua --with-tcl=/Users/chris/Sources/tcl86/lib/
make -j4
make install
Sorry for the confusion and thanks for the good work. Can you post here
when rc2 is uploaded? I'll try that one, too.
Many thanks,
Christian
> On 11/19/2012 01:51 AM, Christian Gollwitzer wrote:
>> But 8.6b3 fails to compile on Mountain Lion.
>
> That was out in September. When did you plan on telling somebody?
Sorry, I'm not usually recompiling Tcl that often, it just failed when I
>> But 8.6b3 fails to compile on Mountain Lion.
>
> That was out in September. When did you plan on telling somebody?
tried to recompile this morning in order to patch it.
> Anyhow, if Kevin Walzer's instruction do not help, please give the
> Tcl/Tk 8.6.0rc1 preview releases a try. You can find them at
> ftp://ftp.tcl.tk/pub/tcl/tcl8_6/
>
> If you don't get to it right away, you may find 8.6.0rc2 previews there
> instead. If so, go ahead and test those instead.
>
> If any Release Candidate fails to build, PLEASE REPORT THAT RIGHT AWAY!
>
command line was:
# Tcl
./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
make -j4
make install
cd tk8.6.0/unix/
./configure --prefix=/Users/chris/Sources/tcl86 --enable-64bit
--enable-aqua --with-tcl=/Users/chris/Sources/tcl86/lib/
make -j4
make install
Sorry for the confusion and thanks for the good work. Can you post here
when rc2 is uploaded? I'll try that one, too.
Many thanks,
Christian
Christian Gollwitzer
Nov 19, 2012, 12:02:45 PM11/19/12
to
Bugs filed:
Am 19.11.12 09:45, schrieb Christian Gollwitzer:
>>> X11: -typevariable returns the wrong thing (works as documented in
>>> Windows
>>> and TkCarbon)
>>
>> Please put the patch as part of your SourceForge bug.
>>
3588460
I'll have a look at 3217462 soon.
Christian
Am 19.11.12 09:45, schrieb Christian Gollwitzer:
> Am 16.11.12 18:07, schrieb Gerald W. Lester:
>>> TkCocoa: -typevariable is not implemented in file dialogs. It worked
>>> under
>>> Carbon, but in Cocoa the UI elements are missing (native applications
>>> like
>>> Pages have it, and it behaves exactly like -typevariable).
3588462
>>> TkCocoa: -typevariable is not implemented in file dialogs. It worked
>>> under
>>> Carbon, but in Cocoa the UI elements are missing (native applications
>>> like
>>> Pages have it, and it behaves exactly like -typevariable).
>>> X11: -typevariable returns the wrong thing (works as documented in
>>> Windows
>>> and TkCarbon)
>>
>> Please put the patch as part of your SourceForge bug.
>>
I'll have a look at 3217462 soon.
Christian
Twylite
Nov 20, 2012, 6:51:12 AM11/20/12
to
Hi,
> > What I mean is that I strongly agree that this would be an ideal
> > moment to reconsider the multithreading model in Tcl, so developers
> > have *possibility* to use many threads on one interpreter, or at
> > least an easy way to share some of resources.
>
> And add a Global Interpreter Lock to protect all those resources from
> concurrent access so that we can get the memory management correct.
Multiple threads per interp is bad. Tcl's multiprocess (rather than multithread) model frees developers from a host of shared resource access problems that plague popular languages.
What I _would_ like to see is a much easier, lightweight way to run code in parallel in a different interp. Something along the lines of transferring a closure to another interp and having it notifying the origin interp on completion.
That of course requires its own brand of magic. But it may be quite easy to accomplish if we distinguish between a proc (which can modify global state) and a function (which cannot), and allow lightweight interp forking to execute functions. I seem to recall that a proc/function distinction will also lend itself to a variety of bytecode compiler enhancements.
> > What I mean is that I strongly agree that this would be an ideal
> > moment to reconsider the multithreading model in Tcl, so developers
> > have *possibility* to use many threads on one interpreter, or at
> > least an easy way to share some of resources.
>
> And add a Global Interpreter Lock to protect all those resources from
> concurrent access so that we can get the memory management correct.
What I _would_ like to see is a much easier, lightweight way to run code in parallel in a different interp. Something along the lines of transferring a closure to another interp and having it notifying the origin interp on completion.
That of course requires its own brand of magic. But it may be quite easy to accomplish if we distinguish between a proc (which can modify global state) and a function (which cannot), and allow lightweight interp forking to execute functions. I seem to recall that a proc/function distinction will also lend itself to a variety of bytecode compiler enhancements.
Georgios Petasis
Nov 20, 2012, 7:56:08 AM11/20/12
to
Right now I have the feeling that it is extremely difficult to embed tcl
in multi-threaded applications, which is a pitty.
The cases where the answer is "place it in a database" when you simply
want to access a Tcl array from multiple threads, or "convert it to a
string" to pass an object among threads, comes too often I think.
George
Uwe Klein
Nov 20, 2012, 8:52:17 AM11/20/12
to
Donal K. Fellows
Nov 20, 2012, 10:55:53 AM11/20/12
to
On 20/11/2012 12:56, Georgios Petasis wrote:
> But sometimes you *need* access to shared resources.
> Right now I have the feeling that it is extremely difficult to embed tcl
> in multi-threaded applications, which is a pitty.
There's a lot of badly-threaded applications out there.
> But sometimes you *need* access to shared resources.
> Right now I have the feeling that it is extremely difficult to embed tcl
> in multi-threaded applications, which is a pitty.
> The cases where the answer is "place it in a database" when you simply
> want to access a Tcl array from multiple threads, or "convert it to a
> string" to pass an object among threads, comes too often I think.
when thread A writes to the array. Without blocking." The level of basic
thread hygiene ignorance you display is not shocking because it is such
a common thing. However, it does require a few corrections.
Modifiable state requires locking to be thread safe. This is enormously
difficult to get right. It is much easier to get right if we restrict
modifications to a single thread. Note that disposal is a modification.
Truly read-only state should be sharable; we could do better with this,
but we need to learn what operations are required here. By "operations"
I mean Tcl_Obj-level functions. There's possibly also a need for some
special cases where we somehow transfer ownership of an entity to
another thread for work while the original thread does other things; the
specific case I'm thinking of here is the Tk_PhotoMaster...
Donal.
Georgios Petasis
Nov 20, 2012, 1:43:57 PM11/20/12
to Donal K. Fellows
Στις 20/11/2012 17:55, ο/η Donal K. Fellows έγραψε:
> On 20/11/2012 12:56, Georgios Petasis wrote:
>> But sometimes you *need* access to shared resources.
>> Right now I have the feeling that it is extremely difficult to embed tcl
>> in multi-threaded applications, which is a pitty.
>
> There's a lot of badly-threaded applications out there.
Yes, but we cannot ignore the world :-)
> On 20/11/2012 12:56, Georgios Petasis wrote:
>> But sometimes you *need* access to shared resources.
>> Right now I have the feeling that it is extremely difficult to embed tcl
>> in multi-threaded applications, which is a pitty.
>
> There's a lot of badly-threaded applications out there.
>
>> The cases where the answer is "place it in a database" when you simply
>> want to access a Tcl array from multiple threads, or "convert it to a
>> string" to pass an object among threads, comes too often I think.
>
> "I want to set a trace on a Tcl array and have callbacks in thread B
> when thread A writes to the array. Without blocking."
Why not?
>> The cases where the answer is "place it in a database" when you simply
>> want to access a Tcl array from multiple threads, or "convert it to a
>> string" to pass an object among threads, comes too often I think.
>
> "I want to set a trace on a Tcl array and have callbacks in thread B
> when thread A writes to the array. Without blocking."
The level of basic
> thread hygiene ignorance you display is not shocking because it is such
> a common thing. However, it does require a few corrections.
>
> Modifiable state requires locking to be thread safe. This is enormously
> difficult to get right. It is much easier to get right if we restrict
> modifications to a single thread. Note that disposal is a modification.
>
> Truly read-only state should be sharable; we could do better with this,
> but we need to learn what operations are required here. By "operations"
> I mean Tcl_Obj-level functions. There's possibly also a need for some
> special cases where we somehow transfer ownership of an entity to
> another thread for work while the original thread does other things; the
> specific case I'm thinking of here is the Tk_PhotoMaster...
>
> Donal.
What I am currently missing is a way to integrate tcl in a threaded
apache web server, for example. And how resources can be shared in such
an environment. And this is just an example...
Regards,
George
Googie
Nov 23, 2012, 8:41:20 AM11/23/12
to
W dniu poniedziałek, 19 listopada 2012 15:58:30 UTC+1 użytkownik Donal K. Fellows napisał:
[...]
If I understand correctly what you wrote (and please correct me if I didn't), you're saying that you doubt at Tcl developers being capable of writing good/stable software with many threads in one interpreter.
Well, that possibility is dangerous, but so is renaming Tcl commands. I might even compare it to an old example - a killer with a knife - should we forbid knifes?
Some time ago I had a chance to teach Tcl to a friend of mine, who is a very talented java developer. After some time he told me that Tcl is a very powerful language, yet very dangerous in irresponsible hands. That was because of command renaming and all consequences of it. Nobody forces developers to use command renaming. It's just there if you need it (and I love Tcl for it).
I want to emphasise again - the model which I'm proposing doesn't prevent from using it as it is currently.
I wonder if there are some known Tcl core design issues that might make it impossible to implement this?
Regards,
Googie
[...]
If I understand correctly what you wrote (and please correct me if I didn't), you're saying that you doubt at Tcl developers being capable of writing good/stable software with many threads in one interpreter.
Well, that possibility is dangerous, but so is renaming Tcl commands. I might even compare it to an old example - a killer with a knife - should we forbid knifes?
Some time ago I had a chance to teach Tcl to a friend of mine, who is a very talented java developer. After some time he told me that Tcl is a very powerful language, yet very dangerous in irresponsible hands. That was because of command renaming and all consequences of it. Nobody forces developers to use command renaming. It's just there if you need it (and I love Tcl for it).
I want to emphasise again - the model which I'm proposing doesn't prevent from using it as it is currently.
I wonder if there are some known Tcl core design issues that might make it impossible to implement this?
Regards,
Googie
Donal K. Fellows
Nov 23, 2012, 9:58:51 AM11/23/12
to
On 23/11/2012 13:41, Googie wrote:
> If I understand correctly what you wrote (and please correct me if I
> didn't), you're saying that you doubt at Tcl developers being capable
> of writing good/stable software with many threads in one
> interpreter.
Yes. Given the patterns of failure experienced by developers of threaded
> If I understand correctly what you wrote (and please correct me if I
> didn't), you're saying that you doubt at Tcl developers being capable
> of writing good/stable software with many threads in one
> interpreter.
code across other languages and applications, I'm of the opinion that
it's exceptionally difficult to write threaded code that has shared
mutable state. I have no reason to believe that Tcl would be
significantly different in that respect.
> Well, that possibility is dangerous, but so is renaming Tcl commands.
> I might even compare it to an old example - a killer with a knife -
> should we forbid knifes?
have to add suitable locking so that the state remains consistent. This
is important with threads on single CPUs, but it is *utterly vital* when
you've got a multi-CPU system due to the way that modern memory systems
work. This means that every program has to pay the costs of all that
lock management all the time. Big Fat Global Locks suck as they really
do not scale.
And that's before we get into the problems of actually writing threaded
programs in the first place. That's well known to be tricky.
The problem isn't that you're carrying a knife around, the problem is
that the knife is mandatory, has a sharpened handle, and weighs a few
tonnes. Really.
> I wonder if there are some known Tcl core design issues that might
> make it impossible to implement this?
it, which enables performance of code that works within a thread to be
very good indeed. Inter-thread communication is done by messaging, a
model that is much easier to reason about and use correctly than the
shared resource model you seem to be advocating.
A lot of developers seem to feel that the problems of multi-threading
can't be that bad. They neglect the point that memory coherence in a
multi-CPU configuration is exceptionally challenging to get right. IIRC,
doing it on ix86 requires prefixing the relevant instructions with the
LOCK prefix — which forces the CPU to do extra work to ensure the
coherence of memory (at substantial performance cost) — and there's no
way to express the necessity of that at the C level; this is the sort of
thing that the lowest levels of the threading library handle for you.
Other architectures have equivalents. Without this sort of thing, you
get mysterious failures that are not reproducible when you run in a
debugger...
Donal (threading is harder than it looks, OK?).
Googie
Nov 25, 2012, 6:49:52 PM11/25/12
to
Firstly, I was hoping I misunderstood you before. It's quiet offensive to put everybody into one sack called "those, who cannot do multithreading development correctly". Of course you can have your opinion on it and I respect that.
Messaging method to communicate is nice, but it's not always sufficient. We all know the old example with Itcl objects.
There's also processing many images in several threads to use the result images in the main thread.
I could throw more examples, although I'm sure you already know a lot of them.
Serializing/deserializing everything to/from messages is 10 times worse, than having slight overhead for synchronization.
I agree that debugging is significantly harder, but it shouldn't be reason to drop it.
Finally, if this model we're talking about is so bad, why is everybody implementing it in almost every modern language?
Regards,
Pawel
Messaging method to communicate is nice, but it's not always sufficient. We all know the old example with Itcl objects.
There's also processing many images in several threads to use the result images in the main thread.
I could throw more examples, although I'm sure you already know a lot of them.
Serializing/deserializing everything to/from messages is 10 times worse, than having slight overhead for synchronization.
I agree that debugging is significantly harder, but it shouldn't be reason to drop it.
Finally, if this model we're talking about is so bad, why is everybody implementing it in almost every modern language?
Regards,
Pawel
pmarin
Nov 26, 2012, 2:08:13 AM11/26/12
to
On Monday, November 26, 2012 12:49:52 AM UTC+1, Googie wrote:
>
> Finally, if this model we're talking about is so bad, why is everybody implementing it in almost every modern language?
>
>
>
> Regards,
>
> Pawel
>
As far I know every modern language is transitioning to a CSP model of concurrency which is what Tcl has right now.
>
> Finally, if this model we're talking about is so bad, why is everybody implementing it in almost every modern language?
>
>
>
> Regards,
>
> Pawel
>
pmarin.
Donal K. Fellows
Nov 26, 2012, 4:32:12 AM11/26/12
to
On 25/11/2012 23:49, Googie wrote:
> Firstly, I was hoping I misunderstood you before. It's quiet
> offensive to put everybody into one sack called "those, who cannot do
> multithreading development correctly". Of course you can have your
> opinion on it and I respect that.
I toned it down from my first draft. :-D
> Firstly, I was hoping I misunderstood you before. It's quiet
> offensive to put everybody into one sack called "those, who cannot do
> multithreading development correctly". Of course you can have your
> opinion on it and I respect that.
> Messaging method to communicate is nice, but it's not always
> sufficient. We all know the old example with Itcl objects.
explicit (but linking to a wiki page that explains it would be fine).
> There's also processing many images in several threads to use the
> result images in the main thread.
special. The issue there is that there's a large block of memory that
needs to be shifted across, and the solution that the memory can be
locked from use in the main thread until the worker finishes its task.
(It also requires that the worker be unable to change the memory block
allocated to the image; it's really important to keep the number of
locks down.)
> Serializing/deserializing everything to/from messages is 10 times
> worse, than having slight overhead for synchronization.
the main cause of the problems that lead to Amdahl's Law and has lead to
some academically-fascinating effects in the past (the problems
associated with the performance of Python's GIL are a case in point,
though they partially arise from what happens when one gets synch subtly
wrong).
We're planning to improve the efficiency of Tcl's messaging; sending
everything through strings is not very good...
> I agree that debugging is significantly harder, but it shouldn't be
> reason to drop it.
more related to the fact that it scales badly.
> Finally, if this model we're talking about is so bad, why is
> everybody implementing it in almost every modern language?
knowing what the trade-offs are. However, when you are dealing with
larger scale parallelism, the *norm* is message passing. (That's how MPI
is defined; it's even in the expansion of the abbreviation “Message
Passing Interface”.) The problem is that the cost of the interconnect
required to make shared-memory parallel processing work is strongly
super-linear in the number of processing units; while there have been
thousand-processor shared-memory supercomputers, they were horribly
expensive and not really all that practical to scale up further, and the
techniques used wouldn't really scale down to ordinary computing either.
By contrast, message passing (and intelligently-selected algorithms that
make use of it) can scale to a few orders of magnitude larger and will
simultaneously work just fine on a desktop. (Arguably, that's how the
internet works: a parallel system with billions of CPUs attached.)
The fact that message passing is easier to program with — the rest of
the world only changes under your feet at controlled points — just makes
it all the sweeter.
Donal.
Bob Techentin
Nov 27, 2012, 6:18:49 PM11/27/12
to
On Monday, November 26, 2012 3:32:12 AM UTC-6, Donal K. Fellows wrote:
> On 25/11/2012 23:49, Googie wrote:
>
> > Firstly, I was hoping I misunderstood you before. It's quiet
> > offensive to put everybody into one sack called "those, who cannot do
> > multithreading development correctly". Of course you can have your
> > opinion on it and I respect that.
>
> I toned it down from my first draft. :-D
>
> > Messaging method to communicate is nice, but it's not always
> > sufficient. We all know the old example with Itcl objects.
>
> Actually, we don't all necessarily know the example in question. Be
> explicit (but linking to a wiki page that explains it would be fine).
I admit to being a fan of the Tcl threading model. Life is much too short to debug transient behaviors. Re-coding computations to scale to a dozen cores is quite nice.
> On 25/11/2012 23:49, Googie wrote:
>
> > Firstly, I was hoping I misunderstood you before. It's quiet
> > offensive to put everybody into one sack called "those, who cannot do
> > multithreading development correctly". Of course you can have your
> > opinion on it and I respect that.
>
> I toned it down from my first draft. :-D
>
> > Messaging method to communicate is nice, but it's not always
> > sufficient. We all know the old example with Itcl objects.
>
> Actually, we don't all necessarily know the example in question. Be
> explicit (but linking to a wiki page that explains it would be fine).
That said, I think that we might collectively benefit from a few more code examples on the wiki, showing how to accomplish different types of tasks in parallel. I'm sure, Googie, that you have some particular applications in mind. And there might well be robust approaches to Tcl-style multithreading that would apply.
Bob
johannes falcone
Nov 27, 2012, 11:13:48 PM11/27/12
to
Donal K. Fellows
Nov 28, 2012, 4:42:22 AM11/28/12
to
On 28/11/2012 04:13, johannes falcone wrote:
> could the epoll kqueue thing that cherokee etc use be a solution to this?
No, not to this, but it might be worth doing anyway. :-)
> could the epoll kqueue thing that cherokee etc use be a solution to this?
Donal.
ped...@west.com
Nov 28, 2012, 5:13:20 PM11/28/12
to
On Thursday, November 15, 2012 12:07:07 PM UTC-6, Donal K. Fellows wrote:
> The Tcl Core Team is pleased to say that development has started on Tcl
>
> 9.0, where we will be trying to take a more radical approach to cleaning
>
> up our code in order to enable improved long-term code health. Our aims
>
> are to minimize the amount of breakage at the Tcl level (unless we've
>
> got a *really good* reason otherwise); the C level will have rather more
>
> changes with an aim to support such things as support for much larger
>
> data and much greater performance.
>
>
>
> We've started a branch in our fossil repository at:
>
>
>
> https://core.tcl.tk/tcl/timeline?r=novem
>
>
>
> Follow along — or help! — but be aware that we've only just started on
> The Tcl Core Team is pleased to say that development has started on Tcl
>
> 9.0, where we will be trying to take a more radical approach to cleaning
>
> up our code in order to enable improved long-term code health. Our aims
>
> are to minimize the amount of breakage at the Tcl level (unless we've
>
> got a *really good* reason otherwise); the C level will have rather more
>
> changes with an aim to support such things as support for much larger
>
> data and much greater performance.
>
>
>
> We've started a branch in our fossil repository at:
>
>
>
> https://core.tcl.tk/tcl/timeline?r=novem
>
>
>
>
> this and there is a fair old way to go.
>
>
>
> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
>
> distant future. We'll be progressing those in parallel; we don't
>
> anticipate the effort for 9.0 from detracting from those in any way.)
>
>
>
> Donal Fellows (for the TCT).
Everyone talks about TK, but the eventloop in TCL needs some updating.
> this and there is a fair old way to go.
>
>
>
> (Also, watch out for coming releases of 8.6.0 and 8.4.20 in the not too
>
> distant future. We'll be progressing those in parallel; we don't
>
> anticipate the effort for 9.0 from detracting from those in any way.)
>
>
>
> Donal Fellows (for the TCT).
Please add EPOLL / Pollset / kqueue support.
Gerald W. Lester
Nov 28, 2012, 5:42:05 PM11/28/12
to
On 11/28/12 4:13 PM, ped...@west.com wrote:
> ...
that it works on MS Windows, OS X as well as the various flavors of *nix.
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
> ...
> Everyone talks about TK, but the eventloop in TCL needs some updating.
>
> Please add EPOLL / Pollset / kqueue support.
Please feel free to submit a patch to add this -- and do remember to ensure
>
> Please add EPOLL / Pollset / kqueue support.
that it works on MS Windows, OS X as well as the various flavors of *nix.
--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+
George Petasis
Nov 29, 2012, 1:15:22 AM11/29/12
to
facilities the thread package offers at the Tcl level) in the core, for
the C level. Most languages do not follow the threading model of Tcl,
which makes a thread pool a necessity in many cases. And currently there
is no way to do this in C, without writing the pool code your self.
George
Donal K. Fellows
Nov 29, 2012, 5:25:40 AM11/29/12
to
On 29/11/2012 06:15, George Petasis wrote:
> I would suggest that we need a thread pool implementation (and many
> facilities the thread package offers at the Tcl level) in the core, for
> the C level. Most languages do not follow the threading model of Tcl,
> which makes a thread pool a necessity in many cases. And currently there
> is no way to do this in C, without writing the pool code your self.
The thread pool code is written in C, and will be distributed with Tcl
> I would suggest that we need a thread pool implementation (and many
> facilities the thread package offers at the Tcl level) in the core, for
> the C level. Most languages do not follow the threading model of Tcl,
> which makes a thread pool a necessity in many cases. And currently there
> is no way to do this in C, without writing the pool code your self.
8.6.0. You will be able to find the code in:
tcl8.6.0/pkgs/thread2.7.0/generic/threadPoolCmd.c
Donal.
Donal K. Fellows
Nov 29, 2012, 5:47:22 AM11/29/12
to
Patches welcome. :-D
More seriously, this would be a single file added, plus some logic to
allow selection of the API to use. (I happen to use a system where the
correct API to use is actually select() because of kernel bugs![*] Don't
assume that it is very simple, but don't worry too much about it; we can
help with the autoconfery.) The other thing about this: this would be
something we could ship with any future version of Tcl. The notifier API
is pretty static and would likely not change at all in the future either.
Donal.
[* This is also why I don't work on this myself; I can't test my changes
so I won't know if what I alter makes sense. ]
More seriously, this would be a single file added, plus some logic to
allow selection of the API to use. (I happen to use a system where the
correct API to use is actually select() because of kernel bugs![*] Don't
assume that it is very simple, but don't worry too much about it; we can
help with the autoconfery.) The other thing about this: this would be
something we could ship with any future version of Tcl. The notifier API
is pretty static and would likely not change at all in the future either.
Donal.
[* This is also why I don't work on this myself; I can't test my changes
so I won't know if what I alter makes sense. ]
0 new messages