pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> You might want to try TableModel2, this contains the same code but now 
> part of a ProjectBuilder project. This project does work with python 
> 2.2.

I actually did, the app builds fine, but when I launch it it immediately quits,
no trace of any error in the Console, no crash, nothing. Hm, I just tried again
with Python 2.2 instead of CVS, and it works! Hey, that's great!

I guess I'll rebuild my FrameWork install and see how far I get with running the
examples with that.

Just

Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

[Ronald O. <ous...@ci...>]

On Monday, Nov 11, 2002, at 09:35 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> You should run 'setup-app.py' in the same directory to create a .app
>> bundle, and then use 'open *.app' to actually run the example.
>
> This results in an ImportError on buildtools. Note that this is a 
> plain unix
> install: even if I make sure buildtools can be found I get an error: 
> about the
> macfs module this time. Doesn't look this is going to work with a 
> vanilla 2.2
> install :-(

Thanks for reminding me! The setup-app.py script indirectly uses a 
MacPython module, and that is not installed in a vanilla install. I'll 
have to rewrite the buildtools module.

You might want to try TableModel2, this contains the same code but now 
part of a ProjectBuilder project. This project does work with python 
2.2.
>
>> nibwrapper.py could not be found because the objc module updates
>> sys.path to make sure the Resources directory in an .app bundle is on
>> the Python search path. I'm checking in an updated version of that 
>> code
>> later today, the current version is slightly to aggressive.
>
> Ah.

Not that this patch actually helps you, after sending my previous 
e-mail I checked in the patch and tried to start the example from the 
command-line and got an error from Cocoa about not being able to find a 
value in the Info.plist file. And then I remembered: To use NIB files 
you have to have a real .app bundle.

Ronald

Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> You should run 'setup-app.py' in the same directory to create a .app 
> bundle, and then use 'open *.app' to actually run the example.

This results in an ImportError on buildtools. Note that this is a plain unix
install: even if I make sure buildtools can be found I get an error: about the
macfs module this time. Doesn't look this is going to work with a vanilla 2.2
install :-(

> nibwrapper.py could not be found because the objc module updates 
> sys.path to make sure the Resources directory in an .app bundle is on 
> the Python search path. I'm checking in an updated version of that code 
> later today, the current version is slightly to aggressive.

Ah.

Thanks,

Just

Re: [Pyobjc-dev] Newbie: Can't get TableModel to work

[Ronald O. <ous...@ci...>]

You should run 'setup-app.py' in the same directory to create a .app 
bundle, and then use 'open *.app' to actually run the example.

nibwrapper.py could not be found because the objc module updates 
sys.path to make sure the Resources directory in an .app bundle is on 
the Python search path. I'm checking in an updated version of that code 
later today, the current version is slightly to aggressive.

Ronald

[Pyobjc-dev] Newbie: Can't get TableModel to work

[Just v. R. <ju...@le...>]

Hi all,

I just subscribed to this list. I'm looking forward to learn more about PyObjC
and Cocoa!

The Hello World example works fine. However, if I try to run the TableModel
example, I get the following traceback:

  [python:pyobjc/Examples/TableModel] just% python TableModel.py
  Traceback (most recent call last):
    File "TableModel.py", line 5, in ?
      from nibwrapper import PyModelBase
  ImportError: No module named nibwrapper

This happens both with the Apple-shipped Python 2.2 and CVS Python (also a plain
unix install, not a FrameWork). Is the way I invoke the script supposed to work?
The nibwrapper.py module is right there in the current directory.

Thanks,

Just

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Bill N. <no...@sn...>]

I am updating a number of machines to 10.2 and would like to start 
working on some pyObjC
projects.  I have been using the python 2.3 code and use a lot of unix 
applications/libraries.

The framework build has worked fine, but I am wondering whether whether 
there is any preference
between a framework install or a basic unix install.

I want to distribute applications locally that can use packages from a 
central place (whether
/Library/Frameworks or /usr/local/lib/python2.3) and be linked to 
python directly.

Is there a preference?

--Bill Noon


On Sunday, November 10, 2002, at 12:43 PM, Ronald Oussoren wrote:

> Long. Apple seems to have a long feature-freeze for the Darwin part of 
> new OSX releases and Python 2.3 has not even reached an alpha release 
> at the moment, I wouldn't be surprised if Python 2.3 isn't released 
> before the summer of 2003.
>
> BTW. The alpha status of 2.3 doesn't mean that this version is 
> unusable. I haven't really run into problems while using it the last 
> couple of months.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Peter M. <zig...@po...>]

On Monday, November 11, 2002, at 04:43 AM, Ronald Oussoren wrote:

>
> On Saturday, Nov 9, 2002, at 15:42 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>> Great! But why wouldn't NSArray be a subclass of NSObject under my 
>> scheme? ObjCObject isn't an NSObject is it? I though it was a proxy, 
>> passing method calls to an encapsulated id. I was thinking a list 
>> based NSArray wrapper would act the same: answering any sequence 
>> methods by translating them into NSArray methods and passing any non 
>> sequence methods (ie. native NSArray methods) on to the encapsulated 
>> NSArray. This way, any NSArray instances would look like sequences to 
>> pure python code but would still respond to all the Cocoa methods as 
>> per normal. Of course, I'm still pretty new to the inner workings of 
>> PyObjC so I could be completely mistaken. And I have absolutely no 
>> idea how hard that would be.
>
> Don't forget that there are two sets of classes with the same name: 
> The original Objective-C classes and the Python proxy classes. 
> Currently the latter have the same inheritence graph as the former, 
> with the addition of a single root: objc.objc_object. It would be 
> possible to make the Python class NSArray a subclass of list, but then 
> it can no longer be a subclass of objc.objc_object (imcompatible base 
> classes).

OK, I had a feeling it was impossible. It seemed too obvious. Thanks 
for the lesson.


> I just remembered that this wouldn't solve the list slicing problem on 
> Python 2.2, because the list slicing code directly accesses the PyList 
> representation (even if a subclass of list has overridden > __getitem__).

That was what I was referring to in the question below.


>> How is either method going to solve the splice problem if the splice 
>> code is trying to access the list directly? Did I understand that 
>> correctly?
> Subclassing list doesn't help with Python 2.2. In Python 2.3 either 
> method will work (not subclassing list actually works better at the 
> moment, but that will be fixed soon). Given this situation I'd prefer 
> to not change the base-class for NSArray.

Fine. These "suggestions" of mine are really just my way of extracting 
information about pyobjc from you guys. :-)


>>
>> BTW, how long do you think it will take Apple to include Python 2.3 
>> in the default install?
> Long. Apple seems to have a long feature-freeze for the Darwin part of 
> new OSX releases and Python 2.3 has not even reached an alpha release 
> at the moment, I wouldn't be surprised if Python 2.3 isn't released 
> before the summer of 2003.

Sooo, 10.5 is it?

Peter

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Ronald O. <ous...@ci...>]

On Saturday, Nov 9, 2002, at 20:13 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Sunday, November 10, 2002, at 04:10 AM, bb...@ma... wrote:
>
>> On Saturday, November 9, 2002, at 09:42 AM, Peter Montagner wrote:
>>> How is either method going to solve the splice problem if the splice 
>>> code is trying to access the list directly? Did I understand that 
>>> correctly?
>>
>> Python has been moving to using the types-- string, int, etc..-- as 
>> inheritable classes for some time.   As such, you can do things like:
>>
> [snip]
>>
>> Or something like that... I haven't fully wrapped my head around this 
>> stuff yet.
>
> OK. Maybe I misunderstood. I'm think I'm clear now. So what you're 
> saying is that the splice code will work for any list, although just 
> implementing the methods is not enough?
Just in case someone missed my other messages on this subject:
List slice assignment will work when the source is not a python list 
object if and only if you use a recent snapshot of Python 2.3. In 
Python 2.2 this will not work correctly, even if the object is an 
instance of a subclass of __builtin__.list.

Ronald

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Bill N. <no...@sn...>]

I am updating a number of machines to 10.2 and would like to start 
working on some pyObjC
projects.  I have been using the python 2.3 code and use a lot of unix 
applications/libraries.

The framework build has worked fine, but I am wondering whether whether 
there is any preference
between a framework install or a basic unix install.

I want to distribute applications locally that can use packages from a 
central place (whether
/Library/Frameworks or /usr/local/lib/python2.3) and be linked to 
python directly.

Is there a preference?

--Bill Noon

On Sunday, November 10, 2002, at 12:43 PM, Ronald Oussoren wrote:

> Long. Apple seems to have a long feature-freeze for the Darwin part of 
> new OSX releases and Python 2.3 has not even reached an alpha release 
> at the moment, I wouldn't be surprised if Python 2.3 isn't released 
> before the summer of 2003.
>
> BTW. The alpha status of 2.3 doesn't mean that this version is 
> unusable. I haven't really run into problems while using it the last 
> couple of months.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Ronald O. <ous...@ci...>]

On Saturday, Nov 9, 2002, at 18:10 Europe/Amsterdam, bb...@ma... wrote:
> So, if we were able to make an encapsulated NSArray inherit from the  
> base class 'list' on the Python side, it would behave exactly like any  
> other 'list' in all contexts.
Unless the implementation directly accesses the list representation!  
The implementation of the list type predates newstyle classes  
(obiously) and does not always check if it is save to directly accesses  
the representation instead of using accessor functions (the former is  
more efficient and used to be equivalent).
>
> There is some subtlety -- for example, the '2' in the above example  
> really is an 'int' and not a 'FooInt'.   To preserve it as a FooInt, I  
> would need to redefine all of the math operations (__add__, etc) on  
> FooInt to return instances of FooInt.  Of course, I can't do anything  
> about it [I don't think] if FooInt is the operand -- i.e. in the case  
> of '1 + x'.
'if FooInt is not the operand' :-)

>
> Or something like that... I haven't fully wrapped my head around this  
> stuff yet.
Subclassing builtin types works just like subclassing normal objects.
>
> Ronald:  Can you point me to the bug that you filed and a description  
> of the fix?  Is a workaround possible?
Bug:  
http://sourceforge.net/tracker/ 
?func=detail&aid=633152&group_id=5470&atid=105470

