pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Getting a better stack trace with PyObjc possible?

[Ronald O. <ron...@ma...>]

On 27 Dec, 2011, at 22:08, Marc Van Olmen wrote:

> hi,
> 
> I looked around the web and more specific stack overflow: I was hoping if there is something I can do to have a better stack trace from pyobjc/python.

<http://pypi.python.org/pypi/faulthandler/> might be helpful for this. I haven't used it myself yet, but as that module will be part of the stdlib in python 3.3 it should work well.

This module would allow you to write code that saves a python stacktrace when a fatal error occurs, which users could then mail to you.

Ronald

> 
> For example my end users send me this, after a hard crash.
> 
> 0 libobjc.A.dylib 0x99b51c22 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 350
> 1 com.apple.CoreFoundation 0x97b2c515 _CFAutoreleasePoolPop + 53
> 2 com.apple.Foundation 0x96316b87 -[NSAutoreleasePool release] + 131
> 3 com.apple.CoreFoundation 0x97b01749 CFRelease + 169
> 4 _objc.so 0x04019c21 object_dealloc + 257
> 5 org.python.python 0x01c6e2cf subtype_dealloc + 575
> 6 org.python.python 0x01c3a041 frame_dealloc + 385
> 7 org.python.python 0x01ced87c tb_dealloc + 156
> 8 org.python.python 0x01ced88c tb_dealloc + 172
> 9 org.python.python 0x01c52179 PyDict_DelItem + 249
> 10 org.python.python 0x01c52251 PyDict_DelItemString + 49
> 11 org.python.python 0x01cb940a PyEval_EvalFrameEx + 4810
> 12 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 13 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 14 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 15 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 16 org.python.python 0x01cbee9d PyEval_EvalCodeEx + 2109
> 17 org.python.python 0x01c3ba36 function_call + 166
> 18 org.python.python 0x01c0a315 PyObject_Call + 85
> 19 org.python.python 0x01c1c8e6 instancemethod_call + 422
> 20 org.python.python 0x01c0a315 PyObject_Call + 85
> 21 org.python.python 0x01cb717e PyEval_CallObjectWithKeywords + 78
> 22 org.python.python 0x01cf89d6 t_bootstrap + 70
> 23 libsystem_c.dylib 0x957c2ed9 _pthread_start + 335
> 24 libsystem_c.dylib 0x957c66de thread_start + 34
> 
> Would be nice to know which method and object was called at 
> 
> PyEval_EvalFrameEx + 21862
> 
> for example.
> 
> Marc
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Getting a better stack trace with PyObjc possible?

[Marc V. O. <mar...@gm...>]

Thanks to both of you for your thoughtful answers!

I just looked at the source code of:
http://pypi.python.org/pypi/faulthandler/
This looks very interesting, it doesn't seem to have much overhead, I could
easily add this to my shipping app. This could be a very helpful tool.

Thanks again.

marc


On Wed, Dec 28, 2011 at 6:34 AM, Ronald Oussoren <ron...@ma...>wrote:

> You cannot extract the python stack trace from a Apple crash log, but
> could save one yourself using the faulthandler package <
> http://pypi.python.org/pypi/faulthandler/>.
>
> I have a slightly longer message in my mail.app outgoing folder, that will
> get send once I have full Internet connectivity again (this mail is send
> through webmail).
>
> Ronald
>
> On Dec 28, 2011, at 09:09 AM, Ken Thomases <ke...@co...> wrote:
>
> On Dec 27, 2011, at 3:08 PM, Marc Van Olmen wrote:
>
> > I looked around the web and more specific stack overflow: I was hoping
> if there is something I can do to have a better stack trace from
> pyobjc/python.
> >
> > For example my end users send me this, after a hard crash.
> >
> > 0 libobjc.A.dylib 0x99b51c22 (anonymous
> namespace)::AutoreleasePoolPage::pop(void*) + 350
> > 1 com.apple.CoreFoundation 0x97b2c515 _CFAutoreleasePoolPop + 53
> > 2 com.apple.Foundation 0x96316b87 -[NSAutoreleasePool release] + 131
> > 3 com.apple.CoreFoundation 0x97b01749 CFRelease + 169
> > 4 _objc.so 0x04019c21 object_dealloc + 257
> > 5 org.python.python 0x01c6e2cf subtype_dealloc + 575
> > 6 org.python.python 0x01c3a041 frame_dealloc + 385
> > 7 org.python.python 0x01ced87c tb_dealloc + 156
> > 8 org.python.python 0x01ced88c tb_dealloc + 172
> > 9 org.python.python 0x01c52179 PyDict_DelItem + 249
> > 10 org.python.python 0x01c52251 PyDict_DelItemString + 49
> > 11 org.python.python 0x01cb940a PyEval_EvalFrameEx + 4810
> > 12 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> > 13 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> > 14 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> > 15 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> > 16 org.python.python 0x01cbee9d PyEval_EvalCodeEx + 2109
> > 17 org.python.python 0x01c3ba36 function_call + 166
> > 18 org.python.python 0x01c0a315 PyObject_Call + 85
> > 19 org.python.python 0x01c1c8e6 instancemethod_call + 422
> > 20 org.python.python 0x01c0a315 PyObject_Call + 85
> > 21 org.python.python 0x01cb717e PyEval_CallObjectWithKeywords + 78
> > 22 org.python.python 0x01cf89d6 t_bootstrap + 70
> > 23 libsystem_c.dylib 0x957c2ed9 _pthread_start + 335
> > 24 libsystem_c.dylib 0x957c66de thread_start + 34
> >
> >
> > Would be nice to know which method and object was called at
> >
> > PyEval_EvalFrameEx + 21862
> >
> > for example.
>
> I assume you know that "PyEval_EvalFrameEx + 21862" doesn't correspond to
> any particular Python code. Since Python is running as an interpreter, the
> Python code is purely data and doesn't correspond to any machine
> instructions. Therefore, the stack trace doesn't "see" it. It's only seeing
> the Python interpreter's functions.
>
> So, you're asking for the crash reporter to look into the data being used
> by a function, not just translating the function's address to a symbol.
> Certainly, there's no way to coax the crash reporter to do that. Likewise,
> there's no way to deduce the Python code being executed just by analyzing a
> crash report.
>
> Since the crash appears to be due to an over-release, you can try to get
> more information about the specific object using the "zombies" facilities
> of the frameworks. If the issue is reproducible, you can ask your users to
> run your app with certain environment variables set, such as:
>
> CFZombieLevel=19 NSZombieEnabled=YES
> /Applications/YourApp.app/Contents/MacOS/YourApp
>
> (I'm not actually certain that the "CFZombieLevel=19" is desirable. You
> might have them try with and without, if they're willing.)
>
> That should at least cause a better diagnostic message to be printed to
> the console log at the time of the crash. I believe that messaging a zombie
> triggers a SIGTRAP these days instead of raising an exception. The latter
> would have been nice in that it might have been translated into a Python
> exception and provoked Python into dumping a backtrace. Instead, the
> SIGTRAP will just crash your app in a slightly different way than the
> above. However, you may be able to translate the SIGTRAP into a Python
> exception by setting a Python signal handler for SIGTRAP. That would get
> you a better backtrace from zombies.
>
> By the way, you've excerpted a crash report. You may have left out some
> important information about the specific nature of the crash. Also, if you
> haven't already, you should ask your users if anything was written to the
> console log at the same time as the crash.
>
> Good luck,
> Ken
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] Getting a better stack trace with PyObjc possible?

