pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Monday, November 25, 2002, at 08:56 PM, Peter Montagner wrote:
> On Tuesday, November 26, 2002, at 01:24 AM, Ronald Oussoren wrote:
>> On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... 
>> wrote:
>>> Key challenge:   The classes that are subsequently subclassed by the 
>>> loaded module must have instance variables that look/feel/act 
>>> exactly like the iVars in the original parent class....
>> That should be no problem, PyObjC can already to that. For me the key 
>> challenge is finding a way to initialize an embedded python 
>> interpreter and run a python script when the plugin bundle is loaded 
>> (and for bonus points: Initialize exactly 1 interpreter, even when 
>> loading more than 1 python-based plugin)
> Will this work with Apple's python? Or are you planning on shipping a 
> full python distro with the plugin? Otherwise it'd be a nice hack but 
> it wouldn't be distributable.

It would only work with a distribution of python that has an embeddable 
library.... i.e. not the Apple build.

>>>> Finding a way to automaticly execute a function when 'our' shared 
>>>> library is loaded will probably the most problematic part of this. 
>>>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>>>> 'initPyObjCExtension' in that library should run. I haven't looked 
>>>> into this yet and this may well be either trivial or impossible.
>>> Assuming that the target application is ObjC, simply creating a 
>>> +(void)load in a class/category within the dylib should be enough to 
>>> cause a hunk of code to be executing that can call 
>>> -initPyObjCExtension.   There is also a similar mechanism in the 
>>> pure C++ world.
>> I hadn't though of using a (dummy) class to do this. Thanks for the 
>> tip.
> There are problems with +(void)load. Namely, you can't guarantee the 
> order of +(void)load methods, so you can't rely on any other classes. 
> Well, certainly not those in the same bundle. This doesn't sound like 
> a problem in this case but it is something to be wary of.

Not really a problem;   in any given hunk o' dynamically loadable code, 
provide a single +load or ensure that your initialization code is only 
executed once.   Alternatively, the code invoked as a part of the 
static initializer (which +load really is) should *only* initialize the 
class in question, never touching anything else.

If the initialization code *must* be executed at a point in time when 
the rest of the framework has been loaded/initialized, then one can 
typically use something like NSNotificationCenter to cause a notif to 
be sent (exact mechanism varies according to environment).

[In all my experience as a developer, I find it surprising the number 
of times folks have been tripped up by the undefined order of execution 
inflicted upon really early initialization code...   The NS 3.3 and OS 
4.2 AppKit's both suffered from really nasty bugs if you touched 
classes in the wrong order, thereby causing +initialize to b executed 
in an "unexpected" order, very bad things would happen.  I'm surprised 
at the number of times I have tripped over this and I should *really* 
know better by now!  In any case, unless explicitly defined... don't 
assume anything prior to main() or at dyna-load time.]

b.bum

Re: [Pyobjc-dev] F-script may be worth a look

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

On Tuesday, November 26, 2002, at 12:28 AM, Peter Montagner wrote:

>
> On Tuesday, November 26, 2002, at 12:02 AM, Ronald Oussoren wrote:
>
>> On Monday, Nov 25, 2002, at 13:01 Europe/Amsterdam, Peter Montagner 
>> wrote:
>>
>>> On Monday, November 25, 2002, at 10:24 PM, Ronald Oussoren wrote:
>>>
>>>> That might be usefull for PyObjC as well. I have something like 
>>>> this on my private wishlist: I'd like to be able to write (system) 
>>>> prefpanes in Python.
>>>
>>> Interesting. Well, if you want to take a crack at it, F-Script 
>>> Anywhere uses libPatch to force itself into a running application. 
>>> libPatch seems to be a very hard to get bit of code. 
>>> http://www.phasic.com/~arwyn/libPatch-1.2.tgz
>>
>> Some time in the future I will probably try to write whatever is 
>> needed to get prefpanes to work. That is probably simular to what is 
>> needed to write plugins for programs that use Objective-C classes as 
>> plugins (e.g. which is basicly what the system preferences 
>> application is doing). I probably won't work on forcing this onto 
>> unwilling applications.
>>
>> Finding a way to automaticly execute a function when 'our' shared 
>> library is loaded will probably the most problematic part of this. 
>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>> 'initPyObjCExtension' in that library should run. I haven't looked 
>> into this yet and this may well be either trivial or impossible.
>
> Well, you could override +alloc on the Principal Class and when the 
> plugin is loaded you could do what ever is needed to do the python 
> stuff. I'm not sure how you are going to get a python interpreter into 
> a running third party app (ie, SysPrefs). One solution would be to use 
> Distributed Objects. The bundle loaded could launch a python 
> interpreter and start listening for a DO connection. The python 
> interpreter would then connect to the loaded bundle. When the 
> connection is made, the loaded module would return the DO proxy (from 
> the +alloc method). Returning from +alloc before a connection is made 
> would be pretty pointless. The Principal Class would never really 
> exist as an instance because a remote object would take its place.
>
> I haven't exactly thought this through but it seems possible. It is a 
> bit of a kludge but I don't see any other way to do it, especially 
> with Apple's non-embeddable python. It would be fun if someone killed 
> the python interpreter while System Preferences was still open! Also, 
> this method relies on DO working in PyObjC which it currently doesn't 
> seem to.

OK, I can answer my own question. This is basically impossible. You 
can't pass an NSView across an NSConnection and expect it to work in 
the new application. The reason is very obvious: It will try to do its 
GUI stuff locally instead of on the other side of the connection. This 
is entirely reasonable. Ignore the above message.

Peter

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Tuesday, November 26, 2002, at 01:24 AM, Ronald Oussoren wrote:

> On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... wrote:
>
>> Key challenge:   The classes that are subsequently subclassed by the 
>> loaded module must have instance variables that look/feel/act exactly 
>> like the iVars in the original parent class....
>
> That should be no problem, PyObjC can already to that. For me the key 
> challenge is finding a way to initialize an embedded python 
> interpreter and run a python script when the plugin bundle is loaded 
> (and for bonus points: Initialize exactly 1 interpreter, even when 
> loading more than 1 python-based plugin)

Will this work with Apple's python? Or are you planning on shipping a 
full python distro with the plugin? Otherwise it'd be a nice hack but 
it wouldn't be distributable.


>>> Finding a way to automaticly execute a function when 'our' shared 
>>> library is loaded will probably the most problematic part of this. 
>>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>>> 'initPyObjCExtension' in that library should run. I haven't looked 
>>> into this yet and this may well be either trivial or impossible.
>>
>> Assuming that the target application is ObjC, simply creating a 
>> +(void)load in a class/category within the dylib should be enough to 
>> cause a hunk of code to be executing that can call 
>> -initPyObjCExtension.   There is also a similar mechanism in the pure 
>> C++ world.
>
> I hadn't though of using a (dummy) class to do this. Thanks for the 
> tip.

There are problems with +(void)load. Namely, you can't guarantee the 
order of +(void)load methods, so you can't rely on any other classes. 
Well, certainly not those in the same bundle. This doesn't sound like a 
problem in this case but it is something to be wary of.

Peter

[Pyobjc-dev] bundlebuilder.py: standalone app support

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

Folks,

I've added support for building standalone apps to bundlebuilder.py. (I've
checked it in into the Python CVS tree, I'm sure someone will do a new import
into the pyobjc project, I'm going to bed now...)

I've tested it with Examples/CurrencyConverter and Examples/TableModel.

Requirement #1: it needs freeze's modulefinder.py to be on sys.path. (Work is in
progress to add it to the standard lib for 2.3, so maybe this is also a
candidate for the MPCompat directory.)

Requirement #2: a *static* build of Python. It currently does *not* work for
Python.framework. Making this work might not be trivial.

To build a standalone app:

  % python buildapp.py --standalone build

