pyobjc-dev — CVS commit notices go here

Re: help file formats (was: Re: [Pyobjc-dev] problem accessing outlet)

[Donovan P. <ds...@ma...>]

On Tuesday, October 29, 2002, at 02:42 PM, Steven D. Arnold wrote:

> On 10/29/02 4:31 PM, "Jack Jansen" <Jac...@or...> wrote:
>
>>
>> Bill Fancher contributed a script to convert the Python manual
>> from it's HTML form to the form required by Apple Help Viewer
>> (see Mac/OSX/setupDocs.py in the Python CVS tree).
>>
>> Even though help viewer is a [censored] piece of [censored]
>> (although it's slightly better in Jaguar, admitted) it has the
>> advantage of the search engine and of everyone understanding it.
>> And I think it would be good to have all the Python
>> documentation together in one place, which would then have
>> sections for Python Language, IDE, PyObjC and anything else.
>
> That makes a lot of sense.  It almost sounds like I should use a 
> version of
> XML with some tool that can convert to HTML, text, or other formats.  I
> could then hack the script you mentioned so that the same XML source 
> could
> be converted to Apple Help format.
>
> I'll do a search for such tools; if anyone knows of such a tool, 
> please send
> me a link.  In the absence of such a tool, I'll go ahead with HTML for 
> now,
> and keep my eyes open.

There's been some work done recently on the documentation tool that 
Twisted uses (http://www.twistedmatrix.com). It used to be called 
generate-domdocs and it basically took XHTML and used some special 
attributes to indicate where function reference, python source files, 
etc should be placed. Moshe Zadka refactored it recently into a 
package, twisted.lore, and added LaTeX support (and thus, ps and pdf 
support)

You might want to drop by #twisted on irc.openprojects.net or email the 
twisted list to get more information. I personally would be interested 
in adding Apple Help Viewer support to lore. The only question is would 
I have time to do it :)

Donovan

help file formats (was: Re: [Pyobjc-dev] problem accessing outlet)

[Steven D. A. <st...@ne...>]

On 10/29/02 4:31 PM, "Jack Jansen" <Jac...@or...> wrote:

> 
> Bill Fancher contributed a script to convert the Python manual
> from it's HTML form to the form required by Apple Help Viewer
> (see Mac/OSX/setupDocs.py in the Python CVS tree).
> 
> Even though help viewer is a [censored] piece of [censored]
> (although it's slightly better in Jaguar, admitted) it has the
> advantage of the search engine and of everyone understanding it.
> And I think it would be good to have all the Python
> documentation together in one place, which would then have
> sections for Python Language, IDE, PyObjC and anything else.

That makes a lot of sense.  It almost sounds like I should use a version of
XML with some tool that can convert to HTML, text, or other formats.  I
could then hack the script you mentioned so that the same XML source could
be converted to Apple Help format.

I'll do a search for such tools; if anyone knows of such a tool, please send
me a link.  In the absence of such a tool, I'll go ahead with HTML for now,
and keep my eyes open.

steve
-- 

Re: [Pyobjc-dev] problem accessing outlet

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

On dinsdag, oktober 29, 2002, at 05:16 , bb...@ma... wrote:

> Thank you! That would be brilliant -- we can drop it in the 
> Docs directory.   At some point, I really want to pull out the 
> web site and stick it in CVS.  It would be doubly-brilliant if 
> we could compile the web site and the shipped-with-the-module 
> docs from the same tree of source [Fink does this -- and Fink 
> compiles the content down to HTML, text, and-- I believe-- some 
> other formats all from the same source].
>
> But-- a "getting started writing Cocoa Python" apps would be a 
> HUGE step forward from where we are today!

Bill Fancher contributed a script to convert the Python manual 
from it's HTML form to the form required by Apple Help Viewer 
(see Mac/OSX/setupDocs.py in the Python CVS tree).

Even though help viewer is a [censored] piece of [censored] 
(although it's slightly better in Jaguar, admitted) it has the 
advantage of the search engine and of everyone understanding it. 
And I think it would be good to have all the Python 
documentation together in one place, which would then have 
sections for Python Language, IDE, PyObjC and anything else.
--
- 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] Achieving 1.0....

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

On dinsdag, oktober 29, 2002, at 02:06 , Bill Bumgarner wrote:
>> To answer my own question: no, it doesn't. isMultiThreaded 
>> still returns NO after this call.
>> Is this a problem? If so, is there a way to tell NSThread that 
>> we *are* multithreaded?
>
> That would seem to be a bug that should be reported to 
> bugreport.apple.com.  If you have a little hunk of test code, 
> that typically accelerates Apple's bug fixing process 
> considerably.

I'll try and find the time, but feel free to beat me to it:-)
>
> It sounds like you'll need to create a zero resources thread 
> via NSThread:
>
> [NSThread detachNewThreadSelector:@selector(intoTheVoid:) 
> toTarget:[NSObject class] withObject: nil];
>
> @implementation NSObject (TheVoid)
> + (void) intoTheVoid: aNothing
> {
>     l = [[NSLock alloc] init];
>     [l lock];
>     [l lock];
> }
> @end

I did this (but of course with a bit of code a lot less elegant 
than yours:-), and it solves the isMultiThreaded problem. 
Unfortunately it doesn't solve my PyOpenGL problem, but that's a 
different story...

Something else you may want to try though, if this is needed for 
PyObjC, is to let the thread terminate. The comments in 
NSThread.h lead me to believe that once you've made the 
transition to a multithreaded program there's no going back. If 
that's indeed the case then letting the thread terminate isn't a 
problem.
--
- 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] problem accessing outlet

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

Thank you! That would be brilliant -- we can drop it in the Docs 
directory.   At some point, I really want to pull out the web site and 
stick it in CVS.  It would be doubly-brilliant if we could compile the 
web site and the shipped-with-the-module docs from the same tree of 
source [Fink does this -- and Fink compiles the content down to HTML, 
text, and-- I believe-- some other formats all from the same source].

But-- a "getting started writing Cocoa Python" apps would be a HUGE 
step forward from where we are today!

If you want to have a crack at some new content for 
http://pyobjc.sourceforge.net/, please feel free!

b.bum

On Tuesday, October 29, 2002, at 11:10 AM, Steven D. Arnold wrote:

> On 10/29/02 8:19 AM, "bb...@ma..." <bb...@ma...> wrote:
>
>> This is extremely valuable feedback -- every question helps us to
>> understand where we need to provide better documentation or better
>> examples.
>
> Your message gave me everything I needed -- HelloWorld works!
>
> As thanks for the help, I'll write a guide to creating a Cocoa app in
> Python, using HelloWorld as an example.  I guess I'll put it in HTML 
> format
> to best support graphics and avoid proprietary formats.  I'll 
> contribute it
> to the project under your license terms.  I should have a rough draft 
> in a
> week or so.  If you want any of the above to be different, e.g. text 
> format
> instead of HTML, let me know ASAP.
>
> Thanks again!
>
> steve
> -- 
>
>
>
>
> -------------------------------------------------------
> 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
>
b.bum
I ride tandem with the random....
	.... things don't run the way I planned them.

Re: [Pyobjc-dev] problem accessing outlet

[Steven D. A. <st...@ne...>]

On 10/29/02 8:19 AM, "bb...@ma..." <bb...@ma...> wrote:

> This is extremely valuable feedback -- every question helps us to
> understand where we need to provide better documentation or better
> examples.

Your message gave me everything I needed -- HelloWorld works!

As thanks for the help, I'll write a guide to creating a Cocoa app in
Python, using HelloWorld as an example.  I guess I'll put it in HTML format
to best support graphics and avoid proprietary formats.  I'll contribute it
to the project under your license terms.  I should have a rough draft in a
week or so.  If you want any of the above to be different, e.g. text format
instead of HTML, let me know ASAP.

Thanks again!

steve
-- 

Re: [Pyobjc-dev] problem accessing outlet

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

On Tuesday, October 29, 2002, at 01:42 AM, Steven D. Arnold wrote:
> I appreciate the helpful answers I've gotten so far from Ronald and 
> Bill.  I
> hate to ask so many questions, but I think I'm very close to a working
> Python/Cocoa application.

This is extremely valuable feedback -- every question helps us to 
understand where we need to provide better documentation or better 
examples.

> I've done as I said in a previous post:
>
> 1. Start PB, create Cocoa app
> 2. Open resources, double-click the IB icon
> 3. Create a subclass of NSObject, in my case HelloWorld
> 4. Create an outlet called "text" which is the NSTextField intended to
> display the "Hello World" message
> 5. Create an action called "sayIt" which is wired to a button on the 
> form
> 6. Modify main.m to look exactly as described in Ronald's TableModel2
> project
> 7. Create a file Main.py which is in the "Other Sources" in my project.
> This file looks like this:
>
> import sys
> import os.path
>
> sys.path.insert( 0, os.path.join( sys.path[ 0 ], "pyobjc" ) )
>
> import objc
> import Foundation
> import AppKit
> print "foo"
>
> class HelloWorld(Foundation.NSObject):
>     __slots__ = ( 'text' )

For an outlet, replace the above line with this:

     text = objc.IBOutlet('text')

I wonder if there is a way to remove this requirement?  I'll have to 
investigate the whole IBConnection stuff -- I just did a boat load of 
custom IB work (converting NIB files from NS 3.3 -> OS X) and the APIs 
are still fresh.

>     def __init__( self ):
>         print "hello!"
>         self.text.setStringValue_( "Hello World!" )

This should just be init() and it should return self.  However...

For initialization from a NIB file, implement awakeFromNib() -- there 
are cases where the object might be instantiated before the NIB is 
loaded (NIB loading takes a significant hunk of time -- lazy loading 
the NIB for a piece of UI that the user may not use can increase 
perceived performance).  From the currency example:

         def awakeFromNib(self):
                 print "awakeFromNib"

                 # Provide some defaults for the user...
                 self.dollarField.setFloatValue_(2.0)
                 self.rateField.setFloatValue_(3.0)

>     def sayIt( self ):
>         self.text.setStringValue_( "Hello World, I am here!" )

An action method takes a single argument, the sender of the action.  
So, this should be:

     def sayIt_( self, sender ):
         self.text.setStringValue_( "Hello World, I am here!" )

b.bum

Re: [Pyobjc-dev] Achieving 1.0....

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

On Tuesday, October 29, 2002, at 07:16 AM, Jack Jansen wrote:
> On Tuesday, Oct 29, 2002, at 11:31 Europe/Amsterdam, Jack Jansen wrote:
>> On Monday, Oct 28, 2002, at 17:45 Europe/Amsterdam, Bill Bumgarner 
>> wrote:
>>> When traversing from Python into Obj-C in a thread that was created 
>>> in pure python (i.e. is just a pthread, does not have an NSThread 
>>> instance), invoking NSThread's +currentThread method will return an 
>>> NSThread that encapsulates the already created pthread.
>>
>> If you do this, does that make a pthread a fullblown NSThread? I.e. 
>> does it make the problems you sketched earlier (such as 
>> isMultiThreaded returning NO) go away?
>
> To answer my own question: no, it doesn't. isMultiThreaded still 
> returns NO after this call.
> Is this a problem? If so, is there a way to tell NSThread that we 
> *are* multithreaded?

That would seem to be a bug that should be reported to 
bugreport.apple.com.  If you have a little hunk of test code, that 
typically accelerates Apple's bug fixing process considerably.

It sounds like you'll need to create a zero resources thread via 
NSThread:

[NSThread detachNewThreadSelector:@selector(intoTheVoid:) 
toTarget:[NSObject class] withObject: nil];

@implementation NSObject (TheVoid)
+ (void) intoTheVoid: aNothing
{
     l = [[NSLock alloc] init];
     [l lock];
     [l lock];
}
@end

This will effectively dead lock the thread in a fashion that should use 
zero CPU cycles (assuming NSLock is correctly implemented).  There is 
also no way to kill the thread -- export the NSLock and call [l unlock] 
once to do so.

Bogus.  Totally Bogus.  But should do the trick.

It is likely that we will need some similar bogosity in the PyObjC 
bridge.

b.bum

Re: [Pyobjc-dev] Achieving 1.0....

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

On Tuesday, Oct 29, 2002, at 11:31 Europe/Amsterdam, Jack Jansen wrote:

>
> On Monday, Oct 28, 2002, at 17:45 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> When traversing from Python into Obj-C in a thread that was created 
>> in pure python (i.e. is just a pthread, does not have an NSThread 
>> instance), invoking NSThread's +currentThread method will return an 
>> NSThread that encapsulates the already created pthread.
>
> If you do this, does that make a pthread a fullblown NSThread? I.e. 
> does it make the problems you sketched earlier (such as 
> isMultiThreaded returning NO) go away?

To answer my own question: no, it doesn't. isMultiThreaded still 
returns NO after this call.
Is this a problem? If so, is there a way to tell NSThread that we *are* 
multithreaded?
--
- 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] Achieving 1.0....

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

