pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Enums on 10.2

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

On Friday, Sep 27, 2002, at 16:56 Europe/Amsterdam, bb...@fr... 
wrote:

> The various autogenned files in the Cocoa module were done against the 
> 10.1 headers.
>
> Is there any reason not to regenerate the files for 10.2?
The most important reason for them being agains 10.1 is that I 
completely forgot to update them. There is one problem with updating 
them: The resulting files will not compile on 10.1 (for obvious 
reasons).

>
> (I ask because I need access to the enumerated types for 
> NSProgressIndicator -- some of which are new to 10.2).
>
> BTW:  Running the enum generator script against NSOpenGL.h picks up 
> defines for "if" and "endif" -- that would likely not make things work 
> well.
An enum with an embedded #define, I'm not surprised this doesn't do 
what you want.

The generator scripts are quick hacks to avoid creating the mappings 
manually. I've started on a slightly cleaner version, but haven't made 
a lot of progress with that. It only extracts enum values at the 
moment, and suffers from the same bug as the current version of the 
script.

Ronald

[Pyobjc-dev] if/endif in #defines

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

The current enum_generator.py was leaking an "if", if into the 
resulting output in this case:

typedef enum {
         NSOpenGLCPSwapRectangle       = 200,    /* Set or get the swap 
rectangle {x, y, w, h}       */
         NSOpenGLCPSwapRectangleEnable = 201,    /* Enable or disable 
the swap rectangle             */
         NSOpenGLCPRasterizationEnable = 221,    /* Enable or disable 
all rasterization              */
         NSOpenGLCPSwapInterval        = 222,    /* 0 -> Don't sync, n 
-> Sync every n retrace       */
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_2
         NSOpenGLCPSurfaceOrder        = 235,    /* 1 -> Above Window 
(default), -1 -> Below Window  */
         NSOpenGLCPSurfaceOpacity      = 236,    /* 1-> Surface is 
opaque (default), 0 -> non-opaque */
#endif
         NSOpenGLCPStateValidation     = 301     /* Validate state for 
multi-screen functionality    */
} NSOpenGLContextParameter;

I committed an extremely bogus patch to fix this problem.

b.bum

[Pyobjc-dev] Enums on 10.2

[<bb...@fr...>]

The various autogenned files in the Cocoa module were done against the 
10.1 headers.

Is there any reason not to regenerate the files for 10.2?

(I ask because I need access to the enumerated types for 
NSProgressIndicator -- some of which are new to 10.2).

BTW:  Running the enum generator script against NSOpenGL.h picks up 
defines for "if" and "endif" -- that would likely not make things work 
well.

I'm currently writing a small app for interrogating XML-RPC servers.  
It uses NSWindowController and implements a ToolBar.   This should test 
PyObjC fairly well in that there is lots of weird delegation and 
symbolic references floating around.    It also happens to be a very 
useful app for XML-RPC developers...

thanks!
b.bum

[Pyobjc-dev] TableModel2 comitted

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

I "ported" Ronald's TableModel into a Project Builder project.   It is 
committed into the repository under Examples/TableModel2 (original 
name, huh?).

The conversion is fairly straightforward -- the key is in the 
implementation of the main function.  Outside of the four or five steps 
necessary to configure the project, everything else should "just work" 
as it would in a normal Cocoa application.

I also discovered that the Python that Apple distributes in incomplete 
-- it lacks a library (static or dynamic) to link against.  
Unfortunately, this means that you have to have some alternative 
distribution of python installed -- Fink's works nicely and I'm sure 
the framework build of Python will work equally as well (actually -- 
the one advantage of the Framework build is the integration with 
Project Builder when compensating for Apple's incomplete distribution 
of Python).

Bummer on that -- appropriate bugs have been reported.

If you miss readline support from Apple's distribution of Python (not 
an oversight on Apple's part, but due to the non-free nature of the 
GPL), I hacked together a setup.py that can build/install the readline 
module into Apple's python distribution:

	http://radio.weblogs.com/0100490/2002/09/25.html#a283

b.bum

Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

On Wednesday, September 25, 2002, at 01:51 PM, Ronald Oussoren wrote:
> On Tuesday, Sep 24, 2002, at 19:48 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> In all, it solves a different problem than the problem presented by 
>> the goal of creating standalone fully Cocoa compliant applications.  
>> Namely, PythonLauncher is much more about invoking a particular 
>> script and much less about distributing a standalone ".app" that a 
>> user can simply double-click to use.
>
> Could you please rename your PythonLauncher, two applications with the 
> same name is pretty confusing. To illustrate this: The 
> 'PythonLauncher' you mention above is probably Jack's version, not 
> yours but I'm not entirely sure...