To strip all binaries from debugging info:

  % python buildapp.py --standalone --strip build

(This makes the app shrink to more than half the size.)

There are some additional options, check --help.

Just

[Pyobjc-dev] Quick summary of Perl bridges

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

On Monday, November 25, 2002, at 05:54 AM, Peter Montagner wrote:
> On another note, has anyone here looked at CamelBones? I'm not really 
> a Perl person but has anyone looked at how it does the Perl-ObjC 
> bridge? Could be interesting.

The author of CamelBones and I exchanged a few messages a bit ago.  
CamelBones doesn't currently do subclassing.   It hopefully will in the 
next version, but that won't be due out for a while.  The author sends 
his thanks-- he has been using the PyObjC module's source to solve some 
of the issues he has faces.

According to...

man PerlObjCBridge

... the PerlObjC bridge is bidirectional but does not yet support 
subclassing(?) ...

        Objective-C objects from Perl programs, allowing Cocoa
        objects in Apple Computer's Mac OS X to be directly manip-
        ulated from Perl. In addition, Perl objects can be mes-
        saged from Objective-C, making it possible for Perl
        objects to function as Cocoa delegates and as targets of
        notifications and other Cocoa call-back messages. Perl
        programs can take advantage of Cocoa's Distributed Objects
        mechanism to support messaging between Perl objects and
        Objective-C objects (or other Perl objects) in different
        address spaces, possibly on different machines.

It also uses the same name mangling as pyobjc.   Clearly, the author 
had some challenges in wrapping the NSProxy class [perfectly 
understandable] because the man page has a huge section on using the 
PerlObjC bridge with DO -- something that should "just work" once the 
bridge is working correctly.

This is interesting...

        When an Objective-C method declares a signed char or
        signed short argument, if a negative value is passed the
        actual value received by the method is coerced to an
        unsigned char or unsigned short, respectively. For exam-
        ple, if a method declares a signed char argument and -100
        is passed the actual value received by the method will be
        156. This is due to bug 2545453 in the Foundation frame-
        work.

... either the bug is fixed or our implementation doesn't suffer from 
it:

 >>> from Foundation import NSNumber
 >>> x = NSNumber.numberWithShort_(-100)
 >>> x
-100
 >>> x.intValue() + 2
-98

The PerlObjC bridge does not support all of the various #defines, 
typedef enums, and C Functions found in the Foundation or AppKit.  The 
author indicates that support is left to the developer.

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... wrote:
> In any case, embedding Python as an extension to existing applications 
> would require a build of Python other than Apple's.

Bill,
this sort of thing is exactly why I still moderately favor a framework 
Python over a static python. With framework Python, a plugin would be a 
couple of lines of C code (call Py_Initialize(), call one python 
function to set the rest up), and it would be linked against 
Python.framework. The other options (static Python, 
python-with-a-dylib) are much more cumbersome to get to work.
--
- 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 -

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Monday, Nov 25, 2002, at 14:37 Europe/Amsterdam, bb...@ma... wrote:

> On Monday, November 25, 2002, at 08:02 AM, Ronald Oussoren wrote:
>> Some time in the future I will probably try to write whatever is 
>> needed to get prefpanes to work. That is probably simular to what is 
>> needed to write plugins for programs that use Objective-C classes as 
>> plugins (e.g. which is basicly what the system preferences 
>> application is doing). I probably won't work on forcing this onto 
>> unwilling applications.
>
> I.e. implement an application that implements enough of the various 
> classes in Python that are required to make a loaded preferences panel 
> work in some place other than System Preferences?  Or create a plugin 
> type architecture for new apps?

The former, mostly because it would be a neat trick but adding a System 
Preference is IMHO better than adding lots of small applications when 
you want to write 'customize-some-unix-tool' applications.

>
> Key challenge:   The classes that are subsequently subclassed by the 
> loaded module must have instance variables that look/feel/act exactly 
> like the iVars in the original parent class....