On Monday, Oct 28, 2002, at 17:45 Europe/Amsterdam, Bill Bumgarner 
wrote:
> When traversing from Python into Obj-C in a thread that was created in 
> pure python (i.e. is just a pthread, does not have an NSThread 
> instance), invoking NSThread's +currentThread method will return an 
> NSThread that encapsulates the already created pthread.

If you do this, does that make a pthread a fullblown NSThread? I.e. 
does it make the problems you sketched earlier (such as isMultiThreaded 
returning NO) go away?

Hmm, this may well point to a solution to a completely different 
problem I have (my multithreaded OpenGL programs stopped working as of 
10.2).... Is there an easy way to do this from C?

>    I would assume that threaded python already has the pthread 
> initialized with the appropriate state and it would just be a matter 
> of adding any bridge specific state at this point?

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

[Pyobjc-dev] problem accessing outlet

[Steven D. A. <st...@ne...>]

I appreciate the helpful answers I've gotten so far from Ronald and Bill.  I
hate to ask so many questions, but I think I'm very close to a working
Python/Cocoa application.

I've done as I said in a previous post:

1. Start PB, create Cocoa app
2. Open resources, double-click the IB icon
3. Create a subclass of NSObject, in my case HelloWorld
4. Create an outlet called "text" which is the NSTextField intended to
display the "Hello World" message
5. Create an action called "sayIt" which is wired to a button on the form
6. Modify main.m to look exactly as described in Ronald's TableModel2
project
7. Create a file Main.py which is in the "Other Sources" in my project.
This file looks like this:

import sys
import os.path

sys.path.insert( 0, os.path.join( sys.path[ 0 ], "pyobjc" ) )

import objc
import Foundation
import AppKit
print "foo"

class HelloWorld(Foundation.NSObject):

    __slots__ = ( 'text' )

    def __init__( self ):
        print "hello!"
        self.text.setStringValue_( "Hello World!" )

    def sayIt( self ):
        self.text.setStringValue_( "Hello World, I am here!" )
        
sys.exit( AppKit.NSApplicationMain(sys.argv) )

8. Build the project; if the project was called HelloWorld, you'll have a
program called HelloWorld.app.


When I build and run the program, the window comes up with the form elements
I put in place.  I can click the button (which is supposed to make an
NSTextField say "hello world"), but nothing happens.  In the run window of
Project Builder, I see the following messages:

foo
2002-10-29 01:36:19.450 pysample[784] Could not connect the action sayIt: to
target of class HelloWorld
2002-10-29 01:36:19.672 pysample[784] Can't open input server
/Library/InputManagers/Menu Extra Enabler

Note that it printed the "foo" that I put in my program, above!  However,
the "hello" that I print in __init__ never gets displayed.  So apparently my
file is being processed by no instance of HelloWorld is ever being created
-- which may explain why it couldn't connect sayIt to my class.

So my question is why am I getting the results I'm getting instead of a
correct connection to the sayIt method?

steve
-- 

Re: [Pyobjc-dev] Achieving 1.0....

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

On Monday, October 28, 2002, at 04:00 AM, Ronald Oussoren wrote:
> All,
>
> I just remembered one implementation issue that should be worked on 
> before reaching a 1.0 release: Thread safety.

Agreed.

> The current code is probably save for multi-threading, but I haven't 
> really checked this. Basicly I removed all static/global buffers while 
> working on the code.
>
> There are some more issues:
> 1. Python has a global interpreter lock. When one thread owns this 
> lock, no
>    other thread can execute python code. The bridge currently never 
> gives up
>    the GIL when moving into native code and we probably should. I have 
> not yet
>    researched what we should do with callbacks from Objective-C to 
> Python.
>
>    E.g. the NSApplicationMain wrapper should release the GIL before 
> calling
>    the actuall function, but how do you regain the GIL during calls to 
> methods
>    implemented in Python?
>
>    This is necessary to avoid unecessary blockage of Python threads 
> during
>    calls to Objective-C code.

I believe Jack covered this, but wanted to add a couple of Obj-C and 
NS* specific bits of information:

As of OS X, NSThreads are actually built on top of pthreads and it 
should be possible to use Jack's code directly.  From the documentation:

...
NSThreads are built upon POSIX threads (pthreads). You can create your 
own pthreads, but some Cocoa classes, such as NSAutoreleasePool, expect 
to be running within an NSThread and may not work properly in a 
pthread. Creating a pthread does not notify Cocoa classes that the 
application has become multithreaded, so the NSThread method 
isMultiThreaded may return NO. If you need access to the pthread within 
an NSThread, call the pthread_self function from within that thread.
...

I would still recommend using the NSThread based API to create threads 
if the goal is to multi-thread an app that mixes Python and Obj-C in 
threads (for an app that uses pure-python in the threads, there is no 
need) because this is the only way that the ObjC runtime is going to 
become "thread aware".  Specifically, see the documentation on these 
notifications:

FOUNDATION_EXPORT NSString * const 
NSWillBecomeMultiThreadedNotification;
FOUNDATION_EXPORT NSString * const 
NSDidBecomeSingleThreadedNotification;
FOUNDATION_EXPORT NSString * const NSThreadWillExitNotification;

However, once the NSThread is created, the pthreads API can be used to 
store state and otherwise manipulate the thread -- the NSThread API is 
just the glue to make sure the ObjC runtime has the opportunity to deal 
w/the appropriate notifications.

If desired, NSThread provides for storage of per-thread state in a 
mutable dictionary.  Simply invoke -threadDictionary while executing in 
the thread that wants to store/retrieve the state.

When traversing from Python into Obj-C in a thread that was created in 
pure python (i.e. is just a pthread, does not have an NSThread 
instance), invoking NSThread's +currentThread method will return an 
NSThread that encapsulates the already created pthread.   I would 
assume that threaded python already has the pthread initialized with 
the appropriate state and it would just be a matter of adding any 
bridge specific state at this point?

It sounds like the harder problem is when the developer crosses from 
ObjC -> Python in a thread that was not created in Python and, 
therefore, the interpreter has not initialized the pthread state in the 
specific context of Python?

Note that as of 10.2, NSThread offers these two *extremely* handy 
methods:

- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg 
waitUntilDone:(BOOL)wait modes:(NSArray *)array;
- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg 
waitUntilDone:(BOOL)wait;

b.bum

[Pyobjc-dev] Reality check on memory management.

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

On Monday, October 28, 2002, at 03:51 AM, Ronald Oussoren wrote:
> Jonathan,
>
> I agree that we should try to abstract away manual management of 
> reference counts. Until a few days ago I believed we already reached 
> this point.

Even without the automatic compensation for the methods that transfer 
ownership, we have abstracted away the manual management of reference 
counts in almost all cases.