The bugreport is for a slightly different problem: as noted above the  
implementation of list sometimes directly accesses the datastructure,  
even if subclasses have overridden the accessor functions. This is more  
obviously a bug than the problem you were seeing and the correct fix  
for this problem also solves our problem :-)

I don't think there is a workaround for this.

>
> As much as I hate to limit our feature set, I feel it is absolutely  
> critical that PyObjC remain compatible with the Python distributed by  
> Apple.
I agree, PyObjC gets less usefull if it requires you to install a  
seperate version of Python (especially so if that different version is  
an unreleased version of Python).

Ronald

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Ronald O. <ous...@ci...>]

On Saturday, Nov 9, 2002, at 15:42 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Sunday, November 10, 2002, at 01:11 AM, Ronald Oussoren wrote:
>
>>
>> On Saturday, Nov 9, 2002, at 11:31 Europe/Amsterdam, Peter Montagner 
>> wrote:
>>
>>> Bill Bumgarner wrote:
>>>
>>>>  ... is true, then we add <type 'list'> to the bases for the newly
>>>> created Python class object?   Assuming a complete implementation of
>>>> convenience methods, this would allow bridged instances of NSArray 
>>>> to
>>>> function fully on the Python side of the bridge [i.e. work in 
>>>> contexts
>>>> like the above where the runtime is testing for a particular type 
>>>> and
>>>> not just a set of methods].
>>>>
>>>> As an experiment, I tried-- naively-- to add this to the function 
>>>> that
>>>> bridges classes to Python... it doesn't work.
>>>
>>> So you can't do it by adding list as a base but could you instead 
>>> just not use ObjCObject to do the wrapping? What if you created 
>>> another class with list as the only base? You can't slam 
>>> PyListObject and ObjCObject together but could you subclass list and 
>>> add real_object as another variable? Or will python not even let you 
>>> subclass compiled classes in C?
>>
>> That would work, but then NSArray would no longer by a subclass of 
>> NSObject. This will probably cause subtle bugs and won't buy us much 
>> in the long run. Especially because this will be a non-issue in 
>> Python 2.3: I filed a bug-report related to this and the bug was 
>> fixed within a day :-)
>
> Great! But why wouldn't NSArray be a subclass of NSObject under my 
> scheme? ObjCObject isn't an NSObject is it? I though it was a proxy, 
> passing method calls to an encapsulated id. I was thinking a list 
> based NSArray wrapper would act the same: answering any sequence 
> methods by translating them into NSArray methods and passing any non 
> sequence methods (ie. native NSArray methods) on to the encapsulated 
> NSArray. This way, any NSArray instances would look like sequences to 
> pure python code but would still respond to all the Cocoa methods as 
> per normal. Of course, I'm still pretty new to the inner workings of 
> PyObjC so I could be completely mistaken. And I have absolutely no 
> idea how hard that would be.

Don't forget that there are two sets of classes with the same name: The 
original Objective-C classes and the Python proxy classes. Currently 
the latter have the same inheritence graph as the former, with the 
addition of a single root: objc.objc_object. It would be possible to 
make the Python class NSArray a subclass of list, but then it can no 
longer be a subclass of objc.objc_object (imcompatible base classes). I 
just remembered that this wouldn't solve the list slicing problem on 
Python 2.2, because the list slicing code directly accesses the PyList 
representation (even if a subclass of list has overridden __getitem__).
>
> How is either method going to solve the splice problem if the splice 
> code is trying to access the list directly? Did I understand that 
> correctly?
Subclassing list doesn't help with Python 2.2. In Python 2.3 either 
method will work (not subclassing list actually works better at the 
moment, but that will be fixed soon). Given this situation I'd prefer 
to not change the base-class for NSArray.

>
> BTW, how long do you think it will take Apple to include Python 2.3 in 
> the default install?
Long. Apple seems to have a long feature-freeze for the Darwin part of 
new OSX releases and Python 2.3 has not even reached an alpha release 
at the moment, I wouldn't be surprised if Python 2.3 isn't released 
before the summer of 2003.

BTW. The alpha status of 2.3 doesn't mean that this version is 
unusable. I haven't really run into problems while using it the last 
couple of months.

Ronald

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Peter M. <zig...@po...>]

On Sunday, November 10, 2002, at 04:10 AM, bb...@ma... wrote:

> On Saturday, November 9, 2002, at 09:42 AM, Peter Montagner wrote:
>> How is either method going to solve the splice problem if the splice 
>> code is trying to access the list directly? Did I understand that 
>> correctly?
>
> Python has been moving to using the types-- string, int, etc..-- as 
> inheritable classes for some time.   As such, you can do things like:
>
[snip]
>
> Or something like that... I haven't fully wrapped my head around this 
> stuff yet.

OK. Maybe I misunderstood. I'm think I'm clear now. So what you're 
saying is that the splice code will work for any list, although just 
implementing the methods is not enough?


> As much as I hate to limit our feature set, I feel it is absolutely 
> critical that PyObjC remain compatible with the Python distributed by 
> Apple.

Absolutely. That's why I asked the question.

Peter

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

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

