pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Subclassing in Interface Builder

[Dinu G. <gh...@da...>]

Tony Lownds:

> I am making a subclass of NSImageView in interface builder. The=20
> subclass does get made but overrided initializers don't seem to get=20
> called:
>
> class MyImageView(AutoBaseClass):
> =A0=A0=A0 def initWithFrame_(self, frame):
> =A0=A0=A0=A0=A0=A0=A0 self =3D NSImageView.initWithFrame_(self, frame)
> =A0=A0=A0=A0=A0=A0=A0 print "never gets here"
> =A0=A0=A0=A0=A0=A0=A0 return self
>
> Has anyone seen this before?

On 7 Jan. 2003 I posted a message titled "QuickTimeViewer demo
using PyObjC!" which will point you to an example implementing
something like this:

    http://python.net/~gherman/#QuickTimeViewer

Dinu

--
Dinu C. Gherman
......................................................................
"Fais de ta vie un r=EAve, et d'un r=EAve, une r=E9alit=E9."
(Antoine de Saint-Exup=E9ry)

[Pyobjc-dev] Subclassing in Interface Builder

[Tony L. <to...@lo...>]

Hi,

I am making a subclass of NSImageView in interface builder. The 
subclass does get made but overrided initializers don't seem to get 
called:

class MyImageView(AutoBaseClass):
     def initWithFrame_(self, frame):
         self = NSImageView.initWithFrame_(self, frame)
         print "never gets here"
         return self

Has anyone seen this before?

Thanks,
-Tony

Re: [Pyobjc-dev] unit tests from ObjC

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

On Thursday, Feb 20, 2003, at 03:23 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Monday, Feb 17, 2003, at 01:58 US/Eastern, Ronald Oussoren wrote:
>> I was thinking of writing 1 compiled module containing a small number 
>> of 'native' Objective-C classes (possibly 1), this would be part in 
>> Lib/objc/test. I'll start by creating a test that mirrors 
>> Examples/subclassing-objective-c.py.
>
> Sounds like a plan.  Do we need one per Cocoa and Foundation under the 
> assumption that (a) they need testing and (b) loading the objc tests 
> should not drag in the Cocoa [at least] or Foundation tests?

I've started on a module in Lib/objc/test, I'll check it in when I've 
automated the build procedure. I don't think we need native modules in 
AppKit or Foundation. We will be testing the very core of the bridge: 
message passing. If the unittests are good enough we don't have to add 
additional tests for additional frameworks.

Ronald

Re: [Pyobjc-dev] unit tests from ObjC

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

On Monday, Feb 17, 2003, at 01:58 US/Eastern, Ronald Oussoren wrote:
> I was thinking of writing 1 compiled module containing a small number 
> of 'native' Objective-C classes (possibly 1), this would be part in 
> Lib/objc/test. I'll start by creating a test that mirrors 
> Examples/subclassing-objective-c.py.

Sounds like a plan.  Do we need one per Cocoa and Foundation under the 
assumption that (a) they need testing and (b) loading the objc tests 
should not drag in the Cocoa [at least] or Foundation tests?

b.bum

Re: [Pyobjc-dev] unit tests from ObjC

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

On Sunday, Feb 16, 2003, at 22:37 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Sunday, Feb 16, 2003, at 16:30 US/Eastern, Ronald Oussoren wrote:
>> + BTW. The unittests don't cover calling Python from Objective-C at 
>> all!
> 	
> Agreed -- the unit tests don't cover testing from the perspective of 
> ObjC at all.   Not just calling from ObjC->Python, but any of the 
> bridging or other functionality from [subclassing, method addition, 
> etc] from the ObjC side.
>
> Certainly, the cross bridge calling is the big one to test.
>
> Maybe we should add a compiled test module to each of the test/ 
> directories?   The end result should not be offensively large and it 
> would likely contribute greatly to overall bridge quality....

I was thinking of writing 1 compiled module containing a small number 
of 'native' Objective-C classes (possibly 1), this would be part in 
Lib/objc/test. I'll start by creating a test that mirrors 
Examples/subclassing-objective-c.py.

