pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

What we would really want (at least, I think that's what we really 
want:-) is a hook in the Python object deallocation. If we would create 
an ObjC proxy for every Python object that is every shoved our way and 
have an easy way to find the proxy for a given Python object then the 
only thing we would need is a notification that the Python object is 
going to go away. If the proxy starts out life with a retain count of 1 
(signifying the "reference" the Python object has to it) then the 
Python object going away would cause the proxy to turn the weak ref to 
the Python object into a normal ref (thereby reviving the Python 
object) and decrease its own retain count.  As soon as the proxy retain 
count drops to zero (which could be immediately, or it could be later 
if ObjC code still has references to the proxy (and therefore to the 
Python object)) the Python object would be decreffed.

If I'm not mistaken this would give perfectly normal semantics on each 
side of the bridge.

I'm not familiar enough with weak references, but I'm pretty sure this 
signalling isn't part of its services, or is it? Is there another way 
we could fake this (with GC, for instance)?
--
- 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] [ pyobjc-Bugs-673381 ] Inappropriate abort() calls.

[SourceForge.net <no...@so...>]

Bugs item #673381, was opened at 2003-01-23 22:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=673381&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inappropriate abort() calls.

Initial Comment:
One example (I'm sure there are more): the code that converts Python arguments to a selector call aborts the process it it comes across an argument type it can't handle. This is incredibly annoying if you're playing around with objects interactively. Here's a simple example I came across the other day:

  >>> from Foundation import *
  >>> from AppKit import *
  >>> NSColor.redColor().getRed_green_blue_alpha_()
  PyObjC: objc_skip_typespec: Unhandled type 'o' (111)
  Abort

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=673381&group_id=14534

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Project Templates/Cocoa-Python Document-based Application MyDocument.py,1.1,1.2

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

On Thursday, Jan 23, 2003, at 16:26 US/Eastern, Just van Rossum wrote:
> Update of /cvsroot/pyobjc/pyobjc/Project Templates/Cocoa-Python=20
> Document-based Application
> In directory sc8-pr-cvs1:/tmp/cvs-serv22938
>
> Modified Files:
> 	MyDocument.py
> Log Message:
> Fixed non-ascii characters, this file was probably checked in with the
> wrong encoding. Fixes bug #670739. (And what a terrible idea to use
> non-ascii chars for macro expansion to begin with :-( )
>
> TODO: for Python 2.3, the source encoding can and should be defined in=20=

> the
> source. There is a new directive for that, but I don't know the =
details
> off-hand. Without it, Python 2.3 warns that it uses non ascii=20
> characters
> without being able to establish the encoding (which I think then=20
> defaults
> to latin-1, to be compatible with Python 2.2 and earlier). This should
> only affect the template documents, in all other sources we should=20
> avoid
> non-ascii characters.

Yeah, pretty odd -- but there is a history behind it.   The=20
=ABcharacters=BB were used in the original Edit.app on NeXTSTEP-- all =
the=20
way back to 0.8, if I remember correctly-- to indicate fields in text=20
documents.   You could hit shift-cmd-N to move to the next field. =20
Very, very handy.   Actually, Edit.app was one of the best plain-text=20
editors around -- had a number of *amazing* features that were=20
implemented in a unique and very elegant manner.  (Yes, I just verified=20=

that it was shift-cmd-N on our NS 3.3 cube :-).

There shouldn't be a need to define the encoding as the non-ASCII=20
characters will *never* appear in projects created from that template=20
unless the template has a bug.  Given that it is nearly impossible to=20
directly edit the template project without blowing things up, the=20
Python should basically never see the non-ASCII characters.

(thanks -- I was going to fix this on the train ride home)

b.bum=

Re: [Pyobjc-dev] I posted a news item...

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

On Thursday, Jan 23, 2003, at 22:02 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>>> Uh, whether I can use a class may depend on the _order_ in which I
>>> import AppKit and Foundation?!?
>>
>> Yuck, this shouldn't be. I'll look into it.
>
> Superficially looking it seems that the "import Foundation" in
> AppKit/__init__.py could be moved up to become the first import. I 
> would
> guess this fixes it.

Technically it would hide the problem, not fix it ;-) That said, I'll 
move the import & create a bugreport if this is a hard problem.

>
>>> Btw. are we using the SF bug tracker? Although it sucks, it's a lot
>>> better than letting bug reports rot in mailing list archives.
>>
>> Not really, but I think we've reached the point where using the
>> tracker is usefull (e.g. bugs get compilicated enough that I cannot
>> fix them while typing a reply ;-))
>>
>> Without having used the tracker (other than for filing bugs) I do see
>> a problem: I'm not organized enough to regularly check if their are
>> new bugs in the tracker. I'd therefore prefer if new bugreports are
>> mailed somewhere (SF seems to have an option for that)
>
> Same here. While the project is fairly small, I think it's a good idea
> to just forward all reports to the dev list. Hm, or reuse the checkins
> list for it? Yeah, that doesn't sound too bad.

I've just modified the bug tracker preferences: All new bug reports 
will be posted to the dev list.

