[Pythonmac-SIG] New release of macholib ?
Hello, I've noticed that the newest release of macholib (1.1) came out in July 2006. Since then fixes have been made on the trunk to fix serious bugs such as the unknown load command 27 problem. (see http://mail.python.org/pipermail/pythonmac-sig/2007-June/019060.html ) This problem has become quite blocking now : with Leopard, even /bin/ ls has the unknown load command 27 bug. Would it be possible to tag a new release of macholib in order to let port systems such as MacPorts integrate it within their distribution ? Thanks :-) ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
Bill Janssen wrote: We discussed this a bit last year, but with no resolution that I remember. I've got a situation where a Python program is preventing logout/shutdown. It's a script that just runs in an endless loop watching what app I'm working with; when it sees one it knows (Preview, MS Word, Safari, etc.) it uses appscript to ask the app what document I'm looking at. It then squirrels that document away in a journal so that I've got a record of what I've been working with. The basic control loop is something like this: while True: ... see what's running, and possibly what document ... time.sleep(1.0) See: http://mail.python.org/pipermail/pythonmac-sig/2008-December/020792.html Two options described there: replace your 'while True' loop with a Carbon/Cocoa event loop, allowing a GUI-based process to handle incoming events, or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). Regards, has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
has hengist.p...@virgin.net wrote: ...or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). Thanks! I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Perhaps it's not the OS upgrading the process, but rather some code in some extension calling TransformProcessType (http://www.cocoadev.com/index.pl?TransformProcessType)? And I still don't see how to fix the logout/shutdown problem. The Apple Cocoa document on this, http://developer.apple.com/documentation/Cocoa/Conceptual/AppArchitecture/Tasks/GracefulAppTermination.html, seems to say In Cocoa, all raw events requiring application termination result in the invocation of the NSApplication delegation method applicationShouldTerminate:. If the delegate does not implement this method, the application is terminated regardless of any unsaved documents. Presumably, my script doesn't implement this method, and thus the application is terminated. How? Is it as simple as installing a SIGTERM handler? Bill Bill Janssen wrote: We discussed this a bit last year, but with no resolution that I remember. I've got a situation where a Python program is preventing logout/shutdown. It's a script that just runs in an endless loop watching what app I'm working with; when it sees one it knows (Preview, MS Word, Safari, etc.) it uses appscript to ask the app what document I'm looking at. It then squirrels that document away in a journal so that I've got a record of what I've been working with. The basic control loop is something like this: while True: ... see what's running, and possibly what document ... time.sleep(1.0) See: http://mail.python.org/pipermail/pythonmac-sig/2008-December/020792.html Two options described there: replace your 'while True' loop with a Carbon/Cocoa event loop, allowing a GUI-based process to handle incoming events, or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). Regards, has ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
Bill Janssen jans...@parc.com wrote: I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Hmmm, but when I do a ps, I see that the system, at least, thinks I'm using Python.app. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
In article 55150.1233433...@parc.com, Bill Janssen jans...@parc.com wrote: has hengist.p...@virgin.net wrote: ...or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Actually, you probably are. This can be a bit confusing unless you carefully trace through the steps in the Mac/Makefile.in, as I have been doing recently. Note that the binary at FW/bin/python2.5 is *not* the actual python interpreter binary. Rather it is the so-called pythonw binary whose only function is to execv to the real python binary which is located at FW/Resources/Python.app/Contents/MacOS/Python and that is inside an app bundle. -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
On 31 Jan 2009, at 20:18, Bill Janssen wrote: has hengist.p...@virgin.net wrote: ...or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). Thanks! I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/ python2.5, That's just a stub that kicks off the real executable at: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ Python.app/Contents/MacOS/Python Perhaps it's not the OS upgrading the process, but rather some code in some extension calling TransformProcessType It's the Carbon Process Manager. (There's no good reason for it to do so, but hey, I didn't write the thing.) And I still don't see how to fix the logout/shutdown problem. The Apple Cocoa document on this, http://developer.apple.com/documentation/Cocoa/Conceptual/AppArchitecture/Tasks/GracefulAppTermination.html , seems to say In Cocoa, all raw events requiring application termination result in the invocation of the NSApplication delegation method applicationShouldTerminate:. If the delegate does not implement this method, the application is terminated regardless of any unsaved documents. Right now this is irrelevant as your process doesn't have an event loop. Regards, has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
Ned Deily n...@acm.org wrote: In article 55150.1233433...@parc.com, Bill Janssen jans...@parc.com wrote: has hengist.p...@virgin.net wrote: ...or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Actually, you probably are. This can be a bit confusing unless you carefully trace through the steps in the Mac/Makefile.in, as I have been doing recently. Note that the binary at FW/bin/python2.5 is *not* the actual python interpreter binary. Rather it is the so-called pythonw binary whose only function is to execv to the real python binary which is located at FW/Resources/Python.app/Contents/MacOS/Python and that is inside an app bundle. Thanks, Ned. Yes, so I see, looking at the sources. The next question is, since the rocket-in-the-dock only happens sometime, is there something I can do to forestall the promotion? And, is the promotion happening because of the OS, or because of code in some extension (appscript, say, or PyObjC). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
