Thread: Re: [Pyobjc-dev] ValueError: Unknown typestr
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Aahz <aa...@py...> - 2010-05-07 00:28:29
|
On Fri, May 07, 2010, Luc Heinrich wrote: > > Maintaining Miro on 10.4, 10.5 and 10.6 has become a real pain lately > and since we are introducing several dependencies which only work on > 10.5 and upward, we are finally ditching 10.4 support. Yay for PyObjC > 2 instead of PyObjC 1.4, yay for Python 2.5 or 2.6 instead of 2.4, > etc. However, producing a PyObjC application which runs on both 10.5 > and 10.6 seems to cause an equal amount of problems, which I frankly > wasn't expecting. You need to use PyObjC 2.2 built on 10.5 IME -- see archives. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan |
|
From: Luc H. <lu...@ho...> - 2010-05-09 22:37:27
|
On 7 mai 2010, at 02:27, Aahz wrote:
> You need to use PyObjC 2.2 built on 10.5 IME -- see archives.
Right. Ok.
So I'm now using a built-from-sources Python 2.6.5, PyObjC 2.2 and py2app 0.4.3, all on OS X 10.5. Building the application and then running it on OS X 10.6 now gives this:
Traceback (most recent call last):
File "/Users/luc/Desktop/Miro.app/Contents/Resources/__boot__.py", line 31, in <module> _run('Miro.py')
File "/Users/luc/Desktop/Miro.app/Contents/Resources/__boot__.py", line 28, in _runexecfile(path, globals(), globals())
File "/Users/luc/Desktop/Miro.app/Contents/Resources/Miro.py", line 42, in <module> import Foundation
File "build/bdist.macosx-10.5-fat/egg/Foundation/__init__.py", line 10, in <module>
File "build/bdist.macosx-10.5-fat/egg/CoreFoundation/__init__.py", line 19, in <module>
File "objc/_bridgesupport.pyo", line 156, in initFrameworkWrapper
File "objc/_bridgesupport.pyo", line 58, in _parseBridgeSupport
ValueError: Don't know CF type for typestr '^{__CFAllocator=}', cannot create special wrapper
I've looked at the list archive and it seems that you had the *exact* same error not so long ago:
<http://sourceforge.net/mailarchive/forum.php?thread_name=20100223010249.GA3923%40panix.com&forum_name=pyobjc-dev>
Did you manage to make it work?
--
Luc Heinrich - lu...@ho...
|
|
From: Luc H. <lu...@ho...> - 2010-05-10 19:46:49
|
On 10 mai 2010, at 00:37, Luc Heinrich wrote:
> Traceback (most recent call last):
> File "/Users/luc/Desktop/Miro.app/Contents/Resources/__boot__.py", line 31, in <module> _run('Miro.py')
> File "/Users/luc/Desktop/Miro.app/Contents/Resources/__boot__.py", line 28, in _runexecfile(path, globals(), globals())
> File "/Users/luc/Desktop/Miro.app/Contents/Resources/Miro.py", line 42, in <module> import Foundation
> File "build/bdist.macosx-10.5-fat/egg/Foundation/__init__.py", line 10, in <module>
> File "build/bdist.macosx-10.5-fat/egg/CoreFoundation/__init__.py", line 19, in <module>
> File "objc/_bridgesupport.pyo", line 156, in initFrameworkWrapper
> File "objc/_bridgesupport.pyo", line 58, in _parseBridgeSupport
> ValueError: Don't know CF type for typestr '^{__CFAllocator=}', cannot create special wrapper
I was able to make it all work.
For the record my problem was, as Aahz said in his detailed report of the issue [1], related to py2app and not PyObjC itself. I did build everything from sources so I was expecting everything to work, but it didn't.
The clue was in the stack trace, where you can see "normal" pathnames, like this one...
> File "/Users/luc/Desktop/Miro.app/Contents/Resources/Miro.py", line 42, in <module> import Foundation
...and weird ones, like the four last ones:
> File "build/bdist.macosx-10.5-fat/egg/Foundation/__init__.py", line 10, in <module>
> File "build/bdist.macosx-10.5-fat/egg/CoreFoundation/__init__.py", line 19, in <module>
> File "objc/_bridgesupport.pyo", line 156, in initFrameworkWrapper
> File "objc/_bridgesupport.pyo", line 58, in _parseBridgeSupport
The reason why it fails miserably is because py2app doesn't seem to know how to deal (or fail to deal correctly) with compressed Python eggs. The solution (at least for me :)) is to force PyObjC and any other library to be installed as non-compressed eggs. I personnally did it by patching all the setup.cfg files with an additional easy_install section, like this:
[easy_install]
zip_ok = 0
[1] http://sourceforge.net/mailarchive/message.php?msg_name=20100304190050.GA17310%40panix.com
--
Luc Heinrich - lu...@ho...
|
|
From: Aahz <aa...@py...> - 2010-05-10 21:05:17
|
On Mon, May 10, 2010, Luc Heinrich wrote: > > The reason why it fails miserably is because py2app doesn't seem to > know how to deal (or fail to deal correctly) with compressed Python > eggs. The solution (at least for me :)) is to force PyObjC and any > other library to be installed as non-compressed eggs. Ah, yes, compressed eggs, the bane of both py2app and py2exe. They both rely on modulefinder, which is the real root of the problem. Thanks for posting an update! -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. |
|
From: Ronald O. <ron...@ma...> - 2010-05-11 07:33:20
Attachments:
smime.p7s
|
On 10 May, 2010, at 23:05, Aahz wrote: > On Mon, May 10, 2010, Luc Heinrich wrote: >> >> The reason why it fails miserably is because py2app doesn't seem to >> know how to deal (or fail to deal correctly) with compressed Python >> eggs. The solution (at least for me :)) is to force PyObjC and any >> other library to be installed as non-compressed eggs. > > Ah, yes, compressed eggs, the bane of both py2app and py2exe. They both > rely on modulefinder, which is the real root of the problem. py2app doesn't use modulefinder but modulegraph, which has simular functionality to modulefinder but is slightly different. Ronald > > Thanks for posting an update! > -- > Aahz (aa...@py...) <*> http://www.pythoncraft.com/ > > f u cn rd ths, u cn gt a gd jb n nx prgrmmng. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
|
From: Ronald O. <ron...@ma...> - 2010-05-11 07:39:00
Attachments:
smime.p7s
|
On 10 May, 2010, at 21:46, Luc Heinrich wrote: > > >> File "build/bdist.macosx-10.5-fat/egg/Foundation/__init__.py", line 10, in <module> >> File "build/bdist.macosx-10.5-fat/egg/CoreFoundation/__init__.py", line 19, in <module> >> File "objc/_bridgesupport.pyo", line 156, in initFrameworkWrapper >> File "objc/_bridgesupport.pyo", line 58, in _parseBridgeSupport > > The reason why it fails miserably is because py2app doesn't seem to know how to deal (or fail to deal correctly) with compressed Python eggs. The solution (at least for me :)) is to force PyObjC and any other library to be installed as non-compressed eggs. I personnally did it by patching all the setup.cfg files with an additional easy_install section, like this: Crap. Py2app is supposed to support zipped eggs. I'll make sure that the next release of pyobjc has 'zip_safe=False' in its setup.py files, after that I want to spend time on cleaning up and fixing py2app. Ronald |
|
From: Ronald O. <ron...@ma...> - 2010-05-11 07:44:30
Attachments:
smime.p7s
|
On 10 May, 2010, at 21:46, Luc Heinrich wrote: > I personnally did it by patching all the setup.cfg files with an additional easy_install section, like this: > > [easy_install] > zip_ok = 0 You can do this globally as well by adding these lines to ".pydistutils.cfg" in your home directory. Ronald |
|
From: Luc H. <lu...@ho...> - 2010-05-11 09:55:14
|
On 11 mai 2010, at 09:44, Ronald Oussoren wrote: > You can do this globally as well by adding these lines to ".pydistutils.cfg" in your home directory. Indeed I can, but since I'm building all my dependencies in a sandbox using a script which will also run on machines other than my own I preferred not to tinker with global user settings too much. But thanks for the tip ;) -- Luc Heinrich - lu...@ho... |
|
From: Aahz <aa...@py...> - 2010-05-14 02:08:06
|
On Tue, May 11, 2010, Ronald Oussoren wrote: > On 10 May, 2010, at 21:46, Luc Heinrich wrote: >> >> I personnally did it by patching all the setup.cfg files with an >> additional easy_install section, like this: >> >> [easy_install] >> zip_ok = 0 > > You can do this globally as well by adding these lines to > ".pydistutils.cfg" in your home directory. Any way to get that effect for regular setup.py usage? I ran into this problem building PyObjC 2.2 from source. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. |
|
From: Scott H. <sco...@gm...> - 2010-05-14 06:41:03
|
I've got this obj-c object in a simple demo program:
@implementation junker
-(id) init
{
[super init];
NSLog(@"initing");
[self action];
return self;
}
-(void) action
{
NSLog(@"junk");
//NSBeep();
}
@end
I call it from Python in my App delegate like this:
from Foundation import *
from AppKit import *
class PyObjCTestAppDelegate(NSObject):
def applicationDidFinishLaunching_(self, sender):
NSLog("Application did finish launching.")
self.a=junker.alloc().init()
def awakeFromNib(self):
NSLog("Awoke from NIB")
@objc.IBAction
def buttonPress_(self, sender):
NSLog("Button pressed!")
self.a.action()
The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange.
Here's the console output:
2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB
2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing
2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching.
2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing
2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk
2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed
2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk
Program received signal: “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all
Any ideas?
Thanks,
-Scott |
|
From: Scott H. <sco...@gm...> - 2010-05-15 00:55:49
|
Sorry is this gets posted twice. I sent it out the other night, but never saw it show up on the list.
My goal was to make a simple demo program that has a NSView implemented in Python, a NSView implemented in ObjC and that demonstrates both languages calling each other all in one app.
Any ideas?
Thanks,
-Scott
On May 14, 2010, at 12:40 AM, Scott Harris wrote:
> I've got this obj-c object in a simple demo program:
>
>
> @implementation junker
> -(id) init
> {
> [super init];
> NSLog(@"initing");
> [self action];
> return self;
> }
> -(void) action
> {
> NSLog(@"junk");
> //NSBeep();
> }
> @end
>
> I call it from Python in my App delegate like this:
>
> from Foundation import *
> from AppKit import *
>
> class PyObjCTestAppDelegate(NSObject):
> def applicationDidFinishLaunching_(self, sender):
> NSLog("Application did finish launching.")
> self.a=junker.alloc().init()
>
> def awakeFromNib(self):
> NSLog("Awoke from NIB")
>
> @objc.IBAction
> def buttonPress_(self, sender):
> NSLog("Button pressed!")
> self.a.action()
>
> The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange.
>
> Here's the console output:
> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB
> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing
> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching.
> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing
> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk
> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed
> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk
> Program received signal: “EXC_BAD_ACCESS”.
> sharedlibrary apply-load-rules all
>
> Any ideas?
>
> Thanks,
> -Scott
|
|
From: Ronald O. <ron...@ma...> - 2010-05-15 17:24:39
Attachments:
smime.p7s
|
On 14 May, 2010, at 8:40, Scott Harris wrote:
> I've got this obj-c object in a simple demo program:
>
>
> @implementation junker
> -(id) init
> {
> [super init];
> NSLog(@"initing");
> [self action];
> return self;
> }
> -(void) action
> {
> NSLog(@"junk");
> //NSBeep();
> }
> @end
>
> I call it from Python in my App delegate like this:
>
> from Foundation import *
> from AppKit import *
>
> class PyObjCTestAppDelegate(NSObject):
> def applicationDidFinishLaunching_(self, sender):
> NSLog("Application did finish launching.")
> self.a=junker.alloc().init()
>
> def awakeFromNib(self):
> NSLog("Awoke from NIB")
>
> @objc.IBAction
> def buttonPress_(self, sender):
> NSLog("Button pressed!")
> self.a.action()
>
> The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange.
>
> Here's the console output:
> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB
> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing
> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching.
> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing
> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk
> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed
> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk
> Program received signal: “EXC_BAD_ACCESS”.
> sharedlibrary apply-load-rules all
>
> Any ideas?
The code looks correct, but indeed crashes. I'm looking into this, at first glance it seems that PyObjC is confused about the return type for [junker -action], and that's probably caused by the metadata files.
One quick way to work around this: rename 'action' to something else.
Ronald
|
|
From: Scott H. <sco...@gm...> - 2010-05-20 19:52:47
|
Thanks. Changing the method name to something other than action fixes the issue. Is action a bad choice for a method in general?
-Scott
On May 15, 2010, at 11:24 AM, Ronald Oussoren wrote:
>
> On 14 May, 2010, at 8:40, Scott Harris wrote:
>
>> I've got this obj-c object in a simple demo program:
>>
>>
>> @implementation junker
>> -(id) init
>> {
>> [super init];
>> NSLog(@"initing");
>> [self action];
>> return self;
>> }
>> -(void) action
>> {
>> NSLog(@"junk");
>> //NSBeep();
>> }
>> @end
>>
>> I call it from Python in my App delegate like this:
>>
>> from Foundation import *
>> from AppKit import *
>>
>> class PyObjCTestAppDelegate(NSObject):
>> def applicationDidFinishLaunching_(self, sender):
>> NSLog("Application did finish launching.")
>> self.a=junker.alloc().init()
>>
>> def awakeFromNib(self):
>> NSLog("Awoke from NIB")
>>
>> @objc.IBAction
>> def buttonPress_(self, sender):
>> NSLog("Button pressed!")
>> self.a.action()
>>
>> The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange.
>>
>> Here's the console output:
>> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB
>> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing
>> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching.
>> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing
>> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk
>> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed
>> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk
>> Program received signal: “EXC_BAD_ACCESS”.
>> sharedlibrary apply-load-rules all
>>
>> Any ideas?
>
> The code looks correct, but indeed crashes. I'm looking into this, at first glance it seems that PyObjC is confused about the return type for [junker -action], and that's probably caused by the metadata files.
>
> One quick way to work around this: rename 'action' to something else.
>
> Ronald
>
|
|
From: Jonathan <jon...@jo...> - 2010-05-20 20:22:25
|
It's probably python getting what you're doing confused with methods
common to the target-action system. I've found it to be a good idea
to avoid method names that come up in AppKiDo when using bridged
languages with cocoa.
Cheers
jonathan Saggau
Happily elbows-deep in python again, if only for a couple of weeks. :)
On Thu, May 20, 2010 at 3:52 PM, Scott Harris <sco...@gm...> wrote:
> Thanks. Changing the method name to something other than action fixes the
> issue. Is action a bad choice for a method in general?
> -Scott
> On May 15, 2010, at 11:24 AM, Ronald Oussoren wrote:
>
> On 14 May, 2010, at 8:40, Scott Harris wrote:
>
> I've got this obj-c object in a simple demo program:
>
> @implementation junker
> -(id) init
> {
> [super init];
> NSLog(@"initing");
> [self action];
> return self;
> }
> -(void) action
> {
> NSLog(@"junk");
> //NSBeep();
> }
> @end
> I call it from Python in my App delegate like this:
> from Foundation import *
> from AppKit import *
> class PyObjCTestAppDelegate(NSObject):
> def applicationDidFinishLaunching_(self, sender):
> NSLog("Application did finish launching.")
> self.a=junker.alloc().init()
> def awakeFromNib(self):
> NSLog("Awoke from NIB")
> @objc.IBAction
> def buttonPress_(self, sender):
> NSLog("Button pressed!")
> self.a.action()
> The funny thing is that the program crashes when I press the button that
> calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep
> is uncommented. Strange.
> Here's the console output:
> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB
> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing
> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish
> launching.
> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing
> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk
> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed
> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk
> Program received signal: “EXC_BAD_ACCESS”.
> sharedlibrary apply-load-rules all
> Any ideas?
>
> The code looks correct, but indeed crashes. I'm looking into this, at first
> glance it seems that PyObjC is confused about the return type for [junker
> -action], and that's probably caused by the metadata files.
> One quick way to work around this: rename 'action' to something else.
> Ronald
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
--
Jonathan Saggau
jonathansaggau.com
This amusement engaged me so much that [friends] were obliged to force
me from it; and thus it is with every inclination I give into, it
continues to augment, till at length it becomes so powerful, that I
lose sight of everything except the favorite amusement. - Rousseau
|
|
From: Ronald O. <ron...@ma...> - 2010-05-21 05:45:07
Attachments:
smime.p7s
|
On 20 May, 2010, at 21:52, Scott Harris wrote:
> Thanks. Changing the method name to something other than action fixes the issue. Is action a bad choice for a method in general?
I'd say so purely design/code smell view: 'action' doesn't communicate what the method will do (at least not unless it returns an action of some sort).
That said, the crash your having is a bug in PyObjC as I expected. The bug has two levels: first of all PyObjC thinks there is an informal protocol that describes the interface of an action method because a class in AppKit defines its action method in a category. Secondly PyObjC shouldn't use its knowlegde about informal protocols to override the method signature of method that is defined in ObjC.
This last bit causes the crash: your ObjC method is a method dat returns nothing ("-(void)action"), while the action method in the PyObjC metadata returns a selector ("-(SEL)action"). This causes PyObjC to treat some arbitrary value on the stack as a SEL, which is basicly a C string and that causes a EXC_BAD_ACCESS.
Ronald
>
> -Scott
> On May 15, 2010, at 11:24 AM, Ronald Oussoren wrote:
>
>>
>> On 14 May, 2010, at 8:40, Scott Harris wrote:
>>
>>> I've got this obj-c object in a simple demo program:
>>>
>>>
>>> @implementation junker
>>> -(id) init
>>> {
>>> [super init];
>>> NSLog(@"initing");
>>> [self action];
>>> return self;
>>> }
>>> -(void) action
>>> {
>>> NSLog(@"junk");
>>> //NSBeep();
>>> }
>>> @end
>>>
>>> I call it from Python in my App delegate like this:
>>>
>>> from Foundation import *
>>> from AppKit import *
>>>
>>> class PyObjCTestAppDelegate(NSObject):
>>> def applicationDidFinishLaunching_(self, sender):
>>> NSLog("Application did finish launching.")
>>> self.a=junker.alloc().init()
>>>
>>> def awakeFromNib(self):
>>> NSLog("Awoke from NIB")
>>>
>>> @objc.IBAction
>>> def buttonPress_(self, sender):
>>> NSLog("Button pressed!")
>>> self.a.action()
>>>
>>> The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange.
>>>
>>> Here's the console output:
>>> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB
>>> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing
>>> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching.
>>> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing
>>> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk
>>> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed
>>> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk
>>> Program received signal: “EXC_BAD_ACCESS”.
>>> sharedlibrary apply-load-rules all
>>>
>>> Any ideas?
>>
>> The code looks correct, but indeed crashes. I'm looking into this, at first glance it seems that PyObjC is confused about the return type for [junker -action], and that's probably caused by the metadata files.
>>
>> One quick way to work around this: rename 'action' to something else.
>>
>> Ronald
>>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X