Oh, I suppose -- I mean, my PythonLauncher was actually a quickie hack 
posted to python-mac to answer some questions about how to write a 
PythonLauncher type thing.  I even cc'd Jack on the original...

But, he beat me into the repository, so the name is his. :-)

The above referred to Jack's app.

(In all seriousness, yes-- the name should and will be changed if I get 
around to writing a replacement for the existing [Jack's] 
PythonLauncher).

> Just to make things clear: Is your PythonLauncher meant to be a binary 
> that can be dropped in a '.app' directory to create a python-based 
> application?

Nope -- that is a completely different app/problem.   More info later 
today.

>>> BTW. I'd prefer to have a framework install of python as the 
>>> standard python sometime in the future. Maybe in MacOSX 10.4........
>>
>> I would rather see Python remain as open and cross platform 
>> compatible as possible.  In that context, a framework (or bundle) 
>> might be an appropriate means of encapsulating resources specific to 
>> the Macintosh extension modules.  I.e. the mac specific (OS X, 
>> really) resources would be shoved into PyMac.framework down in 
>> site-packages (assuming the macintosh support were to remain as a 
>> module).
>>
>>   However, encapsulating all of python into a framework doesn't 
>> really add anything to the environment in terms of features and 
>> definitely makes for a weird twist when using the Mac platform.
>
> This is probably something that should be discussed on the 
> Python-on-Mac SIG, but what the heck...

We can go there once we have hashed through it a bit here...

> I definitely do not like a partial framework (the unix install 
> containing a PyMac.framework for Mac specific stuff). That would be 
> both confusing and reduce cross-platform compatibility (e.g. how 
> should distutils cope with that?).
>
> Like you said, the framework install doesn't really add new features. 
> However, I also feel that it doesn't hamper cross-platform 
> compatibility and openess. If you replace /usr/bin/python by a symlink 
> to the python inside a framework install the resulting situation is 
> completely compatible with the current situation.

If it doesn't add any features, then why add all of the 
administrative/maintenance overhead to the core python project that is 
necessary to support it?

Looking at the piles and piles of patches required in configure, the 
various makefiles, and an entire subdirectory full of gunk that is 
special cased into the framework build, it seems that the framework 
build is already hampering cross-platform compatibility in that it 
requires so much extra effort to make python work on the Mac platform 
[assuming a framework build is a part of supporting the Mac platform].

Anything that unnecessarily makes the Macintosh support behave 
differently than, say, bsd/sun/linux hampers cross platform 
compatibility.

>
> The reasons I like the framework approach are twofold. First of all 
> frameworks are the method Apple is pushing for publishing library-type 
> stuff (and I like to think of the python interpreter as a complicated 
> type of dynamic loader :-)). But more importantly, a framework install 
> makes it more clear that Python is not just tool for 'unix weenies' 
> but something you can use for real work.

Apple pushes framework based encapsulation of things that are libraries 
for reusable code specific to the platform, not for reusable/libary 
code that is made available across many platforms.   Looking at the 
system (and Darwin), the only exception is the readline framework.

Looking /usr/lib/ reveals that Apple is very much pushing for a build 
model for portable code -- libz, termcap, ruby, perl, python, tcl, 
crypto, pthreads, etc... -- that requires as few changes as possible 
between OS X/Darwin and any other Unix derived platform.

IMO, this is a wise decision -- it reduces the amount of maintenance 
necessary on the part of Apple and third party developers to achieve 
continued first class support for these tools on the platform.

Whether Python is in a framework or as a regular "command line" tool 
will do little to attract or deter non "unix weenies" from using it.   
We will be able to attract many more developers by supporting and 
providing examples for doing Python development in PBX using the 
out-of-the-box python on OS X.

Certainly, having a Python IDE and the ability to run individual 
scripts from, say, the Finder will help, but having to 
rebuild/reinstall Python to gain access to that capability will deter 
many.   Given the rather crufty implementation of said solutions-- 
Carbon is legacy and at a completely different granularity than Python 
or Cooca-- quite a few more developers will be deterred.

>
> BTW. I'm a Unix weenie myself and most (Python) code I write at the 
> moment has to do with either command-line scripts or webbased stuff. 
> The framework install of Python I have at my machine is perfectly 
> useable for this.

Perfectly usable, yes, but it adds a boatload of additional maintenance 
cost and installation headache to the core python codebase.  The 
framework based build of Python has existed since the NeXT days along 
with a number of unnecessary, platform specific, modifications to the 
core codebase to support NeXT and it has been a constant source of 
headaches.   The end result is that the version of Python on NeXT and, 
now, OS X has typically lagged behind the version available on other-- 
more mainstream-- platforms by anywhere from days to months.