That should be no problem, PyObjC can already to that. For me the key 
challenge is finding a way to initialize an embedded python interpreter 
and run a python script when the plugin bundle is loaded (and for bonus 
points: Initialize exactly 1 interpreter, even when loading more than 1 
python-based plugin)

>
>> Finding a way to automaticly execute a function when 'our' shared 
>> library is loaded will probably the most problematic part of this. 
>> That is: Whenever the 'pyobjcextension' shared libary is loaded 
>> 'initPyObjCExtension' in that library should run. I haven't looked 
>> into this yet and this may well be either trivial or impossible.
>
> Assuming that the target application is ObjC, simply creating a 
> +(void)load in a class/category within the dylib should be enough to 
> cause a hunk of code to be executing that can call 
> -initPyObjCExtension.   There is also a similar mechanism in the pure 
> C++ world.

I hadn't though of using a (dummy) class to do this. Thanks for the tip.

Ronald

Re: [Pyobjc-dev] Embedding

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

On Monday, November 25, 2002, at 07:01 AM, Peter Montagner wrote:
> There is also Unsanity's Application Enhancer: 
> http://www.unsanity.com/haxies/ape/

As much as some of Unsanity's Haxies are very cool, I would avoid using 
this as a mechanism for embedding the python interpreter.   APE has 
been a constant source-- directly and indirectly-- of system 
instability, app crashes, and other problems.  Mostly, this has been 
the result of module developers exercising various APIs incorrectly and 
not the fault of APE directly.

The end result is that APE is synonymous with the Extensions mechanism 
found in Mac OS 9 and prior.  They both provide a way to modify the 
system in just about anyway desired at the cost of stability and 
consistency of operation.

APE is a hell of a technical achievement, but has caused a boatload of 
problems within the user community.

b.bum

Re: [Pyobjc-dev] Embedding in Apps & Loading preferences Bundles

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

On Monday, November 25, 2002, at 08:02 AM, Ronald Oussoren wrote:
> Some time in the future I will probably try to write whatever is 
> needed to get prefpanes to work. That is probably simular to what is 
> needed to write plugins for programs that use Objective-C classes as 
> plugins (e.g. which is basicly what the system preferences application 
> is doing). I probably won't work on forcing this onto unwilling 
> applications.

I.e. implement an application that implements enough of the various 
classes in Python that are required to make a loaded preferences panel 
work in some place other than System Preferences?  Or create a plugin 
type architecture for new apps?

In the first case, Outside of it being an excellent test of the bridge, 
is the goal to provide the user with standalone prefs apps?   Neat idea.

Key challenge:   The classes that are subsequently subclassed by the 
loaded module must have instance variables that look/feel/act exactly 
like the iVars in the original parent class....

In the second case, there isn't really anything to do -- it already 
"just works" (and is analogous to what a couple of my apps are doing 
when they mixin ObjC code as frameworks within the app wrapper).   You 
will need to create ObjC headers that declare the classes that are 
defined in Python that will be subclassed in the bundle (mostly for the 
iVars, but also just to compile a subclass).  To compile the bundle 
will likely require an '-undefined suppress' option....

> Finding a way to automaticly execute a function when 'our' shared 
> library is loaded will probably the most problematic part of this. 
> That is: Whenever the 'pyobjcextension' shared libary is loaded 
> 'initPyObjCExtension' in that library should run. I haven't looked 
> into this yet and this may well be either trivial or impossible.

Assuming that the target application is ObjC, simply creating a 
+(void)load in a class/category within the dylib should be enough to 
cause a hunk of code to be executing that can call 
-initPyObjCExtension.   There is also a similar mechanism in the pure 
C++ world.

In any case, embedding Python as an extension to existing applications 
would require a build of Python other than Apple's.  Not really a big 
deal -- completely different situation than creating a standalone 
python App (though it would be nice to have an app extension that 
doesn't require a multi-MB download because it includes a python 
distribution).