Ronald

Re: [Pyobjc-dev] I posted a news item...

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

Ronald Oussoren wrote:

> > Uh, whether I can use a class may depend on the _order_ in which I
> > import AppKit and Foundation?!?
> 
> Yuck, this shouldn't be. I'll look into it.

Superficially looking it seems that the "import Foundation" in
AppKit/__init__.py could be moved up to become the first import. I would
guess this fixes it.

> > Btw. are we using the SF bug tracker? Although it sucks, it's a lot
> > better than letting bug reports rot in mailing list archives.
> 
> Not really, but I think we've reached the point where using the
> tracker is usefull (e.g. bugs get compilicated enough that I cannot
> fix them while typing a reply ;-))
> 
> Without having used the tracker (other than for filing bugs) I do see
> a problem: I'm not organized enough to regularly check if their are
> new bugs in the tracker. I'd therefore prefer if new bugreports are
> mailed somewhere (SF seems to have an option for that)

Same here. While the project is fairly small, I think it's a good idea
to just forward all reports to the dev list. Hm, or reuse the checkins
list for it? Yeah, that doesn't sound too bad.

Just

Re: [Pyobjc-dev] I posted a news item...

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

On Thursday, Jan 23, 2003, at 15:48 US/Eastern, Ronald Oussoren wrote:
> The most important requirement by far would be documentation. On the 
> technical side the most important missing features are threading 
> support, posing and categories (and dynamicly modifying existing 
> classes in general). That doesn't mean we should implement all these 
> before 0.9, but I do think we should try to implement them before a 
> 1.0 release.

Agreed.

I am in the middle of doing support for posing and categories because 
*I* need them for a project I'm working on...   I have some ideas on 
this front and I want to see if they'll work before bugging anyone else 
with 'em.

Documentation, documentation, documentation....

Brings up the fact that we should someday revisit the web site -- port 
it to some Python centric solution.  Webware+PTL seems to be fairly 
workable.  And, most importantly, move to using a Python based solution 
that lets us [hopefully automatically] compile the ReST documentation 
into HTML, etc.

.bubm

Re: [Pyobjc-dev] I posted a news item...

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

On Thursday, Jan 23, 2003, at 19:59 Europe/Amsterdam, Bill Bumgarner 
wrote:

> .... to pyobjc.sf.net that outlines recent progress.
>
> We have come a long way -- at some point, we need to think about 0.9 
> requirements.

The most important requirement by far would be documentation. On the 
technical side the most important missing features are threading 
support, posing and categories (and dynamicly modifying existing 
classes in general). That doesn't mean we should implement all these 
before 0.9, but I do think we should try to implement them before a 1.0 
release.

Ronald

Re: [Pyobjc-dev] I posted a news item...

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

On Thursday, Jan 23, 2003, at 20:22 Europe/Amsterdam, Just van Rossum 
wrote:

> Bill Bumgarner wrote:
>
>> ..... to pyobjc.sf.net that outlines recent progress.
>
> I saw it, great.
>
>> We have come a long way -- at some point, we need to think about 0.9
>> requirements.
>
> There is at least one issues that I think needs to be addressed: the
> code that converts Python arguments to a selector call aborts the
> process it it comes across an argument type it can't handle. This is
> incredibly annoying if you're playing around with objects 
> interactively.
> Here's a simple example I came across the other day:
>
>>>> from Foundation import *
>>>> from AppKit import *
>>>> NSColor.redColor().getRed_green_blue_alpha_()
>   PyObjC: objc_skip_typespec: Unhandled type 'o' (111)
>   Abort

I agree that we should try to remove all calls to abort unless we 
detect that the system is in such a mess that aborting is the only 
sensible thing to do. This specific instance is not necessary, but 
happens to indicate an easily fixable bug in the bridge.

>
> And while reproducing the above I came across something very strange,
> which somehow also needs fixing:

[ example removed]

> Uh, whether I can use a class may depend on the _order_ in which I
> import AppKit and Foundation?!?

Yuck, this shouldn't be. I'll look into it.

>
> Btw. are we using the SF bug tracker? Although it sucks, it's a lot
> better than letting bug reports rot in mailing list archives.

Not really, but I think we've reached the point where using the tracker 
is usefull (e.g. bugs get compilicated enough that I cannot fix them 
while typing a reply ;-))

Without having used the tracker (other than for filing bugs) I do see a 
problem: I'm not organized enough to regularly check if their are new 
bugs in the tracker. I'd therefore prefer if new bugreports are mailed 
somewhere (SF seems to have an option for that)

Ronald

[Pyobjc-dev] libffi snapshot install instructions

[David E. <epp...@ic...>]

One change that would be helpful to include in the snapshot's INSTALL file 
(at least, I forgot to do this): instead of make install, you may need to 
run sudo make install (depending on the prefix configuration).
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] I posted a news item...

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

Bill Bumgarner wrote:

> ..... to pyobjc.sf.net that outlines recent progress.

I saw it, great.