Certainly, OS X's popularity will reduce that gap, but why have a gap 
if it can be avoided entirely and comfortably?

Furthermore, the chances of Apple shipping a framework build of python 
as a part of the system are pretty slim as the framework build of 
python doesn't add much to the capabilities of the language and incurs 
a bunch of additional maintenance/support headaches for Apple (i.e. do 
they have to ship a separate version for, say, Darwin??).

Not that Carbon support in Python does not require the framework build 
-- it is just the extended Mac Python IDE / Dev environment that 
requires the framework (mostly because the build of it is currently 
quite broken).

>
> Back to making Python the best development tool on MacOS X,
>
> 	Ronald
>
> P.S. Don't let this keep you from improving PyObjC for users of the 
> Apple-distributed Python ;-) ;-)

I think of Python + Cocoa via PyObjC as being at the same level as, 
say, AppleScript Studio.   Python provides the high level, easy to 
author, development language similar to AppleScript (though easier) 
while PyObjC provides the glue into the Cocoa frameworks.   Frankly, 
given the comparative cleanliness with which Python interacts with ObjC 
across the PyObjC bridge, the Python solution is a hell of a lot 
simpler and easier to deal with than AppleScript Studio -- not a 
criticism of Studio, just the realities of building AppleScript based 
development tools.

The proof is in the code -- I'm going to stop blathering now and 
actually put together a proper / easy recipe for creating Python based 
Cocoa apps and commit that into the repository...

b.bum

Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

On Tuesday, Sep 24, 2002, at 19:48 Europe/Amsterdam, Bill Bumgarner 
wrote:

>
> In all, it solves a different problem than the problem presented by 
> the goal of creating standalone fully Cocoa compliant applications.  
> Namely, PythonLauncher is much more about invoking a particular script 
> and much less about distributing a standalone ".app" that a user can 
> simply double-click to use.

Could you please rename your PythonLauncher, two applications with the 
same name is pretty confusing. To illustrate this: The 'PythonLauncher' 
you mention above is probably Jack's version, not yours but I'm not 
entirely sure...

Just to make things clear: Is your PythonLauncher meant to be a binary 
that can be dropped in a '.app' directory to create a python-based 
application?
>
>>
>>>
>>> It also requires a framework build of python.  This is completely 
>>> unnecessary and incurs an arbitrary limitation [user has to have 
>>> Python.framework around as opposed to using the standard 
>>> out-of-the-box Python included with 10.2].
>>
>> Is the framework really necessary or is it only required because of 
>> the current build procedure?
>
> The framework isn't necessary at all.   Everything pyobjc related 
> works fine with the "out of the box" install included with OS X 10.2.

I was refering to your remark about (Jack's) PythonLauncher requiring a 
framework python, but given the completely different goals of yours and 
Jack's PythonLauncher that is not really relevant.

>
>>
>> BTW. I'd prefer to have a framework install of python as the standard 
>> python sometime in the future. Maybe in MacOSX 10.4........
>
> I would rather see Python remain as open and cross platform compatible 
> as possible.  In that context, a framework (or bundle) might be an 
> appropriate means of encapsulating resources specific to the Macintosh 
> extension modules.  I.e. the mac specific (OS X, really) resources 
> would be shoved into PyMac.framework down in site-packages (assuming 
> the macintosh support were to remain as a module).
>
>   However, encapsulating all of python into a framework doesn't really 
> add anything to the environment in terms of features and definitely 
> makes for a weird twist when using the Mac platform.

This is probably something that should be discussed on the 
Python-on-Mac SIG, but what the heck...

I definitely do not like a partial framework (the unix install 
containing a PyMac.framework for Mac specific stuff). That would be 
both confusing and reduce cross-platform compatibility (e.g. how should 
distutils cope with that?).

Like you said, the framework install doesn't really add new features. 
However, I also feel that it doesn't hamper cross-platform 
compatibility and openess. If you replace /usr/bin/python by a symlink 
to the python inside a framework install the resulting situation is 
completely compatible with the current situation.

The reasons I like the framework approach are twofold. First of all 
frameworks are the method Apple is pushing for publishing library-type 
stuff (and I like to think of the python interpreter as a complicated 
type of dynamic loader :-)). But more importantly, a framework install 
makes it more clear that Python is not just tool for 'unix weenies' but 
something you can use for real work.

BTW. I'm a Unix weenie myself and most (Python) code I write at the 
moment has to do with either command-line scripts or webbased stuff. 
The framework install of Python I have at my machine is perfectly 
useable for this.

Back to making Python the best development tool on MacOS X,

	Ronald