[Ronald O. <ron...@ma...>]

You cannot extract the python stack trace from a Apple crash log, but could save one yourself using the faulthandler package <http://pypi.python.org/pypi/faulthandler/>. 

I have a slightly longer message in my mail.app outgoing folder, that will get send once I have full Internet connectivity again (this mail is send through webmail).

Ronald

On Dec 28, 2011, at 09:09 AM, Ken Thomases <ke...@co...> wrote:

On Dec 27, 2011, at 3:08 PM, Marc Van Olmen wrote:

> I looked around the web and more specific stack overflow: I was hoping if there is something I can do to have a better stack trace from pyobjc/python.
> 
> For example my end users send me this, after a hard crash.
> 
> 0 libobjc.A.dylib 0x99b51c22 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 350
> 1 com.apple.CoreFoundation 0x97b2c515 _CFAutoreleasePoolPop + 53
> 2 com.apple.Foundation 0x96316b87 -[NSAutoreleasePool release] + 131
> 3 com.apple.CoreFoundation 0x97b01749 CFRelease + 169
> 4 _objc.so 0x04019c21 object_dealloc + 257
> 5 org.python.python 0x01c6e2cf subtype_dealloc + 575
> 6 org.python.python 0x01c3a041 frame_dealloc + 385
> 7 org.python.python 0x01ced87c tb_dealloc + 156
> 8 org.python.python 0x01ced88c tb_dealloc + 172
> 9 org.python.python 0x01c52179 PyDict_DelItem + 249
> 10 org.python.python 0x01c52251 PyDict_DelItemString + 49
> 11 org.python.python 0x01cb940a PyEval_EvalFrameEx + 4810
> 12 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 13 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 14 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 15 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 16 org.python.python 0x01cbee9d PyEval_EvalCodeEx + 2109
> 17 org.python.python 0x01c3ba36 function_call + 166
> 18 org.python.python 0x01c0a315 PyObject_Call + 85
> 19 org.python.python 0x01c1c8e6 instancemethod_call + 422
> 20 org.python.python 0x01c0a315 PyObject_Call + 85
> 21 org.python.python 0x01cb717e PyEval_CallObjectWithKeywords + 78
> 22 org.python.python 0x01cf89d6 t_bootstrap + 70
> 23 libsystem_c.dylib 0x957c2ed9 _pthread_start + 335
> 24 libsystem_c.dylib 0x957c66de thread_start + 34
> 
> 
> Would be nice to know which method and object was called at 
> 
> PyEval_EvalFrameEx + 21862
> 
> for example.

I assume you know that "PyEval_EvalFrameEx + 21862" doesn't correspond to any particular Python code. Since Python is running as an interpreter, the Python code is purely data and doesn't correspond to any machine instructions. Therefore, the stack trace doesn't "see" it. It's only seeing the Python interpreter's functions.

So, you're asking for the crash reporter to look into the data being used by a function, not just translating the function's address to a symbol. Certainly, there's no way to coax the crash reporter to do that. Likewise, there's no way to deduce the Python code being executed just by analyzing a crash report.

Since the crash appears to be due to an over-release, you can try to get more information about the specific object using the "zombies" facilities of the frameworks. If the issue is reproducible, you can ask your users to run your app with certain environment variables set, such as:

CFZombieLevel=19 NSZombieEnabled=YES /Applications/YourApp.app/Contents/MacOS/YourApp

(I'm not actually certain that the "CFZombieLevel=19" is desirable. You might have them try with and without, if they're willing.)