On Saturday, November 9, 2002, at 09:42 AM, Peter Montagner wrote:
> How is either method going to solve the splice problem if the splice 
> code is trying to access the list directly? Did I understand that 
> correctly?

Python has been moving to using the types-- string, int, etc..-- as 
inheritable classes for some time.   As such, you can do things like:

 >>> class FooInt(int): pass
...
 >>> x = FooInt(1)
 >>> x
1
 >>> type(x)
<class '__main__.FooInt'>
 >>> x + 1
2

That is, for all intents and purposes, instances of 'FooInt' behave 
exactly like any old 'int'.

So, if we were able to make an encapsulated NSArray inherit from the 
base class 'list' on the Python side, it would behave exactly like any 
other 'list' in all contexts.

There is some subtlety -- for example, the '2' in the above example 
really is an 'int' and not a 'FooInt'.   To preserve it as a FooInt, I 
would need to redefine all of the math operations (__add__, etc) on 
FooInt to return instances of FooInt.  Of course, I can't do anything 
about it [I don't think] if FooInt is the operand -- i.e. in the case 
of '1 + x'.

Or something like that... I haven't fully wrapped my head around this 
stuff yet.

> BTW, how long do you think it will take Apple to include Python 2.3 in 
> the default install?

If we are lucky, it may make it into 10.3 assuming that Python 2.3 goes 
stable at least three months in advance of the release of 10.3.  I 
really can't imagine 10.3 coming out before next summer given how much 
change there was in 10.0->10.1 and 10.1->10.2 and assuming that that 
amount of change is a decent benchmark.   Then again, Apple has been 
absolutely ripping through 10.2.x updates since the release of 10.2.

Ronald:  Can you point me to the bug that you filed and a description 
of the fix?  Is a workaround possible?

As much as I hate to limit our feature set, I feel it is absolutely 
critical that PyObjC remain compatible with the Python distributed by 
Apple.

b.bum

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

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

Right -- and we absolutely must preserve the class hierarchy.  That is, 
if something is to be used transparently as an array on the ObjC side 
of the bridge, it must be a subclass of NSArray.  Many things do 
'isKindOfClass:' style tests to figure out what kind of collection/data 
they are looking at.   As well, NSArray provides the transparent 
bridging into the CFArray API-- the CF* APIs are used to implement a 
good chunk of the functionality found in the Foundation and AppKit.

b.bum

On Saturday, November 9, 2002, at 09:11 AM, Ronald Oussoren wrote:
> That would work, but then NSArray would no longer by a subclass of 
> NSObject. This will probably cause subtle bugs and won't buy us much 
> in the long run. Especially because this will be a non-issue in Python 
> 2.3: I filed a bug-report related to this and the bug was fixed within 
> a day :-)

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Peter M. <zig...@po...>]

On Sunday, November 10, 2002, at 01:11 AM, Ronald Oussoren wrote:

>
> On Saturday, Nov 9, 2002, at 11:31 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>> Bill Bumgarner wrote:
>>
>>>  ... is true, then we add <type 'list'> to the bases for the newly
>>> created Python class object?   Assuming a complete implementation of
>>> convenience methods, this would allow bridged instances of NSArray to
>>> function fully on the Python side of the bridge [i.e. work in 
>>> contexts
>>> like the above where the runtime is testing for a particular type and
>>> not just a set of methods].
>>>
>>> As an experiment, I tried-- naively-- to add this to the function 
>>> that
>>> bridges classes to Python... it doesn't work.
>>
>> So you can't do it by adding list as a base but could you instead 
>> just not use ObjCObject to do the wrapping? What if you created 
>> another class with list as the only base? You can't slam PyListObject 
>> and ObjCObject together but could you subclass list and add 
>> real_object as another variable? Or will python not even let you 
>> subclass compiled classes in C?
>
> That would work, but then NSArray would no longer by a subclass of 
> NSObject. This will probably cause subtle bugs and won't buy us much 
> in the long run. Especially because this will be a non-issue in Python 
> 2.3: I filed a bug-report related to this and the bug was fixed within 
> a day :-)

Great! But why wouldn't NSArray be a subclass of NSObject under my 
scheme? ObjCObject isn't an NSObject is it? I though it was a proxy, 
passing method calls to an encapsulated id. I was thinking a list based 
NSArray wrapper would act the same: answering any sequence methods by 
translating them into NSArray methods and passing any non sequence 
methods (ie. native NSArray methods) on to the encapsulated NSArray. 
This way, any NSArray instances would look like sequences to pure 
python code but would still respond to all the Cocoa methods as per 
normal. Of course, I'm still pretty new to the inner workings of PyObjC 
so I could be completely mistaken. And I have absolutely no idea how 
hard that would be.

How is either method going to solve the splice problem if the splice 
code is trying to access the list directly? Did I understand that 
correctly?

BTW, how long do you think it will take Apple to include Python 2.3 in 
the default install?

Peter

Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Ronald O. <ous...@ci...>]

On Saturday, Nov 9, 2002, at 11:31 Europe/Amsterdam, Peter Montagner 
wrote:

> Bill Bumgarner wrote:
>
>>  ... is true, then we add <type 'list'> to the bases for the newly
>> created Python class object?   Assuming a complete implementation of
>> convenience methods, this would allow bridged instances of NSArray to
>> function fully on the Python side of the bridge [i.e. work in contexts
>> like the above where the runtime is testing for a particular type and
>> not just a set of methods].
>>
>> As an experiment, I tried-- naively-- to add this to the function that
>> bridges classes to Python... it doesn't work.
>
> So you can't do it by adding list as a base but could you instead just 
> not use ObjCObject to do the wrapping? What if you created another 
> class with list as the only base? You can't slam PyListObject and 
> ObjCObject together but could you subclass list and add real_object as 
> another variable? Or will python not even let you subclass compiled 
> classes in C?

That would work, but then NSArray would no longer by a subclass of 
NSObject. This will probably cause subtle bugs and won't buy us much in 
the long run. Especially because this will be a non-issue in Python 
2.3: I filed a bug-report related to this and the bug was fixed within 
a day :-)

Ronald

[Pyobjc-dev] Re: Making List<->Array bridging transparent

[Peter M. <zig...@po...>]

Bill Bumgarner wrote:

>  ... is true, then we add <type 'list'> to the bases for the newly
> created Python class object?   Assuming a complete implementation of
> convenience methods, this would allow bridged instances of NSArray to
> function fully on the Python side of the bridge [i.e. work in contexts
> like the above where the runtime is testing for a particular type and
> not just a set of methods].
>
> As an experiment, I tried-- naively-- to add this to the function that
> bridges classes to Python... it doesn't work.

So you can't do it by adding list as a base but could you instead just 
not use ObjCObject to do the wrapping? What if you created another 
class with list as the only base? You can't slam PyListObject and 
ObjCObject together but could you subclass list and add real_object as 
another variable? Or will python not even let you subclass compiled 
classes in C?

Peter

Re: [Pyobjc-dev] Python rather than ObjC for main?

[Peter M. <zig...@po...>]

On Saturday, November 9, 2002, at 04:56 AM, bb...@ma... wrote:

> The setenv() call would have to happen in the main [python] 
> executable.  The PyObjC module is too late because it is dynamically 
> loaded.    Back to square one-- we could use a Python script in the 
> app wrapper, but it would (a) be slower and (b) not add any 
> functionality over the current bootstrap executable.
>
> BTW:  There is nothing app specific about the bootstrap executable.  
> You don't even need to compile it to use it in another project-- just 
> add a copy files phase that copies the executable into the Executables 
> area of the app wrapper and make sure that the executable name 
> attribute in the info dictionary of the app wrapper is set correctly.

Yeah, the first thing I tried was a python script as the executable 
that mirrors bin-python-main.m ie. it calls the python version of 
exec(). It works without any problems but as you said, there isn't any 
point.


>> I think I know what will help me: a proper build of python. So what 
>> is recommended? CVS python? Stable python? Fink?
>
> Fink rocks.
>
> I would go with Fink -- make sure you follow the 10.2 instructions at 
> fink.sourceforge.net.   It keeps itself up to date quite nicely and is 
> incredibly easy to uninstall (fink remove python -- once it is built, 
> there will be a debian package containing the python build and, 
> therefore, a subsequent fink remove / fink install of python does not 
> require it to be rebuilt).   Go with 'python-nox' if you don't have or 
> want X11 installed.

I haven't got fink for 10.2 yet. How different is it from stable python?


>> Unfortunately, I can't read binary :-)
>
> A trick:
>
>     otool -TtVv /usr/lib/crt1.o

Ah, thanks. I was doing otool -tv /usr/lib/crt1.o. The other options 
make it much more readable. Still can't really figure it out but I can 
see where it sets _NXArgv.


>> I'm a very curious person. But one can only be so curious when one is 
>> trying to read messy, #ifdef laced source code through a CVSWeb site 
>> over a dialup link.
>
> Agreed.  C in this form is very much like macro assembly....

Sums it up well.


>>> In any case, all of this-- the whole execve() style bootstrapper-- 
>>> is just a hack that'll go away as soon as we have an embeddable 
>>> build of Python shipping with OS X.
>>
>> Yeah, I know. I just had the kluge alert going off in my head and I 
>> felt compelled to try and fix it. Anything other than the current 
>> hack is going to be an even bigger hack. You guys have done a great 
>> job.
>
> Thanks.  It just got better.  If you cvs update the pyobjc source 
> tree, the new Cocoa-Python project template has been cleaned up a bit. 
>   BTW:  You can create a symlink from /Developer/ProjectBuilder 
> Extras/Project Templates/... wherever ... to the project template(s) 
> in the pyobjc source tree directly.   Just make sure you don't end up 
> w/a .pbxuser file in the template pbproj....

Done.  Main.py is now __main__.py? Good idea. My only problem with the 
current scheme is that you have to add import statements for your 
source. Is there away this could be automatically, or better yet 
dynamically? It would be nice if the user didn't have to touch 
__main__.py manually. It would be even nicer if __main__.py could 
figure out where the other stuff is itself.

Peter

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