Ronald

[Pyobjc-dev] unit tests from ObjC

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

On Sunday, Feb 16, 2003, at 16:30 US/Eastern, Ronald Oussoren wrote:
> + BTW. The unittests don't cover calling Python from Objective-C at 
> all!
	
Agreed -- the unit tests don't cover testing from the perspective of 
ObjC at all.   Not just calling from ObjC->Python, but any of the 
bridging or other functionality from [subclassing, method addition, 
etc] from the ObjC side.

Certainly, the cross bridge calling is the big one to test.

Maybe we should add a compiled test module to each of the test/ 
directories?   The end result should not be offensively large and it 
would likely contribute greatly to overall bridge quality....

b.bum

Re: [Pyobjc-dev] toplevel modules

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

On Sunday, Feb 16, 2003, at 14:41 US/Eastern, Ronald Oussoren wrote:
> I'm getting worried about the toplevel modules/packages introduced by 
> PyObjC, especially after introducing 3 new ones while playing around 
> with the PreferencePanes framework (none of these are in CVS at the 
> moment).
>
> We currently introduce 4 toplevel packages, the bridge itself and 
> wrappers for Foundation, AppKit and AddressBook. If the hacking I'm 
> doing on Python based plugins ends up with something usefull there 
> will also be PreferencePanes, ScreenSaver and InterfaceBuilder 
> packages.
>
> The reason I'm starting to get worried is that both AddressBook and 
> InterfaceBuilder are not only Cocoa frameworks but also 
> AppleScriptable applications. From my limited research I deduct that 
> the Python interface to the AppleScript functionality in AddressBook 
> would also be in a module named AddressBook if MacPython would have 
> such a convenience module (which is doesn't) [e.g. try 'import 
> CodeWarrior', you get a module that allows access to CodeWarrior 
> through its AppleScript interface].
>
> Another reason for worries is that AddressBook also has a C API 
> (although just using PyObjC would probably be easier). Other 
> frameworks might also have both a C and Objective-C API, which might 
> lead to conflicts if both versions are wrapped (DiskRecording seems to 
> have both C and Objective-C APIs).

Agreed.   Two thoughts.

First:   We should split out the optional frameworks that build on top 
of PyObjC but are not a part of the core.   Preferences, Address Book, 
NetInfo [a personal plaything I have been hacking on], and others into 
a new top level project in the PyObjC repository.  "Modules" or 
"ThirdParty" or "Optional" or something.

Each additional framework should have its own root, its own setup.py, 
etc...

Second:  maybe we should reconsider importing things through the pyobjc 
root?   I.e. 'from pyobjc import AddressBook'.  The goal would be to 
use 'pyobjc' as a root namespace through which all pyobjc related 
modules are imported whether they are a part of the core or an optional 
add on.

I know that the primary opposition is that 'from pyobjc.AppKit import 
*' is ugly and that the goal of pyobjc is to effectively make it as 
transparent as possible, but I think there is real value in 
perpetuating a consistent hierarchical namespace across the solution.  
In particular, that the AppKit is being glued into Python via PyObjC 
is, and always will be, a significant bit of knowledge.   'from pyobjc 
import AppKit' or 'from pyobjc.AppKit import *' gives the developer a 
keyword through which to figure out what the heck is going on.

I always like to apply the Google test:

If I search for 'AppKit' or 'AppKit python', PyObjC doesn't appear or 
is fairly far down the list.  If I search for 'pyobjc appkit', it is 
obviously one of the first hits...

Imagine that you are a developer who downloaded a random app and 
cracked it open to discover MyAppDelegate.py.   You open up that odd 
little source file and see that one of the first statements is an 
import of the AppKit -- 'from pyobjc.AppKit import *' provides you with 
a lot more of a chance of finding out what is really going on than just 
a 'from AppKit import *'....

b.bum

[Pyobjc-dev] toplevel modules

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