That should at least cause a better diagnostic message to be printed to the console log at the time of the crash. I believe that messaging a zombie triggers a SIGTRAP these days instead of raising an exception. The latter would have been nice in that it might have been translated into a Python exception and provoked Python into dumping a backtrace. Instead, the SIGTRAP will just crash your app in a slightly different way than the above. However, you may be able to translate the SIGTRAP into a Python exception by setting a Python signal handler for SIGTRAP. That would get you a better backtrace from zombies.

By the way, you've excerpted a crash report. You may have left out some important information about the specific nature of the crash. Also, if you haven't already, you should ask your users if anything was written to the console log at the same time as the crash.

Good luck,
Ken


------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Pyobjc-dev mailing list
Pyo...@li...
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Getting a better stack trace with PyObjc possible?

[Ken T. <ke...@co...>]

On Dec 27, 2011, at 3:08 PM, Marc Van Olmen wrote:

> I looked around the web and more specific stack overflow: I was hoping if there is something I can do to have a better stack trace from pyobjc/python.
> 
> For example my end users send me this, after a hard crash.
> 
> 0 libobjc.A.dylib 0x99b51c22 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 350
> 1 com.apple.CoreFoundation 0x97b2c515 _CFAutoreleasePoolPop + 53
> 2 com.apple.Foundation 0x96316b87 -[NSAutoreleasePool release] + 131
> 3 com.apple.CoreFoundation 0x97b01749 CFRelease + 169
> 4 _objc.so 0x04019c21 object_dealloc + 257
> 5 org.python.python 0x01c6e2cf subtype_dealloc + 575
> 6 org.python.python 0x01c3a041 frame_dealloc + 385
> 7 org.python.python 0x01ced87c tb_dealloc + 156
> 8 org.python.python 0x01ced88c tb_dealloc + 172
> 9 org.python.python 0x01c52179 PyDict_DelItem + 249
> 10 org.python.python 0x01c52251 PyDict_DelItemString + 49
> 11 org.python.python 0x01cb940a PyEval_EvalFrameEx + 4810
> 12 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 13 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 14 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 15 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
> 16 org.python.python 0x01cbee9d PyEval_EvalCodeEx + 2109
> 17 org.python.python 0x01c3ba36 function_call + 166
> 18 org.python.python 0x01c0a315 PyObject_Call + 85
> 19 org.python.python 0x01c1c8e6 instancemethod_call + 422
> 20 org.python.python 0x01c0a315 PyObject_Call + 85
> 21 org.python.python 0x01cb717e PyEval_CallObjectWithKeywords + 78
> 22 org.python.python 0x01cf89d6 t_bootstrap + 70
> 23 libsystem_c.dylib 0x957c2ed9 _pthread_start + 335
> 24 libsystem_c.dylib 0x957c66de thread_start + 34
> 
> 
> Would be nice to know which method and object was called at 
> 
> PyEval_EvalFrameEx + 21862
> 
> for example.

I assume you know that "PyEval_EvalFrameEx + 21862" doesn't correspond to any particular Python code.  Since Python is running as an interpreter, the Python code is purely data and doesn't correspond to any machine instructions.  Therefore, the stack trace doesn't "see" it.  It's only seeing the Python interpreter's functions.

So, you're asking for the crash reporter to look into the data being used by a function, not just translating the function's address to a symbol.  Certainly, there's no way to coax the crash reporter to do that.  Likewise, there's no way to deduce the Python code being executed just by analyzing a crash report.

Since the crash appears to be due to an over-release, you can try to get more information about the specific object using the "zombies" facilities of the frameworks.  If the issue is reproducible, you can ask your users to run your app with certain environment variables set, such as:

CFZombieLevel=19 NSZombieEnabled=YES /Applications/YourApp.app/Contents/MacOS/YourApp

(I'm not actually certain that the "CFZombieLevel=19" is desirable.  You might have them try with and without, if they're willing.)

That should at least cause a better diagnostic message to be printed to the console log at the time of the crash.  I believe that messaging a zombie triggers a SIGTRAP these days instead of raising an exception.  The latter would have been nice in that it might have been translated into a Python exception and provoked Python into dumping a backtrace.  Instead, the SIGTRAP will just crash your app in a slightly different way than the above.  However, you may be able to translate the SIGTRAP into a Python exception by setting a Python signal handler for SIGTRAP.  That would get you a better backtrace from zombies.

By the way, you've excerpted a crash report.  You may have left out some important information about the specific nature of the crash.  Also, if you haven't already, you should ask your users if anything was written to the console log at the same time as the crash.

Good luck,
Ken

[Pyobjc-dev] Getting a better stack trace with PyObjc possible?

[Marc V. O. <mar...@gm...>]

hi,

I looked around the web and more specific stack overflow: I was hoping if
there is something I can do to have a better stack trace from pyobjc/python.

For example my end users send me this, after a hard crash.