b.bum

Re: [Pyobjc-dev] F-script may be worth a look

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

On Tuesday, November 26, 2002, at 12:02 AM, Ronald Oussoren wrote:

> On Monday, Nov 25, 2002, at 13:01 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>> On Monday, November 25, 2002, at 10:24 PM, Ronald Oussoren wrote:
>>
>>> That might be usefull for PyObjC as well. I have something like this 
>>> on my private wishlist: I'd like to be able to write (system) 
>>> prefpanes in Python.
>>
>> Interesting. Well, if you want to take a crack at it, F-Script 
>> Anywhere uses libPatch to force itself into a running application. 
>> libPatch seems to be a very hard to get bit of code. 
>> http://www.phasic.com/~arwyn/libPatch-1.2.tgz
>
> Some time in the future I will probably try to write whatever is 
> needed to get prefpanes to work. That is probably simular to what is 
> needed to write plugins for programs that use Objective-C classes as 
> plugins (e.g. which is basicly what the system preferences application 
> is doing). I probably won't work on forcing this onto unwilling 
> applications.
>
> Finding a way to automaticly execute a function when 'our' shared 
> library is loaded will probably the most problematic part of this. 
> That is: Whenever the 'pyobjcextension' shared libary is loaded 
> 'initPyObjCExtension' in that library should run. I haven't looked 
> into this yet and this may well be either trivial or impossible.

Well, you could override +alloc on the Principal Class and when the 
plugin is loaded you could do what ever is needed to do the python 
stuff. I'm not sure how you are going to get a python interpreter into 
a running third party app (ie, SysPrefs). One solution would be to use 
Distributed Objects. The bundle loaded could launch a python 
interpreter and start listening for a DO connection. The python 
interpreter would then connect to the loaded bundle. When the 
connection is made, the loaded module would return the DO proxy (from 
the +alloc method). Returning from +alloc before a connection is made 
would be pretty pointless. The Principal Class would never really exist 
as an instance because a remote object would take its place.

I haven't exactly thought this through but it seems possible. It is a 
bit of a kludge but I don't see any other way to do it, especially with 
Apple's non-embeddable python. It would be fun if someone killed the 
python interpreter while System Preferences was still open! Also, this 
method relies on DO working in PyObjC which it currently doesn't seem 
to.

Peter

Re: [Pyobjc-dev] F-script may be worth a look

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

On Monday, Nov 25, 2002, at 13:01 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Monday, November 25, 2002, at 10:24 PM, Ronald Oussoren wrote:
>>
>> That might be usefull for PyObjC as well. I have something like this 
>> on my private wishlist: I'd like to be able to write (system) 
>> prefpanes in Python.
>
> Interesting. Well, if you want to take a crack at it, F-Script 
> Anywhere uses libPatch to force itself into a running application. 
> libPatch seems to be a very hard to get bit of code. 
> http://www.phasic.com/~arwyn/libPatch-1.2.tgz

Some time in the future I will probably try to write whatever is needed 
to get prefpanes to work. That is probably simular to what is needed to 
write plugins for programs that use Objective-C classes as plugins 
(e.g. which is basicly what the system preferences application is 
doing). I probably won't work on forcing this onto unwilling 
applications.

Finding a way to automaticly execute a function when 'our' shared 
library is loaded will probably the most problematic part of this. That 
is: Whenever the 'pyobjcextension' shared libary is loaded 
'initPyObjCExtension' in that library should run. I haven't looked into 
this yet and this may well be either trivial or impossible.

Ronald

Re: [Pyobjc-dev] F-script may be worth a look

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

On Monday, November 25, 2002, at 10:24 PM, Ronald Oussoren wrote:

>
> On Monday, Nov 25, 2002, at 11:54 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>>
>> On Saturday, November 23, 2002, at 10:10 AM, Jack Jansen wrote:
>>
>>> I just had a quick look at F-Script (www.fscript.org). It's a 
>>> smalltalk lookalike that includes access to all of Cocoa, and it 
>>> comes with a class browser and such niceties.
>>
>> Yep. I haven't looked at it since Jaguar came out. There is an 
>> F-Script add-on called F-Script Anywhere that lets you load an 
>> F-Script interpreter into any running Cocoa application. This is 
>> useful for exploring a third party app to see what classes it is 
>> using. Anyway, that's kind of OT.
>
> That might be usefull for PyObjC as well. I have something like this 
> on my private wishlist: I'd like to be able to write (system) 
> prefpanes in Python.

Interesting. Well, if you want to take a crack at it, F-Script Anywhere 
uses libPatch to force itself into a running application. libPatch 
seems to be a very hard to get bit of code. 
http://www.phasic.com/~arwyn/libPatch-1.2.tgz

Note: This may be old and may not work on Jaguar. I haven't looked at 
it closely. Don't even know if the link still works.

There is also Unsanity's Application Enhancer: 
http://www.unsanity.com/haxies/ape/

Peter

Re: [Pyobjc-dev] F-script may be worth a look

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

On Monday, Nov 25, 2002, at 11:54 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Saturday, November 23, 2002, at 10:10 AM, Jack Jansen wrote:
>
>> I just had a quick look at F-Script (www.fscript.org). It's a 
>> smalltalk lookalike that includes access to all of Cocoa, and it 
>> comes with a class browser and such niceties.
>
> Yep. I haven't looked at it since Jaguar came out. There is an 
> F-Script add-on called F-Script Anywhere that lets you load an 
> F-Script interpreter into any running Cocoa application. This is 
> useful for exploring a third party app to see what classes it is 
> using. Anyway, that's kind of OT.

That might be usefull for PyObjC as well. I have something like this on 
my private wishlist: I'd like to be able to write (system) prefpanes in 
Python.

>
>
>> It comes with source, so there might be some ideas about solutions to 
>> problems we have(or have had in the past:-). Although: it may be that 
>> you can send messages from fscript to ObjC but not the other way. I 
>> haven't looked long enough to be sore.
>
[... interesting description of f-script removed)

Ronald

Re: [Pyobjc-dev] F-script may be worth a look

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

On Saturday, November 23, 2002, at 10:10 AM, Jack Jansen wrote:

> I just had a quick look at F-Script (www.fscript.org). It's a 
> smalltalk lookalike that includes access to all of Cocoa, and it comes 
> with a class browser and such niceties.

Yep. I haven't looked at it since Jaguar came out. There is an F-Script 
add-on called F-Script Anywhere that lets you load an F-Script 
interpreter into any running Cocoa application. This is useful for 
exploring a third party app to see what classes it is using. Anyway, 
that's kind of OT.


> It comes with source, so there might be some ideas about solutions to 
> problems we have(or have had in the past:-). Although: it may be that 
> you can send messages from fscript to ObjC but not the other way. I 
> haven't looked long enough to be sore.

It *does* work the other way but AFAIK you can't really create a new 
class in F-Script or subclass a Cocoa class. It has a mechanism called 
a block which lets you wrap up a bit of F-Script code in an object. 
This object (IIRC) responses to the value: selector. For example, you 
can create a block and set it as the target of an NSButton and set the 
action to the selector #value. This works but it is nowhere near as 
elegant or as powerful as what PyObjC can currently do. It may still be 
interesting to look at because there is a lot of common ground and, as 
Jack mentioned, it is open source.

On another note, has anyone here looked at CamelBones? I'm not really a 
Perl person but has anyone looked at how it does the Perl-ObjC bridge? 
Could be interesting.

Peter

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On Saturday, Nov 23, 2002, at 18:34 Europe/Amsterdam, Jack Jansen wrote:

>
> On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum 
> wrote:
>> Speaking of bundlebuilder and plistlib: I saw that Ronald checked 
>> them in into
>> the pyobjc project, which made me wonder whether repository symlinks 
>> are
>> possible across sf projects. Shall I just open a support request and 
>> ask?
>
> I think it would be a major can of worms. I think I would designate 
> one as the main copy, and use "cvs import" in the other tree.