I'm getting worried about the toplevel modules/packages introduced by 
PyObjC, especially after introducing 3 new ones while playing around 
with the PreferencePanes framework (none of these are in CVS at the 
moment).

We currently introduce 4 toplevel packages, the bridge itself and 
wrappers for Foundation, AppKit and AddressBook. If the hacking I'm 
doing on Python based plugins ends up with something usefull there will 
also be PreferencePanes, ScreenSaver and InterfaceBuilder packages.

The reason I'm starting to get worried is that both AddressBook and 
InterfaceBuilder are not only Cocoa frameworks but also AppleScriptable 
applications. From my limited research I deduct that the Python 
interface to the AppleScript functionality in AddressBook would also be 
in a module named AddressBook if MacPython would have such a 
convenience module (which is doesn't) [e.g. try 'import CodeWarrior', 
you get a module that allows access to CodeWarrior through its 
AppleScript interface].

Another reason for worries is that AddressBook also has a C API 
(although just using PyObjC would probably be easier). Other frameworks 
might also have both a C and Objective-C API, which might lead to 
conflicts if both versions are wrapped (DiskRecording seems to have 
both C and Objective-C APIs).

Opinions?

Ronald

Re: [Pyobjc-dev] threads + autoreleasepools

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

Ronald Oussoren wrote:

> >>>> NSAutoreleasePool.alloc().init()
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool
> > retain]: Cannot retain an autorelease pool
> >>>>
> >
> > Any wisdom? Or is it a bug?
> 
> It is a bug. Are you using libffi?

Yup.

> I only get this error when not
> using libffi. 

I just tried again after cvs up, same thing.

> The problem is that NSInvocation seems to call retain
> on the 'self' argument of the invocation.

Bill's pyobjcPushPool/pyobjcPopPool stuff works fine, and it's arguably
a better solution. (But looking at an autorelease pool in my Python code
_does_ make make stomache turn ;-)

> BTW. I'm not entirely sure that the bridge itself it thread-safe.

I'll let you know when it crashes ;-)

Just

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc OC_PythonString.[hm]

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

On Sunday, Feb 16, 2003, at 14:14 US/Eastern, Ronald Oussoren wrote:
> I'm in favor of OC_PythonInt.[hm] and OC_PythonString.[hm] that were 
> in before you checked in a new OC_PythonString implementation.

OC_PythonString.[hm] has not been used in a long, long time.

In any case, I'm not attached to the implementation.   I would like to 
avoid the copying simply because strings are passed from Python->ObjC 
*a lot* [in my various PyObjC apps, I often end up with an NSDictionary 
as a backing store for a bunch of data with Python accessing stuff from 
that dictionary on a regular basis -- similarly, I'm frequently passing 
Python strings into various AppKit/Foundation API that require 
strings-- user defaults, notification center, etc...].

I suppose that for small strings it is largely irrelevant.

Whatever -- the only thing I feel strongly about is that the Python -> 
ObjC string conversion code that is currently stuck in objc_support.m 
should move to OC_PythonString and be invoked in a similar fashion as 
the rest of the code in that long if/else if/else if/else if block 
instead of the current chunk of code that is there.

b.bum

Re: [Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc OC_PythonString.[hm]

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

On Sunday, Feb 16, 2003, at 00:02 Europe/Amsterdam, Bill Bumgarner 
wrote:

> Oops.  I really didn't mean to check these in.  Instead of undoing it, 
> I'll leave it for now as this code is *not* used currently.
>
> They actually work -- all unit tests pass -- but do not work in that 
> they do not handle unicode correctly.
>
> I believe this is the direction we should move in when bridging 
> strings from Python into ObjC -- it can be made fast and it  will 
> often avoid copying the python buffers.   There are very likely 
> reference counting issues.   I'm not sure.
>
> If we don't use this stuff, OC_PythonString.[hm] should be removed 
> entirely from the project.

I'm in favor of OC_PythonInt.[hm] and OC_PythonString.[hm] that were in 
before you checked in a new OC_PythonString implementation.

I have my doubts regarding a speedup by not copying python strings. And 
as NSString is a unicode object the new-style OC_PythonString should 
probably only be used for python unicode objects.

Ronald

Re: [Pyobjc-dev] threads + autoreleasepools

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

On Saturday, Feb 15, 2003, at 23:05 Europe/Amsterdam, Just van Rossum 
wrote:

> When I use Cocoa functions in a different thread, I get lots of 
> warnings
> like this:
>
> 2003-02-15 22:57:19.522 python2.3[9157] *** _NSAutoreleaseNoPool():
> Object 0x2878170 of class NSInvocation autoreleased with no pool in
> place - just leaking
>
> However, creating an NSAutoreleasePool manually doesn't work the way I
> think it should work:
>
>>>> NSAutoreleasePool.alloc().init()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool
> retain]: Cannot retain an autorelease pool
>>>>
>
> Any wisdom? Or is it a bug?