On Friday, November 8, 2002, at 12:04 PM, Peter Montagner wrote:
> On Saturday, November 9, 2002, at 01:47 AM, bb...@ma... wrote:
>
>> On Friday, November 8, 2002, at 08:21 AM, Peter Montagner wrote:
>> ... excellent sleuth work deleted -- thank you for tracking this=20
>> down!!! ...
>
> Well, it didn't really get us anywhere. Just to elaborate, my test=20
> copy of PythonEdit with the python start code works if you setenv=20
> CFProcessPath to the right place before you run it. I really wish CF=20=

> would not decide where the executable is so quickly. Why does it not=20=

> check the first time you actually ask for it (with CFBundle et al)? It=20=

> would be great if we could sneak a setenv() call somewhere in PyObjC=20=

> but by then CF has already looked and decided that /usr/bin/python is=20=

> the path to the executable. Arrgh.

Anything that fills in gaps in my knowledge is generally a good thing=20
-- so, again, thanks for doing a bunch of legwork.

The setenv() call would have to happen in the main [python] executable.=20=

  The PyObjC module is too late because it is dynamically loaded.   =20
Back to square one-- we could use a Python script in the app wrapper,=20
but it would (a) be slower and (b) not add any functionality over the=20
current bootstrap executable.

BTW:  There is nothing app specific about the bootstrap executable. =20
You don't even need to compile it to use it in another project-- just=20
add a copy files phase that copies the executable into the Executables=20=

area of the app wrapper and make sure that the executable name=20
attribute in the info dictionary of the app wrapper is set correctly.

> I think I know what will help me: a proper build of python. So what is=20=

> recommended? CVS python? Stable python? Fink?

Fink rocks.

I would go with Fink -- make sure you follow the 10.2 instructions at=20
fink.sourceforge.net.   It keeps itself up to date quite nicely and is=20=

incredibly easy to uninstall (fink remove python -- once it is built,=20
there will be a debian package containing the python build and,=20
therefore, a subsequent fink remove / fink install of python does not=20
require it to be rebuilt).   Go with 'python-nox' if you don't have or=20=

want X11 installed.

The Fink build of python, like the Apple build, does not include an ssl=20=

enabled socket module.  Trivial to fix;  go to versiontracker and=20
search for 'python' in the OS X area and grab the package I put=20
together.

The framework build [and, I would guess, MacPython] also work, from=20
what I hear.  I personally don't use them because making sure my code=20
works out of the box on OS X 10.2 and making sure my code that should=20
be portable to other Unix like systems is portable are the two top=20
priorities for me...

>>> Anyway, a function called __CFInitialize() is called by _start() (or=20=

>>> something else before main() is called, I'm not sure. Couldn't find=20=

>>> the source for _start()). Down the bottom of the function is this >=20=

>>> line:
>>
>> _start() is defined in crt1.o -- see /usr/lib/crt1.o -- and is a part=20=

>> of the C runtime [crt] bootstrap that is built as a part of gcc.    =20=

>> It calls a series of module init functions-- modules in the most=20
>> primitive sense [mach-o files involved in the linking, I believe]--=20=

>> and is what triggers, say, the static initialization mechanism in=20
>> C++.   Immediately after initialization the modules, it initializes=20=

>> the ObjC runtime, if present.
>
> Unfortunately, I can't read binary :-)

A trick:

     otool -TtVv /usr/lib/crt1.o

This dissassembles the executable code within a mach-o file (the TEXT=20
segments).  I'm not much of an assembly person, myself, but was able to=20=

figure out the above from that output and from my knowledge of how C++=20=

and ObjC initialize as an app loads.

> Even a disassembly of it is pretty painful because none of the=20
> interesting stuff is in the module. _start() calls a couple of dyld=20
> functions (I think) then jumps to a couple of functions that have=20
> presumably just been loaded. It has to be something like that because=20=

> the jumps are to addresses past the end of the TEXT segment. They are=20=

> also all nicely prebound so that all I see is a hexadecimal address,=20=

> no stubs. I couldn't find the crt.c file and frankly it's not really=20=

> worth my time anymore.

The module init likely walks the list of Mach-O modules that have been=20=