0 libobjc.A.dylib 0x99b51c22 (anonymous
namespace)::AutoreleasePoolPage::pop(void*) + 350
1 com.apple.CoreFoundation 0x97b2c515 _CFAutoreleasePoolPop + 53
2 com.apple.Foundation 0x96316b87 -[NSAutoreleasePool release] + 131
3 com.apple.CoreFoundation 0x97b01749 CFRelease + 169
4 _objc.so 0x04019c21 object_dealloc + 257
5 org.python.python 0x01c6e2cf subtype_dealloc + 575
6 org.python.python 0x01c3a041 frame_dealloc + 385
7 org.python.python 0x01ced87c tb_dealloc + 156
8 org.python.python 0x01ced88c tb_dealloc + 172
9 org.python.python 0x01c52179 PyDict_DelItem + 249
10 org.python.python 0x01c52251 PyDict_DelItemString + 49
11 org.python.python 0x01cb940a PyEval_EvalFrameEx + 4810
12 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
13 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
14 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
15 org.python.python 0x01cbd6a6 PyEval_EvalFrameEx + 21862
16 org.python.python 0x01cbee9d PyEval_EvalCodeEx + 2109
17 org.python.python 0x01c3ba36 function_call + 166
18 org.python.python 0x01c0a315 PyObject_Call + 85
19 org.python.python 0x01c1c8e6 instancemethod_call + 422
20 org.python.python 0x01c0a315 PyObject_Call + 85
21 org.python.python 0x01cb717e PyEval_CallObjectWithKeywords + 78
22 org.python.python 0x01cf89d6 t_bootstrap + 70
23 libsystem_c.dylib 0x957c2ed9 _pthread_start + 335
24 libsystem_c.dylib 0x957c66de thread_start + 34


Would be nice to know which method and object was called at

PyEval_EvalFrameEx + 21862

for example.

Marc

Re: [Pyobjc-dev] PyObjC and multiprocessing module

[Trevor B. <mr...@gm...>]

> Multiprocessing uses fork+exec on windows, because those aren't
> separate system calls there but AFAIK you cannot force the
> multiprocessing library to do the same on Unix platforms.
> 
> Could you file a bug on python's tracker about the problem you ran
> into?  A demo program that only uses the stdlib would be great
> (possibly something using Tkinter), but isn't required.

Sure, I can file a bug with them.  Before I do that, I'd like to try to
figure out a solution.  Here's my problem:

I'm writing a cross-platform PyGTK application.  The main thread does
windowing, and there are two secondary threads: one for USB
communication (PyUSB), and one for text to speech (pyttsx).  Although I
would prefer true multiprocessing, the GIL isn't the end of the world
here, so threading will suffice.

It currently works in Linux and Windows with threading or
multiprocessing, but fails in OS X with both.  The multiprocessing
problem makes sense, it's a limitation of Apple's Foundation and
CPython's implementation.

For threading, I feel like there is probably a way to get it to work,
but I don't fully understand it.  I have traced the pyttsx code a bit,
and found what is happening:

1) When you launch the pyttsx processing loop, it calls
AppHelper.runConsoleEventLoop()
2) The sound plays correctly
3) When the utterance is finished, pyttsx stops its processing loop by
calling AppHelper.stopEventLoop()
4) In PyObjC, stopEventLoop() checks to see if there is a valid
"currentRunLoopStopper()" -- it does not find one, but does find a valid
NSApp(), which causes it to run NSApp()._terminate_() and kill my
application.

Here's another crazy tip: "import gtk" makes pyttsx stop working even in
the main thread.  Just importing it, so its module __init__ must be
doing something.

I don't fully understand NSRunLoops and how to manage them in threads,
nor the interaction between that and Python "threads".

Here's my test code: https://gist.github.com/1447666

Do you have any ideas on what I could try to get this working?

Thanks,

Trevor

Re: [Pyobjc-dev] PyObjC and multiprocessing module

[Ronald O. <ron...@ma...>]

On 7 Dec, 2011, at 23:54, Trevor Bentley wrote:

> I found a bunch of hits for this on Google, but no answers:
> 
> I am working on a Python application that uses the multiprocessing library.  I am trying to spawn a process and perform text-to-speech with pyttsx, but I get the dreaded  __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()  error.

Most of Apple's frameworks beyond the basic Unix tools require that you child proceses immediately call execv() instead of forking of a child and doing work there as multiprocessing does.
> 
> Is there any way to get this working, short of switching back to threads?  I see that the 'correct' way is to fork() and exec(), but I don't see any way to make that compatible with the multiprocessing module's API.

Multiprocessing uses fork+exec on windows, because those aren't separate system calls there but AFAIK you cannot force the multiprocessing library to do the same on Unix platforms.

Could you file a bug on python's tracker about the problem you ran into?  A demo program that only uses the stdlib would be great (possibly something using Tkinter), but isn't required.

Ronald

> 
> Thanks,
> 
> -Trevor
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjC and multiprocessing module

[Aahz <aa...@py...>]

On Wed, Dec 07, 2011, Trevor Bentley wrote:
>
> I found a bunch of hits for this on Google, but no answers:
> 
> I am working on a Python application that uses the multiprocessing library.
>  I am trying to spawn a process and perform text-to-speech with pyttsx, but
> I get the
> dreaded  __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
>  error.
> 
> Is there any way to get this working, short of switching back to threads?
> I see that the 'correct' way is to fork() and exec(), but I don't see any
> way to make that compatible with the multiprocessing module's API.

You could do something other than multiprocessing module to access
another process (socket to me!).  Depends how much a problem the GIL is
for you.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..."  --Siobhan

[Pyobjc-dev] PyObjC and multiprocessing module

[Trevor B. <mr...@gm...>]

I found a bunch of hits for this on Google, but no answers:

I am working on a Python application that uses the multiprocessing library.
 I am trying to spawn a process and perform text-to-speech with pyttsx, but
I get the
dreaded  __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
 error.

Is there any way to get this working, short of switching back to threads?
 I see that the 'correct' way is to fork() and exec(), but I don't see any
way to make that compatible with the multiprocessing module's API.