It is a bug. Are you using libffi? I only get this error when not using 
libffi. The problem is that NSInvocation seems to call retain on the 
'self' argument of the invocation.

BTW. I'm not entirely sure that the bridge itself it thread-safe.

Ronald

Re: [Pyobjc-dev] threads + autoreleasepools

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

On Sunday, Feb 16, 2003, at 07:12 US/Eastern, Just van Rossum wrote:
> Your fix works great, thanks!

Cool!  And as an added bonus, it'll be ever so slightly faster when 
messaging into ObjC from Python -- one less object being shoved into 
the autorelease pool.   A few nanos here, a few there... ;-)

b.bum

Re: [Pyobjc-dev] threads + autoreleasepools

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

bb...@ma... wrote:

> > Btw. I still get one warning, just for calling
> > NSAutoreleasePool.pyobjcPushPool():
> >
> > 2003-02-16 00:15:59.062 python2.3[9275] *** _NSAutoreleaseNoPool():
> > Object 0x3bfa90 of class NSInvocation autoreleased with no pool in 
> > place
> > - just leaking
> >
> > Kindof a chicken & egg problem I suppose...
> 
> This is in your thread, correct?  

Yup.

> Any thread running w/a runloop will always have a top level
> autorelease pool.   Non looping threads do not -- hence the error
> message.

Right, I have no intention to have a run loop in this thread.

Your fix works great, thanks!

Just

Re: [Pyobjc-dev] gmane?

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

A request has been submitted to gmane.org.

b.bum

Re: [Pyobjc-dev] threads + autoreleasepools

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

On Saturday, Feb 15, 2003, at 18:18 US/Eastern, Just van Rossum wrote:
> Btw. I still get one warning, just for calling
> NSAutoreleasePool.pyobjcPushPool():
>
> 2003-02-16 00:15:59.062 python2.3[9275] *** _NSAutoreleaseNoPool():
> Object 0x3bfa90 of class NSInvocation autoreleased with no pool in 
> place
> - just leaking
>
> Kindof a chicken & egg problem I suppose...

This is in your thread, correct?   Any thread running w/a runloop will 
always have a top level autorelease pool.   Non looping threads do not 
-- hence the error message.

If so, then yes -- the NSInvocation used to cross the bridge (?) is 
being leaked.

That is obviously bad.

The stoopid, by-the-API, fix is to do something like:

     p = [NSAutoreleasePool new];
     inv = [NSInvocation invocationWithMethodSignature: ...]
     [inv retain];
     [p release];

Of course, this is a grossly inefficient thing to add to *every single 
method invocation from Python -> ObjC*.

As it turns out, NSInvocation *does* implement 
-initWithMethodSignature:.  It just isn't declared in the header.  I 
don't know why.  Unit tests still pass.   Code Committed pending a peer 
flogging to take it out.  I'm filing a bug against the Foundation to 
advertise that method -- it is obviously *required* if you want to 
build a bridge that doesn't leak and doesn't produce lots of stoopid 
warning messages.

Now to clean up some of the unit tests that are currently failing 
because of other fixes that have been applied recently....

b.bum

Re: [Pyobjc-dev] threads + autoreleasepools

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