loaded into the app [each dylib will define a single module -- maybe=20
more than one, I can't remember] by calling a specifically named=20
function, it would appear.

>>> =A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early
>>>
>>> This means that CF already has the process path determined and=20
>>> cached before main() is even called. Damn. I was getting hopeful for=20=

>>> a while there.  Well, I think I give up.
>>
>> No reason not to outside of curiosity.   We can't control the order=20=

>> of static initialization and, therefore, could not guarantee that a=20=

>> piece of our code-- module initialization code-- would be executed=20
>> prior to the call into the Core Foundation initialization.
>
> I'm a very curious person. But one can only be so curious when one is=20=

> trying to read messy, #ifdef laced source code through a CVSWeb site=20=

> over a dialup link.

Agreed.  C in this form is very much like macro assembly....

>> In any case, all of this-- the whole execve() style bootstrapper-- is=20=

>> just a hack that'll go away as soon as we have an embeddable build of=20=

>> Python shipping with OS X.
>
> Yeah, I know. I just had the kluge alert going off in my head and I=20
> felt compelled to try and fix it. Anything other than the current hack=20=

> is going to be an even bigger hack. You guys have done a great job.

Thanks.  It just got better.  If you cvs update the pyobjc source tree,=20=

the new Cocoa-Python project template has been cleaned up a bit.   BTW:=20=

  You can create a symlink from /Developer/ProjectBuilder Extras/Project=20=

Templates/... wherever ... to the project template(s) in the pyobjc=20
source tree directly.   Just make sure you don't end up w/a .pbxuser=20
file in the template pbproj....

b.bum

Re: [Pyobjc-dev] Python rather than ObjC for main?

[Peter M. <zig...@po...>]

On Saturday, November 9, 2002, at 01:47 AM, bb...@ma... wrote:

> On Friday, November 8, 2002, at 08:21 AM, Peter Montagner wrote:
> ... excellent sleuth work deleted -- thank you for tracking this=20
> down!!! ...

Well, it didn't really get us anywhere. Just to elaborate, my test copy=20=

of PythonEdit with the python start code works if you setenv=20
CFProcessPath to the right place before you run it. I really wish CF=20
would not decide where the executable is so quickly. Why does it not=20
check the first time you actually ask for it (with CFBundle et al)? It=20=

would be great if we could sneak a setenv() call somewhere in PyObjC=20
but by then CF has already looked and decided that /usr/bin/python is=20
the path to the executable. Arrgh.

I think I know what will help me: a proper build of python. So what is=20=

recommended? CVS python? Stable python? Fink?


>> Anyway, a function called __CFInitialize() is called by _start() (or=20=

>> something else before main() is called, I'm not sure. Couldn't find=20=

>> the source for _start()). Down the bottom of the function is this >=20=

>> line:
>
> _start() is defined in crt1.o -- see /usr/lib/crt1.o -- and is a part=20=

> of the C runtime [crt] bootstrap that is built as a part of gcc.    =20=

> It calls a series of module init functions-- modules in the most=20
> primitive sense [mach-o files involved in the linking, I believe]--=20
> and is what triggers, say, the static initialization mechanism in C++.=20=

>   Immediately after initialization the modules, it initializes the=20
> ObjC runtime, if present.

Unfortunately, I can't read binary :-)

Even a disassembly of it is pretty painful because none of the=20
interesting stuff is in the module. _start() calls a couple of dyld=20
functions (I think) then jumps to a couple of functions that have=20
presumably just been loaded. It has to be something like that because=20
the jumps are to addresses past the end of the TEXT segment. They are=20
also all nicely prebound so that all I see is a hexadecimal address, no=20=

stubs. I couldn't find the crt.c file and frankly it's not really worth=20=

my time anymore.


>> =A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early
>>
>> This means that CF already has the process path determined and cached=20=

>> before main() is even called. Damn. I was getting hopeful for a while=20=

>> there.  Well, I think I give up.
>
> No reason not to outside of curiosity.   We can't control the order of=20=

> static initialization and, therefore, could not guarantee that a piece=20=

> of our code-- module initialization code-- would be executed prior to=20=

> the call into the Core Foundation initialization.

I'm a very curious person. But one can only be so curious when one is=20
trying to read messy, #ifdef laced source code through a CVSWeb site=20
over a dialup link.


> In any case, all of this-- the whole execve() style bootstrapper-- is=20=

> just a hack that'll go away as soon as we have an embeddable build of=20=

> Python shipping with OS X.

Yeah, I know. I just had the kluge alert going off in my head and I=20
felt compelled to try and fix it. Anything other than the current hack=20=

is going to be an even bigger hack. You guys have done a great job.

Peter=

Re: [Pyobjc-dev] Handling (void *)

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

[of course, in the immediate term, we should handle None passed to a 
(void *) argument as NULL and vice-versa -- this should be pretty easy 
and takes care of most situations as most callbacks really don't need 
callback information given that the callback method is executed in the 
same instance of the class that made the original call and, as such, 
all of the context is available to the developer anyway.]

On Friday, November 8, 2002, at 05:31 AM, Ronald Oussoren wrote:
> BTW. Jack's solution (None->nil, PyCObject->extract the pointer, ...) 
> is a better solution for almost anything with the possible exception 
> of the userInfo arguments in some Cocoa APIs. This does work correctly 
> with 'void*-as-pointer-to-block-of-memory'.

Why don't we simply limit the calls to methods that take context 
information to always taking an object reference?  This is what the 
Java Bridge does and, as much as modeling things after the Java bridge 
is typically a bad idea, it seems like a pretty reasonable solution.

In all cases, the context information is produced by the developer and 
subsequently consumed by the developer-- there is never a case where 
the AppKit manipulates the context data.   In general, the whole MVC 
design pattern will lead the developer to producing and consuming the 
context information within the same class.   While there could be the 
rare situation that the developer would produce a value in ObjC to be 
consumed in Python or vice-versa, this is easily addressed by simply 
providing cover in one language or the other to handle the conversion 
across the bridge, as necessary.

If we wanted to be particularly tricky, we could use a weak reference 
type scheme to create a map between (void *) values that were passed 
across and their corresponding Python object.   By maintaining two 
maps-- Python->ObjC and ObjC->Python-- we could actually map between 
the Python and ObjC objects as the bridge is crossed.   That is, a call 
that uses a Python encapsulated NSView reference would enter ObjC w/the 
context information being the (id) of the NSView instance.  Similarly, 
the call back into Python could map back from the NSView instance to 
the Python object.

As long as everything is maintained as weak references-- as straight 
maps mapping the addresses and nothing more-- this would even work if 
the developer passes something like [foo userContext: (void *) 1234] 
across the bridge.   The key is to make sure that the weak references 
are destroyed as the python objects are destroyed (not much we can do 
on the C side of the bridge-- but not much we need to do, I don't 
think).

--

This doesn't cover NSData, NSImage, and the handful-- very small 
handful-- of other cases where there is a (void *) method and there 
isn't some alternative API that can be used instead.   Those situations 
are somewhat of a per-context type issue;  i.e. we might need to create 
specific bridging functionality to support these classes.

b.bum


b.bum
Are you laughing?
	... they are.

Re: [Pyobjc-dev] Python rather than ObjC for main?

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

On Friday, November 8, 2002, at 08:21 AM, Peter Montagner wrote:
... excellent sleuth work deleted -- thank you for tracking this=20
down!!! ...

> Anyway, a function called __CFInitialize() is called by _start() (or=20=

> something else before main() is called, I'm not sure. Couldn't find=20
> the source for _start()). Down the bottom of the function is this > =
line:

_start() is defined in crt1.o -- see /usr/lib/crt1.o -- and is a part=20
of the C runtime [crt] bootstrap that is built as a part of gcc.     It=20=

calls a series of module init functions-- modules in the most primitive=20=

sense [mach-o files involved in the linking, I believe]-- and is what=20
triggers, say, the static initialization mechanism in C++.  =20
Immediately after initialization the modules, it initializes the ObjC=20
runtime, if present.

> =A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early
>
> This means that CF already has the process path determined and cached=20=

> before main() is even called. Damn. I was getting hopeful for a while=20=

> there.  Well, I think I give up.

No reason not to outside of curiosity.   We can't control the order of=20=

static initialization and, therefore, could not guarantee that a piece=20=

of our code-- module initialization code-- would be executed prior to=20
the call into the Core Foundation initialization.

In any case, all of this-- the whole execve() style bootstrapper-- is=20
just a hack that'll go away as soon as we have an embeddable build of=20
Python shipping with OS X.

b.bum

[Pyobjc-dev] Re: libffi

[Ronald O. <ous...@ci...>]

I got my copy from the GCC CVS some time ago. I checked out the CVS 
HEAD and used just the libffi part. The only thing I had to do was a 
small patch to configure: I kept complaining about a file in .., which 
probably wasn't there because I didn't build the rest of GCC.

As I said, I couldn't get it to build into a shared library. This seems 
to be caused by an assembler file that is used for closures. Just 
removing this file is of no use because I actually want to use that 
feature.

Ronald

Re: [Pyobjc-dev] Python rather than ObjC for main?

[Peter M. <zig...@po...>]

On Friday, November 8, 2002, at 05:59 PM, Ronald Oussoren wrote:

> On Thursday, Nov 7, 2002, at 16:40 Europe/Amsterdam, bb...@ma...=20
> wrote:
>
>> A lot of Foundation/CFBundle applications (and a number of AppKit=20
>> applications) never use NSApplicationMain().  As well, one could=20
>> easily implement something like:
>
> As Bill noted Cocoa seems to fetch the value of argv[0] from somewhere=20=

> else. It is not even fetched from the argv vector (e.g. argv[0] =3D=20
> "foo" wouldn't be usable). I guess it is fetched directly from the=20
> datastructure passed in by execv(), which is only the source from=20
> which the argv vector is build.
>
> IIRC a couple of months ago someone on the MacPython list suggested=20
> how to deal with this using some undocumented function calls.

OK, I've been looking though some of the source to CoreFoundation and=20
CFBundleGetMainBundle() uses a function called _CFProcessPath() to get=20=

the path to the process.

_CFProcessPath() does a couple of things. First it checks to see if it=20=

already has the path cached. If it doesn't, it looks to see if an=20
environment variable called "CFProcessPath" exists. If it does, it uses=20=

that (I've checked this. It works!). If it doesn't, it calls=20
_NSGetArgv(). _NSGetArgv() just returns the global variable char=20
**NXArgv. Note that this variable is present in even the simplest CLI=20
program. You can apparently modify it (unsupported of course).

Anyway, a function called __CFInitialize() is called by _start() (or=20
something else before main() is called, I'm not sure. Couldn't find the=20=

source for _start()). Down the bottom of the function is this line:

=A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early

This means that CF already has the process path determined and cached=20
before main() is even called. Damn. I was getting hopeful for a while=20
there.  Well, I think I give up.

Peter=

[Pyobjc-dev] libffi

[Jack J. <Jac...@cw...>]

Ronald,
I understand from your messages that you've been playing with libffi, 
but I can't even get it to compile (after manually configuring it, that 
also failed for OSX). So I guess I'm looking at a different version 
than you, and/or you know things that I don't.

Where did you find libffi, and did you have to do anything special to 
make it build?
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -