pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Help getting Started with PyObjc2 and Leopard

[George A. <ar...@la...>]

Hello,

This is my first attempt at using pyobjc and I run into some problems.

I created a new project using XCode 3.0 with the Cocoa-Python 
Application template.
I then proceeded to do a build on the application (n.b. I haven't added 
any of my own code yet) and the build succeeded.
When I do a build and run however, I get the following error message in 
console:

//--------------------------------------------------------------------------------------------------------------------------------
The Debugger Debugger is attaching to process
[Session started at 2007-11-29 08:32:29 -0500.]
Traceback (most recent call last):
  File 
"/Users/Armahg/Builds/Release/again.app/Contents/Resources/main.py", 
line 10, in <module>
    import objc
ImportError: No module named objc
2007-11-29 08:32:29.349 again[2542:10b] *** Terminating app due to 
uncaught exception 'NSInternalInconsistencyException', reason: 
'/Users/Armahg/again/main.m:46 main() PyRun_SimpleFile failed with file 
'/Users/Armahg/Builds/Release/again.app/Contents/Resources/main.py'.  
See console for errors.'
2007-11-29 08:32:29.352 again[2542:10b] Stack: (
    2488480363,
    2511437979,
    2488479819,
    2488479882
)
//--------------------------------------------------------------------------------------------------------------------------------
 From what I have read, i thought pyobjC2  should work right out of the 
box with Leopard. Is there anything configuration I have to do to get 
the app working?


I also tried to run some of the PyObjc examples and received the 
following error message

//--------------------------------------------------------------------------------------------------------------------------------
Armahg:CurrencyConverter Armahg$ python setup.py py2app
Traceback (most recent call last):
  File "setup.py", line 8, in <module>
    import py2app
ImportError: No module named py2app
//--------------------------------------------------------------------------------------------------------------------------------

TroubleShooting done so far:

My current path for Python is:
Armahg$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python

I modified the main.m file in my test PyObjc app to read
 /*Py_SetProgramName("/usr/bin/python");*/
Py_SetProgramName("/Library/Frameworks/Python.framework/Versions/Current/bin/python");

and this has not helped either.


Any help given would be much appreciated. Also, in return, I'll document 
what I do and post it somewhere online so that
other newcomers won't have to email this dev list with the same problem 
again :)

Thanks in advance ,

George.

[Pyobjc-dev] Multiple PyObjC plugins

[Duncan W. <du...@mc...>]

Hi, I have an objc leopard app that has a plain objc loadable bundle =20
plugin structure. I'm finding that doing plugins with pyobjc is great.

I don't have an extensive python experience, and python embedding is a =20=

complete mystery to me, so I borrowed Jon Wight's Python Action =20
startup code, with Ian Baird's tweaks: =
http://paste.lisp.org/display/51497

The problem I'm seeing is that the first plugin I load will work just =20=

fine, but as soon as I load a second plugin (from a second bundle, =20
with the same startup code), I'll get bad crashes, specifically Xcode =20=

will fail with an error like this:

Program received signal:  =93EXC_BAD_ACCESS=94.
Xcode: Introspection dylib not loaded because thread 1 has function: =20
=
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkCon=
textE=20
  on stack

When running from the terminal I get a Bus Error and Crash Reporter =20
showing this backtrace:

Thread 0 Crashed:
0   org.python.python             	0x0c69d1bb PyImport_AddModule + =
29
1   org.python.python             	0x0c6a681a =
PyRun_SimpleFileExFlags =20
+ 29
2   org.python.python             	0x0c6a6ba4 PyRun_SimpleFile + 40

The PyRun_SimpleFile call is from the python startup code above.

This is on stock 10.5.1.

I also tried modifying the startup code to guard the initialization =20
like this:

	if(! Py_IsInitialized())
	{
		Py_SetProgramName("/usr/bin/python");
		Py_Initialize();
	}

but the crash didn't change.

Should I be using more lower level embedding glue? Should I be moving =20=

interpreter startup to the main app?

Thanks for any reply,
Duncan

Re: [Pyobjc-dev] NSCoding support for python list & dict

[Barry W. <bar...@gm...>]

I don't think I have the chops to pull off the pickling of Objective-C
objects. It seems that we might be able to encode list and dict types
however by just calling [super encode...] from their OC_PythonXX
wrappers. Unless one of the gurus thinks that's a stupid idea, I will
give it a try.

Barry

