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:
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.)
> 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?
> 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
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.)
> 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:
> 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).
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... :-)
> 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
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. :-)
> 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
> 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.
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...
> 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 (both in terms of its library dependency and licensing, which is LGPL).
On Friday, November 16, 2012 2:33:33 PM UTC+1, Georgios Petasis wrote:
..., with some
> interesting capabilities, like drawing on a pdf document...
> George
Well, with Peter Spjuth's pdf4tcl package available that would be relatively easy
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.
> 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!
> (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.
> 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!
> (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.
> 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 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?
No, that window/door is closed.
> For the last two, I could possibly provide a patch.
Please put the patch as part of your SourceForge bug.
Joe English wrote:
> Kevin Walzer asked:
>> 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
> 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
It sounds like 9 is a defacto... *gulp*... fork, then.
On Fri, 16 Nov 2012, Georgios Petasis wrote:
> Date: Fri, 16 Nov 2012 09:46:18 +0200
> From: Georgios Petasis <peta...@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:
>> 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).
> 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 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).
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.
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.
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:
[...]
> 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...
> 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:
> [...]
>> 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...
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
> Am 18.11.12 19:13, schrieb Donal K. Fellows:
>> 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:
>> [...]
>>> 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...
> 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
>> 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 see I haven't submitted a bug for that. I'll do it soon. For the records, here is the patch for X11:
> 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.
> 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
It is what you are thinking about. It is not too easy to combine Tcl with other threaded apps.
> 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
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.
The big problem is that it is *difficult* to make programs that use
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. ]
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?
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.por...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
> 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 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.
> 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
>>> X11: -typevariable returns the wrong thing (works as documented in
>>> Windows
>>> and TkCarbon)
>> Please put the patch as part of your SourceForge bug.
> > 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.