Thanks,

-Trevor

Re: [Pyobjc-dev] Lion and pyobjc 2.2b3 Decimal compares with NSDecimalNumber compare goes in endless recursive call..

[Marc V. O. <mar...@gm...>]

Aahz

Regarding your suggestion, there is helper function that does that:

Just for those googling for answers:,

I can also add that

from PyObjCTools.Conversion import fromPythonDecimal

Does this conversion for you from Decimal To NSDecimalNumber.

Code is located at:

pyobjc-framework-Cocoa/Lib/PyObjCTools/Conversion.py




On Thu, Dec 1, 2011 at 8:06 AM, Marc Van Olmen <mar...@gm...>wrote:

> hi Aahz,
>
> i got an answer offline that confirmed a bug in Lion:
>
> :>>>   aNSDecimalNumber.compare_(aPythonDecimal)
>>
>> This also causes infinite recusion, this time on the Python side. With
>> some luck it is related to the issue you ran into using bindings.
>
>
> I currently found a workaround  in my code. I haven't tried yours yet.
>
> Thanks for the input!
>
> marc
>
>
> On Tue, Nov 29, 2011 at 9:17 PM, Aahz <aa...@py...> wrote:
>
>> On Tue, Nov 22, 2011, Marc Van Olmen wrote:
>> >
>> > for our project we haven't upgraded to latest version of pyobjc I just
>> > notice we run with 2.2b3 but we have the following bug on Lion Only:
>> >
>> > When bindings try to compare a decimal number that originally came from
>> > Python code. It goes in endless recursive calls...
>>
>> Nobody else has responded, so I'll just suggest that you should
>> explicitly convert between Python Decimal and NSDecimalNumber.
>> --
>> Aahz (aa...@py...)           <*>
>> http://www.pythoncraft.com/
>>
>> "....Normal is what cuts off your sixth finger and your tail..."
>>  --Siobhan
>>
>
>

Re: [Pyobjc-dev] Lion and pyobjc 2.2b3 Decimal compares with NSDecimalNumber compare goes in endless recursive call..

[Marc V. O. <mar...@gm...>]

hi Aahz,

i got an answer offline that confirmed a bug in Lion:

:>>>   aNSDecimalNumber.compare_(aPythonDecimal)
>
> This also causes infinite recusion, this time on the Python side. With
> some luck it is related to the issue you ran into using bindings.


I currently found a workaround  in my code. I haven't tried yours yet.

Thanks for the input!

marc


On Tue, Nov 29, 2011 at 9:17 PM, Aahz <aa...@py...> wrote:

> On Tue, Nov 22, 2011, Marc Van Olmen wrote:
> >
> > for our project we haven't upgraded to latest version of pyobjc I just
> > notice we run with 2.2b3 but we have the following bug on Lion Only:
> >
> > When bindings try to compare a decimal number that originally came from
> > Python code. It goes in endless recursive calls...
>
> Nobody else has responded, so I'll just suggest that you should
> explicitly convert between Python Decimal and NSDecimalNumber.
> --
> Aahz (aa...@py...)           <*>
> http://www.pythoncraft.com/
>
> "....Normal is what cuts off your sixth finger and your tail..."  --Siobhan
>

Re: [Pyobjc-dev] Lion and pyobjc 2.2b3 Decimal compares with NSDecimalNumber compare goes in endless recursive call..

[Aahz <aa...@py...>]

On Tue, Nov 22, 2011, Marc Van Olmen wrote:
> 
> for our project we haven't upgraded to latest version of pyobjc I just
> notice we run with 2.2b3 but we have the following bug on Lion Only:
> 
> When bindings try to compare a decimal number that originally came from
> Python code. It goes in endless recursive calls...

Nobody else has responded, so I'll just suggest that you should
explicitly convert between Python Decimal and NSDecimalNumber.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..."  --Siobhan

Re: [Pyobjc-dev] QuickLook.framework

[Ronald O. <ron...@ma...>]

On 11 Nov, 2011, at 1:52, Lee Treveil wrote:

> Are there going to be any bindings implemented for this framework?

Probably, I don't know when though.

Ronald

[Pyobjc-dev] Lion and pyobjc 2.2b3 Decimal compares with NSDecimalNumber compare goes in endless recursive call..

[Marc V. O. <mar...@gm...>]

hi,

for our project we haven't upgraded to latest version of pyobjc I just
notice we run with 2.2b3 but we have the following bug on Lion Only:

When bindings try to compare a decimal number that originally came from
Python code. It goes in endless recursive calls...

.... (this last few lines are repeated over and over again...

#3515 0x02edf84d in _ffi_call_SYSV at x86-darwin.S:74
#3516 0x02edfc01 in ffi_call
#3517 0x02ef8d79 in PyObjCFFI_Caller
#3518 0x02f1ddbd in objcsel_call
#3519 0x0289f315 in PyObject_Call
#3520 0x02950677 in PyEval_EvalFrameEx
#3521 0x02953e9d in PyEval_EvalCodeEx
#3522 0x028d0a36 in function_call
#3523 0x0289f315 in PyObject_Call
#3524 0x028b18e6 in instancemethod_call
#3525 0x0289f315 in PyObject_Call
#3526 0x0290706b in half_richcompare
#3527 0x0290714b in slot_tp_richcompare
#3528 0x028e8dd7 in try_rich_compare
#3529 0x028eb60e in PyObject_Compare
#3530 0x02f11f14 in -[OC_PythonNumber compare:]
#3531 0x94ea8f68 in -[NSDecimalNumber compare:]
#3532 0x94f0dc7c in -[NSDecimalNumber isEqual:]
#3533 0x02edf84d in _ffi_call_SYSV at x86-darwin.S:74
#3534 0x02edfc01 in ffi_call
#3535 0x02ef8d79 in PyObjCFFI_Caller
#3536 0x02f1ddbd in objcsel_call
#3537 0x0289f315 in PyObject_Call
#3538 0x02950677 in PyEval_EvalFrameEx
#3539 0x02953e9d in PyEval_EvalCodeEx
#3540 0x028d0a36 in function_call
#3541 0x0289f315 in PyObject_Call
#3542 0x028b18e6 in instancemethod_call
#3543 0x0289f315 in PyObject_Call
#3544 0x0290706b in half_richcompare
#3545 0x0290714b in slot_tp_richcompare
#3546 0x028e8dd7 in try_rich_compare
#3547 0x028eb60e in PyObject_Compare
#3548 0x02f11f14 in -[OC_PythonNumber compare:]
#3549 0x94ea8f68 in -[NSDecimalNumber compare:]
#3550 0x94f0dc7c in -[NSDecimalNumber isEqual:]
#3551 0x02edf84d in _ffi_call_SYSV at x86-darwin.S:74
#3552 0x02edfc01 in ffi_call
#3553 0x02ef8d79 in PyObjCFFI_Caller
#3554 0x02f1ddbd in objcsel_call
#3555 0x0289f315 in PyObject_Call
#3556 0x02950677 in PyEval_EvalFrameEx
#3557 0x02953e9d in PyEval_EvalCodeEx
#3558 0x028d0a36 in function_call
#3559 0x0289f315 in PyObject_Call
#3560 0x028b18e6 in instancemethod_call
#3561 0x0289f315 in PyObject_Call
#3562 0x0290706b in half_richcompare
#3563 0x0290714b in slot_tp_richcompare
#3564 0x028e8dd7 in try_rich_compare
#3565 0x028eb60e in PyObject_Compare
#3566 0x02f11f14 in -[OC_PythonNumber compare:]
#3567 0x94ea8f68 in -[NSDecimalNumber compare:]
#3568 0x94f0dc7c in -[NSDecimalNumber isEqual:]
#3569 0x02edf84d in _ffi_call_SYSV at x86-darwin.S:74
#3570 0x02edfc01 in ffi_call
#3571 0x02ef8d79 in PyObjCFFI_Caller
#3572 0x02f1ddbd in objcsel_call
#3573 0x0289f315 in PyObject_Call
#3574 0x02950677 in PyEval_EvalFrameEx
#3575 0x02953e9d in PyEval_EvalCodeEx
#3576 0x028d0a36 in function_call
#3577 0x0289f315 in PyObject_Call
#3578 0x028b18e6 in instancemethod_call
#3579 0x0289f315 in PyObject_Call
#3580 0x0290706b in half_richcompare
#3581 0x0290714b in slot_tp_richcompare
#3582 0x028e8dd7 in try_rich_compare
#3583 0x028eb60e in PyObject_Compare
#3584 0x02f11f14 in -[OC_PythonNumber compare:]
#3585 0x94ea8f68 in -[NSDecimalNumber compare:]
#3586 0x94f0dc7c in -[NSDecimalNumber isEqual:]
#3587 0x98cc98cd in _NSValuesAreEqual
#3588 0x993a6ccb in -[NSValueBinder _validateDisplayValue]
#3589 0x993a5471 in -[NSValueBinder
validateAndCommitValueInEditor:editingIsEnding:errorUserInterfaceHandled:]
#3590 0x993ea198 in -[_NSBindingAdaptor
_validateAndCommitValueInEditor:editingIsEnding:errorUserInterfaceHandled:bindingAdaptor:]
#3591 0x993ea2bf in -[_NSBindingAdaptor
validateAndCommitValueInEditor:editingIsEnding:errorUserInterfaceHandled:]
#3592 0x992f343e in -[NSTextField textShouldEndEditing:]

Was this bug addressed already in subsequently releases?

Thanks

Marc Van Olmen

Re: [Pyobjc-dev] strange problem using NSWorkspace/NSTask to start PyObjC apps

[Ronald O. <ron...@ma...>]

On 22 Nov, 2011, at 16:50, Robert Klep wrote:

> Ronald Oussoren <ron...@ma...> wrote on Tue Nov 22 2011 at 16:44:55:
>> 
>> What happens when you add "os.delenv('PYOBJC_BUNDLE_ADDRESS')" before you try to open the bundle? 
> 
> Great, that solves the problem!

Great to hear that. I've filed a bug in my py2app tracker (<https://bitbucket.org/ronaldoussoren/py2app/issue/33/py2app-should-clean-environment-better>) to ensure that I won't forget fixing this in a future release of py2app.

Ronald
> 
> -- robert
> 

Re: [Pyobjc-dev] strange problem using NSWorkspace/NSTask to start PyObjC apps

[Robert K. <rob...@gm...>]

Ronald Oussoren <ron...@ma...> wrote on Tue Nov 22 2011 at 16:44:55:
> 
> What happens when you add "os.delenv('PYOBJC_BUNDLE_ADDRESS')" before you try to open the bundle? 

Great, that solves the problem!

-- robert

Re: [Pyobjc-dev] strange problem using NSWorkspace/NSTask to start PyObjC apps

[Ronald O. <ron...@ma...>]

On 21 Nov, 2011, at 7:08, Robert Klep wrote:

> Hey all,
> 
> I'm running into a strange problem with PyObjC-based apps.
> 
> The situation: I'm working on a .mailbundle (a plug-in for Apple Mail). From that plug-in, I want to start a PyObjC-based application. No matter what, this fails: the application gets a SIGSEGV (I'll post some more information below).
> 
> I've used pretty much all methods of starting the application (NSWorkspace, NSTask, even executing "open -a APP" from the Python subprocess module), and it keeps failing. Of course, the app works without problems when started manually. Starting the app from a Python-shell using [NSWorkspace launchApplication:] works, too. Just not from within the plug-in.

If I'd have to guess I'd say that py2app doesn't fully reset the environment and some bits of the environment that py2app sets to communicate with the bundle code leaks into application bundle and causes problems there.

What happens when you add "os.delenv('PYOBJC_BUNDLE_ADDRESS')" before you try to open the bundle? 

Ronald

[Pyobjc-dev] strange problem using NSWorkspace/NSTask to start PyObjC apps

[Robert K. <rob...@gm...>]

Hey all,

I'm running into a strange problem with PyObjC-based apps.

The situation: I'm working on a .mailbundle (a plug-in for Apple Mail). From that plug-in, I want to start a PyObjC-based application. No matter what, this fails: the application gets a SIGSEGV (I'll post some more information below).

I've used pretty much all methods of starting the application (NSWorkspace, NSTask, even executing "open -a APP" from the Python subprocess module), and it keeps failing. Of course, the app works without problems when started manually. Starting the app from a Python-shell using [NSWorkspace launchApplication:] works, too. Just not from within the plug-in.

Even the simplest 'app' fails:
-snip-
from Foundation import *

class MyTestClass(NSObject): pass
-snip-

Same thing: SIGSEGV.

Starting other apps (like Safari) isn't a problem, so it doesn't seem to be some sandbox-type blocking.

Below is the relevant part of the crashlog. All I've been able to find out is that objc_msgSend_vtable3 is an Objective-C runtime shortcut for getting 'self'. It smells like a memory issue, but I'd be grateful if anyone could help me out.