> We have come a long way -- at some point, we need to think about 0.9
> requirements.

There is at least one issues that I think needs to be addressed: the
code that converts Python arguments to a selector call aborts the
process it it comes across an argument type it can't handle. This is
incredibly annoying if you're playing around with objects interactively.
Here's a simple example I came across the other day:

  >>> from Foundation import *
  >>> from AppKit import *
  >>> NSColor.redColor().getRed_green_blue_alpha_()
  PyObjC: objc_skip_typespec: Unhandled type 'o' (111)
  Abort

And while reproducing the above I came across something very strange,
which somehow also needs fixing:

Session #1:

  >>> import AppKit
  >>> AppKit.NSColor
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  AttributeError: 'module' object has no attribute 'NSColor'
  >>> 

Session #2:

  >>> import AppKit
  >>> import Foundation
  >>> AppKit.NSColor
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  AttributeError: 'module' object has no attribute 'NSColor'
  >>> 

Session #3:

  >>> import Foundation
  >>> import AppKit
  >>> AppKit.NSColor
  <objective-c class NSColor at 0xa309d410>
  >>> 

Uh, whether I can use a class may depend on the _order_ in which I
import AppKit and Foundation?!?

Btw. are we using the SF bug tracker? Although it sucks, it's a lot
better than letting bug reports rot in mailing list archives.

> I would like to see more unit tests as it provides an excellent
> foundation for documentation [i.e. what features exist and how they
> are expected to work] while ensuring quality/consistency as we move
> forward.

A very good thing indeed. I'll keep my eyes open for unittest
opportunities.

Just

[Pyobjc-dev] I posted a news item...

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

.... to pyobjc.sf.net that outlines recent progress.

We have come a long way -- at some point, we need to think about 0.9 
requirements.

I would like to see more unit tests as it provides an excellent 
foundation for documentation [i.e. what features exist and how they are 
expected to work] while ensuring quality/consistency as we move forward.

b.bum

Re: [Pyobjc-dev] ***ALERT*** Non-FFI builds are completely broken right now

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

This fixes the problems I was seeing!

--Bill Noon

On Thursday, January 23, 2003, at 01:48 AM, Bill Bumgarner wrote:

> If you are building PyObjC without Ronald's recently mentioned FFI 
> support, the resulting build is completely broken.
>
> Errors such as 'objc.error: Class NSObject does not respond to alloc' 
> and 'RuntimeError: Cannot rescan method table' when running the unit 
> tests (or your own code), then it is likely because of this problem 
> (full log enclosed -- two of the unit tests normally fail; a  kind of 
> TODO item for the developers).

Re: [Pyobjc-dev] ***ALERT*** Non-FFI builds are completely broken right now

[Ronald_Oussoren <ous...@ci...>]