Btw. I still get one warning, just for calling
NSAutoreleasePool.pyobjcPushPool():

2003-02-16 00:15:59.062 python2.3[9275] *** _NSAutoreleaseNoPool():
Object 0x3bfa90 of class NSInvocation autoreleased with no pool in place
- just leaking

Kindof a chicken & egg problem I suppose...

just

Re: [Pyobjc-dev] threads + autoreleasepools

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

bb...@ma... wrote:

> On Saturday, Feb 15, 2003, at 17:52 US/Eastern, Just van Rossum wrote:
> > Hm, this crashes when I use it from a different thread (shortly
> > after calling pyobjcPopPool()). I wonder whether this has anything
> > to do with autoGIL :-/
> 
> You are popping in the same thread that you pushed the release pool, 
> correct?   Release pools are thread specific.

I am, but somehow now that I cvs up'ed your latest changes things seem
to work fine. Thanks!

Just

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc OC_PythonString.[hm]

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

Oops.  I really didn't mean to check these in.  Instead of undoing it, 
I'll leave it for now as this code is *not* used currently.

They actually work -- all unit tests pass -- but do not work in that 
they do not handle unicode correctly.

I believe this is the direction we should move in when bridging strings 
from Python into ObjC -- it can be made fast and it  will often avoid 
copying the python buffers.   There are very likely reference counting 
issues.   I'm not sure.

If we don't use this stuff, OC_PythonString.[hm] should be removed 
entirely from the project.

b.bum

On Saturday, Feb 15, 2003, at 17:56 US/Eastern, Bill Bumgarner wrote:

> Update of /cvsroot/pyobjc/pyobjc/Modules/objc
> In directory sc8-pr-cvs1:/tmp/cvs-serv16696/Modules/objc
>
> Modified Files:
> 	OC_PythonString.h OC_PythonString.m pyobjc.h
> Log Message:
> Fixed autoreleasepool silliness.
>
> Index: OC_PythonString.h
> ===================================================================
> RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/OC_PythonString.h,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -C2 -d -r1.3 -r1.4
> *** OC_PythonString.h	18 Oct 2002 10:03:14 -0000	1.3
> --- OC_PythonString.h	15 Feb 2003 22:56:33 -0000	1.4
> ***************
> *** 1,44 ****
> ! /* Copyright (c) 1996,97 by Lele Gaifax.  All Rights Reserved
> !  *
> !  * This software may be used and distributed freely for any purpose
> !  * provided that this notice is included unchanged on any and all
> !  * copies. The author does not warrant or guarantee this software in
> !  * any way.
> !  *
> !  * This file is part of the PyObjC package.
> !  *
> !  * RCSfile: OC_PythonString.h,v
> !  * Revision: 1.8
> !  * Date: 1998/01/04 17:59:21
> !  *
> !  * Created Thu Sep  5 19:46:45 1996.
> !  */
>
> ! #ifndef _OC_PythonString_H
> ! #define _OC_PythonString_H
>
> ! #include "OC_PythonObject.h"
>
> ! /*#C This class wraps a PyString object, making it easier to handle 
> this
> !   kind of objects from Objective-C.  */
> ! @interface OC_PythonString : OC_PythonObject
>   {
>   }
>
> ! /*#M Returns a new autoreleased PyString object with @var{str} of
> !   length @var{size} as contents. */
> ! + (id <PythonObject>) fromString:(char *) str andSize:(int) size;
> !
> ! //#M Returns a new autoreleased PyString object with @var{str} as 
> contents.
> ! + (id <PythonObject>) fromString:(char *) str;
> !
> ! //#M Returns the size of the string.
> ! - (int) size;
> !
> ! //#M Returns the ``C'' equivalent.
> ! - (char *) asString;
> !
> ! @end /* OC_PythonString class interface */
> !
> !
> ! #endif /* _OC_PythonString_H */
> --- 1,29 ----
> ! #ifndef OC_PythonString_h
> ! #define OC_PythonString_h
>
> ! #import <CoreFoundation/CoreFoundation.h>
> ! #import <Foundation/NSString.h>
> ! #include "Python.h"
>
> ! /*
> !  * OC_PythonString - Objective-C proxy class for Python strings
> !  *
> !  * Instances of this class are used as proxies for Python strings
> !  * when these are passed to Objective-C code. Because this class is
> !  * a subclass of NSString Python sequences can be used everywhere
> !  * where NSString is used.  Python strings are immutable.
> !  */
>
> ! @interface OC_PythonString:NSString
>   {
> +     PyObject* value;
> +     PyObject* _internalRep;
> +     CFStringRef stringValue;
>   }
>
> ! +newWithPythonObject:(PyObject*)value;
> ! -initWithPythonObject:(PyObject*)value;
> ! -(void)dealloc;
> ! -(PyObject*)__pyobjc_PythonObject__;
> ! @end
> ! #endif
>
> Index: OC_PythonString.m
> ===================================================================
> RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/OC_PythonString.m,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -C2 -d -r1.4 -r1.5
> *** OC_PythonString.m	5 Feb 2003 21:08:51 -0000	1.4
> --- OC_PythonString.m	15 Feb 2003 22:56:33 -0000	1.5
> ***************
> *** 1,49 ****
> - /* Copyright (c) 1996,97 by Lele Gaifax.  All Rights Reserved
> -  *
> -  * This software may be used and distributed freely for any purpose
> -  * provided that this notice is included unchanged on any and all
> -  * copies. The author does not warrant or guarantee this software in
> -  * any way.
> -  *
> -  * This file is part of the PyObjC package.
> -  *
> -  * RCSfile: OC_PythonString.m,v
> -  * Revision: 1.9
> -  * Date: 1998/01/04 17:59:22
> -  *
> -  * Created Thu Sep  5 19:49:36 1996.
> -  */
> -
>   #include "OC_PythonString.h"
>
>   @implementation OC_PythonString
>
> ! + (id <PythonObject>) fromString:(char *) str andSize:(int) size
>   {
> ! 	PyObject *pystr = PyString_FromStringAndSize (str, size);
> ! 	id <PythonObject> result = [self newWithObject:pystr];
>
> ! 	Py_DECREF(pystr);
> ! 	return result;
>   }
>
> ! + (id <PythonObject>) fromString:(char *) str
>   {
> ! 	PyObject *pystr = PyString_FromString(str);
> ! 	id <PythonObject> result = [self newWithObject:pystr];
> !
> ! 	Py_DECREF(pystr);
> ! 	return result;
>   }
>
> ! - (int) size
>   {
> ! 	return PyString_Size([self  pyObject]);
>   }
>
> ! - (char *) asString
>   {
> ! 	return PyString_AsString([self  pyObject]);
>   }
>
> ! @end /* OC_PythonString class implementation */
> --- 1,84 ----
>   #include "OC_PythonString.h"
> + #include "pyobjc.h"
> + #include "objc_support.h"
>
>   @implementation OC_PythonString
> + +newWithPythonObject:(PyObject*)v;
> + {
> +     OC_PythonString* res = [[OC_PythonString alloc] 
> initWithPythonObject:v];
> +     [res autorelease];
> +     return res;
> + }
>
> ! -initWithPythonObject:(PyObject*)v;
>   {
> !     value = v;
>
> !     if (PyString_Check(value)) {
> ! 	char *buffer;
> ! 	int length;
> ! 	int result;
> !
> ! 	result = PyString_AsStringAndSize(value, &buffer, &length);
> ! 	if(result == -1) {
> ! 	    ObjCErr_ToObjC();
> ! 	    [self release];
> ! 	    return nil; // not reached
> ! 	}
> ! 	stringValue = CFStringCreateWithCStringNoCopy(NULL,
> ! 						      buffer,
> ! 						      kCFStringEncodingUTF8,
> ! 						      kCFAllocatorNull);
> ! 	_internalRep = NULL;
> !     } else if (PyUnicode_Check(value)) {
> ! 	char *buffer;
> ! 	int length;
> ! 	int result;
> ! #warning Is there a way to determine what the encoding of value is 
> and instantiate a CFString directly?
> ! 	_internalRep = PyUnicode_AsUTF8String(value);
> ! 	result = PyString_AsStringAndSize(_internalRep, &buffer, &length);
> ! 	if(result == -1) {
> ! 	    ObjCErr_ToObjC();
> ! 	    [self release];
> ! 	    return nil;
> ! 	}
> !
> ! 	stringValue = CFStringCreateWithCStringNoCopy(NULL,
> ! 						      buffer,
> ! 						      kCFStringEncodingUTF8,
> ! 						      kCFAllocatorNull);
> !     }
> !
> !     Py_INCREF(value);
> !
> !     return self;
>   }
>
> ! -(PyObject*)__pyobjc_PythonObject__
>   {
> ! 	Py_INCREF(value);
> ! 	return value;
>   }
>
> ! -(void)dealloc
>   {
> !     CFRelease(stringValue);
> !     Py_XDECREF(value);
> !     Py_XDECREF(_internalRep);
> !     [super dealloc];
>   }
>
> ! - (unsigned int)length;
>   {
> !     int result;
> !     result = CFStringGetLength(stringValue);
> !     return result;
>   }
>
> ! - (unichar)characterAtIndex:(unsigned)index;
> ! {
> !     UniChar result;
> !     result = CFStringGetCharacterAtIndex(stringValue, index);
> !     return result;
> ! }
> ! @end
>
> Index: pyobjc.h
> ===================================================================
> RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/pyobjc.h,v
> retrieving revision 1.20
> retrieving revision 1.21
> diff -C2 -d -r1.20 -r1.21
> *** pyobjc.h	8 Feb 2003 21:41:22 -0000	1.20
> --- pyobjc.h	15 Feb 2003 22:56:33 -0000	1.21
> ***************
> *** 13,16 ****
> --- 13,17 ----
>   #include "OC_PythonArray.h"
>   #include "OC_PythonDictionary.h"
> + #include "OC_PythonString.h"
>   #include "super-call.h"
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> pyobjc-checkins mailing list
> pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-checkins
>
b.bum
In cyberspace, no one can hear you laugh.