P.S. Don't let this keep you from improving PyObjC for users of the 
Apple-distributed Python ;-) ;-)

[Pyobjc-dev] Functions in the Objective-C method table

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

The major problem I see with the current version of PyObjC is the 
(large) list of functions that are used in the method dispatch tables 
in Objective-C classes (the file 'Modules/objc/register.m'). Using a 
static list makes the compile-time of PyObjC too long and makes it 
necessary to add C module when you want to override methods whose 
signature is not in the table.

I'd like to find (and implement) a solution for this. But let me start 
with an in-depth description of the problem.

Objective-C classes are basicly structs with a number of fields. One of 
those fields is a pointer to the super-class and another is a list of 
method descriptors, and each descriptor contains the method name, 
signature and a pointer to its implementation.

If you subclass an Objective-C class from python and override and 
existing method (like 'init') it is necessary to add a method 
descriptor for the python method to the method list of the Objective-C 
end of your subclass. If we do not add such a descriptor the method 
resulotion code will find the descriptor in the superclass, which 
defeats our purpose. The method descriptor is not necessary for 
entirely new methods, because calls to those methods can be routed 
through 'forwardMethodInvocation'.

In the current code the method implementation for the method 
descriptors are generated at compile-time, resulting in a large file: 
1.6MByte, 56K lines.

Only halve of that file contains the functions for the method 
descriptors, the other halve contains functions that are used to call 
the super-class implementation of a method from the new version of the 
method (e.g. these are used to implement 'super(MyClass, 
self).init()'). These functions are necessary because there is no 
'NSInvocation' like interface for performing this task (neither as a 
neatly packaged class nor in the objective-C runtime). The only way to 
call a superclass implementation is through 'objc_msgSendSuper' in the 
objective-C runtime.

I've been looking at libffi (homepage at http://sources.redhat.com, the 
most recent implementation is in the GCC CVS repository). From what 
I've seen it should be possible to use this library to:
1) Generate the functions for use in method descriptors at runtime
2) Write an 'NSInvocation' work-alike for calls to the superclass 
implementation

As an added bonus, using libffi would make it possible to implement 
item 2 and 'execute_and_pythonify_method' in 1 function, thereby 
reducing the amount of code.

And now on my questions...

* Am I seeing ghosts or is register.m (and the python script generating 
it) as problemetic as I think it is?

* Does any of you have experience with libffi, and if so could it do 
what I describe?

* Are their alternatives to useing a library like libffi?

* And last but not least, how are your opinions regarding the use of 
external libraries (e.g. libffi)?

Ronald

[Pyobjc-dev] PyCocoa in PBX success!!

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

I was able to create a standalone Project Builder project that contains 
the TableModel example.  It works exactly as any other Cocoa 
project/application and editing Python in ProjectBuilder is not 
horrendously painful -- not quite like emacs, but not too bad either.

Generalized solution will be committed later today/tomorrow along w/a 
more thorough description....

b.bum

Re: [Pyobjc-dev] 2.2.x / non-framework build update

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

On Tuesday, September 24, 2002, at 12:23 PM, Ronald Oussoren wrote:
> On Tuesday, Sep 24, 2002, at 16:30 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> I just did a bit of an experiment and was successfully able to run 
>> the TableModel example against Python 2.2.1 using the standard system 
>> supplied version of Python.
>>
> That's great. Did you have to change much in the pyobjc code?

No changes required -- it was just a matter of hacking together the 
.app wrapper in the appropriate structure.

BTW:  I committed the changes to setup.py to allow pyobjc to build with 
Python 2.2.x against a non-framework build.  From here, it should be 
trivial to cut a release that can be built from a fink package -- it's 
on the todo list. :-)   If anyone wants to update the sourceforge pages 
and figure out how to cut a release, it would be most welcome.

PBX integration: I think the problem is a lot easier to solve than I 
initially thought, but I also know how dangerous that particular line 
of thinking is... I'll beat on it on the train this evening.

Also, I think we should move the subclass-branch to the trunk.   It is 
so far beyond the trunk at this point that I can't imagine development 
continuing on the trunk.

b.bum

Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

On Tuesday, September 24, 2002, at 12:32 PM, Ronald Oussoren wrote:
> On Monday, Sep 23, 2002, at 19:13 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>
>> I'll have to revisit Jack's PythonLauncher when I have more time-- it 
>> has some serious issues/bugs.
>
> Such as? IMHO it would be better not to fork python, the situation is 
> hazy enough. I'd like to see a python-based PythonLauncher in the 
> future, but that is a completely different story.

In general, the application appears to have been created by someone who 
doesn't have an understanding of how to leverage the Cocoa APIs in a 
pattern that is consistent with the API's design.  This is not a 
criticism of Jack -- he is obviously a brilliant developer.   The 
application could use to be rewritten.