-snip-
Process:         App1 [797]
Path:            /Users/USER/*/App1.app/Contents/MacOS/App1
Identifier:      name.klep.app1
Version:         0.0.0 (0.0.0)
Code Type:       X86-64 (Native)
Parent Process:  launchd [301]

Date/Time:       2011-11-21 06:49:06.394 +0100
OS Version:      Mac OS X 10.7.2 (11C74)
Report Version:  9

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fc2dac50c60

VM Regions Near 0x7fc2dac50c60:
    MALLOC_TINY            0000000104e00000-0000000104f00000 [ 1024K] rw-/rwx SM=PRV  
--> 
    STACK GUARD            00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0

Application Specific Information:
objc_msgSend() selector name: self
objc[797]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                 0x00007fff8c84c0cd objc_msgSend_vtable3 + 13
1   _objc.so                        0x0000000101ba5a71 pythonify_c_value + 573
2   _objc.so                        0x0000000101b9d92e 0x101b80000 + 121134
3   org.python.python               0x0000000101a87b58 PyEval_EvalFrameEx + 13318
4   org.python.python               0x0000000101a8acd8 PyEval_EvalCodeEx + 1996
5   org.python.python               0x0000000101a8ae6c PyEval_EvalCode + 341
6   org.python.python               0x0000000101a87e0a PyEval_EvalFrameEx + 14008
7   org.python.python               0x0000000101a8acd8 PyEval_EvalCodeEx + 1996
8   org.python.python               0x0000000101a28abf PyClassMethod_New + 1378
9   org.python.python               0x0000000101a07d32 PyObject_Call + 97
10  org.python.python               0x0000000101a83c40 PyEval_CallObjectWithKeywords + 180
11  _objc.so                        0x0000000101ba0bd3 0x101b80000 + 134099
12  org.python.python               0x0000000101a4cafa PyType_Modified + 891
13  org.python.python               0x0000000101a07d32 PyObject_Call + 97
14  org.python.python               0x0000000101a07eed PyObject_CallFunctionObjArgs + 178
15  org.python.python               0x0000000101a8576b PyEval_EvalFrameEx + 4121
16  org.python.python               0x0000000101a8acd8 PyEval_EvalCodeEx + 1996
17  org.python.python               0x0000000101a8ad4d PyEval_EvalCode + 54
18  org.python.python               0x0000000101aa208f Py_CompileString + 62
19  org.python.python               0x0000000101aa214f PyRun_FileExFlags + 157
20  org.python.python               0x0000000101a801f6 _PyBuiltin_Init + 4630
21  org.python.python               0x0000000101a87d77 PyEval_EvalFrameEx + 13861
22  org.python.python               0x0000000101a8acd8 PyEval_EvalCodeEx + 1996
23  org.python.python               0x0000000101a8ae6c PyEval_EvalCode + 341
24  org.python.python               0x0000000101a87e0a PyEval_EvalFrameEx + 14008
25  org.python.python               0x0000000101a8acd8 PyEval_EvalCodeEx + 1996
26  org.python.python               0x0000000101a8ad4d PyEval_EvalCode + 54
27  org.python.python               0x0000000101aa208f Py_CompileString + 62
28  org.python.python               0x0000000101aa214f PyRun_FileExFlags + 157
29  org.python.python               0x0000000101aa32a2 PyRun_SimpleFileExFlags + 392
30  name.klep.app1                  0x0000000100004476 start + 12854
31  name.klep.app1                  0x0000000100004a96 main + 1465
32  name.klep.app1                  0x0000000100001274 start + 52
-snip-

-- robert

[Pyobjc-dev] What version of Xcode for lion?

[Jair G. <jyr...@gm...>]

Hi,

I just installed and Lion in Snow Leopard xoode pyobjc runs in 4.1,which
version should install Xcode?

Thanks

-- 
SIN ETIQUETAS.[ PUNTO ]
http://flavors.me/jyr
http://pythoncocoa.com
http://opentumblr.com

[Pyobjc-dev] QuickLook.framework

[Lee T. <lee...@gm...>]

Are there going to be any bindings implemented for this framework?

Thanks

Re: [Pyobjc-dev] PyObjC on Lion

[Ronald O. <ron...@ma...>]

On 28 Aug, 2011, at 17:31, Gordon Watson wrote:

> Hi,
> 
> Short version: Does there exsit a working version of PyObcC and AddressBook for Lion?
> 
> Long version: ...
> 
> I have been using the AddressBook 2.3 wrapper with Python 2.6.6, PyObjC v2.3 (all built using MacPorts) on OS X 10.6 Snow Leopard. After upgrading to OS X 10.7.1 Lion, although most of AddressBook seems to continue working, it no longer reads the postal address fields.

That's odd, AFAIK nothing has changed in AddressBook in this respect.
> 
> So, I tried reinstalling a fresh version (using MacPorts): Python 2.7.2, PyObjC v2.3 and AddressBook 2.3
> 
> I have tried Ronald Oussoren's latest work on bitbucket, but I haven't been able to figure out how to install it.

Installing that copy won't help, the wrappers for AddressBook are the same as in 2.3. 

Installing from the repository is too hard at the moment, you need to run "python setup.py install" in a number of subdirectories and in the right order.  Adding an install script is on my list, but that will have to wait until I have updated the metadata for Lion. That in turn is blocked on creating a proper parser for Objective-C, which is progressing slowly because I don't spent enough time on it. 

Ronald

> 
> Thanks so much for any help.
> 
> Gordon
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management 
> Up to 160% more powerful than alternatives and 25% more efficient. 
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] PyObjC on Lion

[Gordon W. <gor...@gm...>]

Hi,

Short version: Does there exsit a working version of PyObcC and AddressBook
for Lion?

Long version: ...

I have been using the AddressBook 2.3 wrapper with Python 2.6.6, PyObjC v2.3
(all built using MacPorts) on OS X 10.6 Snow Leopard. After upgrading to OS
X 10.7.1 Lion, although most of AddressBook seems to continue working, it no
longer reads the postal address fields.

So, I tried reinstalling a fresh version (using MacPorts): Python
2.7.2, PyObjC v2.3 and AddressBook 2.3

I have tried Ronald Oussoren's latest work on bitbucket, but I haven't been
able to figure out how to install it.

Thanks so much for any help.

Gordon

Re: [Pyobjc-dev] selector in pyobjc

[Ronald O. <ron...@ma...>]

On 10 Aug, 2011, at 8:56, Jair Gaxiola wrote:

> Hello,
> 
> Try to translate the following code to PyObjC
> (https://github.com/shpakovski/Popup/blob/master/Popup/MenubarController.m),
> but I have a question about how to translate the line number 20 of the
> selector
> 
> _statusItemView.action = @ selector (togglePanel:);
> 
> Does not work with
> 
> statusItemView.action (selector (togglePanel))

_statusItemView.setAction_(b'togglePanel')


Selectors are byte-strings (the 'b' prefix is only necessary when you use Python 3.x)

Ronald

> 
> Thanks
> 
> -- 
> SIN ETIQUETAS.[ PUNTO ]
> http://flavors.me/jyr
> http://pythoncocoa.com
> http://opentumblr.com
> 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] selector in pyobjc

[Jair G. <jyr...@gm...>]

Hello,

Try to translate the following code to PyObjC
(https://github.com/shpakovski/Popup/blob/master/Popup/MenubarController.m),
but I have a question about how to translate the line number 20 of the
selector

_statusItemView.action = @ selector (togglePanel:);

Does not work with

statusItemView.action (selector (togglePanel))

Thanks

-- 
SIN ETIQUETAS.[ PUNTO ]
http://flavors.me/jyr
http://pythoncocoa.com
http://opentumblr.com

[Pyobjc-dev] [ pyobjc-Bugs-3387767 ] NSLog raises exception on non-ascii text

[SourceForge.net <no...@so...>]

Bugs item #3387767, was opened at 2011-08-07 14:28
Message generated for change (Tracker Item Submitted) made by eaganjr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=3387767&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: James Eagan (eaganjr)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSLog raises exception on non-ascii text

Initial Comment:
It looks like the fix for bug ID 3085651 broke support for non-ascii (e.g., UTF8) strings for NSLog.


[Using the standard system Python in 10.7.0]

Frog:~ $ python
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Foundation import *
>>> NSLog(u'Foo')
2011-08-07 13:22:46.578 Python[9268:1507] Foo
>>> NSLog(u'\xe9')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128)
>>> 


For reference, here’s the same thing using the standard system Python in 10.6.7:

Jagaroth:~ $ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Foundation import *
>>> NSLog(u'Foo')
2011-08-07 13:24:14.206 Python[44733:b07] Foo
>>> NSLog(u'\xe9')
2011-08-07 13:24:27.737 Python[44733:b07] é
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=3387767&group_id=14534