The remaining issues are not specific to Obj-C, they are specific to 
particular kits of objects implemented in using Objective-C.   Therein 
lies the problem-- every developer who builds a kit of objects can 
choose [consciously or not, doesn't matter] to implement a completely 
different retain/release/autorelease pattern across their API.

Example:  I often use the +new pattern to return an object with 
ownership transfer implied.   I.e. +newWithFile: (NSString *) aPath; 
returns a freshly instantiated instance of my Image class that has been 
retained.   However, Apple's DragNDropOutlineView example uses 
+newGroupFromLeaf: to return an autoreleased object.

We cannot possibly predict what developers are going to do with the 
bridge.   Nor can we ever completely hide the 
retain/release/autorelease "feature" of Objective-C.   It is very much 
a reality and will always be a reality in any bridged environment.

However, what we can do is make the bridge work as transparently as 
possible in light of this reality (which it pretty much already does)!  
  In particular, we can make sure that if a program fails because of a 
retain/release/autorelease problem, it does so in as graceful of a 
fashion as possible (i.e. it dies in ObjC, not python, as often as 
possible :-).

To these ends, let's do a reality check on the problem.

The problem is not that we need to deal with -retain/-release in the 
normal course of using the bridge -- that is already very cleanly taken 
care of.

The problem is that there are a handful of methods-- +alloc, +copy, 
+mutableCopy, +new, and any of a number of methods that the developer 
might create that we cannot know about in advance-- that "transfer 
ownership" to the caller.  That is, they return retained objects.   In 
the context of the bridge, this yields an extra reference count and 
Ronald's goal is to try and automatically compensate for that reference 
count.

A worthy goal, but not one that can be achieved with 100% coverage.

OK-- so why not just leave it out?  What are the implications then?

To the ObjC developer, the apps "just work" as expected.

To the Python developer, the apps "just work" as expected, but leak a 
little bit of memory.

Leaks are a hell of a lot easier to fix than retain/release/autorelease 
crashes.

Furthermore, it means that taking advantage of a new framework/bundle 
of objects is as easy simply dynamically loading the code -- no need to 
worry about analyzing the API and trying to figure out what methods 
should be "special cased" before we can even write line-one of python 
code against that API.

I have worked on a number of language bridges -- Java<->ObjC, 
Perl<->ObjC (long before CamlBones), Tcl<->ObjC, Tcl<->Python [don't 
ask], and a couple that involved bridging languages I created to Python 
or Obj-C -- and in *every single case*, a decision to special case as 
would be [is] required by this [relatively small] problem was a *very 
bad idea*.   It caused confusion in the developer community-- including 
confusion among the authors of the bridge-- and was a constant source 
of maintenance and support headaches.

> There are now two sets of ...

There will always be situations that expose retain/release in contexts 
that do not map directly to a pattern we have quantified.

An example: when implementing a window controller, it is not uncommon 
to do a [self retain] when the NIB is loaded (or the window is 
displayed) and a [self autorelease] in windowWillClose:.   That is, the 
window controller implements a "as long as my window is open-- 
miniaturized or not, doesn't matter-- I should remain in existence" 
notion.  This pattern makes it extremely easy to implement 
multi-document apps where the application doesn't manage the list of 
documents in some formal "ownership implied" fashion.

(This is the paradigm that the Web Services Tool follows, btw).

> 1. Bill mentioned that it is common in some Objective-C code to 
> transfer
>    ownership of returned objects to the caller (He's the resident 
> expert
>    on these issues, I'm learning Objective-C/Cocoa as a go along).
>
>    It will be hard to correctly identify all these cases. IMHO this 
> shouldn't
>    keep us from doing away with autorelease/release/retain in Python 
> code:
>    it will just be a little harder to correctly wrap an Objective-C 
> class
>    library. As wrapping an Objective-C class is an order of magnitude 
> simpler
>    than wrapper other 'native' code that should not be a problem.

I suppose that this basically introduces a wrapping step into the 
"let's use some random hunk of dynamically loadable API" process?  If 
that step is not taken, then the retains will not be compensated for in 
the bridge?  I.e. the step is optional.

As long as the wrapping step is optional, it isn't a big deal.   If it 
becomes non-optional, then it vastly increases the complexity of using 
external frameworks/bundles over what we have today (a one liner to 
load the bundle/framework w/some optional glue code that Ronald has 
nicely documented in the wrapping.txt document).

> 2. Bill also mentioned a coding style that uses 'autorelease' to make 
> sure
>    that an object is around to the end of the current loop through the
>    eventloop (which in case of non-GUI programs may be quite a long 
> time).
>
>    I don't really like this coding style, so IMHO it is not a problem 
> to use
>    'obj.retain().autorelease()' in these cases, instead of just
>    'obj.autorelease()'. I'm also pretty sure that doesn't really have 
> anything
>    to do with the automatic management of refcounts by the bridge.

The end result would be that the retain/autorelease is still exposed to 
the Python developer while the ObjC developer has to remember a special 
case.... I would rather the solution that exposes only the autorelease 
to the python developer and leaves things as is for the ObjC developer.

The reality in this situation is that to use this pattern requires 
knowledge of the ObjC patterns of object management and the various 
APIs (most likely NSTimer or NSNotification) therein.

Keep in mind that an autorelease pool's lifespan may not be tied to one 
pass through a run loop and, therefore, object's like NSTimer-- which 
are processed as a part of passing through the run loop-- are perfectly 
valid in this context.

We cannot possible predict what the developer is going to do...

> 3. The NSMutableArray class cluster (and probably all 
> NS<DataStructure> class
>    clusters) play games with reference counts during allocation. This 
> is not
>    a problem if you use the common Objective-C idiom, but it is when 
> you try
>    to automate management of reference counts.
>
>    Basicly the issue is that the Objective-C manual strongly suggest 
> that the
>    following two lines should be equivalent, but they are not for 
> these class
>    clusters:
>
>    NSArray.alloc().autorelease().init()	# Basicly what the bridge does
>    NSArray.alloc().init().autorelease()   # Common Objective-C idiom
>
>    I'm thinking on how to fix this. The one requireing the least 
> amount of
>    engeneering is saying "Don't use 'alloc().init()' for these class 
> clusters",
>    or even "Don't allocate Objective-C containers from Python". I 
> don't really
>    like this and am thinking on how to fix this in a correct manner.

If we create a special case to handle this situation, it will only 
cause maintenance hell down the road.  What if Apple changes the 
semantics?  What if new collection classes are introduced that suddenly 
start breaking in the way NSArray does now?   What if a third party 
creates collection classes with the same behavior as Apple's?

b.bum

[Pyobjc-dev] Re: memory management

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

First, 	I would like to say THANK YOU!!!! to Jonathan LaCour for 
jumping into the discussion.  The input is very definitely appreciated.

First, what we are really talking about is a relatively small part of 
the overall problem.  That the bridge already automatically increases 
and decreases the retain count as python references to the ObjC objects 
are created and destroyed solves most of the problem.

The remaining problem is how to deal with the situations that require 
special casing on a per method basis.

On Monday, October 28, 2002, at 12:35 AM, Jonathan LaCour wrote:
> I have been watching the discussion on retain/release/autorelease 
> semantics for a few days and I have put some thought into things.  
> After a lot of thought, I would like to sincerely urge you to make an 
> attempt at abstracting out any and all retain/release/autorelease 
> responsibilities for the programmer.  I understand the argument that 
> it isn't very "Cocoa-like", but I feel that I have a compelling 
> argument here.

I think all of us agree wholeheartedly that eliminating as much of the 
retain/release/autorelease noise from the Python side of the bridge as 
is possible is a high priority goal.

> First, I believe that you alienate most python programmers by 
> enforcing memory management on them.  Python programmers use python 
> *because* they don't have to worry about this kind of thing.  Its not 
> that they don't know how or are afraid of it, they just don't want to 
> touch it.  If you force people into it, they will likely end up using 
> wxPython or something like REALBasic.

Agreed.  Keep in mind that we are not writing the Foundation, AppKit 
and the rest of the ObjC APIs in Python -- we are bridging them.   
While a bridge makes the functionality available on the other side of 
the bridge, there is always going to be evidence that the functionality 
on the other side of the bridge is implemented in a different 
technology.

> Secondly, to counter the "Cocoa-like" argument, placing memory 
> management functionality into a python product is simply not 
> "Python-like".  Sure, it will feel more like developing with Cocoa and 
> Objective-C, but people are going to use the Python bridge because 
> they don't want to work with Objective-C when they don't have to.  You 
> have to make a choice here... if PyObjC is for Cocoa developers who 
> don't know python, then certainly you should try and be "Cocoa-like."  
> But if PyObjC is for *python programmers* (which I have a feeling it 
> is), then it should strive to be Python like... meaning no 
> retain/release at all!

Reality:  If a developer is using the Objective-C bridge to write an 
application, they are developing in a combination of Python and 
Objective-C -- ObjC is still very much a part of the equation.  The 
developer is going to have to know *some* objective-c to get the job 
done.

The current bridge already changes the memory management semantics 
significantly -- it already obviates the need for calls to 
-retain/-release/-autorelease when making assignments (foo = bar), when 
dealing with set membership (-retaining an object before removing it 
from a set, if that object is to be returned), and when returning 
objects from methods.  These are the most common situations for use of 
the memory management methods in ObjC.

> Memory management through old-style reference counting stands directly 
> opposite to this power.  If you lose this, why use Python at all?  You 
> might as well just use Objective-C (it only takes a few minutes to 
> learn) and is faster than python.

Because python provides much better rapid turnaround than Obj-C ever 
could.... my compilation time drops to near nothing and I can eliminate 
100s of lines of code that would be required in ObjC to do the same 
thing.   That, and I can take advantage of the incredible array of 
python modules that are available.   Example:  I can now use the 
berkeley db as a persistent store from my Obj-C apps with only a 
handful of lines of code.

> When this project came along I was extremely excited about the 
> possibilities that it offered.  Please consider at least making an 
> automated system an OPTION.  I know its hard, but I think that in the 
> long run it will be worth it.  A system like Cocoa without manual 
> memory management using a language like Python and Mac OS X's 
> developer tools is such a powerful concept and could truly be the 
> "killer app" of development on Mac OS X.

It can't be an option -- if it is used in one hunk of code and not in 
another, those two hunks are incompatible.   I.e. if I create a 
framework that contains Python that doesn't use the option and your app 
uses the option, you can't use my framework.

Even without the option, the bridge as it stands today provides the 
features that you speak... more on that in the next message.

b.bum


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

Re: [Pyobjc-dev] Achieving 1.0....

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

On Monday, Oct 28, 2002, at 10:00 Europe/Amsterdam, Ronald Oussoren 
wrote:

> All,
>
> I just remembered one implementation issue that should be worked on 
> before reaching a 1.0 release: Thread safety.
>
> The current code is probably save for multi-threading, but I haven't 
> really checked this. Basicly I removed all static/global buffers while 
> working on the code.
>
> There are some more issues:
> 1. Python has a global interpreter lock. When one thread owns this 
> lock, no
>    other thread can execute python code. The bridge currently never 
> gives up
>    the GIL when moving into native code and we probably should. I have 
> not yet
>    researched what we should do with callbacks from Objective-C to 
> Python.
>
>    E.g. the NSApplicationMain wrapper should release the GIL before 
> calling
>    the actuall function, but how do you regain the GIL during calls to 
> methods
>    implemented in Python?

I have sample code to do this, based on pthreads. You can have it if 
you want it, but it's probably just as easy to recode it (as you'll 
have to replace the pthreads stuff anyway, I would guess).

The trick I used is to put pthread's per-thread data to work (I assume 
ObjC threads have a similar feature, yes?). You allocate an item of 
per-thread global data, which is automatically initialized to zero in 
all threads. Then when you switch from Python->ObjC you store the 
current PyThreadState in there. When you switch from PObjC to Python 
you get the per-thread global data item. If it is non-null it is the 
PyThreadState and you simply do PyEval_AcquireThread. If it is null 
then this is a thread that has never yet made the Python->ObjC 
transition. As it is apparently executing ObjC code right now it must 
have been created outside of Python. So, you create a new PyThreadState 
for it (with PyThreadState_New), store that in the per-thread global 
data and call PyEval_AcquireThread.
--
- 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] Achieving 1.0....