I completely forgot about 'cvs import'. The version in the Python tree 
should be leading and it was my intention to copy that once in a while.

Ronald

[Pyobjc-dev] More changes to main.m / __main__.py

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

I moved the autoloading framework bootstrap to __init__.py in 
Foundation -- it doesn't do anything unless the PYOBJCFRAMEWORKS 
environment variable is defined.   That variable is now defined by the 
main.m in the Web Services Tool example.   I also fixed a couple of 
bugs in the handling of PYTHONPATH.

This reduces the __main__.py to just the lines to import the various 
modules, define the classes necessary to start the app, and invoke 
NSApplicationMain().

b.bum

[Pyobjc-dev] Integrated main.m and cleaned up Web Services Tool example

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

Ronald [et.al.],

     I cleaned up the Web Services Tool example, including cleaning up 
the main file and integrating your [Ronald's] changes to support 
PYTHONPATH.    The main file in Web Services Tool will migrate to the 
project templates and should be used for all of the other examples that 
use a compiled main.

     Please review the code -- I think it is correct [gdb indicates that 
it is], but I had to restructure a bunch of stuff and fix a few bugs in 
the PYTHONPATH code.

     thanks -- gotta run -- will try to do more later today,

     b.bum

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

Jack Jansen wrote:

> On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum 
> wrote:
> > Go right ahead, but I don't care one single bit for 10.1, so I
> > think it's a waste of time (although it would probably be faster to
> > do it with /usr/bin/sh.
> 
> Forgot to reply to this bit. What makes 10.1.5 interesting is that it's 
> the last release that runs on 603 and 604 hardware, 10.2 is G3/G4-only. 

The only person I know that runs 10.1.5 for that reason (on an old 8500) uses it
as a headless server. The only app on that machine that matters is Apache... I
don't think this an interesting platform for (standalone) Python/PyObjC GUI apps
at *all*.

> And I haven't seen any numbers yet on how many people are sticking with 
> 10.1 because of the price of the upgrade...

On the other hand: Python is free ;-)

I'm not suggesting we should always demand the latest version (not at all) but
I'm all for taking full advantage of the fact that 10.2 ships with Python. I'm
convinced it will save us a lot of time.

> > Speaking of bundlebuilder and plistlib: I saw that Ronald checked
> > them in into the pyobjc project, which made me wonder whether
> > repository symlinks are possible across sf projects. Shall I just
> > open a support request and ask?
> 
> I think it would be a major can of worms. I think I would designate
> one as the main copy, and use "cvs import" in the other tree.

And manually update everytime the main copy has been upgraded? I'm not looking
forward to do _two_ checkins for each change to each of these files. Why would
it be a can of worms? I maintain those modules, and it's my excplicit goal to
stay compatible with Python 2.2.

