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: 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: 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 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 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: 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: 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: 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: 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: 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: 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: Jeff H. <je...@ac...> - 2012-09-10 19:57:39
|
Following up on this, Kevin Walzer was willing to give this a pass for integration. Kevin - note the branch that Jan created below. Andreas can assist with code comparison and build testing. Let us know if you need anything else. See full thread for this at: http://code.activestate.com/lists/tcl-core/11633/ Jeff On 2012-08-09, at 1:10 AM, Jan Nijtmans <jan...@gm...> wrote: > 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 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 > 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 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 |