[pluto <pl...@ob...>]

hi folks,

i'm new to this list, i'm also new to macs and obj-c. i've been 
programming python for a several years as a living... and thats enough 
of an intro ;-)

On Monday, October 28, 2002, at 01:00 AM, Ronald Oussoren wrote:

> All,
>
> I just remembered one implementation issue that should be worked on 
> before reaching a 1.0 release: Thread safety.
>
> The current code is probably save for multi-threading, but I haven't 
> really checked this. Basicly I removed all static/global buffers while 
> working on the code.
>
> There are some more issues:
> 1. Python has a global interpreter lock. When one thread owns this 
> lock, no
>    other thread can execute python code. The bridge currently never 
> gives up
>    the GIL when moving into native code and we probably should. I have 
> not yet
>    researched what we should do with callbacks from Objective-C to 
> Python.
>
>    E.g. the NSApplicationMain wrapper should release the GIL before 
> calling
>    the actuall function, but how do you regain the GIL during calls to 
> methods
>    implemented in Python?
>

write a (objective) c wrapper that gets registered for the callback and 
takes a pointer to the python object to call. on callback reacquire the 
gil and call the object.

>    This is necessary to avoid unecessary blockage of Python threads 
> during
>    calls to Objective-C code.
>
> 2. Threads started using the Cocoa thread class(es) won't have a python
>    interpreter state. Special wrapping code should be written to 
> arrange for the
>    creation of that state. This can wait until item 1 is finished.
>

maybe it would be helpful to look at what pyqt or wxpython do in such 
cases.