On 11/27/07, Ronald Oussoren <ron...@ma...> wrote:
>
> On Tuesday, November 27, 2007, at 08:56AM, "Bill Bumgarner" <bb...@ma...> wrote:
> >On Nov 26, 2007, at 9:59 PM, Ronald Oussoren wrote:
> >> NSCoding support for other objects should also be doable, but is
> >> more work and requires a lot of testing. Pickling Objective-C
> >> objects on the other hand has the outlooks of being a very hard
> >> problem.
> >
> >NSArchiver and NSKeyedArchiver support arbitrary archival of objects.
> >That is, you can create an archiving session and then archive the sub-
> >graphs of objects of objects in arbitrary order and with arbitrary
> >references between the subgraphs.
> >
> >Pickling of a graph containing a mix of Python and Objective-C objects
> >could be done by creating a UUID for each object in the graph at the
> >pickle/archiver boundary.  The UUID could be stored in the pickle,
> >could be used to archive the sub-graph of Objective-C objects and
> >store 'em away via -encodeObject:forKey:, and then the resulting BLOB
> >of archived Objective-C data could be stored in the pickle as a
> ><string>.
> >
> >Completely trivial, right?
>
> At first glance that doesn't quite fit into the pickle interface, but could be made to work using a class/function on top of pickle that does the work.
>
> Dealing with cycles and object-identity will be interesting though (e.g. pickle.dumps([O, NSArray.arrayWithArray_([O])]), where O is a pure Python object (or even (O=[]; A=NSArray.arrayWithArray_([O]); O.append(A); pickle.dumps([O,A]).
>
> The other way around (adding NSCoding support to Python objects) is easy: just call __getstate__/__reduce__ to get object state, then use encodeObject:forKey: to write that, more basic, object to the stream.
>
> >
> >Only because of my ignorance.   There is a definite chicken-and-egg
> >problem in that archival will produce the archived obj-c objects
> >*last* whereas unarchival will need them to be decoded *first*.   And
> >that is just scratching the surface.
>
> What might work: implement __reduce__ for objc.objc_object using a custom NSCoder subclass that builds a python datastructure containing the object state, then let the pickle machinery serialize that. That is, encodeObject:forKey: would add the object to a dictionary. At some point the object state must be some basic object, such as C integers, which pickle can encode without further recursion.
>
> I know this is a bit vague, I made this up while typing this e-mail. It does look like something that can be made to work though.
>
> Volunteers?
>
> Ronald
> >
> >b.bum
> >
> >-------------------------------------------------------------------------
> >This SF.net email is sponsored by: Microsoft
> >Defy all challenges. Microsoft(R) Visual Studio 2005.
> >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >_______________________________________________
> >Pyobjc-dev mailing list
> >Pyo...@li...
> >https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

[blake <ch...@ap...>]

On Nov 27, 2007, at 11:31 AM, Ronald Oussoren wrote:

>
> On 27 Nov, 2007, at 20:08, blake wrote:
>
>>
>> On Nov 27, 2007, at 5:16 AM, Ben Artin wrote:
>>
>>>
>>> On Nov 27, 2007, at 1:07 AM, Ronald Oussoren wrote:
>>>
>>>>
>>>> On 26 Nov, 2007, at 22:55, Ben Artin wrote:
>>>>
>>>>>
>>>>> On Nov 26, 2007, at 3:17 PM, blake wrote:
>>>>>
>>>>>>> The problem appears to be that no metadata exists for  
>>>>>>> <CarbonCore/
>>>>>> UTCUtils.h>. You might try running gen_bridge_metadata(1) on
>>>>>> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.
>>>>>
>>>>> Also, documentation for UTCDateTime specifically says that it's
>>>>> wrong
>>>>> to access it at uint64_t, so that advice is incorrect.
>>>>
>>>> The advice is actually a good idea: just use 'Q' as the encoding
>>>> for struct UTCDate and you're set as long as the definition of
>>>> UTCDate doesn't change, and that's not likely to happen due to
>>>> binary compatibility constrains.
>>>
>>> I guess carrying it across the bridge as a uint64_t is OK as long as
>>> I don't try to do math with it as an integer? Thanks.
>>>
>>
>> I was thinking that a scalar type would be safe for bridge
>> travel(assuming no math expressions) But after rereading the docs, I
>> would recommend testing that solution on both ppc and x86 to be safe.
>
> sizeof(UTCDateTime) is 8 on ppc, x86 and x86_64 (I cannot test on  
> ppc64), so it should be safe to bridge it as a int64_t value.  The  
> value is be a magic cookie (that is doing math on it would give  
> nonsensical results), but otherwise this should work just fine.
>

I was more worried about endianness than size- there may be no  
problem, but someone should verify that.

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

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

On 27 Nov, 2007, at 20:08, blake wrote:

>
> On Nov 27, 2007, at 5:16 AM, Ben Artin wrote:
>
>>
>> On Nov 27, 2007, at 1:07 AM, Ronald Oussoren wrote:
>>
>>>
>>> On 26 Nov, 2007, at 22:55, Ben Artin wrote:
>>>
>>>>
>>>> On Nov 26, 2007, at 3:17 PM, blake wrote:
>>>>
>>>>>> The problem appears to be that no metadata exists for  
>>>>>> <CarbonCore/
>>>>> UTCUtils.h>. You might try running gen_bridge_metadata(1) on
>>>>> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.
>>>>
>>>> Also, documentation for UTCDateTime specifically says that it's
>>>> wrong
>>>> to access it at uint64_t, so that advice is incorrect.
>>>
>>> The advice is actually a good idea: just use 'Q' as the encoding
>>> for struct UTCDate and you're set as long as the definition of
>>> UTCDate doesn't change, and that's not likely to happen due to
>>> binary compatibility constrains.
>>
>> I guess carrying it across the bridge as a uint64_t is OK as long as
>> I don't try to do math with it as an integer? Thanks.
>>
>
> I was thinking that a scalar type would be safe for bridge
> travel(assuming no math expressions) But after rereading the docs, I
> would recommend testing that solution on both ppc and x86 to be safe.

sizeof(UTCDateTime) is 8 on ppc, x86 and x86_64 (I cannot test on  
ppc64), so it should be safe to bridge it as a int64_t value.  The  
value is be a magic cookie (that is doing math on it would give  
nonsensical results), but otherwise this should work just fine.

Ronald
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

[blake <ch...@ap...>]

On Nov 27, 2007, at 5:16 AM, Ben Artin wrote:

>
> On Nov 27, 2007, at 1:07 AM, Ronald Oussoren wrote:
>
>>
>> On 26 Nov, 2007, at 22:55, Ben Artin wrote:
>>
>>>
>>> On Nov 26, 2007, at 3:17 PM, blake wrote:
>>>
>>>>> The problem appears to be that no metadata exists for <CarbonCore/
>>>> UTCUtils.h>. You might try running gen_bridge_metadata(1) on
>>>> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.
>>>
>>> Also, documentation for UTCDateTime specifically says that it's  
>>> wrong
>>> to access it at uint64_t, so that advice is incorrect.
>>
>> The advice is actually a good idea: just use 'Q' as the encoding  
>> for struct UTCDate and you're set as long as the definition of  
>> UTCDate doesn't change, and that's not likely to happen due to  
>> binary compatibility constrains.
>
> I guess carrying it across the bridge as a uint64_t is OK as long as  
> I don't try to do math with it as an integer? Thanks.
>

I was thinking that a scalar type would be safe for bridge  
travel(assuming no math expressions) But after rereading the docs, I  
would recommend testing that solution on both ppc and x86 to be safe.

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

[Ben A. <be...@ar...>]

On Nov 27, 2007, at 1:07 AM, Ronald Oussoren wrote:

>
> On 26 Nov, 2007, at 22:55, Ben Artin wrote:
>
>>
>> On Nov 26, 2007, at 3:17 PM, blake wrote:
>>
>>>> The problem appears to be that no metadata exists for <CarbonCore/
>>> UTCUtils.h>. You might try running gen_bridge_metadata(1) on
>>> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.
>>
>> Also, documentation for UTCDateTime specifically says that it's wrong
>> to access it at uint64_t, so that advice is incorrect.
>
> The advice is actually a good idea: just use 'Q' as the encoding for  
> struct UTCDate and you're set as long as the definition of UTCDate  
> doesn't change, and that's not likely to happen due to binary  
> compatibility constrains.

I guess carrying it across the bridge as a uint64_t is OK as long as I  
don't try to do math with it as an integer? Thanks.

--

<http://artins.org/ben>

"Youth cannot know how age thinks and feels. But old men are guilty
if they forget what it was to be young" -- Albus Dumbledore

Re: [Pyobjc-dev] NSCoding support for python list & dict

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

 
On Tuesday, November 27, 2007, at 08:56AM, "Bill Bumgarner" <bb...@ma...> wrote:
>On Nov 26, 2007, at 9:59 PM, Ronald Oussoren wrote:
>> NSCoding support for other objects should also be doable, but is  
>> more work and requires a lot of testing. Pickling Objective-C  
>> objects on the other hand has the outlooks of being a very hard  
>> problem.
>
>NSArchiver and NSKeyedArchiver support arbitrary archival of objects.   
>That is, you can create an archiving session and then archive the sub- 
>graphs of objects of objects in arbitrary order and with arbitrary  
>references between the subgraphs.
>
>Pickling of a graph containing a mix of Python and Objective-C objects  
>could be done by creating a UUID for each object in the graph at the  
>pickle/archiver boundary.  The UUID could be stored in the pickle,  
>could be used to archive the sub-graph of Objective-C objects and  
>store 'em away via -encodeObject:forKey:, and then the resulting BLOB  
>of archived Objective-C data could be stored in the pickle as a  
><string>.
>
>Completely trivial, right?

At first glance that doesn't quite fit into the pickle interface, but could be made to work using a class/function on top of pickle that does the work.

Dealing with cycles and object-identity will be interesting though (e.g. pickle.dumps([O, NSArray.arrayWithArray_([O])]), where O is a pure Python object (or even (O=[]; A=NSArray.arrayWithArray_([O]); O.append(A); pickle.dumps([O,A]).

The other way around (adding NSCoding support to Python objects) is easy: just call __getstate__/__reduce__ to get object state, then use encodeObject:forKey: to write that, more basic, object to the stream.

>
>Only because of my ignorance.   There is a definite chicken-and-egg  
>problem in that archival will produce the archived obj-c objects  
>*last* whereas unarchival will need them to be decoded *first*.   And  
>that is just scratching the surface.

What might work: implement __reduce__ for objc.objc_object using a custom NSCoder subclass that builds a python datastructure containing the object state, then let the pickle machinery serialize that. That is, encodeObject:forKey: would add the object to a dictionary. At some point the object state must be some basic object, such as C integers, which pickle can encode without further recursion.

I know this is a bit vague, I made this up while typing this e-mail. It does look like something that can be made to work though.

Volunteers?

Ronald
>
>b.bum
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] NSCoding support for python list & dict

[Bill B. <bb...@ma...>]

On Nov 26, 2007, at 9:59 PM, Ronald Oussoren wrote:
> NSCoding support for other objects should also be doable, but is  
> more work and requires a lot of testing. Pickling Objective-C  
> objects on the other hand has the outlooks of being a very hard  
> problem.

NSArchiver and NSKeyedArchiver support arbitrary archival of objects.   
That is, you can create an archiving session and then archive the sub- 
graphs of objects of objects in arbitrary order and with arbitrary  
references between the subgraphs.

Pickling of a graph containing a mix of Python and Objective-C objects  
could be done by creating a UUID for each object in the graph at the  
pickle/archiver boundary.  The UUID could be stored in the pickle,  
could be used to archive the sub-graph of Objective-C objects and  
store 'em away via -encodeObject:forKey:, and then the resulting BLOB  
of archived Objective-C data could be stored in the pickle as a  
<string>.

Completely trivial, right?

Only because of my ignorance.   There is a definite chicken-and-egg  
problem in that archival will produce the archived obj-c objects  
*last* whereas unarchival will need them to be decoded *first*.   And  
that is just scratching the surface.

b.bum

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

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

On 26 Nov, 2007, at 22:55, Ben Artin wrote:

>
> On Nov 26, 2007, at 3:17 PM, blake wrote:
>
>>> I am trying to bridge UCConvertUTCDateTimeToCFAbsoluteTime using
>>> PyObjC in Leopard.
>>>
>>> The problem that I am running into is that
>>> UCConvertUTCDateTimeToCFAbsoluteTime takes a struct that's declared
>>> (on 32 bits) as {unsigned short; unsigned long; unsigned short;}
>>> using
>>> packed alignment, which means that the offset of the 4-byte long
>>> member is 2. When I use {UTCDateTime=SLS}, PyObjC puts the 4-byte
>>> long
>>> at offset 4, which then causes problems down the line.
>>>
>>> Looking at PyObjC source, I don't see a way to force custom  
>>> alignment
>>> of struct members.
>>>
>>> Did I miss some mechanism for handling this? What are my option?
>>> Thanks,
>>
>> The problem appears to be that no metadata exists for <CarbonCore/
>> UTCUtils.h>. You might try running gen_bridge_metadata(1) on
>> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.
>
> I believe you misunderstood my problem. I am trying to provide the
> bridge metadata myself, and I believe that it is *impossible* to
> provide appropriate bridge metadata because the metadata support as it
> exists right now does not allow bridging a struct that is aligned as
> UTCDateTime (obviously, without writing my own bridge function for
> UCConvertUTCDateTimeToCFAbsoluteTime -- if I write my own, I can do
> anything I want).
>
> Also, documentation for UTCDateTime specifically says that it's wrong
> to access it at uint64_t, so that advice is incorrect.

The advice is actually a good idea: just use 'Q' as the encoding for  
struct UTCDate and you're set as long as the definition of UTCDate  
doesn't change, and that's not likely to happen due to binary  
compatibility constrains.

That way you won't have to write C code to bridge this API.

Ronald

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

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

On 26 Nov, 2007, at 21:17, blake wrote:

>> I am trying to bridge UCConvertUTCDateTimeToCFAbsoluteTime using
>> PyObjC in Leopard.
>>
>> The problem that I am running into is that
>> UCConvertUTCDateTimeToCFAbsoluteTime takes a struct that's declared
>> (on 32 bits) as {unsigned short; unsigned long; unsigned short;}  
>> using
>> packed alignment, which means that the offset of the 4-byte long
>> member is 2. When I use {UTCDateTime=SLS}, PyObjC puts the 4-byte  
>> long
>> at offset 4, which then causes problems down the line.
>>
>> Looking at PyObjC source, I don't see a way to force custom alignment
>> of struct members.
>>
>> Did I miss some mechanism for handling this? What are my option?  
>> Thanks,
>>
>> Ben
>
> The problem appears to be that no metadata exists for <CarbonCore/ 
> UTCUtils.h>. You might try running gen_bridge_metadata(1) on  
> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.


Generating metadata won't help. AFAIK metadata doesn't have support  
for packed structs, and PyObjC definitely doesn't even if the metadata  
would.

Casting int64_t should help, but isn't easily possible from Python.  
This could easily be done using metadata though (that is, teach  
gen_bridge_metadata that it should treat a UTCDateTime struct as if it  
is an int64_t) and then generate the required metadata.

Ronald
>
> Blake Chaffin
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] NSCoding support for python list & dict

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

On 26 Nov, 2007, at 21:35, Barry Wark wrote:

> PyObjC2 now raises an exception if one tries to encode a python list
> or dict instance using an NSCoder. I agree that this behavior is
> preferable to letting the action proceed silently. I'm wondering why
> PyObjC doesn't encode a list as if it were an NSMutableArray and a
> dict as if it were an NSMutableDictionary, however. One of our apps
> does a lot encoding of dictionaries created in python plugins.
> Converting these dicts to NSDictionaries via
> NSDictionary.dictionaryFromDictionary_ is fine, but seems to be a
> glaring special case of the otherwise seemless bridge. If I can treat
> python dicts as NSMutableDictionaries on the Objective-C side, why
> can't I encode them as such? Scanning the NEWS file, I see that this
> is mentioned, but I haven't found the rationale.
>
> Please understand I'm not trying to disparage the amazing work that
> the PyObjC devs have done on PyObjC2. I'm just posing the question to
> either understand the technical reason(s) behind the decision or raise
> some discussion on other options.

Good point. I'd like to add full NSCoding support for all python  
objects (or at least all pickle-able objects) in the future, but  
supporting just lists/tuples/dicts should be easy enough to do.

NSCoding support for other objects should also be doable, but is more  
work and requires a lot of testing. Pickling Objective-C objects on  
the other hand has the outlooks of being a very hard problem.

Anyhow, the most likely reason for missing features like this is me  
not having time to work on them. Knowing which features are helpfull  
for real applications, rather than just looking nice on a list of  
features, helps prioritizing development. So, thanks for the feedback.

Ronald
>
>
> Thanks,
> Barry
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

[Ben A. <be...@ar...>]

On Nov 26, 2007, at 3:17 PM, blake wrote:

>> I am trying to bridge UCConvertUTCDateTimeToCFAbsoluteTime using
>> PyObjC in Leopard.
>>
>> The problem that I am running into is that
>> UCConvertUTCDateTimeToCFAbsoluteTime takes a struct that's declared
>> (on 32 bits) as {unsigned short; unsigned long; unsigned short;}  
>> using
>> packed alignment, which means that the offset of the 4-byte long
>> member is 2. When I use {UTCDateTime=SLS}, PyObjC puts the 4-byte  
>> long
>> at offset 4, which then causes problems down the line.
>>
>> Looking at PyObjC source, I don't see a way to force custom alignment
>> of struct members.
>>
>> Did I miss some mechanism for handling this? What are my option?  
>> Thanks,
>
> The problem appears to be that no metadata exists for <CarbonCore/ 
> UTCUtils.h>. You might try running gen_bridge_metadata(1) on  
> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.

I believe you misunderstood my problem. I am trying to provide the  
bridge metadata myself, and I believe that it is *impossible* to  
provide appropriate bridge metadata because the metadata support as it  
exists right now does not allow bridging a struct that is aligned as  
UTCDateTime (obviously, without writing my own bridge function for  
UCConvertUTCDateTimeToCFAbsoluteTime -- if I write my own, I can do  
anything I want).

Also, documentation for UTCDateTime specifically says that it's wrong  
to access it at uint64_t, so that advice is incorrect.

Ben

--

<http://artins.org/ben>

"Clue meter is reading zero." -- Alice

[Pyobjc-dev] NSCoding support for python list & dict

[Barry W. <bar...@gm...>]

PyObjC2 now raises an exception if one tries to encode a python list
or dict instance using an NSCoder. I agree that this behavior is
preferable to letting the action proceed silently. I'm wondering why
PyObjC doesn't encode a list as if it were an NSMutableArray and a
dict as if it were an NSMutableDictionary, however. One of our apps
does a lot encoding of dictionaries created in python plugins.
Converting these dicts to NSDictionaries via
NSDictionary.dictionaryFromDictionary_ is fine, but seems to be a
glaring special case of the otherwise seemless bridge. If I can treat
python dicts as NSMutableDictionaries on the Objective-C side, why
can't I encode them as such? Scanning the NEWS file, I see that this
is mentioned, but I haven't found the rationale.

Please understand I'm not trying to disparage the amazing work that
the PyObjC devs have done on PyObjC2. I'm just posing the question to
either understand the technical reason(s) behind the decision or raise
some discussion on other options.

Thanks,
Barry

Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

[blake <ch...@ap...>]

> I am trying to bridge UCConvertUTCDateTimeToCFAbsoluteTime using
> PyObjC in Leopard.
>
> The problem that I am running into is that
> UCConvertUTCDateTimeToCFAbsoluteTime takes a struct that's declared
> (on 32 bits) as {unsigned short; unsigned long; unsigned short;} using
> packed alignment, which means that the offset of the 4-byte long
> member is 2. When I use {UTCDateTime=SLS}, PyObjC puts the 4-byte long
> at offset 4, which then causes problems down the line.
>
> Looking at PyObjC source, I don't see a way to force custom alignment
> of struct members.
>
> Did I miss some mechanism for handling this? What are my option?  
> Thanks,
>
> Ben

The problem appears to be that no metadata exists for <CarbonCore/ 
UTCUtils.h>. You might try running gen_bridge_metadata(1) on  
CarbonCore.framework, or typecast UTCDateTime to int64_t instead.

Blake Chaffin

Re: [Pyobjc-dev] Fwd: RubyCocoa 0.13.0 + RubyInject 0.1.0

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

On 26 Nov, 2007, at 2:53, Bill Bumgarner wrote:

> On Nov 25, 2007, at 5:23 PM, Timothy Reaves wrote:
>> On Nov 25, 2007, at 12:39 PM, Bill Bumgarner wrote:
>>> Now that both RubyCocoa and PyObjC are sitting on BridgeSupport, the
>>> releases of RubyCocoa are relevant to PyObjC...
>>>
>>> So, FYI.
>>
>> 	Why is it relevant?  Because they both use BridgeSupport?  They also
>> both use a Mac.  Not sure I understand.
>
> Because there is a growing body of code duplication between the two
> bridges and, since they share underpinnings of both BridgeSupport and
> FFI, a growing expectation that there is a bit of parity in feature
> set (if only in more awareness of between the two communities).
>
>
> Personally, I would like to see more synergy between the two bridges
> (and others using BridgeSupport, of course) with a goal of eliminating
> a lot of what is now duplicate code.

I'm far from convinced that code sharing is feasible. Most of the code  
PyObjC deals is fairly specific to Python.

Sharing of design and feature sets are much more useful, that would  
make it easier for both bridges to move forward.

Ronald
>
>
> b.bum
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Fwd: RubyCocoa 0.13.0 + RubyInject 0.1.0

[Bill B. <bb...@ma...>]

On Nov 25, 2007, at 5:23 PM, Timothy Reaves wrote:
> On Nov 25, 2007, at 12:39 PM, Bill Bumgarner wrote:
>> Now that both RubyCocoa and PyObjC are sitting on BridgeSupport, the
>> releases of RubyCocoa are relevant to PyObjC...
>>
>> So, FYI.
>
> 	Why is it relevant?  Because they both use BridgeSupport?  They also
> both use a Mac.  Not sure I understand.

Because there is a growing body of code duplication between the two  
bridges and, since they share underpinnings of both BridgeSupport and  
FFI, a growing expectation that there is a bit of parity in feature  
set (if only in more awareness of between the two communities).

Personally, I would like to see more synergy between the two bridges  
(and others using BridgeSupport, of course) with a goal of eliminating  
a lot of what is now duplicate code.

b.bum

Re: [Pyobjc-dev] Fwd: RubyCocoa 0.13.0 + RubyInject 0.1.0

[Timothy R. <tr...@si...>]

On Nov 25, 2007, at 12:39 PM, Bill Bumgarner wrote:

> Now that both RubyCocoa and PyObjC are sitting on BridgeSupport, the
> releases of RubyCocoa are relevant to PyObjC...
>
> So, FYI.

	Why is it relevant?  Because they both use BridgeSupport?  They also  
both use a Mac.  Not sure I understand. 

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Bill B. <bb...@ma...>]

On Nov 25, 2007, at 4:02 PM, Nathan wrote:
> On Nov 22, 2007 1:23 AM, Bill Bumgarner <bb...@ma...> wrote:
>> On Nov 21, 2007, at 11:28 PM, Ronald Oussoren wrote:
>> I agree. I've filed a bug for this as radar #5610558. Feel free to  
>> do the
>> same to boost the priority of this issue.
>> No need -- I filed the bug directly earlier today, including a  
>> description
>
> FYI, I've been _repeatedly_ told by Apple engineers that duplicate
> bugs are very helpful.  In particular, each duplicate is counted as a
> vote for fixing the bug, and that's one of the primary ways they
> prioritize which bugs to work on.
>
> So if you really want your bug fixed, you should encourage _everyone_
> to file a bug about it.

I completely agree.

However, there is an exception.  If an Apple engineer pipes up and  
says "no need for dupes", then it is because there really isn't a need  
for dupes -- the priority, etc, has already been set and isn't going  
to change.   In most cases, this means that the bug is on the fast  
track to be fixed.

b.bum

Re: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks

[Nathan <nat...@gm...>]

On Nov 22, 2007 1:23 AM, Bill Bumgarner <bb...@ma...> wrote:
> On Nov 21, 2007, at 11:28 PM, Ronald Oussoren wrote:
> I agree. I've filed a bug for this as radar #5610558. Feel free to do the
> same to boost the priority of this issue.
> No need -- I filed the bug directly earlier today, including a description

FYI, I've been _repeatedly_ told by Apple engineers that duplicate
bugs are very helpful.  In particular, each duplicate is counted as a
vote for fixing the bug, and that's one of the primary ways they
prioritize which bugs to work on.

So if you really want your bug fixed, you should encourage _everyone_
to file a bug about it.

~ Nathan

Re: [Pyobjc-dev] PyObjC & RubyCocoa in a single app

[Bill B. <bb...@ma...>]

On Nov 25, 2007, at 6:21 AM, Ronald Oussoren wrote:
> On 25 Nov, 2007, at 6:58, Bill Bumgarner wrote:
>
>> Yes, it works.  Sort of.
>>
>> http://www.friday.com/bbum/2007/11/25/can-ruby-python-an-objective-c-co-exist-in-a-single-application/
>>
>> The biggest issue is that both RubyCocoa and PyObjC assume that no  
>> one
>> else [in their right mind :)] might have loaded the BridgeSupport
>> dylibs.
>
> PyObjC just does:
>                dlopen(dylibPath, RTLD_LAZY);
>
> (without any error checking). Shouldn't that just work fine even  
> when RubyCocoa has already loaded the dylib?
>
> Patches to make this work nicer are welcome ;-)

I'll try to fix it later today.  Zoo first.  The example lives in a  
Svn repository for a reason -- I'll cut branches of it to track  
cleaner versions against non-Leopard baselines of RubyCocoa, PyObjC  
and, eventually, CamelBones (and whoever else wants to join the party).

Note that RubyCocoa fails in the same way.

Removing one of the stupid exception suppressors for the moment, the  
full exception barfed up is this:

Traceback (most recent call last):
   File "/tmp/bbum-products/Release/PyRu.app/Contents/Resources/ 
main.py", line 11, in <module>
     import Foundation
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/Foundation/__init__.py", line 10, in <module>
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/CoreFoundation/__init__.py", line 17, in <module>
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/PyObjC/objc/_bridgesupport.py", line 129, in  
initFrameworkWrapper
     _parseBridgeSupport(data, globals, frameworkName, dylib_path)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/PyObjC/objc/_bridgesupport.py", line 53, in  
_parseBridgeSupport
     objc.parseBridgeSupport(data, globals, frameworkName, *args,  
**kwds)
objc.error: CFXMLParserRef is overriding existing Objective-C class
2007-11-25 09:44:50.811 PyRu[16076:10b] /Volumes/Data/developer- 
external/bbum-red-bean/trunk/hacques/Silly/PyRu/AppDelegate.m:48  
main() PyRun_SimpleFile failed with file '/tmp/bbum-products/Release/ 
PyRu.app/Contents/Resources/main.py'.  See console for errors.

[Pyobjc-dev] Fwd: RubyCocoa 0.13.0 + RubyInject 0.1.0

[Bill B. <bb...@ap...>]

Now that both RubyCocoa and PyObjC are sitting on BridgeSupport, the  
releases of RubyCocoa are relevant to PyObjC...

So, FYI.

Begin forwarded message:
> Begin forwarded message:
>
>> From: Laurent Sansonetti <lsa...@ap...>
>> Date: November 24, 2007 9:28:26 PM GMT+01:00
>> To: ruby-users <rub...@gr...>
>> Subject: Fwd: [Rubycocoa-talk] [ANN] RubyCocoa 0.13.0
>>
>> Begin forwarded message:
>>
>>> From: Laurent Sansonetti <lau...@gm...>
>>> Date: November 24, 2007 4:55:08 PM GMT+01:00
>>> To: rub...@li..., rub...@li... 
>>> , rub...@ru...
>>> Subject: [Rubycocoa-talk] [ANN] RubyCocoa 0.13.0
>>> Reply-To: rub...@li...
>>>
>>> Hi,
>>>
>>> I am honored to announce the immediate release of RubyCocoa 0.13.0.
>>>
>>> RubyCocoa is a Mac OS X framework that allows Cocoa programming in  
>>> the
>>> object-oriented scripting language Ruby. In other words, it is a
>>> bridge that let you access Objective-C objects from Ruby, and
>>> vice-versa.
>>>
>>> You can learn more about RubyCocoa on our website:
>>>
>>> http://rubycocoa.sf.net
>>>
>>> A source tarball as well as binary installers for Mac OS X 10.4 and
>>> 10.5 are provided.
>>>
>>> This is mostly a bugs fix release, addressing many critical issues,
>>> but it also brings some nice enhancements. All users are  
>>> encouraged to
>>> upgrade, and report us feedback.
>>>
>>> Mac OS X 10.5, Leopard, is as you can see supported by this release.
>>> Installing this release using the binary installer or manually with
>>> the default build parameters won't override the system version, it
>>> will go in /Library while the system version is in /System.
>>>
>>> The release notes are following. Enjoy!
>>>
>>> Laurent
>>>
>>> New features:
>>>
>>> - NSArray and NSDictionary now respond to the same messages of their
>>> Ruby equivalents, respectively Array and Hash. NSString responds to
>>> the String messages too, except #=~ and #match. The implementation  
>>> is
>>> fast and reliable, but respects the Cocoa semantics. The
>>> #method_missing hack has been removed.
>>>
>>> - Added utility methods to NSRect, NSPoint, NSSize and NSRange.
>>>
>>> - Added useful inspect methods to NSString, NSNumber, NSArray,
>>> NSDictionary, NSCFBoolean and NSDate. Added pretty print support to
>>> NSString, NSArray, NSDictionary.
>>>
>>> - Added a #to_ns method to Array, Hash, String, Numeric, TrueClass,
>>> FalseClass, Time, to convert them to their Cocoa equivalent.
>>>
>>> - Added ObjcPtr#cast_as(encoding) for more generic casting from  
>>> void*.
>>>
>>> - Added Leopard-only samples.
>>>
>>> Bugs fixed:
>>>
>>> - Fixed various memory leaks in the RubyCocoa initialization code,  
>>> and
>>> in the bridge support parsing code. No memory should now be leaked
>>> during initialization.
>>>
>>> - Improved the ruby obj -> ocid and ruby obj -> SEL conversions  
>>> performance.
>>>
>>> - Fixed a crash when passing a pointer to an ObjC object, then  
>>> trying
>>> to convert it as a Ruby object after the API call, but crashing
>>> because the pointer wasn't touched by the API. Now preparing
>>> passed-by-reference pointers to NULL.
>>>
>>> - Fixed an error, "Please install again" on reinstalling using the
>>> binary installer.
>>>
>>> - Do not translate 'set' methods that get more than one argument.
>>>
>>> - Create the slave objects at demand, if they do not exist yet. This
>>> fixes a bindings / CoreData problem in 10.5.
>>>
>>> - Now resetting the context autorelease pools on every thread  
>>> restore.
>>>
>>> - Fixed a bug when an object that was being allocated from a Ruby
>>> thread was still in the cache while the thread was killed, resulting
>>> in a corrupted cache.
>>>
>>> - Make sure we do not cache CF-based objects.
>>>
>>> - Fixed a circular retain cycle from ObjC objects allocated from an
>>> NSObject-based Ruby class, resulting in a leak of both the ObjC  
>>> object
>>> and its Ruby proxy.
>>>
>>> - Hook [copyWithZone:] and reset the slave object so that every ObjC
>>> object has a different slave object. This fixes a crash when  
>>> releasing
>>> a slave object that could be shared by multiple ObjC objects.
>>>
>>> - #objc_send will now pass a frozen selector to the core, where
>>> underscore characters won't be transformed as ':'. This is a
>>> convenience utility to call ObjC methods that contain underscores as
>>> part of their selector, like for example [__rbobj__].
>>>
>>> - Better OvMix retain cycle: if an OvMix object is created from  
>>> Ruby,
>>> we by default don't retain its Ruby proxy, and start tracking
>>> retain/release messages, and appropriately re-retain/re-release the
>>> Ruby proxy.
>>>
>>> - Removed the old __slave_nsobj__ ivar hook. Now all pure-Ruby  
>>> objects
>>> will be wrapped in an autoreleased RBObject.
>>>
>>> - Fixed a bug, when ObjC arguments that were passed from an ObjC
>>> closure to Ruby were not retained, as they should. Added a test  
>>> case.
>>>
>>> - Better facility (10.5 only) that dispatches messages from  
>>> threads to
>>> the thread where RubyCocoa was initialized. It was previously  
>>> assuming
>>> that RubyCocoa was run in the main thread, which may not be always
>>> true (Ruby could be ran in a different thread).
>>>
>>> - Now allow the send the of 'new' message to any ObjC class that  
>>> will
>>> respond to it. Keep the old behavior (raising an exception) for
>>> classes that don't implement new.
>>>
>>> - Added threading support for 10.5.
>>>
>>> - Updated metaconfig and Rakefile to use '--gen-bridge-support=no'  
>>> on 10.5.
>>>
>>> - New metaconfig option --sdkroot. Fix setup error
>>> --macosx-deployment-target=10.4 on 10.5.
>>>
>>> - Fixed String#to_nsstring for 10.5.
>>>
>>> - String#nsenconding, to_nsstring, to_nsmutablestring are now
>>> deprecated. Developers are encouraged to switch to #to_ns.
>>>
>>> - Fixed a bug, calling to_ns for a Ruby String which has illegal  
>>> utf-8
>>> sequences caused a bus error.
>>>
>>> - Avoid an infinite loop when creating the slave proxy, which  
>>> could be
>>> caused by an attempt to pass an object to Objective-C in its
>>> #initialize method.
>>>
>>> - sample/Scripts/darkroom.rb: fix SEGV of darkroom.rb on 10.5.
>>>
>>> - Added CoreData.define_wrapper_for_entity(). This feature was  
>>> part of
>>> CoreData.define_wrapper(). Removed "to_a" for NSArray in CoreData
>>> module.
>>>
>>> - Load the libSystem.bridgesupport file if it exists (10.5 only).
>>>
>>> - rb_nibtool: Fixed a crash when the provided Ruby script only  
>>> defines
>>> actions but no outlets, or vice-versa.
>>>
>>> - rb_nibtool: Fixed bug where #each was called on nil if there were
>>> either no actions OR outlets in the class.
>>>
>>> - rb_nibtool: Fixed bug where a new class from a source file would  
>>> not
>>> show up in the class list in IB because the superclass is unknown to
>>> the classes list in IB. If the superclass const is not found it will
>>> default to NSObject. This change is not effective when rb_nibtool is
>>> used with rubynode.
>>>
>>> - rb_nibtool: Fixed problem when not detecting existing classes.
>>>
>>> - standaloneify: Now sets the environment variable
>>> ENV['RUBYCOCOA_STANDALONEIFYING?']. This is to be able to prevent  
>>> code
>>> from being ran when an application is being standaloneified.
>>>
>>> - standaloneify: Will now skip all the source files at any depth  
>>> in Resources.
>>>
>>> - gen_bridge_doc: Updated to work with the latest Apple  
>>> documentation and 10.5.
>>>
>>> - gen_bridge_doc: Fixed a bug where </i> tags weren't replaced by  
>>> '_'.
>>>
>>> - gen_bridge_doc: Added documentation for the translated bool  
>>> methods,
>>> eg: isRunning -> running?.
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Rubycocoa-talk mailing list
>>> Rub...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
> Begin forwarded message:
>
>> From: Laurent Sansonetti <lsa...@ap...>
>> Date: November 24, 2007 9:28:47 PM GMT+01:00
>> To: ruby-users <rub...@gr...>
>> Subject: Fwd: [Rubycocoa-talk] [ANN] RubyInject 0.1.0
>>
>> Begin forwarded message:
>>
>>> From: Laurent Sansonetti <lau...@gm...>
>>> Date: November 24, 2007 8:21:17 PM GMT+01:00
>>> To: rub...@li..., rub...@li... 
>>> , rub...@ru...
>>> Subject: [Rubycocoa-talk] [ANN] RubyInject 0.1.0
>>> Reply-To: rub...@li...
>>>
>>> Hi,
>>>
>>> I am glad to announce the first version of the RubyInject project.
>>>
>>> RubyInject is a Mac OS X framework that allows you to inject at
>>> runtime the Ruby interpreter into any running application, using the
>>> mach_star mechanism.
>>>
>>> It will spawn a new thread on the remote process, initialize the  
>>> Ruby
>>> interpreter, start a new DRb server that exposes an expression
>>> evaluator object, and advertises the DRb server URI on Bonjour.
>>>
>>> A client is provided, inject.rb, that waits on Bonjour for the DRb
>>> server URI, connects to it, then either executes a given Ruby script
>>> or starts an IRB session.
>>>
>>> RubyInject is especially useful when combined with RubyCocoa. You  
>>> can
>>> at runtime inject RubyCocoa into an Objective-C application and  
>>> start
>>> introspecting and messaging its objects.
>>>
>>> Check out the following link for more details:
>>>
>>> http://rubycocoa.sourceforge.net/RubyInject
>>>
>>> Enjoy,
>>>
>>> Laurent
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Rubycocoa-talk mailing list
>>> Rub...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
>

Re: [Pyobjc-dev] PyObjC & RubyCocoa in a single app

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

On 25 Nov, 2007, at 6:58, Bill Bumgarner wrote:

> Yes, it works.  Sort of.
>
> http://www.friday.com/bbum/2007/11/25/can-ruby-python-an-objective-c-co-exist-in-a-single-application/
>
> The biggest issue is that both RubyCocoa and PyObjC assume that no one
> else [in their right mind :)] might have loaded the BridgeSupport
> dylibs.

PyObjC just does:
                 dlopen(dylibPath, RTLD_LAZY);

(without any error checking). Shouldn't that just work fine even when  
RubyCocoa has already loaded the dylib?

Patches to make this work nicer are welcome ;-)

Ronald

>
>
> b.bum
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjC & RubyCocoa in a single app

[Samantha A. <sja...@ma...>]

On Nov 24, 2007, at 9:58 PM, Bill Bumgarner wrote:

> Yes, it works.  Sort of.
>
> http://www.friday.com/bbum/2007/11/25/can-ruby-python-an-objective-c-co-exist-in-a-single-application/

Hmm.  Why exactly is it an error to load the same dynamic library  
twice or attempt to?  I would have thought the second attempt would  
just be a nop.   No?  Why not?

>
- samantha

[Pyobjc-dev] PyObjC & RubyCocoa in a single app

[Bill B. <bb...@ma...>]

Yes, it works.  Sort of.

http://www.friday.com/bbum/2007/11/25/can-ruby-python-an-objective-c-co-exist-in-a-single-application/

The biggest issue is that both RubyCocoa and PyObjC assume that no one  
else [in their right mind :)] might have loaded the BridgeSupport  
dylibs.

b.bum