Re: [Pyobjc-dev] threads + autoreleasepools

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

On Saturday, Feb 15, 2003, at 17:52 US/Eastern, Just van Rossum wrote:
> Hm, this crashes when I use it from a different thread (shortly after
> calling pyobjcPopPool()). I wonder whether this has anything to do with
> autoGIL :-/

You are popping in the same thread that you pushed the release pool, 
correct?   Release pools are thread specific.

On Saturday, Feb 15, 2003, at 17:37 US/Eastern, Just van Rossum wrote:
>> But I agree with you, I think alloc/init for NSAutoreleasePool should
>> work as we're all used to.
>
> Well, not me, as I'm still pretty much a Cocoa newbie ;-)

I have always thought that the autorelease pool implementation in the 
Foundation was broken.   Autorelease pools are stack based and are 
context dependent upon the thread.  Therefore, the NSAutoreleasePool 
API should have a push/pop that does the right thing on a thread aware 
basis.

Which is exactly what the aforementioned category does (see below, it 
is short) -- does now, anyway, I just fixed a stupid memory leak in it. 
  Ooops.   The category isn't exactly fast, but the developer should 
never push/pop that many release pools anyway.

static NSString *_threadPoolIdentifier = @"PyObjC:  NSThread 
AutoreleasePool Identifier.";

@interface NSAutoreleasePool(PyObjCPushPopSupport)
@end
@implementation NSAutoreleasePool (PyObjCPushPopSupport)
+ (NSMutableArray *) pyobjcPoolStackForCurrentThread
{
   NSMutableDictionary *threadDictionary = [[NSThread currentThread] 
threadDictionary];
   NSMutableArray *poolStack;

   poolStack = [threadDictionary objectForKey: _threadPoolIdentifier];
   if (!poolStack) {
     poolStack = [NSMutableArray array];
     [threadDictionary setObject: poolStack forKey: 
_threadPoolIdentifier];
   }

   return poolStack;
}