cheers,

-p

Re: [Pyobjc-dev] Achieving 1.0....

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

All,

I just remembered one implementation issue that should be worked on 
before reaching a 1.0 release: Thread safety.

The current code is probably save for multi-threading, but I haven't 
really checked this. Basicly I removed all static/global buffers while 
working on the code.

There are some more issues:
1. Python has a global interpreter lock. When one thread owns this 
lock, no
    other thread can execute python code. The bridge currently never 
gives up
    the GIL when moving into native code and we probably should. I have 
not yet
    researched what we should do with callbacks from Objective-C to 
Python.

    E.g. the NSApplicationMain wrapper should release the GIL before 
calling
    the actuall function, but how do you regain the GIL during calls to 
methods
    implemented in Python?

    This is necessary to avoid unecessary blockage of Python threads 
during
    calls to Objective-C code.

2. Threads started using the Cocoa thread class(es) won't have a python
    interpreter state. Special wrapping code should be written to 
arrange for the
    creation of that state. This can wait until item 1 is finished.

Ronald

Re: [Pyobjc-dev] memory management.

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

Jonathan,

I agree that we should try to abstract away manual management of 
reference counts. Until a few days ago I believed we already reached 
this point.

There are now two sets of ...

1. Bill mentioned that it is common in some Objective-C code to transfer
    ownership of returned objects to the caller (He's the resident expert
    on these issues, I'm learning Objective-C/Cocoa as a go along).

    It will be hard to correctly identify all these cases. IMHO this 
shouldn't
    keep us from doing away with autorelease/release/retain in Python 
code:
    it will just be a little harder to correctly wrap an Objective-C 
class
    library. As wrapping an Objective-C class is an order of magnitude 
simpler
    than wrapper other 'native' code that should not be a problem.

2. Bill also mentioned a coding style that uses 'autorelease' to make 
sure
    that an object is around to the end of the current loop through the
    eventloop (which in case of non-GUI programs may be quite a long 
time).

    I don't really like this coding style, so IMHO it is not a problem 
to use
    'obj.retain().autorelease()' in these cases, instead of just
    'obj.autorelease()'. I'm also pretty sure that doesn't really have 
anything
    to do with the automatic management of refcounts by the bridge.

3. The NSMutableArray class cluster (and probably all NS<DataStructure> 
class
    clusters) play games with reference counts during allocation. This 
is not
    a problem if you use the common Objective-C idiom, but it is when 
you try
    to automate management of reference counts.

    Basicly the issue is that the Objective-C manual strongly suggest 
that the
    following two lines should be equivalent, but they are not for these 
class
    clusters:

    NSArray.alloc().autorelease().init()	# Basicly what the bridge does
    NSArray.alloc().init().autorelease()   # Common Objective-C idiom

    I'm thinking on how to fix this. The one requireing the least amount 
of
    engeneering is saying "Don't use 'alloc().init()' for these class 
clusters",
    or even "Don't allocate Objective-C containers from Python". I don't 
really
    like this and am thinking on how to fix this in a correct manner.

Ronald

[Pyobjc-dev] memory management.

[Jonathan L. <pan...@sk...>]

Guys,

I have been watching the discussion on retain/release/autorelease 
semantics for a few days and I have put some thought into things.  
After a lot of thought, I would like to sincerely urge you to make an 
attempt at abstracting out any and all retain/release/autorelease 
responsibilities for the programmer.  I understand the argument that it 
isn't very "Cocoa-like", but I feel that I have a compelling argument 
here.

First, I believe that you alienate most python programmers by enforcing 
memory management on them.  Python programmers use python *because* 
they don't have to worry about this kind of thing.  Its not that they 
don't know how or are afraid of it, they just don't want to touch it.  
If you force people into it, they will likely end up using wxPython or 
something like REALBasic.

Secondly, to counter the "Cocoa-like" argument, placing memory 
management functionality into a python product is simply not 
"Python-like".  Sure, it will feel more like developing with Cocoa and 
Objective-C, but people are going to use the Python bridge because they 
don't want to work with Objective-C when they don't have to.  You have 
to make a choice here... if PyObjC is for Cocoa developers who don't 
know python, then certainly you should try and be "Cocoa-like."  But if 
PyObjC is for *python programmers* (which I have a feeling it is), then 
it should strive to be Python like... meaning no retain/release at all!

My last point is that I believe this project is a unique opportunity to 
take the already simple and powerful Cocoa development frameworks and 
make them even more elegant.  Python has a powerful ability to help 
developers implement or prototype things QUICKLY.  Memory management 
through old-style reference counting stands directly opposite to this 
power.  If you lose this, why use Python at all?  You might as well 
just use Objective-C (it only takes a few minutes to learn) and is 
faster than python.

When I switched to Mac OS X a few months ago, I had been using Java 
Swing, wxPython, and GNOME's Python bindings to build GUI applications. 
  On OS X, I really wanted to be able to leverage the native widgets and 
native frameworks to their fullest potential using a language that I 
was comfortable with.  I tried out the Java bridge and was terribly 
disappointed with speed, documentation, and general instability of the 
bridge.  Then I bit the bullet and learned Objective-C.  I was 
impressed overall, but really felt that the memory management system 
was pathetically outdated and cumbersome.  Its certainly better than C, 
but definitely not as simple as my previous solutions.  When this 
project came along I was extremely excited about the possibilities that 
it offered.  Please consider at least making an automated system an 
OPTION.  I know its hard, but I think that in the long run it will be 
worth it.  A system like Cocoa without manual memory management using a 
language like Python and Mac OS X's developer tools is such a powerful 
concept and could truly be the "killer app" of development on Mac OS X.

Just some food for thought...

  - Jonathan

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

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

On Friday, October 25, 2002, at 09:31 AM, Jack Jansen wrote:
> Bill,
> a couple of questions on your architectural remarks.
> On Friday, Oct 25, 2002, at 02:40 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> Bugs & Architecture:
>>
>>     - there should be a way in the GUI to open a file into the 
>> settings -- i.e. the Open... command should be "Run script..." and 
>> "Open..." should truly open the script as a document.  [...]
>>
>>     - the 'run in terminal' button doesn't update the field contents 
>> and, as such, the contents can get out of sync...
>>
>>     - If the multi-doc architecture is going to be used, there should 
>> be something to save! [...]
>>     Finally, the app really isn't a multiple-document type app. [...]
>
> All these hinge on the fact that PythonLauncher looks like a 
> multidocument application, but really isn't. Is that a problem? I 
> modeled the semantics more-or-less after Stuffit Expander: 
> PythonLauncher can operate in 2 modes, one where it's already running 
> (and opening a document always goes into interactive mode) and another 
> one where the application is started for a single document, which is 
> launched (optionally after allowing interaction to set the options) 
> after which PythonLauncher quits without further ado.

Ahh... OK -- that clarifies things a bit and I'll modify my comments 
accordingly.

I could see use for a multi-doc app if one were to want to save 
per-script configuration information but, as you indicate, there isn't 
a whole heck of a lot of value in that.

A console might be nice, though, and that would open the need to leave 
the app running.

>>     - If I use the new menu item, it doesn't seem possible to set the 
>> script to be executed by the document.
>
> That's because I haven't been able to disable the New command, which 
> is what I really would want to do. Can you tell me how to do this? 
> (Or, better, tell me where I should have found the information)

In a multiple document architecture app, the 'new' menu item is bound 
to newDocument: on the First Responder.  If it should always be 
disabled, why not just delete the menu item?

In any case, you can use Cocoa's automatic menu validation to disable 
the menu item.  Implement the following method on the application's 
delegate:

- (BOOL)validateMenuItem:(NSMenuItem *)aCell {
     SEL action = [aCell action];
     if (action == @selector(newDocument:))
	    return NO;
     return YES;
}

-validateMenuItem: can be implemented on any object in the responder 
chain.  Whenever a menu is popped down, the method is called for each 
cell in the menu -- the invocation of methods follows the same pattern 
as the responder chain.  I.e. first responder view -> superview -> 
superview -> ...etc... -> window -> window's delegate -> app -> app's 
delegate.

If you don't have any documents/windows on the screen, then the 
responder chain is just app -> app's delegate and, in this case, means 
you want to return NO for the newDocument: item from the app's 
delegate's implementation.

>>     - Since both the preferences window and the documents have the 
>> same interior UI, the NIB file for that UI should be split out and 
>> the preferences and document window should share that single NIB.  
>> The preferences window should likely move to a tabbed view with the 
>> different file types in the tabs -- that seems to be the HIG way 
>> these days.
>
> Again, I wanted to do this but I haven't been able to come up with a 
> way to do it. Please enlighten me. There's actually two things that I 
> haven't been able to find out:
> 1. How can I share the interior contents of two windows?

First, create a new nib file that contains a Custom View in it (a 
Custom View is just a container for other views, in this instance -- 
kind of like a window in a regular nib file).   Stick the shared UI 
into this NIB file.   The trick is that the file's owner doesn't have 
to be the same class as it is in the runtime-- it just needs to be the 
instance of some class that defines the same set of actions and outlets 
as are used in IB.

An alternative would be to make the Settings class control the UI 
elements -- if the outlets are non-nil, it keeps the UI up to date and 
monitors user interaction with the UI.   An instance of settings could 
then be passed as the owner.

Then, when you load either the preferences panel or a script window's 
NIB, load this second NIB as well.

Now that you have all the UI elements loaded, the trick is to shove 'em 
into the window.   This is mostly a case of moving the various views 
around to make room for the new chunk of content.

Very likely, the easiest solution is to simply dump a custom view into 
the window.   Resize it to be in the position and of the same size as 
the chunk of UI you are going to be sharing between the two windows.   
Add an outlet to the PreferencesWindowController and MyDocument classes 
that connect to the view to be replaced. Then, in awakeFromNib:, do 
something like:

[[viewToBeReplacedWithRealContents superview] replaceSubview: 
viewToBeReplacedWithRealContents with: 
customViewThatContainsTheSharedContentsInThatOtherNibFile]

More sane variable names would likely be preferable...

(For the preferences controller, there is no need to do the view swap 
thing as the TabView already has a view in it that can be used to swap 
the UI elements in as necessary.

> 2. How do I get a tabbed view without actually having something 
> different on every tab (I want the same controls on each tab, really, 
> and I don't want to duplicate either the code or the controls)?

Good question. I don't... didn't... know.  I gave it a try and it boils 
down to a one liner (I love Cocoa that way :-).

Set your window controller (document, whatever) to be the delegate of 
the Tab View.   Then, implement something like:

- (void)tabView:(NSTabView *)aTabView 
didSelectTabViewItem:(NSTabViewItem *)tabViewItem;
{
   // share the shared UI elements across all tabs.  Use -identifier to 
figure out which tab was selected if you want to do so passively.  
Alternatively, use [[tabView selectedTabViewItem] ...] or create three 
outlets to the tab view items and simply do == when updating / reading 
from the UI.
   NSLog(@"Did select tab %@ (%@)", [tabViewItem identifier], 
[tabViewItem label]);
   [[[tabView selectedTabViewItem] view] addSubview: sharedUIElements];
}

To make sure *something* is displayed when the nib is loaded, do the 
following in, say, -awakeFromNib:

   [[[tabView selectedTabViewItem] view] addSubview: sharedUIElements];

You can grab the example from the following URL -- it is bogus save for 
the tab view manipulation.  It also shows how to programmatically 
create tabs -- may be necessary if you want to support a dynamic list 
of configurations or something similar.

http://www.friday.com/software/examples/tabtest.tgz

>>     - NSTask would be a better candidate than system() to subshell 
>> out the command.  It would allow the app to monitor the output and 
>> display a console.
> [...]
>> The first step in moving to a true multi-doc style app is for the app 
>> to give the user control over when documents are closed -- that is, 
>> if a user opens a python script [as opposed to Running... a script 
>> without opening a visible document at all], the associated window 
>> should remain open until the user tells it to go away.  The document 
>> should have a notion of 'currently running, do you want to launch 
>> another instance of the same thing?' and 'abort/stop current run'.
>
> These are things I specifically don't want to do (i.e. convince me 
> otherwise if you think it's worthwhile). The intention of 
> PythonLauncher is to be like Java AppletLauncher (or the above 
> mentioned Stuffit Expander): it should "fire and forget" the script. 
> Remember, the reason this was written in the first place is because 
> CFBundleTypeRole=Shell doesn't work (which is what it's trying to 
> emulate, with the options dialog thrown in so that we no longer have 
> to provide that in pythonw, and have the functionality for console 
> scripts too). Ideally a naive user shouldn't even be aware of the fact 
> that this thing exists.

I'm all for keeping it as simple as possible.  If someone really wants 
to have more control over the execution of a script, then they can use 
the IDE or command line directly.

Given the clarification as to the design goals provided above, these 
requested features are pretty much out the window-- but they would be 
nice to have in other contexts...

b.bum

Re: [Pyobjc-dev] Importing custom Objc libraries/frameworks

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

Sebastian,

     The Web Services Tool example project contains everything within it=20=

to support automatic linking of frameworks into the Python runtime as=20
the app starts up.

     Once you create a new Cocoa-Python project, add a framework target=20=

to the project.  Put only classes that you want compiled into that=20
target.   Then, in the app target, add a "Copy files" build phase and=20
copy the built framework into the "Frameworks" subdirectory of the=20
application (it is an option in the pop-up for the build phase=20
inspector).

     If you have everything set up correctly, the framework will be=20
dynamically loaded automatically by the code in Main.py.  If you add an=20=

Init.py python scripts as a Resource in the framework target, it will=20
be automatically evaluated immediately after the framework is=20
dynamically loaded.   This allows you to import any other python code=20
that you might need (the framework's Resources directory is=20
automatically added to Python's sys.path).

     Unfortunately, the Cocoa-Python project template does not currently=20=

include the correct code.   When you create a new Cocoa-Python project,=20=

simply replace the contents of the main.m and the Main.py file with the=20=

contents from the same files in the Web Services Tool project.

     I hope to have a chance to make a real tutorial out of this stuff,=20=

that and write some documentation....

     b.bum

On Saturday, October 26, 2002, at 05:18 AM, S=E9bastien Pierre wrote:
> Hi,
>
> I am writing an Objective-C library that I'd like to import and use in=20=

> Python through pyobjc.
>
> Is it possible to do this? If so, what do I have to do to make my=20
> library available to python ?
>
> TIA,
>
>  -- S=E9bastien

Re: [Pyobjc-dev] Importing custom Objc libraries/frameworks

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

On Saturday, Oct 26, 2002, at 11:18 Europe/Amsterdam, S=E9bastien Pierre=20=

wrote:

> Hi,
>
> I am writing an Objective-C library that I'd like to import and use in=20=

> Python through pyobjc.
>
> Is it possible to do this? If so, what do I have to do to make my=20
> library available to python ?
It is quite easy to do this, assuming that you want to access the=20
classes in the  Objective-C library and the library is in a framework.

If your library is installed in the framework=20
'/path/to/mylib.framework' you
can do something like this:

# This is 'mylib.py', a python library for accessing classes
# in 'mylib.framework'
import Foundation
class_list =3D Foundation.load_bundle(
         '/path/to/mylib.framework')
gl =3D globals()
for cls in class_list:
         gl[cls.__name__] =3D cls

del class_list, cls, gl, Foundation
# end of mylib.py

This will load 'mylib.framework' and export all classes in that=20
framework.

Ronald=

[Pyobjc-dev] Importing custom Objc libraries/frameworks

[<sp...@al...>]

Hi,

I am writing an Objective-C library that I'd like to import and use in=20=

Python through pyobjc.

Is it possible to do this? If so, what do I have to do to make my=20
library available to python ?

TIA,

  -- S=E9bastien

PS: I am rather new to Objective-C and the difference between libraries=20=

and framework is rather unclear...

--
=ABIl vaut mieux suivre une voix stupide que l'on connait,
plut=F4t qu'une intelligente que l'on ne connait pas.=BB
<http://www.type-z.org>                -- No comment on Jacques C.=

Re: [Pyobjc-dev] Bug Fixed!!! Dealing with alloc / init oddities

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

On Friday, October 25, 2002, at 04:06 PM, Ronald Oussoren wrote:
> Bill,
>
> The 'fix' was not your change to 'objc_support.m', but the change to 
> 'selector.m' (the one I'm so unhappy about ;-()

Yes -- I undid the change in objc_support.m and committed the 
unmodified version.  Sorry.  Should have undid that.

> The problem is that NSMutableArray isn't really following the Cocoa 
> refcounting conventions. This can be demonstrated using a simple 
> Objective-C program:

That the NSArray class cluster uses a placeholder upon allocation isn't 
a violation of the Cocoa refcounting conventions -- it is just fallout 
from the design of the class cluster.   There is nothing that says that 
what is returned by +alloc must be  the same instance as whatever is 
returned by -init.

> Note that return value of the two calls of alloc is the same, and 
> different from the return value of the corresponding init calls. 
> Appearently 'alloc' just returns a kind of factory object, and 'init' 
> is the one that actually allocates memory.
> Further investigation shows that the return value of 'alloc' is a 
> 'NSPlaceholderMutableArray'. Actually it is probably that class and 
> not an instance of it. Both 'x->isa->name' and 'x->isa->isa->name' are 
> 'NSPlaceholderMutableArray', if 'x' where an object I'd expect the 
> second to be 'NSObject'.

The NSArray class cluster returns a placeholder [factory] for 
allocation because it does not yet have enough information to determine 
which private subclass will most efficiently hold whatever the 
developer is about to throw at it.

> I'm glad to find that the problem with NSArray is caused by a feature 
> of Cocoa and is not a memory corrupting bug in PyObjC itself. That 
> doesn't make it easier to actually fix it of course, but at least we 
> can now start to think about how to really solve this instead of 
> hunting down an elusive memory corruption
> error.

That the placeholder is both shared, but allows itself to be released 
to the point of destruction, would seem to be something that Apple 
would have wanted to avoid by simply overriding -release on the 
placeholder class and having it do nothing.   This would, at least, 
prevent an app from crashing in a bizarre fashion because the cached 
placeholder instance has blown up.

Then again, maybe they are playing interesting internal games with the 
retain count.

The implementation of the placeholder class itself does seem to be a 
bit odd.

b.bum

Re: [Pyobjc-dev] Bug Fixed!!! Dealing with alloc / init oddities

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

Bill,

The 'fix' was not your change to 'objc_support.m', but the change to 
'selector.m' (the one I'm so unhappy about ;-()

The problem is that NSMutableArray isn't really following the Cocoa 
refcounting conventions. This can be demonstrated using a simple 
Objective-C program:

#import <Foundation/Foundation.h>

int main(void)
{
         id x;
         printf("class: %p\n", [NSMutableArray class]);
         printf("alloc: %p\n", x = [NSMutableArray alloc]);
         printf("init: %p\n", x = [x init]);
         printf("alloc: %p\n", x = [NSMutableArray alloc]);
         printf("init: %p\n", x = [x init]);
}

The output on my system:
  class: 0xa07ec7b8
  alloc: 0x875a0
  init: 0x8e7a0
  alloc: 0x875a0
  init: 0x8e7c0

Note that return value of the two calls of alloc is the same, and 
different from the return value of the corresponding init calls. 
Appearently 'alloc' just returns a kind of factory object, and 'init' 
is the one that actually allocates memory.

Further investigation shows that the return value of 'alloc' is a 
'NSPlaceholderMutableArray'. Actually it is probably that class and not 
an instance of it. Both 'x->isa->name' and 'x->isa->isa->name' are 
'NSPlaceholderMutableArray', if 'x' where an object I'd expect the 
second to be 'NSObject'.

I'm glad to find that the problem with NSArray is caused by a feature 
of Cocoa and is not a memory corrupting bug in PyObjC itself. That 
doesn't make it easier to actually fix it of course, but at least we 
can now start to think about how to really solve this instead of 
hunting down an elusive memory corruption
error.

Ronald