Menu
▾
▴
tcl-mac — Q&A for Tcl on the Macintosh platform
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(20) |
Mar
(29) |
Apr
(10) |
May
(10) |
Jun
(7) |
Jul
(6) |
Aug
(59) |
Sep
(19) |
Oct
(55) |
Nov
(22) |
Dec
(40) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(56) |
Feb
(71) |
Mar
(179) |
Apr
(41) |
May
(26) |
Jun
(52) |
Jul
(62) |
Aug
(19) |
Sep
(87) |
Oct
(188) |
Nov
(95) |
Dec
(30) |
| 2003 |
Jan
(83) |
Feb
(119) |
Mar
(174) |
Apr
(77) |
May
(85) |
Jun
(52) |
Jul
(67) |
Aug
(121) |
Sep
(147) |
Oct
(96) |
Nov
(89) |
Dec
(144) |
| 2004 |
Jan
(92) |
Feb
(172) |
Mar
(205) |
Apr
(201) |
May
(105) |
Jun
(42) |
Jul
(94) |
Aug
(109) |
Sep
(81) |
Oct
(59) |
Nov
(84) |
Dec
(68) |
| 2005 |
Jan
(56) |
Feb
(57) |
Mar
(183) |
Apr
(139) |
May
(131) |
Jun
(178) |
Jul
(62) |
Aug
(42) |
Sep
(95) |
Oct
(47) |
Nov
(73) |
Dec
(47) |
| 2006 |
Jan
(66) |
Feb
(31) |
Mar
(51) |
Apr
(20) |
May
(49) |
Jun
(26) |
Jul
(23) |
Aug
(65) |
Sep
(67) |
Oct
(26) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(18) |
Feb
(43) |
Mar
(43) |
Apr
(16) |
May
(33) |
Jun
(48) |
Jul
(34) |
Aug
(7) |
Sep
(9) |
Oct
(55) |
Nov
(44) |
Dec
(73) |
| 2008 |
Jan
(37) |
Feb
(97) |
Mar
(44) |
Apr
(33) |
May
(79) |
Jun
(11) |
Jul
(66) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(12) |
Dec
(19) |
| 2009 |
Jan
(12) |
Feb
(13) |
Mar
(19) |
Apr
(30) |
May
(59) |
Jun
(22) |
Jul
(11) |
Aug
(59) |
Sep
(82) |
Oct
(25) |
Nov
(51) |
Dec
(27) |
| 2010 |
Jan
(27) |
Feb
(8) |
Mar
(29) |
Apr
(9) |
May
(39) |
Jun
(6) |
Jul
(8) |
Aug
(22) |
Sep
(33) |
Oct
(8) |
Nov
(35) |
Dec
(9) |
| 2011 |
Jan
(62) |
Feb
(19) |
Mar
(31) |
Apr
(19) |
May
(1) |
Jun
(1) |
Jul
(17) |
Aug
(10) |
Sep
(14) |
Oct
(11) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(11) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(7) |
Jul
(22) |
Aug
(22) |
Sep
(30) |
Oct
(23) |
Nov
(19) |
Dec
|
| 2013 |
Jan
(6) |
Feb
(1) |
Mar
(10) |
Apr
(7) |
May
(3) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(9) |
Oct
(14) |
Nov
(9) |
Dec
(5) |
| 2014 |
Jan
(13) |
Feb
(1) |
Mar
(6) |
Apr
(3) |
May
(5) |
Jun
(2) |
Jul
(20) |
Aug
(6) |
Sep
(26) |
Oct
(25) |
Nov
(20) |
Dec
(41) |
| 2015 |
Jan
(9) |
Feb
(35) |
Mar
(9) |
Apr
(28) |
May
(20) |
Jun
(3) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
(3) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(12) |
Jun
(35) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
| 2017 |
Jan
(28) |
Feb
(14) |
Mar
(4) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
(8) |
| 2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(7) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(10) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(4) |
Apr
(21) |
May
(8) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
(10) |
Nov
|
Dec
|
| 2022 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jan N. <jan...@gm...> - 2012-08-09 10:10:46
|
2012/8/9 Jan Nijtmans <jan...@gm...>
> Then, let's look at the
> differences between jn-cocoa-full-merge and
> tk-cocoa-8-5-backport. It's only in 5 files:
> Files ../tk8.5/unix/configure and ./unix/configure differ
> Files ../tk8.5/unix/configure.in and ./unix/configure.in differ
> Files ../tk8.5/unix/Makefile.in and ./unix/Makefile.in differ
> Files ../tk8.5/unix/tcl.m4 and ./unix/tcl.m4 differ
> Files ../tk8.5/xlib/xgc.c and ./xlib/xgc.c differ
>
Had a further look, and it turns out that tcl.m4 in the backport
branch was an older version. Upgraded now and re-generated
the configure script.
xgc.c: All this does is allocate and free some extra space in
XCreateGC/XFreeGC. Tk8.6 already has the same file, it has
the proper #ifdefs, so those changes are OK.
In "configure.in" and "Makefile.in" I only see changes in
Mac-specific stuff, I tried to build the "tk-cocoa-8-5-backport"
on Cygwin and win32, everything looks fine to me.
This means that my reservations about this full merge
are gone now. I think it can be done directly from
the "tk-cocoa-8-5-backport", without problems
for other platforms.
Regards,
Jan Nijtmans
|
|
From: Jan N. <jan...@gm...> - 2012-08-09 08:11:01
|
2012/8/9 Jeff Hobbs <je...@ac...> > Understood. We would do the merge based on the assumption that only > tk/macosx/* should change. Any changes in other directories will be > reviewed with extreme prejudice. > > It can have a review branch as well for others prior to final merge. > Thanks! I already looked at some harmless differences, put them in core-8-5-branch. So, let's do some experiment (see jn-cocoa-full-merge-8.5<http://core.tcl.tk/tk/timeline?r=jn-cocoa-full-merge-8.5&nd&c=2012-08-09%2007:52:45>branch). It is constructed from core-8-5-branch, but all generic/tk*.decls and macosx/* files are simply copied from the tk-cocoa-8-5-backport<http://core.tcl.tk/tk/timeline?r=tk-cocoa-8-5-backport&nd&c=2012-08-09%2007:40:10> branch, and "make genstubs" run. Files removed from tk-cocoa-8-5-backport are removed here as well. The changes in the *.decls files are only in the macosx functions (I verified that!), so harmless for other platforms. Therefore the jn-cocoa-full-merge-8.5<http://core.tcl.tk/tk/timeline?r=jn-cocoa-full-merge-8.5&nd&c=2012-08-09%2007:52:45>branch is guaranteed to build on other platforms (unix/windows/...), no-one will have any objection merging this to core-8-5-branch (and then merge-mark to tk-cocoa-8-5-backport and trunk, because everything is in there already). The cocoa build is probably broken, but who cares because it's not broken in tk-cocoa-8-5-backport. Then, let's look at the differences between jn-cocoa-full-merge and tk-cocoa-8-5-backport. It's only in 5 files: Files ../tk8.5/unix/configure and ./unix/configure differ Files ../tk8.5/unix/configure.in and ./unix/configure.in differ Files ../tk8.5/unix/Makefile.in and ./unix/Makefile.in differ Files ../tk8.5/unix/tcl.m4 and ./unix/tcl.m4 differ Files ../tk8.5/xlib/xgc.c and ./xlib/xgc.c differ So, those are the only differences left need to be considered carefully. I think this is the fasted way to get things done. It is better to do things on core-8-5-branch as much as possible, simply because then we don't have to ask people to look at other branches. Now is a good moment to do that: vacation time with little activity, just after the 8.5.12 release, so plenty of time for testing until 8.5.13. How does that sound? Regards, Jan Nijtmans |
|
From: Jeff H. <je...@ac...> - 2012-08-09 01:06:35
|
Understood. We would do the merge based on the assumption that only tk/macosx/* should change. Any changes in other directories will be reviewed with extreme prejudice. It can have a review branch as well for others prior to final merge. Jeff On 08/08/2012 1:44 PM, Jan Nijtmans wrote: > 2012/8/8 Jeff Hobbs <je...@ac... <mailto:je...@ac...>> > > Is there any concern with having the 'tk-cocoa-8-5-backport' merged into > 'core-8-5-branch'? This will only effect OS X. Both Apple and > ActiveState build from the Cocoa port, and aside from some tricky edge > cases with event handling, it has been considered the better variant for > years now. > > > I would be carefull with that. Comparing the core-8-5-branch with > the "tk-cocoa-8-5-backport" branch there are some things I note: > > - In core-8-5-branch, all RCS ID's were removed, in tk-cocoa-8-5-backport > they are all back (e.g. in tk.decls, tkInt.decls, ) > Differences like (macosx/README) : > - (making relinking unnecessary was added in 8.4.2) > + (making relinking unnecessary was added with 8.4.2) > or (unix/tcl.m4) > - AC_MSG_ERROR([Can't find Tcl configuration definitions. Use > --with-tcl to specify a directory containing tclConfig.sh]) > + AC_MSG_WARN([Can't find Tcl configuration definitions]) > + exit 0 > or (unix/configure.in <http://configure.in>): > - AC_CHECK_TOOL(AR, ar) > +dnl FIXME: Replace AC_CHECK_PROG with AC_CHECK_TOOL once cross > compiling is fixed. > +dnl AC_CHECK_TOOL(AR, ar) > + AC_CHECK_PROG(AR, ar, ar) > + AS_IF([test "${AR}" = ""], [ > + AC_MSG_ERROR([Required archive tool 'ar' not found on PATH.]) > + ]) > > Those show that some fixes done in core-8-5-branch > were not done in tk-cocoa-8-5-backport'. What more > would we lose? I guess that the backport branch > was maintained separate for a while (CVS branch?) > and some files where simply copied over.... > > So, please be carefull with that. > > Regards, > Jan Nijtmans |
|
From: Jan N. <jan...@gm...> - 2012-08-08 20:44:53
|
2012/8/8 Jeff Hobbs <je...@ac...>
> Is there any concern with having the 'tk-cocoa-8-5-backport' merged into
> 'core-8-5-branch'? This will only effect OS X. Both Apple and
> ActiveState build from the Cocoa port, and aside from some tricky edge
> cases with event handling, it has been considered the better variant for
> years now.
>
I would be carefull with that. Comparing the core-8-5-branch with
the "tk-cocoa-8-5-backport" branch there are some things I note:
- In core-8-5-branch, all RCS ID's were removed, in tk-cocoa-8-5-backport
they are all back (e.g. in tk.decls, tkInt.decls, )
Differences like (macosx/README) :
- (making relinking unnecessary was added in 8.4.2)
+ (making relinking unnecessary was added with 8.4.2)
or (unix/tcl.m4)
- AC_MSG_ERROR([Can't find Tcl configuration definitions. Use
--with-tcl to specify a directory containing tclConfig.sh])
+ AC_MSG_WARN([Can't find Tcl configuration definitions])
+ exit 0
or (unix/configure.in):
- AC_CHECK_TOOL(AR, ar)
+dnl FIXME: Replace AC_CHECK_PROG with AC_CHECK_TOOL once cross compiling
is fixed.
+dnl AC_CHECK_TOOL(AR, ar)
+ AC_CHECK_PROG(AR, ar, ar)
+ AS_IF([test "${AR}" = ""], [
+ AC_MSG_ERROR([Required archive tool 'ar' not found on PATH.])
+ ])
Those show that some fixes done in core-8-5-branch
were not done in tk-cocoa-8-5-backport'. What more
would we lose? I guess that the backport branch
was maintained separate for a while (CVS branch?)
and some files where simply copied over....
So, please be carefull with that.
Regards,
Jan Nijtmans
|
|
From: Jeff H. <je...@ac...> - 2012-08-07 22:02:23
|
Is there any concern with having the 'tk-cocoa-8-5-backport' merged into 'core-8-5-branch'? This will only effect OS X. Both Apple and ActiveState build from the Cocoa port, and aside from some tricky edge cases with event handling, it has been considered the better variant for years now. The reason it exists is that 8.5 started (long ago) with a full Carbon OS X interface. Daniel Steffen worked to get QD out, then on the full Cocoa port. You can't build Carbon 64-bit (thanks Apple), and it is generally deprecated in OS X. 8.5 has lived a long life, and it would seem that maintaining the Carbon interface has been outlived. Jeff On 07/08/2012 2:53 PM, Kevin Walzer wrote: ... > Jeff, I have no objection to migrating the Cocoa backport to the 8.5 > main branch--it would make my life, and I'm sure Andreas's, a lot > simpler. The backport is fragile and maintaining it separately is a pain > in the rear, especially since no one uses the Carbon branch anymore and > I hear a lot of complaints about how hard it is to find the Cocoa branch > in 8.5. > > I'm not sure I'm the person to do the merge, but I'll help in any way I > can. Other thoughts are appreciated. |
|
From: Ned D. <na...@ac...> - 2012-08-07 21:59:02
|
In article <502...@co...>, Kevin Walzer <kw...@co...> wrote: > On 8/7/12 5:28 PM, Adrian Robert wrote: > > Here is a simple-minded patch that fixes it for me, and I can see no ill > > effects in an application running it. However, I have no understanding of > > the context of what this code is doing, what harm it might do, or what > > change happened in the first place to start causing this though. > > That did the trick--thanks, Adrian. Fix committed on trunk and Tk-Cocoa > backport. And Neil, thanks for reporting the bug. Feel free to close the > bug at the Python tracker. Thanks for the quick response everyone. I'll look forward to an updated ActiveTcl so I can close the Python issue. While you all were working on it, I opened an official Tk issue to track the problem: https://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&a tid=112997 -- Ned Deily, na...@ac... |
|
From: Kevin W. <kw...@co...> - 2012-08-07 21:53:46
|
On 8/7/12 5:28 PM, Adrian Robert wrote: > Here is a simple-minded patch that fixes it for me, and I can see no ill effects in an application running it. However, I have no understanding of the context of what this code is doing, what harm it might do, or what change happened in the first place to start causing this though. That did the trick--thanks, Adrian. Fix committed on trunk and Tk-Cocoa backport. And Neil, thanks for reporting the bug. Feel free to close the bug at the Python tracker. Jeff, I have no objection to migrating the Cocoa backport to the 8.5 main branch--it would make my life, and I'm sure Andreas's, a lot simpler. The backport is fragile and maintaining it separately is a pain in the rear, especially since no one uses the Carbon branch anymore and I hear a lot of complaints about how hard it is to find the Cocoa branch in 8.5. I'm not sure I'm the person to do the merge, but I'll help in any way I can. Other thoughts are appreciated. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Kevin W. <kw...@co...> - 2012-08-07 21:36:33
|
On 8/7/12 5:28 PM, Adrian Robert wrote:
> Here is a simple-minded patch that fixes it for me, and I can see no ill effects in an application running it. However, I have no understanding of the context of what this code is doing, what harm it might do, or what change happened in the first place to start causing this though.
>
>
> --- tkMacOSXEmbed.c
> +++ tkMacOSXEmbed.c
> @@ -155,11 +155,11 @@
> */
>
> macWin->xOff = 0;
> macWin->yOff = 0;
> macWin->toplevel = macWin;
> - } else {
> + } else if (winPtr->parentPtr) {
> macWin->xOff = winPtr->parentPtr->privatePtr->xOff +
> winPtr->parentPtr->changes.border_width +
> winPtr->changes.x;
> macWin->yOff = winPtr->parentPtr->privatePtr->yOff +
> winPtr->parentPtr->changes.border_width +
>
Thanks, I will check this out immediately.
For what it's worth, the crash also happens on trunk under OS X.
I have no idea where this bug came from; I've never touched this file.
--K
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
|
|
From: Adrian R. <adr...@gm...> - 2012-08-07 21:28:28
|
Here is a simple-minded patch that fixes it for me, and I can see no ill effects in an application running it. However, I have no understanding of the context of what this code is doing, what harm it might do, or what change happened in the first place to start causing this though.
--- tkMacOSXEmbed.c
+++ tkMacOSXEmbed.c
@@ -155,11 +155,11 @@
*/
macWin->xOff = 0;
macWin->yOff = 0;
macWin->toplevel = macWin;
- } else {
+ } else if (winPtr->parentPtr) {
macWin->xOff = winPtr->parentPtr->privatePtr->xOff +
winPtr->parentPtr->changes.border_width +
winPtr->changes.x;
macWin->yOff = winPtr->parentPtr->privatePtr->yOff +
winPtr->parentPtr->changes.border_width +
On 2012/08/07, at 16:13, Jeff Hobbs wrote:
> To be clear, this happens in regular Tcl/Tk 8.5.12 as well, but on the cocoa-backport branch. The main Tk core-8-5-branch no longer compiles actually (perhaps it's time to call that dead and just merge cocoa in as the main branch for Tk even in 8.5?).
>
> You can track this branch at:
> https://core.tcl.tk/tk/timeline?r=tk-cocoa-8-5-backport
>
> Jeff
>
> On 07/08/2012 1:05 PM, Adrian Robert wrote:
>> Here's a full stack trace, if it will help anyone. Note, I was trying to find out which changes might have caused this, but the ChangeLogs in tk don't look like they have all updates. Nor do either tcl or tk ChangeLog call out when releases are made (with an entry like "tagged 8.5.12 release" or what have you), at least since 8.5.1. Am I looking in the wrong place? What's the best / supported way to see what changes went in between two given releases?
>>
>> thanks,
>> Adrian
>>
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000178
>> 0x00000001001211b5 in TkpMakeWindow (winPtr=0x10110d410, parent=10) at tk-fossil/unix/../macosx/tkMacOSXEmbed.c:161
>> 161 macWin->xOff = winPtr->parentPtr->privatePtr->xOff +
>> (gdb) bt
>> #0 0x00000001001211b5 in TkpMakeWindow (winPtr=0x10110d410, parent=10) at tk-fossil/unix/../macosx/tkMacOSXEmbed.c:161
>> #1 0x0000000100050ab9 in Tk_MakeWindowExist (tkwin=0x10110d410) at tk-fossil/unix/../generic/tkWindow.c:1728
>> #2 0x0000000100019b57 in TkClipInit (interp=0x10107e610, dispPtr=0x1010faa10) at tk-fossil/unix/../generic/tkClipboard.c:653
>> #3 0x0000000100018c7c in Tk_ClipboardClear (interp=0x10107e610, tkwin=0x102052e10) at tk-fossil/unix/../generic/tkClipboard.c:253
>> #4 0x00000001000196df in Tk_ClipboardObjCmd (clientData=0x1010bfe10, interp=0x10107e610, objc=4, objv=0x101082b90) at tk-fossil/unix/../generic/tkClipboard.c:541
>> #5 0x00000001002485db in TclNREvalObjv (interp=0x10107e610, objc=4, objv=0x101082b90, flags=2097152, cmdPtr=0x101106010) at tcl-fossil/generic/tclBasic.c:4320
>> #6 0x00000001002e1539 in TEBCresume (data=0x101111638, interp=0x10107e610, result=0) at tcl-fossil/generic/tclExecute.c:2791
>> #7 0x0000000100248764 in TclNRRunCallbacks (interp=0x10107e610, result=0, rootPtr=0x0) at tcl-fossil/generic/tclBasic.c:4362
>> #8 0x0000000100247b43 in Tcl_EvalObjv (interp=0x10107e610, objc=2, objv=0x1010828f0, flags=2097152) at tcl-fossil/generic/tclBasic.c:4154
>> #9 0x000000010024a537 in TclEvalEx (interp=0x10107e610, script=0x7fff5fbfdd60 "\n tk_textCopy .t\n", numBytes=20, flags=131072, line=2, clNextOuter=0x0, outerScript=0x7fff5fbfdd60 "\n tk_textCopy .t\n") at tcl-fossil/generic/tclBasic.c:5260
>> #10 0x00000001002499a2 in Tcl_EvalEx (interp=0x10107e610, script=0x7fff5fbfdd60 "\n tk_textCopy .t\n", numBytes=20, flags=131072) at tcl-fossil/generic/tclBasic.c:4918
>> #11 0x0000000100010b74 in Tk_BindEvent (bindPtr=0x101108a10, eventPtr=0x1021d1120, tkwin=0x102052e10, numObjects=0, objectPtr=0x7fff5fbfde70) at tk-fossil/unix/../generic/tkBind.c:1493
>> #12 0x000000010001a25c in TkBindEventProc (winPtr=0x102052e10, eventPtr=0x1021d1120) at tk-fossil/unix/../generic/tkCmds.c:316
>> #13 0x0000000100025d33 in Tk_HandleEvent (eventPtr=0x1021d1120) at tk-fossil/unix/../generic/tkEvent.c:1363
>> #14 0x0000000100026404 in WindowEventProc (evPtr=0x1021d1110, flags=-3) at tk-fossil/unix/../generic/tkEvent.c:1753
>> #15 0x00000001003304cc in Tcl_ServiceEvent (flags=-3) at tcl-fossil/generic/tclNotify.c:670
>> #16 0x0000000100330a91 in Tcl_ServiceAll () at tcl-fossil/generic/tclNotify.c:1098
>> #17 0x00000001003a4679 in UpdateWaitingListAndServiceEvents (observer=0x200011ba0, activity=32, info=0x101071010) at tcl-fossil/macosx/tclMacOSXNotify.c:1415
>> #18 0x00007fff876c8b07 in __CFRunLoopDoObservers ()
>> #19 0x00007fff876a460f in __CFRunLoopRun ()
>> #20 0x00007fff876a3d8f in CFRunLoopRunSpecific ()
>> #21 0x00007fff84f9d8dd in _NSUnhighlightCarbonMenu ()
>> #22 0x00007fff850ccfdc in -[NSCarbonMenuImpl performMenuAction:withTarget:] ()
>> #23 0x00007fff84f8014a in -[NSMenu _performKeyEquivalentWithDelegate:] ()
>> #24 0x00007fff84f8021f in -[NSMenu _performKeyEquivalentWithDelegate:] ()
>> #25 0x00007fff84f7fd84 in -[NSMenu performKeyEquivalent:] ()
>> #26 0x00007fff84f7ebed in -[NSApplication _handleKeyEquivalent:] ()
>> #27 0x00007fff84e4f6b9 in -[NSApplication sendEvent:] ()
>> #28 0x000000010013223a in -[TKApplication(TKNotify) sendEvent:] (self=0x20033f220, _cmd=0x7fff855182c0, theEvent=0x20009cb00) at tk-fossil/unix/../macosx/tkMacOSXNotify.c:83
>> #29 0x0000000100132818 in TkMacOSXEventsCheckProc (clientData=0x20033c120, flags=-3) at tk-fossil/unix/../macosx/tkMacOSXNotify.c:305
>> #30 0x00000001003308f9 in Tcl_DoOneEvent (flags=-3) at tcl-fossil/generic/tclNotify.c:968
>> #31 0x0000000100026a20 in Tk_MainLoop () at tk-fossil/unix/../generic/tkEvent.c:2131
>> #32 0x000000010003ae60 in Tk_MainEx (argc=-1, argv=0x7fff5fbff710, appInitProc=0x1000054a1 <Tcl_AppInit>, interp=0x10107e610) at tk-fossil/unix/../generic/tkMain.c:378
>> #33 0x000000010000549a in main (argc=1, argv=0x7fff5fbff708) at tk-fossil/unix/../unix/tkAppInit.c:74
>>
>>
>>
>>
>> On 2012/08/07, at 15:55, Jeff Hobbs wrote:
>>
>>> I can confirm that this exists and is a regression.
>>>
>>> On 07/08/2012 12:27 PM, Ned Deily wrote:
>>>> There appears to be a major regression with the newly released ActiveTcl
>>>> 8.5.12. It appears that it crashes simply by selecting some text in a
>>>> text widget then selecting the Copy command, using Cmd-C in wish or, in
>>>> Python's IDLE, using Cmd-C or selecting Copy with the mouse. That's a
>>>> major hurt especially for OS X 10.6 users with its totally broken system
>>>> Tcl/Tk 8.5 if they don't have access to an older version of ActiveTcl
>>>> 8.5.
>>>>
>>>> http://bugs.python.org/issue15574
|
|
From: Jeff H. <je...@ac...> - 2012-08-07 20:14:21
|
To be clear, this happens in regular Tcl/Tk 8.5.12 as well, but on the cocoa-backport branch. The main Tk core-8-5-branch no longer compiles actually (perhaps it's time to call that dead and just merge cocoa in as the main branch for Tk even in 8.5?). You can track this branch at: https://core.tcl.tk/tk/timeline?r=tk-cocoa-8-5-backport Jeff On 07/08/2012 1:05 PM, Adrian Robert wrote: > Here's a full stack trace, if it will help anyone. Note, I was trying to find out which changes might have caused this, but the ChangeLogs in tk don't look like they have all updates. Nor do either tcl or tk ChangeLog call out when releases are made (with an entry like "tagged 8.5.12 release" or what have you), at least since 8.5.1. Am I looking in the wrong place? What's the best / supported way to see what changes went in between two given releases? > > thanks, > Adrian > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000178 > 0x00000001001211b5 in TkpMakeWindow (winPtr=0x10110d410, parent=10) at tk-fossil/unix/../macosx/tkMacOSXEmbed.c:161 > 161 macWin->xOff = winPtr->parentPtr->privatePtr->xOff + > (gdb) bt > #0 0x00000001001211b5 in TkpMakeWindow (winPtr=0x10110d410, parent=10) at tk-fossil/unix/../macosx/tkMacOSXEmbed.c:161 > #1 0x0000000100050ab9 in Tk_MakeWindowExist (tkwin=0x10110d410) at tk-fossil/unix/../generic/tkWindow.c:1728 > #2 0x0000000100019b57 in TkClipInit (interp=0x10107e610, dispPtr=0x1010faa10) at tk-fossil/unix/../generic/tkClipboard.c:653 > #3 0x0000000100018c7c in Tk_ClipboardClear (interp=0x10107e610, tkwin=0x102052e10) at tk-fossil/unix/../generic/tkClipboard.c:253 > #4 0x00000001000196df in Tk_ClipboardObjCmd (clientData=0x1010bfe10, interp=0x10107e610, objc=4, objv=0x101082b90) at tk-fossil/unix/../generic/tkClipboard.c:541 > #5 0x00000001002485db in TclNREvalObjv (interp=0x10107e610, objc=4, objv=0x101082b90, flags=2097152, cmdPtr=0x101106010) at tcl-fossil/generic/tclBasic.c:4320 > #6 0x00000001002e1539 in TEBCresume (data=0x101111638, interp=0x10107e610, result=0) at tcl-fossil/generic/tclExecute.c:2791 > #7 0x0000000100248764 in TclNRRunCallbacks (interp=0x10107e610, result=0, rootPtr=0x0) at tcl-fossil/generic/tclBasic.c:4362 > #8 0x0000000100247b43 in Tcl_EvalObjv (interp=0x10107e610, objc=2, objv=0x1010828f0, flags=2097152) at tcl-fossil/generic/tclBasic.c:4154 > #9 0x000000010024a537 in TclEvalEx (interp=0x10107e610, script=0x7fff5fbfdd60 "\n tk_textCopy .t\n", numBytes=20, flags=131072, line=2, clNextOuter=0x0, outerScript=0x7fff5fbfdd60 "\n tk_textCopy .t\n") at tcl-fossil/generic/tclBasic.c:5260 > #10 0x00000001002499a2 in Tcl_EvalEx (interp=0x10107e610, script=0x7fff5fbfdd60 "\n tk_textCopy .t\n", numBytes=20, flags=131072) at tcl-fossil/generic/tclBasic.c:4918 > #11 0x0000000100010b74 in Tk_BindEvent (bindPtr=0x101108a10, eventPtr=0x1021d1120, tkwin=0x102052e10, numObjects=0, objectPtr=0x7fff5fbfde70) at tk-fossil/unix/../generic/tkBind.c:1493 > #12 0x000000010001a25c in TkBindEventProc (winPtr=0x102052e10, eventPtr=0x1021d1120) at tk-fossil/unix/../generic/tkCmds.c:316 > #13 0x0000000100025d33 in Tk_HandleEvent (eventPtr=0x1021d1120) at tk-fossil/unix/../generic/tkEvent.c:1363 > #14 0x0000000100026404 in WindowEventProc (evPtr=0x1021d1110, flags=-3) at tk-fossil/unix/../generic/tkEvent.c:1753 > #15 0x00000001003304cc in Tcl_ServiceEvent (flags=-3) at tcl-fossil/generic/tclNotify.c:670 > #16 0x0000000100330a91 in Tcl_ServiceAll () at tcl-fossil/generic/tclNotify.c:1098 > #17 0x00000001003a4679 in UpdateWaitingListAndServiceEvents (observer=0x200011ba0, activity=32, info=0x101071010) at tcl-fossil/macosx/tclMacOSXNotify.c:1415 > #18 0x00007fff876c8b07 in __CFRunLoopDoObservers () > #19 0x00007fff876a460f in __CFRunLoopRun () > #20 0x00007fff876a3d8f in CFRunLoopRunSpecific () > #21 0x00007fff84f9d8dd in _NSUnhighlightCarbonMenu () > #22 0x00007fff850ccfdc in -[NSCarbonMenuImpl performMenuAction:withTarget:] () > #23 0x00007fff84f8014a in -[NSMenu _performKeyEquivalentWithDelegate:] () > #24 0x00007fff84f8021f in -[NSMenu _performKeyEquivalentWithDelegate:] () > #25 0x00007fff84f7fd84 in -[NSMenu performKeyEquivalent:] () > #26 0x00007fff84f7ebed in -[NSApplication _handleKeyEquivalent:] () > #27 0x00007fff84e4f6b9 in -[NSApplication sendEvent:] () > #28 0x000000010013223a in -[TKApplication(TKNotify) sendEvent:] (self=0x20033f220, _cmd=0x7fff855182c0, theEvent=0x20009cb00) at tk-fossil/unix/../macosx/tkMacOSXNotify.c:83 > #29 0x0000000100132818 in TkMacOSXEventsCheckProc (clientData=0x20033c120, flags=-3) at tk-fossil/unix/../macosx/tkMacOSXNotify.c:305 > #30 0x00000001003308f9 in Tcl_DoOneEvent (flags=-3) at tcl-fossil/generic/tclNotify.c:968 > #31 0x0000000100026a20 in Tk_MainLoop () at tk-fossil/unix/../generic/tkEvent.c:2131 > #32 0x000000010003ae60 in Tk_MainEx (argc=-1, argv=0x7fff5fbff710, appInitProc=0x1000054a1 <Tcl_AppInit>, interp=0x10107e610) at tk-fossil/unix/../generic/tkMain.c:378 > #33 0x000000010000549a in main (argc=1, argv=0x7fff5fbff708) at tk-fossil/unix/../unix/tkAppInit.c:74 > > > > > On 2012/08/07, at 15:55, Jeff Hobbs wrote: > >> I can confirm that this exists and is a regression. >> >> On 07/08/2012 12:27 PM, Ned Deily wrote: >>> There appears to be a major regression with the newly released ActiveTcl >>> 8.5.12. It appears that it crashes simply by selecting some text in a >>> text widget then selecting the Copy command, using Cmd-C in wish or, in >>> Python's IDLE, using Cmd-C or selecting Copy with the mouse. That's a >>> major hurt especially for OS X 10.6 users with its totally broken system >>> Tcl/Tk 8.5 if they don't have access to an older version of ActiveTcl >>> 8.5. >>> >>> http://bugs.python.org/issue15574 |
|
From: Adrian R. <adr...@gm...> - 2012-08-07 20:05:13
|
Here's a full stack trace, if it will help anyone. Note, I was trying to find out which changes might have caused this, but the ChangeLogs in tk don't look like they have all updates. Nor do either tcl or tk ChangeLog call out when releases are made (with an entry like "tagged 8.5.12 release" or what have you), at least since 8.5.1. Am I looking in the wrong place? What's the best / supported way to see what changes went in between two given releases? thanks, Adrian Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000178 0x00000001001211b5 in TkpMakeWindow (winPtr=0x10110d410, parent=10) at tk-fossil/unix/../macosx/tkMacOSXEmbed.c:161 161 macWin->xOff = winPtr->parentPtr->privatePtr->xOff + (gdb) bt #0 0x00000001001211b5 in TkpMakeWindow (winPtr=0x10110d410, parent=10) at tk-fossil/unix/../macosx/tkMacOSXEmbed.c:161 #1 0x0000000100050ab9 in Tk_MakeWindowExist (tkwin=0x10110d410) at tk-fossil/unix/../generic/tkWindow.c:1728 #2 0x0000000100019b57 in TkClipInit (interp=0x10107e610, dispPtr=0x1010faa10) at tk-fossil/unix/../generic/tkClipboard.c:653 #3 0x0000000100018c7c in Tk_ClipboardClear (interp=0x10107e610, tkwin=0x102052e10) at tk-fossil/unix/../generic/tkClipboard.c:253 #4 0x00000001000196df in Tk_ClipboardObjCmd (clientData=0x1010bfe10, interp=0x10107e610, objc=4, objv=0x101082b90) at tk-fossil/unix/../generic/tkClipboard.c:541 #5 0x00000001002485db in TclNREvalObjv (interp=0x10107e610, objc=4, objv=0x101082b90, flags=2097152, cmdPtr=0x101106010) at tcl-fossil/generic/tclBasic.c:4320 #6 0x00000001002e1539 in TEBCresume (data=0x101111638, interp=0x10107e610, result=0) at tcl-fossil/generic/tclExecute.c:2791 #7 0x0000000100248764 in TclNRRunCallbacks (interp=0x10107e610, result=0, rootPtr=0x0) at tcl-fossil/generic/tclBasic.c:4362 #8 0x0000000100247b43 in Tcl_EvalObjv (interp=0x10107e610, objc=2, objv=0x1010828f0, flags=2097152) at tcl-fossil/generic/tclBasic.c:4154 #9 0x000000010024a537 in TclEvalEx (interp=0x10107e610, script=0x7fff5fbfdd60 "\n tk_textCopy .t\n", numBytes=20, flags=131072, line=2, clNextOuter=0x0, outerScript=0x7fff5fbfdd60 "\n tk_textCopy .t\n") at tcl-fossil/generic/tclBasic.c:5260 #10 0x00000001002499a2 in Tcl_EvalEx (interp=0x10107e610, script=0x7fff5fbfdd60 "\n tk_textCopy .t\n", numBytes=20, flags=131072) at tcl-fossil/generic/tclBasic.c:4918 #11 0x0000000100010b74 in Tk_BindEvent (bindPtr=0x101108a10, eventPtr=0x1021d1120, tkwin=0x102052e10, numObjects=0, objectPtr=0x7fff5fbfde70) at tk-fossil/unix/../generic/tkBind.c:1493 #12 0x000000010001a25c in TkBindEventProc (winPtr=0x102052e10, eventPtr=0x1021d1120) at tk-fossil/unix/../generic/tkCmds.c:316 #13 0x0000000100025d33 in Tk_HandleEvent (eventPtr=0x1021d1120) at tk-fossil/unix/../generic/tkEvent.c:1363 #14 0x0000000100026404 in WindowEventProc (evPtr=0x1021d1110, flags=-3) at tk-fossil/unix/../generic/tkEvent.c:1753 #15 0x00000001003304cc in Tcl_ServiceEvent (flags=-3) at tcl-fossil/generic/tclNotify.c:670 #16 0x0000000100330a91 in Tcl_ServiceAll () at tcl-fossil/generic/tclNotify.c:1098 #17 0x00000001003a4679 in UpdateWaitingListAndServiceEvents (observer=0x200011ba0, activity=32, info=0x101071010) at tcl-fossil/macosx/tclMacOSXNotify.c:1415 #18 0x00007fff876c8b07 in __CFRunLoopDoObservers () #19 0x00007fff876a460f in __CFRunLoopRun () #20 0x00007fff876a3d8f in CFRunLoopRunSpecific () #21 0x00007fff84f9d8dd in _NSUnhighlightCarbonMenu () #22 0x00007fff850ccfdc in -[NSCarbonMenuImpl performMenuAction:withTarget:] () #23 0x00007fff84f8014a in -[NSMenu _performKeyEquivalentWithDelegate:] () #24 0x00007fff84f8021f in -[NSMenu _performKeyEquivalentWithDelegate:] () #25 0x00007fff84f7fd84 in -[NSMenu performKeyEquivalent:] () #26 0x00007fff84f7ebed in -[NSApplication _handleKeyEquivalent:] () #27 0x00007fff84e4f6b9 in -[NSApplication sendEvent:] () #28 0x000000010013223a in -[TKApplication(TKNotify) sendEvent:] (self=0x20033f220, _cmd=0x7fff855182c0, theEvent=0x20009cb00) at tk-fossil/unix/../macosx/tkMacOSXNotify.c:83 #29 0x0000000100132818 in TkMacOSXEventsCheckProc (clientData=0x20033c120, flags=-3) at tk-fossil/unix/../macosx/tkMacOSXNotify.c:305 #30 0x00000001003308f9 in Tcl_DoOneEvent (flags=-3) at tcl-fossil/generic/tclNotify.c:968 #31 0x0000000100026a20 in Tk_MainLoop () at tk-fossil/unix/../generic/tkEvent.c:2131 #32 0x000000010003ae60 in Tk_MainEx (argc=-1, argv=0x7fff5fbff710, appInitProc=0x1000054a1 <Tcl_AppInit>, interp=0x10107e610) at tk-fossil/unix/../generic/tkMain.c:378 #33 0x000000010000549a in main (argc=1, argv=0x7fff5fbff708) at tk-fossil/unix/../unix/tkAppInit.c:74 On 2012/08/07, at 15:55, Jeff Hobbs wrote: > I can confirm that this exists and is a regression. > > On 07/08/2012 12:27 PM, Ned Deily wrote: >> There appears to be a major regression with the newly released ActiveTcl >> 8.5.12. It appears that it crashes simply by selecting some text in a >> text widget then selecting the Copy command, using Cmd-C in wish or, in >> Python's IDLE, using Cmd-C or selecting Copy with the mouse. That's a >> major hurt especially for OS X 10.6 users with its totally broken system >> Tcl/Tk 8.5 if they don't have access to an older version of ActiveTcl >> 8.5. >> >> http://bugs.python.org/issue15574 > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Jeff H. <je...@ac...> - 2012-08-07 19:55:45
|
I can confirm that this exists and is a regression. On 07/08/2012 12:27 PM, Ned Deily wrote: > There appears to be a major regression with the newly released ActiveTcl > 8.5.12. It appears that it crashes simply by selecting some text in a > text widget then selecting the Copy command, using Cmd-C in wish or, in > Python's IDLE, using Cmd-C or selecting Copy with the mouse. That's a > major hurt especially for OS X 10.6 users with its totally broken system > Tcl/Tk 8.5 if they don't have access to an older version of ActiveTcl > 8.5. > > http://bugs.python.org/issue15574 |
|
From: Ned D. <na...@ac...> - 2012-08-07 19:27:24
|
There appears to be a major regression with the newly released ActiveTcl 8.5.12. It appears that it crashes simply by selecting some text in a text widget then selecting the Copy command, using Cmd-C in wish or, in Python's IDLE, using Cmd-C or selecting Copy with the mouse. That's a major hurt especially for OS X 10.6 users with its totally broken system Tcl/Tk 8.5 if they don't have access to an older version of ActiveTcl 8.5. http://bugs.python.org/issue15574 -- Ned Deily, na...@ac... |
|
From: Andreas K. <and...@ac...> - 2012-08-07 18:23:49
|
[[
Get your papers, WIPs and posters in.
(We have an exhibition hall with 25 gesture-controlled screens to
show the latter two on).
The deadline for abstracts and proposals is
three weeks away.
]]
[[ Notes:
Colin Walker of F5 is confirmed as our Keynote speaker.
http://www.f5.com
]]
19th Annual Tcl/Tk Conference (Tcl'2012)
http://www.tcl.tk/community/tcl2012/
November 12 - 16, 2012
Sessions:
National Museum of Health and Medicine Chicago
175 W. Washington
Chicago, IL 60602
Rooms:
Holiday Inn Chicago Mart Plaza
350 West Mart Center Drive
Chicago, Illinois, USA
Map:
https://maps.google.com/maps/ms?msid=204739899073144451536.0004c144222a9036c99f6&msa=0&ll=41.885266,-87.633734&spn=0.008443,0.018818
Important Dates:
Abstracts and proposals due August 27, 2012
Notification to authors September 10, 2012
WIP and BOF reservations open August 6, 2012
Author materials due October 29, 2012
Tutorials Start November 12, 2012
Conference starts November 14, 2012
Email Contact: tcl...@go...
Submission of Summaries
Tcl/Tk 2012 will be held in Chicago, Illinois, USA from November 12 -
16, 2012. The program committee is asking for papers and presentation
proposals from anyone using or developing with Tcl/Tk (and
extensions). Past conferences have seen submissions covering a wide
variety of topics including:
* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
directions.
* New areas of exploration for the Tcl/Tk language
Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 27,
2012. Authors of accepted abstracts will have until October 29, 2012
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.
Printed proceedings will be produced as an on-demand book at lulu.com
The authors will have 25 minutes to present their paper at the
conference.
The program committee will review and evaluate papers according to the
following criteria:
* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference
Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.
Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.
Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.
The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.
Other Forms of Participation
The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.
Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 6, 2012. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 2012. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.
Registration Information
More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2012/) and will be published on
various Tcl/Tk-related information channels.
To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.
Conference Committee
Clif Flynt Noumena Corp General Chair, Website Admin
Andreas Kupries ActiveState Software Inc. Program Chair
Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago Site/Facilities Chair
Arjen Markus Deltares
Brian Griffin Mentor Graphics
Donal Fellows University of Manchester
Gerald Lester KnG Consulting, LLC
Jeffrey Hobbs ActiveState Software Inc.
Kevin Kenny GE Global Research Center
Larry Virden
Mike Doyle National Museum of Health & Medicine, Chicago
Ron Fox NSCL/FRIB Michigan State University
Steve Landers Digital Smarties
Contact Information tcl...@go...
Tcl'2012 would like to thank those who are sponsoring the conference:
ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association
|
|
From: James B. <jam...@ma...> - 2012-07-26 02:57:31
|
Well lets not get too far off topic. I think we can agree that: 1) X11 isn't a great solution, I'm an engineer, come from a unix/X11 background and I don't like the experience at all either as a programmer or a user. 2) Tk-Carbon is a dead end. Let's not waste any more time on it. So I think what Kevin meant by "viable" is that the port is basically very solid and is probably the best starting place to get Tk going again on osx. You can use it to make osx apps, just as long as they are about as simple as the Tk widget demo. Other than the thread on the sourceforge bug tracker that Adrian pointed out earlier, does anyone have any more information on topic of the event loop issues? Even previous attempts that didn't work out might have discovered useful information. - James |
|
From: Kevin W. <kw...@co...> - 2012-07-25 22:04:50
|
On 7/25/12 5:20 PM, Steven wrote: > >> It's not perfect, but it provides a viable foundation for Tk going forward, > > Thats a little hard for me to agree with, considering it's serious problems that appear to have no chance of resolution. Well, I guess that's a matter of opinion, but I'm curious what alternative you would offer. X11 may be suitable if you have a technical/Unix-focused audience, but it's a non-starter for maintstream Mac development. Carbon is a dead end. I won't rule out diving back into the event loop issues at some point in the future to see if I can improve them; perhaps Daniel Steffen will have time and the opportunity at some point in the future to do so as well (as an Apple employee, at present he has neither time nor the opportunity). I've also invited anyone else to investigate this and submit patches--I have been very grateful for the patches submitted by Adrian Robert and others on other Tk-Cocoa bugs--but no one has done so. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Steven <ste...@ya...> - 2012-07-25 21:20:42
|
> It's not perfect, but it provides a viable foundation for Tk going forward, Thats a little hard for me to agree with, considering it's serious problems that appear to have no chance of resolution. Steve |
|
From: Kevin W. <kw...@co...> - 2012-07-25 14:09:03
|
On 7/25/12 9:08 AM, Adrian Robert wrote: > Actually, Tk-Carbon is a good alternative at the moment, maybe the best one. Relative to Tk-Cocoa, it lacks a couple of capabilities like input method support, but drawing and event handling is solid. Both 8.5 and 8.6 can be built with it. It's a viable alternative for 8.5, in fact the simplest one--just build from the main release branch. I'm not sure if it's supported in 8.6 anymore, at least in trunk--you may have to specially configure Tk to build with Carbon. There are, however, significant tradeoffs to Carbon-Tk. It doesn't support 64-bit and never will. It's also unmaintained and will never be updated--no one is working on it, including myself. This is too bad, because Carbon is much closer to Tk's design than Cocoa; Carbon-Tk's event loop integration code, for instance, is much shorter. And Daniel Steffen had almost fully modernized Tk-Carbon by 2007 (replacing QuickDraw with CoreGraphics, etc.), so it would have made the transition to 64-bit fairly easily--until Apple pulled the plug. Let's just be glad Apple sponsored the port to Cocoa. It's not perfect, but it provides a viable foundation for Tk going forward, and that's very important. It also has its own advantages, such as integrating with a wider range of OS X API's; I've done all my own extensions to Tk-Cocoa using these Cocoa API's. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Adrian R. <adr...@gm...> - 2012-07-25 13:08:16
|
Actually, Tk-Carbon is a good alternative at the moment, maybe the best one. Relative to Tk-Cocoa, it lacks a couple of capabilities like input method support, but drawing and event handling is solid. Both 8.5 and 8.6 can be built with it. -Adrian On 2012/07/25, at 8:50, Kevin Walzer wrote: > On 7/25/12 3:19 AM, James Burgess wrote: >> My impression is that TkCocoa isn't quite there which is really too bad as running the widget demo would make you think (well I did) that it was a viable replacement for the Mac X11 build. It is tantalizingly close though! I don't mean to tread on anyones toes when I say that, the port is amazing, looks like very high quality code to me and genuinely useful if the app isn't too complex and happens to avoid the event related issues. > > From my perspective, Cocoa-Tk, warts and all, is the only way to go if > you are doing any kind of commercial development on OS X, which is my > use case. There may be specialized instances where the user doesn't mind > an X11 app, but I certainly wouldn't use it for any kind of > commercial-based Mac development, even if its performance is better in > some respects--that's simply a reflection of user expectations. > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Kevin W. <kw...@co...> - 2012-07-25 12:50:41
|
On 7/25/12 3:19 AM, James Burgess wrote: > My impression is that TkCocoa isn't quite there which is really too bad as running the widget demo would make you think (well I did) that it was a viable replacement for the Mac X11 build. It is tantalizingly close though! I don't mean to tread on anyones toes when I say that, the port is amazing, looks like very high quality code to me and genuinely useful if the app isn't too complex and happens to avoid the event related issues. From my perspective, Cocoa-Tk, warts and all, is the only way to go if you are doing any kind of commercial development on OS X, which is my use case. There may be specialized instances where the user doesn't mind an X11 app, but I certainly wouldn't use it for any kind of commercial-based Mac development, even if its performance is better in some respects--that's simply a reflection of user expectations. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: James B. <jam...@ma...> - 2012-07-25 07:19:50
|
Hi Kevin, I think Jeff pretty much summed what I needed to know. I'm a long time user of Tcl and it felt odd I couldn't figure out the build by myself. I'm debugging in Xcode on Lion very nicely now though, thanks to your help. My impression is that TkCocoa isn't quite there which is really too bad as running the widget demo would make you think (well I did) that it was a viable replacement for the Mac X11 build. It is tantalizingly close though! I don't mean to tread on anyones toes when I say that, the port is amazing, looks like very high quality code to me and genuinely useful if the app isn't too complex and happens to avoid the event related issues. Regards, - James On Jul 24, 2012, at 6:43 AM, Kevin Walzer wrote: > James, > > It would be helpful to have a better understanding of what you are > trying to accomplish: then we can help identify the steps you need to > take to get there. > > Thanks, > Kevin > > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Kevin W. <kw...@co...> - 2012-07-24 13:44:03
|
On 7/23/12 11:34 PM, James Burgess wrote: > Thanks Kevin. > > So ActiveState and Apple both don't ship the main branch and it doesn't compile on a latest os. Is there a reason for this other than there is no one to update sourceforge tars or the fossil repo? I can't find anywhere on sourceforge or www.tcl.tk that explains these branches. Did I miss something or is this something that the developers just keep in their heads? > > > - James > James, It would be helpful to have a better understanding of what you are trying to accomplish: then we can help identify the steps you need to take to get there. Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Jeff H. <je...@ac...> - 2012-07-24 04:10:59
|
Hi James, On 2012-07-23, at 8:34 PM, James Burgess wrote: > So ActiveState and Apple both don't ship the main branch and it doesn't compile on a latest os. Is there a reason for this other than there is no one to update sourceforge tars or the fossil repo? I can't find anywhere on sourceforge or www.tcl.tk that explains these branches. Did I miss something or is this something that the developers just keep in their heads? You could call this a quirk of general Tcl development. When 8.5 was started, Carbon was all that anybody used. As Cocoa extended its reach and 8.5 got long in the tooth, it was necessary to make it supported, but core development tries (sometimes too hard) for compatibility on release tracks. Thus 8.5 main branch stuck with Carbon, and 8.6 (as it is still beta) was made Cocoa by default. As there are are only a handful of core folks that focus on the C side of OS X, the knowledge did just rest in our heads. Of course, you found the right venue in which to glean that info. Jeff > On Jul 22, 2012, at 11:02 AM, Kevin Walzer wrote: > >> On 7/22/12 12:58 PM, James Burgess wrote: >>> oh dear, that was a typo - " tcl.h says this is 8.4.9", I meant to say "tcl.h says this is 8.5.9". >>> >>> - James >> >> The main line of Tk 8.5 uses the older Carbon API. 8.6 uses Cocoa, which >> has also been backported to 8.5, is available in source form here: >> >> http://core.tcl.tk/tk/timeline?r=tk-cocoa-8-5-backport >> >> Apple uses an ancestor of this branch in OS X, and ActiveState uses this >> branch in ActiveTcl now as well. >> >> -- >> Kevin Walzer >> Code by Kevin >> http://www.codebykevin.com >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Tcl-mac mailing list >> tc...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-mac > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: James B. <jam...@ma...> - 2012-07-24 03:34:16
|
Thanks Kevin. So ActiveState and Apple both don't ship the main branch and it doesn't compile on a latest os. Is there a reason for this other than there is no one to update sourceforge tars or the fossil repo? I can't find anywhere on sourceforge or www.tcl.tk that explains these branches. Did I miss something or is this something that the developers just keep in their heads? - James On Jul 22, 2012, at 11:02 AM, Kevin Walzer wrote: > On 7/22/12 12:58 PM, James Burgess wrote: >> oh dear, that was a typo - " tcl.h says this is 8.4.9", I meant to say "tcl.h says this is 8.5.9". >> >> - James > > The main line of Tk 8.5 uses the older Carbon API. 8.6 uses Cocoa, which > has also been backported to 8.5, is available in source form here: > > http://core.tcl.tk/tk/timeline?r=tk-cocoa-8-5-backport > > Apple uses an ancestor of this branch in OS X, and ActiveState uses this > branch in ActiveTcl now as well. > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
|
From: Kevin W. <kw...@co...> - 2012-07-22 18:03:02
|
On 7/22/12 12:58 PM, James Burgess wrote: > oh dear, that was a typo - " tcl.h says this is 8.4.9", I meant to say "tcl.h says this is 8.5.9". > > - James The main line of Tk 8.5 uses the older Carbon API. 8.6 uses Cocoa, which has also been backported to 8.5, is available in source form here: http://core.tcl.tk/tk/timeline?r=tk-cocoa-8-5-backport Apple uses an ancestor of this branch in OS X, and ActiveState uses this branch in ActiveTcl now as well. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
9 messages has been excluded from this view by a project administrator.