Also, the application uses the system() call to pass control into the 
Python interpreter.  This effectively leaves the PythonLauncher as the 
parent process of the underlying "real" application.

In all, it solves a different problem than the problem presented by the 
goal of creating standalone fully Cocoa compliant applications.  
Namely, PythonLauncher is much more about invoking a particular script 
and much less about distributing a standalone ".app" that a user can 
simply double-click to use.

I'm going to focus on solving the specific problems related to 
standalone Py-Cocoa based applications first, then revisit 
PythonLauncher.

>
>>
>> It also requires a framework build of python.  This is completely 
>> unnecessary and incurs an arbitrary limitation [user has to have 
>> Python.framework around as opposed to using the standard 
>> out-of-the-box Python included with 10.2].
>
> Is the framework really necessary or is it only required because of 
> the current build procedure?

The framework isn't necessary at all.   Everything pyobjc related works 
fine with the "out of the box" install included with OS X 10.2.

>
> BTW. I'd prefer to have a framework install of python as the standard 
> python sometime in the future. Maybe in MacOSX 10.4........

I would rather see Python remain as open and cross platform compatible 
as possible.  In that context, a framework (or bundle) might be an 
appropriate means of encapsulating resources specific to the Macintosh 
extension modules.  I.e. the mac specific (OS X, really) resources 
would be shoved into PyMac.framework down in site-packages (assuming 
the macintosh support were to remain as a module).

   However, encapsulating all of python into a framework doesn't really 
add anything to the environment in terms of features and definitely 
makes for a weird twist when using the Mac platform.

b.bum

Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

On Monday, Sep 23, 2002, at 19:13 Europe/Amsterdam, Bill Bumgarner 
wrote:

> I'll have to revisit Jack's PythonLauncher when I have more time-- it 
> has some serious issues/bugs.

Such as? IMHO it would be better not to fork python, the situation is 
hazy enough. I'd like to see a python-based PythonLauncher in the 
future, but that is a completely different story.

>
> It also requires a framework build of python.  This is completely 
> unnecessary and incurs an arbitrary limitation [user has to have 
> Python.framework around as opposed to using the standard 
> out-of-the-box Python included with 10.2].

Is the framework really necessary or is it only required because of the 
current build procedure?

BTW. I'd prefer to have a framework install of python as the standard 
python sometime in the future. Maybe in MacOSX 10.4........

Ronald

Re: [Pyobjc-dev] 2.2.x / non-framework build update

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

On Tuesday, Sep 24, 2002, at 16:30 Europe/Amsterdam, Bill Bumgarner 
wrote:

>
> I just did a bit of an experiment and was successfully able to run the 
> TableModel example against Python 2.2.1 using the standard system 
> supplied version of Python.
>
That's great. Did you have to change much in the pyobjc code?
>
> I am going to invest some time into putting together a template 
> Py-Cocoa project that uses a standard distutils style build formula to 
> build a working, standalone, Cocoa application without requiring 
> anything but the pyobjc module and the standard Python 2.2 that ships 
> with OS X.

If you find time to implement this I'm all for replacing the build 
script I wrote, as you said I'm depending on some legacy code that 
should not be necessary.

>
> There are three primary challenges:
>
> 	- generating an appropriately configured plist.  This is trivial, 
> really.
Not entirely trivial but close enough... I'd either like to see 
integration with PB or a standalone tool for editing the plist file. 
Plist files for document based applications are pretty simple, but I 
don't like to edit the XML by hand.

>
> 	- putting something together that can be easily managed through 
> project builder.   I can't think of anything hard here.
;-) that was what I thought when I started on my PyObjC updates ...
> 	
> 	- building a tiny bootstrap binary that can be stuck in the .app 
> wrapper and be used to bootstrap the python interpreter with the 
> appropriate script & arguments within the app wrapper.  This is 
> actually pretty trivial, as well.
Wouldn't the python binary in MacPython (aka the framework install) be 
usefull here? Please try to build something that allows access to the 
Carbon API's

Ronald

[Pyobjc-dev] 2.2.x / non-framework build update

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

I just did a bit of an experiment and was successfully able to run the 
TableModel example against Python 2.2.1 using the standard system 
supplied version of Python.

I had to build the application wrapper by hand as the 
objc/buildtools.py script depends on functionality that is only a part 
of the Framework build of python.   Digging deeply into said 
functionality, most of it is centric to supporting resource forks and 
legacy mac issues which are not relevant to Cocoa development.

Everything else worked as expected.