+ (void) pyobjcPushPool
{
   NSAutoreleasePool *p = [[NSAutoreleasePool alloc] init];
   [[self pyobjcPoolStackForCurrentThread] addObject: [NSValue 
valueWithNonretainedObject: p]];
}

+ (void) pyobjcPopPool
{
   NSMutableArray *poolStack = [self pyobjcPoolStackForCurrentThread];
   NSValue *pValue = [poolStack lastObject];
   [[pValue objectValue] release];
   [poolStack removeLastObject];
}
@end

Re: [Pyobjc-dev] threads + autoreleasepools

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

bb...@ma... wrote:

> A bug.  Sort of.
> 
> I added a category to NSAutoreleasePool to workaround the problem.   
> See the test_nsautoreleasepool.py for details.
> 
>          NSAutoreleasePool.pyobjcPushPool()
> ....
>          NSAutoreleasePool.pyobjcPopPool()

Hm, this crashes when I use it from a different thread (shortly after
calling pyobjcPopPool()). I wonder whether this has anything to do with
autoGIL :-/

Just

Re: [Pyobjc-dev] threads + autoreleasepools

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

On Saturday, Feb 15, 2003, at 17:05 US/Eastern, Just van Rossum wrote:
> However, creating an NSAutoreleasePool manually doesn't work the way I
> think it should work:
>
>>>> NSAutoreleasePool.alloc().init()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool
> retain]: Cannot retain an autorelease pool
>>>>
>
> Any wisdom? Or is it a bug?

A bug.  Sort of.

I added a category to NSAutoreleasePool to workaround the problem.   
See the test_nsautoreleasepool.py for details.

         NSAutoreleasePool.pyobjcPushPool()
...
         NSAutoreleasePool.pyobjcPopPool()

recycle_autorelease_pool() is documented as not to be used by the 
general public.   Looking at it, I'm not sure why the global release 
pool exists at all.

b.bum

Re: [Pyobjc-dev] threads + autoreleasepools

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

Bob Ippolito wrote:

> I think you might have to do: objc.recycle_autorelease_pool() ?

Hm, that does seem to work. Its doc string scares me, though:

"""This 'releases' the global autorelease pool and creates a new one.
This method is for system use only"""

global? system? brrr... Is it ok to use it at all in a different thread?

> But I agree with you, I think alloc/init for NSAutoreleasePool should 
> work as we're all used to.

Well, not me, as I'm still pretty much a Cocoa newbie ;-)

Thanks,

Just

Re: [Pyobjc-dev] threads + autoreleasepools

[Bob I. <bo...@re...>]

On Saturday, Feb 15, 2003, at 17:05 America/New_York, Just van Rossum 
wrote:

> When I use Cocoa functions in a different thread, I get lots of 
> warnings
> like this:
>
> 2003-02-15 22:57:19.522 python2.3[9157] *** _NSAutoreleaseNoPool():
> Object 0x2878170 of class NSInvocation autoreleased with no pool in
> place - just leaking
>
> However, creating an NSAutoreleasePool manually doesn't work the way I
> think it should work:
>

I think you might have to do: objc.recycle_autorelease_pool() ?

But I agree with you, I think alloc/init for NSAutoreleasePool should 
work as we're all used to.

-bob

[Pyobjc-dev] threads + autoreleasepools

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

When I use Cocoa functions in a different thread, I get lots of warnings
like this:

2003-02-15 22:57:19.522 python2.3[9157] *** _NSAutoreleaseNoPool():
Object 0x2878170 of class NSInvocation autoreleased with no pool in
place - just leaking

However, creating an NSAutoreleasePool manually doesn't work the way I
think it should work:

>>> NSAutoreleasePool.alloc().init()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: NSInvalidArgumentException - *** -[NSAutoreleasePool
retain]: Cannot retain an autorelease pool
>>> 

Any wisdom? Or is it a bug?

Just