On Thu, 23 Jan 2003 02:13:46 -0500, Bill Bumgarner wrote
> 
> (Ronald:  Maybe we should stick libFFI.a and the two/three headers 
> into pyobjc's CVS directly?)
Only if it is for a short period. I like adding the libFFI sources better. 
Even then these files should be clearly marked as being an external project 
and we should avoid making changes to those sources. 

Ronald

Re: [Pyobjc-dev] ***ALERT*** Non-FFI builds are completely broken right now

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

On Thursday, Jan 23, 2003, at 01:52 US/Eastern, David Eppstein wrote:
> On 1/23/03 1:48 AM -0500 Bill Bumgarner <bb...@co...> wrote:
>> If you are going to build with FFI support-- it will eventually become
>> the only way to build pyobjc-- you will currently need to download the
>> libffi snapshot that Ronald put together.
>>
>> See...
>>
>>      http://sourceforge.net/project/showfiles.php?group_id=14534
>>
>> ... for the download link.  The tarball contains a 'README.ronald' 
>> file
>> with instructions.   I installed libffi with a prefix of /usr/local/  
>> and
>> it works fine.
>
> What (if anything) does this imply about the ability to produce 
> standalone apps that do not require installs of random libs in random 
> parts of the filesystem?

Good question -- I should have clarified that in the original message.

Nothing, at least nothing permanent.

One of the primary goals-- requirements really-- of PyObjC is that it 
continues to work with the stock Apple Python from standalone, 
double-clickable, "normal" applications.

Lib FFI is linked statically -- once PyObjC is built, the module can be 
copied into the app wrapper and shipped w/a standalone app just like 
you normally would.

The current state of affairs is suboptimal -- at some point, we will 
figure out how to stick libffi into the pyobjc source or build such 
that there isn't a prerequisite for building.  For the moment, it is a 
bit wonky -- while LibFFI support works very well [all unit tests that 
should pass do pass], the build environment needs to be cleaned a bit.

(Ronald:  Maybe we should stick libFFI.a and the two/three headers into 
pyobjc's CVS directly?)

b.bum

[Pyobjc-dev] ***ALERT*** Non-FFI builds are completely broken right now

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

[this all *seems* to be the case -- moving to non-ffi on my system  
broke everything.  rebuilding w/ffi fixed everything.  On my friend's  
system, he rebuilt once w/ffi and it was still broken... a second  
rebuild after grabbing the setup.py from the repository fixed things --  
but the first build may have been hosed.   In any case, something is  
definitely very broken right now.   All things considered, if it does  
turn out to be an ffi vs. non-ffi issue, I'm not totally opposed to  
dropping non-ffi builds -- largely depends on what GNUstep needs,  
AFAIAMC].

If you are building PyObjC without Ronald's recently mentioned FFI  
support, the resulting build is completely broken.

Errors such as 'objc.error: Class NSObject does not respond to alloc'  
and 'RuntimeError: Cannot rescan method table' when running the unit  
tests (or your own code), then it is likely because of this problem  
(full log enclosed -- two of the unit tests normally fail; a  kind of  
TODO item for the developers).

I have gone ahead and committed a setup.py with FFI support *enabled*.   
See variable at top of file.

If you are going to build with FFI support-- it will eventually become  
the only way to build pyobjc-- you will currently need to download the  
libffi snapshot that Ronald put together.

See...

     http://sourceforge.net/project/showfiles.php?group_id=14534

... for the download link.  The tarball contains a 'README.ronald' file  
with instructions.   I installed libffi with a prefix of /usr/local/  
and it works fine.


-- Running 'Lib/AppKit/test/test_nsbitmapimagerep.py'
Traceback (most recent call last):
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/objc/_convenience.py", line 30, in add_convenience_methods
     for sel in type_dict.values():
objc.error: Class NSObject does not respond to alloc
EE
======================================================================
ERROR: testImageData (__main__.TestNSBitmapImageRep)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/AppKit/test/test_nsbitmapimagerep.py", line 39, in  
testImageData
     i1 =  
NSBitmapImageRep.alloc().initWithBitmapDataPlanes_pixelsWide_pixelsHigh_ 
bitsPerSample_samplesPerPixel_hasAlpha_isPlanar_colorSpaceName_bytesPerR 
ow_bitsPerPixel_(dataPlanes, width, height, 8, 3, NO, YES,  
NSDeviceRGBColorSpace, 0, 0)
RuntimeError: Cannot rescan method table

======================================================================
ERROR: testInstantiation (__main__.TestNSBitmapImageRep)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/AppKit/test/test_nsbitmapimagerep.py", line 14, in  
testInstantiation
     i1 =  
NSBitmapImageRep.alloc().initWithBitmapDataPlanes_pixelsWide_pixelsHigh_ 
bitsPerSample_samplesPerPixel_hasAlpha_isPlanar_colorSpaceName_bytesPerR 
ow_bitsPerPixel_(dataPlanes, width, height, 8, 3, NO, NO,  
NSDeviceRGBColorSpace, 0, 0)
error: Class NSObject does not respond to alloc

----------------------------------------------------------------------
Ran 2 tests in 0.716s

FAILED (errors=2)
-- Done
-- Running 'Lib/Foundation/test/test_collections.py'
..
----------------------------------------------------------------------
Ran 2 tests in 0.024s

OK
-- Done
-- Running 'Lib/Foundation/test/test_nsarray.py'
....E...EE
======================================================================
ERROR: testRepeatedAllocInit (__main__.TestNSArrayInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsarray.py", line 9, in  
testRepeatedAllocInit
     a = NSArray.alloc().init()
error: Class NSObject does not respond to alloc

======================================================================
ERROR: test_varargConstruction (__main__.TestNSArrayInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsarray.py", line 150, in  
test_varargConstruction
     x = NSArray.alloc().initWithObjects_(1,2,3,4, None)
error: Class NSObject does not respond to alloc

======================================================================
ERROR: test_varargConstruction2 (__main__.TestNSArrayInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsarray.py", line 166, in  
test_varargConstruction2
     x = NSMutableArray.alloc().initWithObjects_(1,2,3,4, None)
error: Class NSObject does not respond to alloc

----------------------------------------------------------------------
Ran 10 tests in 0.244s

FAILED (errors=3)
-- Done
-- Running 'Lib/Foundation/test/test_nsautoreleasepool.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.004s

OK
-- Done
-- Running 'Lib/Foundation/test/test_nsdata.py'
EEETraceback (most recent call last):
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/objc/_convenience.py", line 30, in add_convenience_methods
     for sel in type_dict.values():
objc.error: Class NSData does not respond to dataWithBytes:length:
EE
======================================================================
ERROR: Test -bytes
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdata.py", line 32, in testBytes
     data = NSData.alloc().initWithBytes_length_(rawBytes, len(rawBytes))
error: Class NSObject does not respond to alloc

======================================================================
ERROR: Test +dataWithBytes:length:
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdata.py", line 20, in  
testDataWithBytes_length_
     data = NSData.dataWithBytes_length_(rawBytes, len(rawBytes))
error: Class NSData does not respond to dataWithBytes:length:

======================================================================
ERROR: Test -initWithBytes:length:
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdata.py", line 26, in  
testInitWithBytes_length_
     data = NSData.alloc().initWithBytes_length_(rawBytes, len(rawBytes))
error: Class NSObject does not respond to alloc

======================================================================
ERROR: Test -mutableBytes
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdata.py", line 46, in  
testMutableBytes
     mutableData = NSMutableData.dataWithBytes_length_(rawBytes,  
len(rawBytes))
RuntimeError: Cannot rescan method table

======================================================================
ERROR: Test data of different lengths.
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdata.py", line 67, in  
testVariousDataLengths
     mutableData = NSMutableData.dataWithBytes_length_(bigRawBytes,  
len(bigRawBytes))
error: Class NSData does not respond to dataWithBytes:length:

----------------------------------------------------------------------
Ran 5 tests in 0.030s

FAILED (errors=5)
-- Done
-- Running 'Lib/Foundation/test/test_nsdictionary.py'
..EEE
======================================================================
ERROR: testRepeatedAllocInit (__main__.TestNSDictionaryInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdictionary.py", line 9, in  
testRepeatedAllocInit
     d = NSDictionary.alloc().init()
error: Class NSObject does not respond to alloc

======================================================================
ERROR: test_varargConstruction (__main__.TestNSDictionaryInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdictionary.py", line 48, in  
test_varargConstruction
     v = NSDictionary.alloc().initWithObjects_forKeys_([1,2,3,4],  
['one', 'two', 'three', 'four'])
error: Class NSObject does not respond to alloc

======================================================================
ERROR: test_varargConstruction2 (__main__.TestNSDictionaryInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsdictionary.py", line 70, in  
test_varargConstruction2
     v = NSMutableDictionary.alloc().initWithObjects_forKeys_([1,2,3,4],  
['one', 'two', 'three', 'four'])
error: Class NSObject does not respond to alloc

----------------------------------------------------------------------
Ran 5 tests in 0.023s

FAILED (errors=3)
-- Done
-- Running 'Lib/Foundation/test/test_nsenumerator.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.041s

OK
-- Done
-- Running 'Lib/Foundation/test/test_nsexception.py'
Traceback (most recent call last):
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/objc/_convenience.py", line 45, in add_convenience_methods
     for name, value in v:
objc.error: Class NSObject does not respond to alloc
E
======================================================================
ERROR: testRepeatedAllocInit (__main__.TestNSExceptionInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsexception.py", line 9, in  
testRepeatedAllocInit
     a = NSException.alloc().initWithName_reason_userInfo_( "Bogus", "A  
bad reason", { "foo" : "bar" } )
RuntimeError: Cannot rescan method table

----------------------------------------------------------------------
Ran 1 test in 0.016s

FAILED (errors=1)
-- Done
-- Running 'Lib/Foundation/test/test_nsnumber.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.011s

OK
-- Done
-- Running 'Lib/Foundation/test/test_nsobject.py'
..E
======================================================================
ERROR: testRepeatedAllocInit (__main__.TestNSObjectInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsobject.py", line 24, in  
testRepeatedAllocInit
     a = NSObject.alloc().init()
error: Class NSObject does not respond to alloc

----------------------------------------------------------------------
Ran 3 tests in 0.012s

FAILED (errors=1)
-- Done
-- Running 'Lib/Foundation/test/test_nsset.py'
..EEE
======================================================================
ERROR: testRepeatedAllocInit (__main__.TestNSSetInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsset.py", line 9, in  
testRepeatedAllocInit
     a = NSSet.alloc().init()
error: Class NSObject does not respond to alloc

======================================================================
ERROR: test_varargsConstruction (__main__.TestNSSetInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsset.py", line 26, in  
test_varargsConstruction
     x = NSSet.alloc().initWithObjects_(0,1,2,3,None)
error: Class NSObject does not respond to alloc

======================================================================
ERROR: test_varargsConstruction2 (__main__.TestNSSetInteraction)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsset.py", line 42, in  
test_varargsConstruction2
     x = NSMutableSet.alloc().initWithObjects_(0,1,2,3,None)
error: Class NSObject does not respond to alloc

----------------------------------------------------------------------
Ran 5 tests in 0.018s

FAILED (errors=3)
-- Done
-- Running 'Lib/Foundation/test/test_nsstring.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.004s

OK
-- Done
-- Running 'Lib/Foundation/test/test_nsundomanager.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.009s

OK
-- Done
-- Running 'Lib/Foundation/test/test_paths.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.003s

OK
-- Done
-- Running 'Lib/Foundation/test/test_subclassing.py'
.
----------------------------------------------------------------------
Ran 1 test in 0.004s

OK
-- Done
-- Running 'Lib/objc/test/test_allocatebuffer.py'
..
----------------------------------------------------------------------
Ran 2 tests in 0.048s

OK
-- Done
-- Running 'Lib/objc/test/test_objc.py'
......EEE
======================================================================
ERROR: testClassInvocation (__main__.TestMethodInvocation)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/objc/test/test_objc.py", line 41, in setUp
     self.NSObjectInstance = objc.runtime.NSObject.alloc()
error: Class NSObject does not respond to alloc

======================================================================
ERROR: testInstanceInvocation (__main__.TestMethodInvocation)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/objc/test/test_objc.py", line 41, in setUp
     self.NSObjectInstance = objc.runtime.NSObject.alloc()
error: Class NSObject does not respond to alloc

======================================================================
ERROR: testVarargsInvocation (__main__.TestMethodInvocation)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/objc/test/test_objc.py", line 41, in setUp
     self.NSObjectInstance = objc.runtime.NSObject.alloc()
error: Class NSObject does not respond to alloc

----------------------------------------------------------------------
Ran 9 tests in 0.115s

FAILED (errors=3)
-- Done
-- Running 'Lib/objc/test/test_posing.py'
objc: Level1Class: [Level1Class poseAs:NSObject]: Level1Class defines  
new instance variables
-- Done
-- Running 'Lib/objc/test/test_subclass.py'
..E.
======================================================================
ERROR: testSubclassOfSubclass (__main__.TestSubclassing)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "Lib/objc/test/test_subclass.py", line 13, in  
testSubclassOfSubclass
     class Level2Class (Level1Class):
internal_error: Cannot fetch key in keylist

----------------------------------------------------------------------
Ran 4 tests in 0.024s

FAILED (errors=1)
-- Done

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

On Wednesday, Jan 22, 2003, at 16:34 US/Eastern, Just van Rossum wrote:
> [me, responding to bbum]
>
>>> The goal was that an object's role as an observer should not affect
>>> the retain count and that the developer should invoke
>>> -removeObjserver: in -dealloc.  The reality is that the developer
>>> should decouple the "I'm not going to use this object anymore" code
>>> from the reference counting code-- yields much cleaner code that
>>> uses resources more efficiently.
>>
>> Heh, but this _utterly_ defeats the purpose of ref counting...
>
> That was a cheap shot. I guess what you mean is similar to the Python
> habit of closing your files even though they will be closed
> automatically upon deallocation. Similarly for windows: you should 
> clean
> up once you know for sure your window is has been closed. I've used 
> that
> strategy a lot in my W toolkit (using the classic Mac Toolbox): I could
> create lots of cyclic refs but get away with that because there's 
> always
> a clear point in time when break them: when the window closes. That
> said, I spent so much time with Python 1.5.2 that I still tend to
> prevent cycles even though Python handles most of them well these days.
>
> Re notifications: even with proper weak refs I don't think you can ever
> safely rely on refcounting to do the right thing here: there will 
> always
> be a point where the observer still exists, but is no longer capable of
> handling a notification, so it's always good to define a clear point at
> which you should unregister your observer.
>
> In other words: you are absolutely right ;-)

Awwww... and I was getting all ready to pull out my 'caustic sarcasm' 
mode of writing to respond...

In all seriousness, this entire discussion centers around a problem 
with automatic garbage collection.   Actually, not a problem with AGC, 
but a problem with many developer's attitude towards AGC.

With AGC, "The garbage collector will clean up after me" is often 
considered to be a valid design pattern.

Bogus.  Bad Idea.

I can't tell you the number of apps I have seen fail under load because 
the developer was counting on the GC to clean up both memory and scarce 
resources.

In the case of the notification center, I'd rather that the app leaked 
memory than crash after, say, I close a document.  Even Omni has fallen 
prey to that bug.... fix one memory leak and suddenly an observer is 
released before de-observing.

b.bum

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

[me, responding to bbum]

> > The goal was that an object's role as an observer should not affect
> > the retain count and that the developer should invoke
> > -removeObjserver: in -dealloc.  The reality is that the developer
> > should decouple the "I'm not going to use this object anymore" code
> > from the reference counting code-- yields much cleaner code that
> > uses resources more efficiently.
> 
> Heh, but this _utterly_ defeats the purpose of ref counting...

That was a cheap shot. I guess what you mean is similar to the Python
habit of closing your files even though they will be closed
automatically upon deallocation. Similarly for windows: you should clean
up once you know for sure your window is has been closed. I've used that
strategy a lot in my W toolkit (using the classic Mac Toolbox): I could
create lots of cyclic refs but get away with that because there's always
a clear point in time when break them: when the window closes. That
said, I spent so much time with Python 1.5.2 that I still tend to
prevent cycles even though Python handles most of them well these days.

Re notifications: even with proper weak refs I don't think you can ever
safely rely on refcounting to do the right thing here: there will always
be a point where the observer still exists, but is no longer capable of
handling a notification, so it's always good to define a clear point at
which you should unregister your observer.

In other words: you are absolutely right ;-)

Just

Re: [Pyobjc-dev] Strange Error: (was Sockets, Files, Fun)

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

I am seeing the following type of exceptions:
objc.error: Class NSObject does not respond to copyWithZone:
Traceback (most recent call last):
   File  
"/Users/noon/Developer/KeyedData/build/KeyedData.app/Contents/ 
Resources/__main__.py", line 20, in ?
     sys.exit(AppKit.NSApplicationMain(sys.argv))
objc.error: Class NSObject does not respond to copyWithZone:

These errors only occur when run from precompiled (.pyc) files.  I.e.  
the first run will work and all subsequent runs will give the above  
objc.error until I delete the imported .pyc file.

Any suggestions on how to debug this?

--Bill Noon

On Wednesday, January 22, 2003, at 08:02 AM, Just van Rossum wrote:

> Tony Lownds wrote:
>
>> Wow, thats cool. I can't get it to work, which I'm guessing is an
>> issue with my environment:
>>
>> Python 2.2 (#1, 07/14/02, 23:25:09)
>> [GCC Apple cpp-precomp 6.14] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>  from Foundation import NSFileHandle
>>>>>  NSFileHandle
>> <objective-c class NSFileHandle at 0xa07edbf8>
>>>>>  NSFileHandle.alloc()
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in ?
>> objc.error: Class NSObject does not respond to alloc
>>>>>
>>
>> I've just re-built pyobjc from CVS; using Apple stock python; Mac OS
>> X 10.2.3
>
> Weird, I can't explain that. (However, TelnetInspect.py is only meant  
> to
> run from an app with an event loop, but I guess that figures.)
>
>> At 11:34 PM +0100 1/21/03, Just van Rossum wrote:
>>> (Adding a check so it only accepts connections from the local
>>> machine is left as an exercise for the reader ;-)
>>
>> -     sock.bind(("", port))
>> +     sock.bind(("127.0.0.1", port))
>>
>>
>> :)
>
> Thanks ;-)
>
> Just
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

bb...@ma... wrote:

> I may be missing something here, but this sounds like normal
> behavior.
> 
> Specifically:  If you pass a pure Python object reference into
> Objective-C, it will behave like an autoreleased object.  That is, if
> you want to hang on to the object on the ObjC side, you need to
> -retain it just like you would any other object.

But the thing is, you don't have control over the autoreleased proxy
that get created for your Python object. That makes passing
(non-NSObject inherited) Python objects to ObjC more dangerous than
passing (NSObject inherited) objects. I don't care _too_ much about this
additional danger, but it would help newbies if it was clearly
documented somewhere.

> One can assume an object reference is only valid in the current scope
> unless the reference is -retained.  In ObjC, the -retain must be
> explicit.  In Python, an assignment or set membership implies the
> -retain (which can be confusing to the ObjC programmer if they expect
> an object to behave as autoreleased but it -releases at end of
> current scope).

But it's confusing to Python programmers (or at least: it was to me ;-)
that even though you explicitly keep a ref to the object, the proxy that
gets passed to ObjC is autoreleased, which may lead to crashes if the
receiver doesn't retain it, yet uses it after the current
autoreleasepool is deallocated. Completely understandable once you
understand how it works (it was quite a "duh" experience for me ;-).

> At least, that is how it should work.
> 
> In the case of NSNotificationCenter, the notification center
> maintains weak references-- non retained references-- to the various
> observers. I have always felt that this was an unfortunate
> implementation decision as it has led to a tremendous number of very
> confused programmers.

After having implemented a similar scheme in Python (and having looked
at how the anygui guys were doing the same thing), I totally understand
why it doesn't keep real refs: if you do keep real refs, you're in
cyclic ref hell before you know it. In Python you could use the weakref
module, but even that is tricky: the most natural way to register
observers is to add a bound method (semantically similar to a
target/selector duo), yet bound methods are made on the fly, so the
bound method _itself_ is not referenced by anyone else, so will go away
if you only keep a weak ref to it. You really need a weak ref to the
target itself. I think it's far less of a problem now that Python has a
cycle detector.

> The goal was that an object's role as an
> observer should not affect the retain count and that the developer
> should invoke -removeObjserver: in -dealloc.  The reality is that the
> developer should decouple the "I'm not going to use this object
> anymore" code from the reference counting code-- yields much cleaner
> code that uses resources more efficiently.

Heh, but this _utterly_ defeats the purpose of ref counting...

Just

Re: [Pyobjc-dev] WebObjects?

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

On Wednesday, Jan 22, 2003, at 14:49 US/Eastern, Dinu Gherman wrote:
> Hi, I'm not sure if this has been a topic before, but I wonder if
> someone has already tried his hands on using pyobjc for WebObjects
> programs??

WebObjects is pure Java these days, so I'm not sure exactly how such an 
integration would work/make sense.

b.bum

[Pyobjc-dev] WebObjects?

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

Hi, I'm not sure if this has been a topic before, but I wonder if
someone has already tried his hands on using pyobjc for WebObjects
programs??

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"I want to put a ding in the universe." (Steve Jobs)

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

On Tuesday, Jan 21, 2003, at 18:53 US/Eastern, Just van Rossum wrote:
>> Having
>> to use special wrappers every time I call back and forth between
>> Python and objc would make pyobjc lose a lot of its appeal: the
>> reason for programming in Python is that it makes it unnecessary to
>> deal with that sort of bookkeeping, most of the time.
>
> The question is whether implicitly wrapping (eg.) a Python list so it
> can be passed to methods that expect an NSArray is such a good idea.
> It's pretty cool, but it only works as long as the receiver keeps a
> reference as long as it needs it (or is done with it before the end of
> the current event loop cycle).
>
> But then again, it's easily possible to get crashes with NSObjects as
> well (eg. if your observer gets deallocated and you haven't removed it
> from the notification center yet), so perhaps I worry too much about
> safety...

I may be missing something here, but this sounds like normal behavior.

Specifically:  If you pass a pure Python object reference into 
Objective-C, it will behave like an autoreleased object.  That is, if 
you want to hang on to the object on the ObjC side, you need to -retain 
it just like you would any other object.

One can assume an object reference is only valid in the current scope 
unless the reference is -retained.  In ObjC, the -retain must be 
explicit.  In Python, an assignment or set membership implies the 
-retain (which can be confusing to the ObjC programmer if they expect 
an object to behave as autoreleased but it -releases at end of current 
scope).

At least, that is how it should work.

In the case of NSNotificationCenter, the notification center maintains 
weak references-- non retained references-- to the various observers.   
I have always felt that this was an unfortunate implementation decision 
as it has led to a tremendous number of very confused programmers.   
The goal was that an object's role as an observer should not affect the 
retain count and that the developer should invoke -removeObjserver: in 
-dealloc.  The reality is that the developer should decouple the "I'm 
not going to use this object anymore" code from the reference counting 
code-- yields much cleaner code that uses resources more efficiently.

Re: [Pyobjc-dev] Sockets, Files, Fun

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

Tony Lownds wrote:

> Wow, thats cool. I can't get it to work, which I'm guessing is an 
> issue with my environment:
> 
> Python 2.2 (#1, 07/14/02, 23:25:09)
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>>  from Foundation import NSFileHandle 
> >>>  NSFileHandle
> <objective-c class NSFileHandle at 0xa07edbf8>
> >>>  NSFileHandle.alloc()
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> objc.error: Class NSObject does not respond to alloc
> >>>
> 
> I've just re-built pyobjc from CVS; using Apple stock python; Mac OS
> X 10.2.3

Weird, I can't explain that. (However, TelnetInspect.py is only meant to
run from an app with an event loop, but I guess that figures.)

> At 11:34 PM +0100 1/21/03, Just van Rossum wrote:
> >(Adding a check so it only accepts connections from the local
> >machine is left as an exercise for the reader ;-)
> 
> -     sock.bind(("", port))
> +     sock.bind(("127.0.0.1", port))
> 
> 
> :)

Thanks ;-)

Just

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

On Tuesday, Jan 21, 2003, at 14:53 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> Did you follow the GIL discussions on python-dev the last few weeks?
>
> Only superficially.
>
>> I filed them away (too busy, but I do want to read them eventually)
>> but there might be interesting stuff in there.
>
> Right. It raises at least one point that may be relevant to us: how to
> find out whether we already have the lock?

We don't? What I intend to do (based on a good idea by Jack Jansen, the 
bugs are mine):

When calling into Objective-C:
* Make sture to store the thread-state in a tread-local variable
* Release the GIL
* Call Objective-C
* Acquire the GIL

When calling from Objective-C:
* Get the tread-state from a thread-local variable
* Aquire the GIL
* Call Python
* Release the GIL

Just in case we get called from an Objective-C thread that was not 
created from Python we can stash away a pointer to the interpreter 
state (assuming there is only 1 interpreter per process) and build a 
new thread-state when the thread-local variable cannot be found.

BTW. The thread-related code in objc_util.[hm] is bogus.

Ronald

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

On Wednesday, Jan 22, 2003, at 00:22 Europe/Amsterdam, Just van Rossum 
wrote:

> I noticed that the documentation for the NSNotificationCenter
> addObserver:selector:name:object: method says it doesn't retain 
> observer
> objects. This means that you shouldn't pass observer objects that 
> aren't
> unretained NSObject instances, eg. any Python object (just like with
> NSOutlineView).
>
> I wonder now, when _is_ it appropriate to pass Python objects to ObjC,
> and is it really that useful to make it worth it to give up some 
> safety?
> Perhaps it's better to explicitly wrap Python objects in a utility
> class, and/or have to convenience functions that wrap some standard
> Python into matching ObjC objects? Perhaps we could add a method to
> NSArray, say NSArray.fromPythonSequence_(). Stuff like that.

Another option would be a simular structure as we do for the proxy 
objects passed from Objective-C to python: Maintain a dict containing 
weakrefs. The idea:
* Whenever you want to pass a python object to Objective-C check the 
dict, if it is there use
   that value.
* If it is not there create a new OC_Python* object, add it to the 
dict, retain and pass to
   Objective-C (retain needed because we hold on to a reference).
* Whenever the Python object gets garbage collected, remove its entry 
from the dict and
   release the proxy object.

This would remove most problems with reference counts (as long as 
people read the Cocoa manuals and
do as they are told). This may have a negative impact on performance 
and/or memory usage, but
we can always look for a different solution if the impact is too bad.

Ronald