I am going to invest some time into putting together a template 
Py-Cocoa project that uses a standard distutils style build formula to 
build a working, standalone, Cocoa application without requiring 
anything but the pyobjc module and the standard Python 2.2 that ships 
with OS X.

Everything is there... just a matter of putting the right bits in the 
right place.

There are three primary challenges:

	- generating an appropriately configured plist.  This is trivial, 
really.

	- putting something together that can be easily managed through 
project builder.   I can't think of anything hard here.
	
	- building a tiny bootstrap binary that can be stuck in the .app 
wrapper and be used to bootstrap the python interpreter with the 
appropriate script & arguments within the app wrapper.  This is 
actually pretty trivial, as well.

So -- nothing left to do but toss some code at the problem. :-)

b.bum

Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

I'll have to revisit Jack's PythonLauncher when I have more time-- it 
has some serious issues/bugs.

It also requires a framework build of python.  This is completely 
unnecessary and incurs an arbitrary limitation [user has to have 
Python.framework around as opposed to using the standard out-of-the-box 
Python included with 10.2].

b.bum

On Monday, September 23, 2002, at 12:48 PM, Tony Lownds wrote:

>> Also -- I believe that we can make standalone scripts work fine even 
>> if they launch UI sessions.  I built a little app called 
>> PythonLauncher that can be used to springboard the launching of a 
>> script that uses the UI.  It provides a full blown "bundle" 
>> environment, as required by the X environment, but allows multiple 
>> copies to be launched.  I'll have to hack on it...
>
> Jack Jansen has made a little app called PythonLauncher as well, see 
> the Python CVS...
>
> -Tony

[Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

I committed changes that allow pyobjc to build with non-framework 
installs and to build against Python 2.2.1 (the latest version 
available via Fink).

It works fine;  the most intrusive change was the presence of PyBool -- 
a new type as of 2.3.   I changed PyBool_Check to a non-operation and 
changed PyBool_FromLong() to be PyInt_FromLong().   This should be 
relatively equivalent at runtime.

The ObjC interface seems to work fine, but the Cocoa based stuff is 
broken -- I'm not sure if this is related to 2.2, to non-Framework 
builds, or just the state of the current development.

In any case -- Ronald, I must extend a HUGE note of gratitude for all 
of your work on this.  It is excellent!!!

Also -- I believe that we can make standalone scripts work fine even if 
they launch UI sessions.  I built a little app called PythonLauncher 
that can be used to springboard the launching of a script that uses the 
UI.  It provides a full blown "bundle" environment, as required by the 
X environment, but allows multiple copies to be launched.  I'll have to 
hack on it....

Comment:   Foundation should not really be a part of Cocoa.  I.e. I 
should be able to do "from Foundation import NSString" -- not "from 
Cocoa.Foundation import NSString".   There are platforms upon which 
Foundation exists, but Cocoa might not -- this is especially true as 
support for GnuStep is reintroduced (or, likely, rewritten).

b.bum

Re: [Pyobjc-dev] PyObjC & Fink

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

>
> BTW: The fix you [Ronald] mentioned for compiling pyobjc w/Python 2.2 
> worked except that it seems the precompiler has gone into an infinite 
> loop while compiling-- it has been using 70% of the CPU for over 10 
> minutes!
>
> gcc -DNDEBUG -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.2 -c 
> Modules/objc/register.m -o 
> build/temp.darwin-6.1-PowerMacintosh-2.2/register.o -g -O0 
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
>
> Maybe I'll let it run -- that is one BIG file...   maybe I need to 
> regenerate it for 2.2 vs. 2.3??
>
It is not the precompiler, it is the compiler itself. The source file 
is way too big, I've replaced it with a smaller version in my last 
checkin. The file contains a lot of functions that can be used in the 
method table of an Objective-C class and the forward the call to python.

I hope to find a better way to do this in the future, maybe using 
libffi.

Ronald

Re: [Pyobjc-dev] PyObjC & Fink

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

On Monday, Sep 23, 2002, at 16:52 Europe/Amsterdam, Bill Bumgarner 
wrote:
> I'll whip up a Fink package that install python 2.3 alpha and work 
> with that... not a problem and likely easier than trying to backport.
You might want to do a 'cvs update' of PyObjC before you start hacking. 
I've just checked in a number of changes, including a fix for the 
memory leak I mentioned before (I've stared at the buggy part of the 
code at least 10 times and somehow missed the (pretty silly) bug every 
time :-().

I also included yet another example application that I wrote for a 
PyObjC demo at a meeting of Dutch Mac programmers: iClass; a class 
browser for Cocoa. In just 250 lines of code...

>
> Though, I will try the fix you mention as it would be nice to have the 
> pyobjc module work against the current production version of Python, 
> if at all possible.
Let me know about the results. I'm curious if this is possible at al.

Ronald

Re: [Pyobjc-dev] PyObjC & Fink

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

On Monday, September 23, 2002, at 08:02 AM, Ronald Oussoren wrote:
> I just noticed that I sent my reply just to Bill:
>
> On Monday, Sep 23, 2002, at 08:40 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> I wouldn't mind pushing out a new snapshot. IMHO it should be marked 
>> experimental, mostly because of a memory leak whose source I've as of 
>> yet have been unable to locate.
>>
>> BTW. Does Fink install a Python framework? PyObjC probably won't be 
>> very usefull unless Python is installed as a framework. But then 
>> again, maybe a normal Unix install works just as well, as long as GUI 
>> scripts are packaged inside '.app' directories.

Fink installs the "normal" python build.  However, pyobjc is 
*extremely* useful without the framework.  Namely, it can be used to do 
very powerful command line scripting -- automating various tasks on the 
system.  There are a number of powerful ObjC APIs that have nothing to 
do with the GUI -- Address Book and NetInfo, for example.

In any case, even for building apps, the non-framework build is still 
very useful.  In particular, embedding the interpreter works quite 
nicely for adding scripting to "traditional" Cocoa apps.

I'll have a look at the memory looks as time permits...

BTW: The fix you [Ronald] mentioned for compiling pyobjc w/Python 2.2 
worked except that it seems the precompiler has gone into an infinite 
loop while compiling-- it has been using 70% of the CPU for over 10 
minutes!

gcc -DNDEBUG -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.2 -c 
Modules/objc/register.m -o 
build/temp.darwin-6.1-PowerMacintosh-2.2/register.o -g -O0 
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX

Maybe I'll let it run -- that is one BIG file...   maybe I need to 
regenerate it for 2.2 vs. 2.3??

b.bum

Re: [Pyobjc-dev] PyObjC & Fink

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

I just noticed that I sent my reply just to Bill:

On Monday, Sep 23, 2002, at 08:40 Europe/Amsterdam, Ronald Oussoren 
wrote:

> I wouldn't mind pushing out a new snapshot. IMHO it should be marked 
> experimental, mostly because of a memory leak whose source I've as of 
> yet have been unable to locate.
>
> BTW. Does Fink install a Python framework? PyObjC probably won't be 
> very usefull unless Python is installed as a framework. But then 
> again, maybe a normal Unix install works just as well, as long as GUI 
> scripts are packaged inside '.app' directories.
>
> Ronald
>
>

W.r.t. the memory leak... If you start the TableModel example and click 
inside the tableview the process will grow. It seems to grow unbounded. 
The CurrencyConverter doesn't have this problem.

Sadly enough I've encountered another problem while debugging this: If 
I try to use MallocDebug my program crashes as soon as the code tries 
to call a method in a PyObjC created class. It crashes somewhere in the 
middle of the objective-C runtime, which is compiled without debug 
information :-(. I've managed to create a standalone Objective-C 
program that features the same problem. This code is based on an 
example in the Objective-C reference from Apple. Any ideas on what 
might be wrong?

BTW. The easiest way to reproduce the problems with the attached code 
is to build it, run 'gdb class-test' and then the following commands 
from inside gdb:
	set start-with-shell 0
	set env DYLD_INSERT_LIBRARIES /usr/lib/libMallocDebug.A.dylib
	set env DYLD_FORCE_FLAT_NAMESPACE 1
	run


Ronald

[Pyobjc-dev] PyObjC & Fink

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

Given that Ronald's work on the module basically supersedes all other 
trees, I believe that we should push out a new snapshot of pyobjc.

In particular, I would like to push out a new version such that a 
source tarball is available somewhere such that a Fink package could be 
built to automatically install the pyobjc module.

I can take care of the Fink package side of things, but need consensus 
on what should be released.

Ronald?

b.bum

Re: [Pyobjc-dev] Development branch

[Steven M. <sd...@ma...>]

On Sunday, September 8, 2002, at 12:49  PM, Ronald Oussoren wrote:

> Hello all,
>
> I've (finally!) merged my work on PyObjC on branch 'subclass-branch'. This 
> features a number of changed w.r.t. my last snapshot:

Great news, Ronald. I'm going to check this out ASAP!

-- Steve Majewski

[Pyobjc-dev] Development branch

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

Hello all,

I've (finally!) merged my work on PyObjC on branch 'subclass-branch'. 
This features a number of changed w.r.t. my last snapshot:

* A number of bugfixes
* Restructured the directory structure
* Skeleton of documention
* More examples

This is experimental code, but it is already quite usable: I'm using it 
to write a 'real' application.

I've checked in a number of generated files, mostly because the build 
process doesn't generate those files (yet).

Some things that need to be done (in no particular order):
* More debugging and documenting
* The extension modules for Cocoa support (wrappers for global 
functions and a number of
   helper functions) are incomplete. Parts of this are generated, it is 
probably usefull to
   replace those by code that is generated by bgen but I don't known how 
to do that.
* There is a mechanisme for writing helper functions for methods that 
have pointer arguments.
   I've written a number of those helper functions, and it might be 
usefull to come up with
   a way to generate those functions from a simpler description.
* I'm currently using lots of (generated) helper functions to implement 
subclassing (these
   functions are needed for the Objective-C dispatch table for a class 
and for calling the
   superclass implementation of a class from Python; the functions are 
in 'register.m'). It
   would be very usefull to look into a way to reduce the number of 
those functions.
* Fix all issues mentioned in 'BUGS' and 'FIXME' (some of those are 
probably already fixed)
* ...

Ronald


  

Re: [Pythonmac-SIG] Re: [Pyobjc-dev] Build of pyobjc and pyobjc-nib failures

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

On Wednesday, July 31, 2002, at 08:21 , Zachery Bir wrote:

> On Wednesday, July 31, 2002, at 01:59 , Ronald Oussoren wrote:
>
>> I suppose your building pyobjc 0.6.1. If you remove the prototype for 
>> getcwd in OC_PythonBundle  it will compile and build.
>
> I have both the pyobjc and your pyobjc-nib - both break similarly.

That's odd. My version doesn't include OC_PythonBundle.m. Could you send 
the output of setup.py for my version to me (either directly or to the 
pyobjc-dev list).

>
> This elusive "framework install". I see this in pyobjc's INSTALL:

>
> ***
> ***  NOTE: You must build Python with Objective-C enabled by
> ***        specifying --with-objc to the configure script to use this.
> ***

That is another issue, apperently python must be build with an 
objective-C compiler to be able to use PyObjC. As the next note says, 
you don't have to do anything special on MacOS X to enable that (the 
reason is probably that 'cc' on MacOS X is an objective-C compiler).

The framework install refers to a special build of python that creates a 
'Python.framework' in /Library/Frameworks. Frameworks are basically 
Apple's solution for shipping shared libraries with supporting files.

To build a framework install call configure like this: ./configure 
--enable-framework. Check out the readme in Mac/OSX for more information.

Ronald

Re: [Pyobjc-dev] Build of pyobjc and pyobjc-nib failures

[Zachery B. <zb...@ur...>]

On Wednesday, July 31, 2002, at 01:59 , Ronald Oussoren wrote:

> I suppose your building pyobjc 0.6.1. If you remove the prototype 
> for getcwd in OC_PythonBundle  it will compile and build.

I have both the pyobjc and your pyobjc-nib - both break similarly.

> One thing though, you'll probably need a framework install of 
> python if you actually want to use this. At the very least you'll 
> have to start the scripts with an absolute path (some part of 
> Cocoa directly accesses argv[0] and fails if that is not an 
> absolute path).

This elusive "framework install". I see this in pyobjc's INSTALL:

***
***  NOTE: You must build Python with Objective-C enabled by
***        specifying --with-objc to the configure script to use this.
***

***
*** NOTE:  This no longer seems to be true under OSX Final Candidate
*** (and future versions, I would suspect).   A build of python
*** configured with './configure --with-suffix=.exe --with-threads
*** --with-dyld' worked fine!
***

I don't think I did anything special when building the 2.3, but I 
can try to specify those specifically at configure time. What else 
is required to get the "framework install"?

> If you're adventurous you could try my version of pyobjc from 
> http://www.cistron/~oussoren/pyobjc. That version is a lot more 
> usefull when you want to play with the combination of Interface 
> Builder and python. That version definitly requires a framework 
> install of python 2.3.

I've also got your -nib version of the pyobjc, and it breaks similarly.

Zac

Re: [Pyobjc-dev] Build of pyobjc and pyobjc-nib failures

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

I suppose your building pyobjc 0.6.1. If you remove the prototype for 
getcwd in OC_PythonBundle  it will compile and build.

One thing though, you'll probably need a framework install of python if 
you actually want to use this. At the very least you'll have to start 
the scripts with an absolute path (some part of Cocoa directly accesses 
argv[0] and fails if that is not an absolute path).

If you're adventurous you could try my version of pyobjc from 
http://www.cistron/~oussoren/pyobjc. That version is a lot more usefull 
when you want to play with the combination of Interface Builder and 
python. That version definitly requires a framework install of python 
2.3.

Ronald