Just

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum 
wrote:
> Go right ahead, but I don't care one single bit for 10.1, so I think 
> it's a
> waste of time (although it would probably be faster to do it with 
> /usr/bin/sh.

Forgot to reply to this bit. What makes 10.1.5 interesting is that it's 
the last release that runs on 603 and 604 hardware, 10.2 is G3/G4-only. 
And I haven't seen any numbers yet on how many people are sticking with 
10.1 because of the price of the upgrade...
--
- 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 -

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On zaterdag, nov 23, 2002, at 14:47 Europe/Amsterdam, Just van Rossum 
wrote:
> Speaking of bundlebuilder and plistlib: I saw that Ronald checked them 
> in into
> the pyobjc project, which made me wonder whether repository symlinks 
> are
> possible across sf projects. Shall I just open a support request and 
> ask?

I think it would be a major can of worms. I think I would designate one 
as the main copy, and use "cvs import" in the other tree.
--
- 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 -

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

Jack Jansen wrote:

> Hmm, there is something to be said for that too, as it'll work 
> pre-jaguar too. So now we have three stubs: one in Python, one in ObjC, 
> one in sh (although I would use /bin/sh, bash wasn't available on 
> 10.1), and each one has a specific advantage.

Go right ahead, but I don't care one single bit for 10.1, so I think it's a
waste of time (although it would probably be faster to do it with /usr/bin/sh.
We're targeting developers mostly, and by the time Python 2.3 and a new PyObjC
get decent exposure, supporting 10.1 will be even less of an issue.

But: I'm about to embarge on a major refactoring of bundlebuilder.py: I'll try
to make it possible to use different templates.

Speaking of bundlebuilder and plistlib: I saw that Ronald checked them in into
the pyobjc project, which made me wonder whether repository symlinks are
possible across sf projects. Shall I just open a support request and ask?

Just

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On zaterdag, nov 23, 2002, at 07:07 Europe/Amsterdam, Ronald Oussoren 
wrote:

>> What we would need is a standard unix tool that we can give 1 
>> argument and that would execute a mangled version of argv[0]. I don't 
>> think such a tool exists:-)
>
> sh?

Hmm, there is something to be said for that too, as it'll work 
pre-jaguar too. So now we have three stubs: one in Python, one in ObjC, 
one in sh (although I would use /bin/sh, bash wasn't available on 
10.1), and each one has a specific advantage.

How about using the Python stub as the default, but make it easy to use 
the other stubs, and in the documentation explain about that?

[Incidentally, what I was originally really after was a #! line that 
would immediately execute the *correct* python, so we wouldn't need the 
execve(). This, I think, is impossible in the general case. But the 
execve() doesn't seem to be such a big deal anyway on current hardware].
--
- 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 -

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On Saturday, Nov 23, 2002, at 00:10 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren
>> wrote:
>>> Sounds good, but how are you going to deal with moving the .app 
>>> bundle
>>> when not using /usr/bin/python? '#!../Resources/python-interpreter'
>>> probably won't work.
>>
>> Don't even bother trying it: I did, and it doesn't:-)
>>
>> What we would need is a standard unix tool that we can give 1 argument
>> and that would execute a mangled version of argv[0]. I don't think 
>> such
>> a tool exists:-)
>
> What are you guys on about? The execve wrapper is run as 
> #!/usr/bin/env python
> (which will usually be /usr/bin/python) and the rest is taken from 
> there. Am I
> missing something?

MacOSX 10.1 isn't shipped with a python interpreter. Not that this 
should keep us from using a python-based main by default.

Ronald

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On Friday, Nov 22, 2002, at 23:49 Europe/Amsterdam, Jack Jansen wrote:

>
> On vrijdag, nov 22, 2002, at 22:05 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> Sounds good, but how are you going to deal with moving the .app 
>> bundle when not using /usr/bin/python? 
>> '#!../Resources/python-interpreter' probably won't work.
>
> Don't even bother trying it: I did, and it doesn't:-)
>
> What we would need is a standard unix tool that we can give 1 argument 
> and that would execute a mangled version of argv[0]. I don't think 
> such a tool exists:-)

sh?

#!/bin/bash

res=$(dirname $(dirname ${0}))/Resources
main=${res}/main.py
export PYTHONPATH
PYTHONPATH=$res

exec /usr/local/bin/python ${main}
# end of file

The above code is completely untested and doesn't like whitespace in 
argv[0].

Ronald

> --
> - 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 -
>
>

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Examples/TableModel2 main.m,1.4,1.5

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

On Friday, November 22, 2002, at 06:08 PM, Just van Rossum wrote:
> But you haven't answered our (Jack and me) question how that is even 
> relevant if
> you wipe the process away with execve()? Or did you, and I missed it? 
> Sorry if
> that's the case, but I still don't understand a word of what you're 
> saying...

I did and you missed it.  :-)

It is in that long winded message that I posted a few days ago...

b.bum