pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Threading

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

Hi,

I'm trying to make a Cocoa front end for an HTTP based python 
application (spambayes). My program spawns a thread to handle the 
HTTP requests, but that thread blocks. I've also tried a thread that 
does nothing count, and it blocks too. Any advice on writing a pyobjc 
program that uses threads?

PyObjC .8
python 2.2 (from Apple)

Thanks,
-Tony

[Pyobjc-dev] Release schedule, version labeling?

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

Hi,

I'm trying to make use of the multi-document project template which
obviously needs a version > 0.8 due to changes in the class named
NSApplicationDelegate. So I've just built the current CVS version,
but now after building the default project I get this when trying
to run it:

Traceback (most recent call last):
   File  
"/Users/dinu/Developer/Cocoa/PyMultiDoc/build/PyMultiDoc.app/Contents/ 
Resources/__main__.py", line 16, in ?
     import MyDocument
   File  
"/Users/dinu/Developer/Cocoa/PyMultiDoc/build/PyMultiDoc.app/Contents/ 
Resources/MyDocument.py", line 17, in ?
     class MyDocument(AutoBaseClass):
   File "/usr/lib/python2.2/site-packages/AppKit/NibClassBuilder.py",  
line 386, in __new__
     return _nibInfo.makeClass(name, bases, methods)
   File "/usr/lib/python2.2/site-packages/AppKit/NibClassBuilder.py",  
line 219, in makeClass
     return metaClass(name, bases, methods)
objc.internal_error: Cannot fetch key in keylist

So, is there some way to label more or less stable versions in
CVS, maybe?

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"A whole generation has grown up with the idea that it is normal
for them to have no freedom." (Richard M. Stallman)

[Pyobjc-dev] Class NSDictionary does not respond to dictionaryWithContentsOfFile

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

When loading a nib file, I now get the following traceback:

Traceback (most recent call last):
   File  
"/usr/local/sources/python/pyobjc/Lib/AppKit/NibClassBuilder.py", line  
471, in ?
     commandline()
   File  
"/usr/local/sources/python/pyobjc/Lib/AppKit/NibClassBuilder.py", line  
467, in commandline
     printTemplate(nibFiles)
   File  
"/usr/local/sources/python/pyobjc/Lib/AppKit/NibClassBuilder.py", line  
443, in printTemplate
     extractClasses(path=path)
   File  
"/usr/local/sources/python/pyobjc/Lib/AppKit/NibClassBuilder.py", line  
139, in extractClasses
     self._extractClassesFromNibFromPath(path)
   File  
"/usr/local/sources/python/pyobjc/Lib/AppKit/NibClassBuilder.py", line  
159, in _extractClassesFromNibFromPath
     nibInfo = NSDictionary.dictionaryWithContentsOfFile_(
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
posixpath.py", line 48, in join
     for b in p:
objc.error: Class NSDictionary does not respond to  
dictionaryWithContentsOfFile:

This is with the latest CVS pyobjc and very recent python (from cvs).

The following line in NibClassBuilder.py raises the exception:
         nibInfo = NSDictionary.dictionaryWithContentsOfFile_(
                 os.path.join(path, 'classes.nib'))

but creating a temp string works fine:

         nibPath = os.path.join(path, 'classes.nib')
         nibInfo = NSDictionary.dictionaryWithContentsOfFile_(
                 nibPath)

Ideas?

--Bill Noon
Northeast Regional Climate Center
Cornell University

Re: [Pyobjc-dev] posing

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

Can't we have two types of bridging objects, both of which share the 
__pyobc_pythonImplementation__ method but implemented in a different 
way? In the cheap bridged object you would have the instance variable 
and __pyobc_pythonImplementation__ would simply return that. In the All 
Singing All Dancing bridged object __pyobc_pythonImplementation__ would 
be implemented using a global dict. (There would need to be auxiliary 
routines to set and break the link between the objc and python objects 
too).

I assume the Python programmer will know which of the objects would 
need to be subclasses of the expensive object...
--
Jack Jansen, <Jac...@cw...>, 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] posing

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

On Monday, Jan 20, 2003, at 15:19 Europe/Amsterdam, bb...@ma... wrote:

> On Monday, Jan 20, 2003, at 01:37 US/Eastern, Ronald Oussoren wrote:
>>> The pyobj_ivar contains a reference to the Python instance that 
>>> effectively provides the Python side of the implementation of the 
>>> current class;  not just a binding to the class, but also to the 
>>> instance on the python side.
>>
>> I thought you found a clever way around this. Sorry about not 
>> mentioning this before. You could of course store the reference to 
>> the python instance in an NSHashTable, but that would probably have a 
>> negative impact on performance.
>
> Only per-class, which was what I was assuming would be all that was 
> necessary.
Its per instance: the instance variable that's added in class-builder.m 
contains a reference to the python half of the mixed class.

>
> I'm not exactly sure how to proceed from here -- see below.
>
>>> OK.
>>>
>>> That makes life a bit more difficult, but I *really* want posing to 
>>> work and, afaict, that instance variable is the only thing that is 
>>> holding this back.
>>>
>>> But this also raises a question regarding the eventual 
>>> implementation of categories.  Sort of.   With Categories, one needs 
>>> to add Python implemented methods to an already existing class.
>>>
>>> Rephrase:  Categories and posing are effectively the same problem:   
>>> they both imply that a class will preexist and that the category (or 
>>> posing class) will not add any instance variables within its 
>>> declaration.
>>
>> With libFFI it is possible to implement categories without adding an 
>> instance variable. One of the features of libFFI is the possibility 
>> to define closures that look like normal functions. A method in a 
>> categorie can be implemented using a closure that contains a 
>> reference to the python function implementing the method.
>> The same trick could be used for mixed classes: 
>> __pyobjc_pythonImplementation__ would also be a closure.
>
> There are three problems that need to be solved:   categories, posing, 
> and subclassing.
>
> Posing is really just a special form of subclassing.
Is it? IMHO it is not. Posing is a way to "trick" the runtime into 
using your class instead of the real class when performing 
objc_lookUpClass.

>
> It sounds like Categories are nailed w/libFFI.   Have you made any 
> progress on some kind of a tarball that contains the necessary bits of 
> libFFI such that we can move to libFFI across the boards?

Yes, I have the tarball on my machine but cannot add it to the files 
section at SF (not enough permissions to add a new section). The 
tarball contains libffi from the GCC CVS HEAD of yesterday evening, 
plus some additional files that were needed to build it (and a 
modification of configure and Makefile.in to teach it to use these 
files).

>
> Subclassing currently works but has a "fatal" flaw in the context of 
> posing:  subclasses currently require an instance variable.
>
> At runtime, posing acts in a similar fashion as to categories.  Sort 
> of.  When class B is posed as class A, class A is effectively renamed 
> to %A and class B is renamed to A (actually, class B's definition is 
> duplicated and the duplicate is marked as class A).    The effect is 
> that the methods of class B are now implemented on class A.   Any 
> overridden methods on the original class A (now %A) can be access by 
> the methods that came from class B (now class A) by invoking [super 
> ... over ridden method ...].
>
> So, how to eliminate the required instance variable from the current 
> implementation?
>
> A Hash, as Ronald mentioned, would both solve the problem and likely 
> introduce a significant performance hit.
>
> However, if __pyobjc_pythonImplementation__ can be a closure (is that 
> a noun?), then the instance variable should be able to be eliminated?

closure is a non, but now that I think of it 
__pyobc_pythonImplementation__ cannot be a closure: It needs act like 
an instance variable :-(.
Ronald

Re: [Pyobjc-dev] posing

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

On Monday, Jan 20, 2003, at 01:37 US/Eastern, Ronald Oussoren wrote:
>> The pyobj_ivar contains a reference to the Python instance that 
>> effectively provides the Python side of the implementation of the 
>> current class;  not just a binding to the class, but also to the 
>> instance on the python side.
>
> I thought you found a clever way around this. Sorry about not 
> mentioning this before. You could of course store the reference to the 
> python instance in an NSHashTable, but that would probably have a 
> negative impact on performance.

Only per-class, which was what I was assuming would be all that was 
necessary.

I'm not exactly sure how to proceed from here -- see below.

>> OK.
>>
>> That makes life a bit more difficult, but I *really* want posing to 
>> work and, afaict, that instance variable is the only thing that is 
>> holding this back.
>>
>> But this also raises a question regarding the eventual implementation 
>> of categories.  Sort of.   With Categories, one needs to add Python 
>> implemented methods to an already existing class.
>>
>> Rephrase:  Categories and posing are effectively the same problem:   
>> they both imply that a class will preexist and that the category (or 
>> posing class) will not add any instance variables within its 
>> declaration.
>
> With libFFI it is possible to implement categories without adding an 
> instance variable. One of the features of libFFI is the possibility to 
> define closures that look like normal functions. A method in a 
> categorie can be implemented using a closure that contains a reference 
> to the python function implementing the method.
> The same trick could be used for mixed classes: 
> __pyobjc_pythonImplementation__ would also be a closure.

There are three problems that need to be solved:   categories, posing, 
and subclassing.

Posing is really just a special form of subclassing.

It sounds like Categories are nailed w/libFFI.   Have you made any 
progress on some kind of a tarball that contains the necessary bits of 
libFFI such that we can move to libFFI across the boards?

Subclassing currently works but has a "fatal" flaw in the context of 
posing:  subclasses currently require an instance variable.

At runtime, posing acts in a similar fashion as to categories.  Sort 
of.  When class B is posed as class A, class A is effectively renamed 
to %A and class B is renamed to A (actually, class B's definition is 
duplicated and the duplicate is marked as class A).    The effect is 
that the methods of class B are now implemented on class A.   Any 
overridden methods on the original class A (now %A) can be access by 
the methods that came from class B (now class A) by invoking [super ... 
over ridden method ...].

So, how to eliminate the required instance variable from the current 
implementation?

A Hash, as Ronald mentioned, would both solve the problem and likely 
introduce a significant performance hit.

However, if __pyobjc_pythonImplementation__ can be a closure (is that a 
noun?), then the instance variable should be able to be eliminated?

It looks like I need to move to the FFI build of PyObjC sooner rather 
than later -- it sounds like this change is going to require FFI's 
support for closures (or some other solution of a similar nature).

b.bum

Re: [Pyobjc-dev] Autopsy of a ktrace

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

On Monday, Jan 20, 2003, at 12:00 Europe/Amsterdam, Jack Jansen wrote:

>
> On Monday, Jan 20, 2003, at 07:41 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>>> Is this with a static Python or a framework python? I still haven't 
>>> gotten around at looking at prebinding, so I don't think any is 
>>> done. Also, it may be possible to prebind extension modules (haven't 
>>> checked) which may also make a difference. If this is all possible 
>>> it should be fairly simple: one prebinding magic incantation in the 
>>> main Python Makefile and explaining distutils how to prebind dynamic 
>>> modules for the Python that was used to run the distutils.
>> Framework python 2.3, last CVS update was yesterday.
>
> I've just added -prebind options to the building of Python. Framework 
> build startup has gone from 180ms to 70ms, non-framework build startup 
> from 100ms to 70ms. (on my 450Mhz G4). The fix has been checked in.
I've compiled my 2.3 framework install with 'OPT="-O3 -mcpu=604 
-faltivec -prebind"'. This causes a 10% speedup of the microbenchmark 
for PyObjC that I'm working on. The downside is that the binaries only 
work on G4s.

>
> I tried enabling -prebind for the extension modules too, but the 
> linker complains that -bundle and -prebind don't go together or 
> something to that effect. Does anyone know whether there is a way 
> around this?
Doesn't -prebind perform at linktime the fixup that the dynamic loader 
normally performs at runtime? If so I'm not surprised that this doesn't 
work with bundles: The linker then doesn't have enough information. 
Building as a dylib and linking with the python framework might help 
(just guessing, this probably won't work at all).

Ronald

Re: [Pyobjc-dev] Autopsy of a ktrace

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

On Monday, Jan 20, 2003, at 07:41 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> Is this with a static Python or a framework python? I still haven't 
>> gotten around at looking at prebinding, so I don't think any is done. 
>> Also, it may be possible to prebind extension modules (haven't 
>> checked) which may also make a difference. If this is all possible it 
>> should be fairly simple: one prebinding magic incantation in the main 
>> Python Makefile and explaining distutils how to prebind dynamic 
>> modules for the Python that was used to run the distutils.
> Framework python 2.3, last CVS update was yesterday.

I've just added -prebind options to the building of Python. Framework 
build startup has gone from 180ms to 70ms, non-framework build startup 
from 100ms to 70ms. (on my 450Mhz G4). The fix has been checked in.

I tried enabling -prebind for the extension modules too, but the linker 
complains that -bundle and -prebind don't go together or something to 
that effect. Does anyone know whether there is a way around this?
--
Jack Jansen, <Jac...@cw...>, 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] Autopsy of a ktrace

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

On Sunday, Jan 19, 2003, at 23:20 Europe/Amsterdam, Jack Jansen wrote:

> Replying to two messages at once:
>
> On zondag, jan 19, 2003, at 15:40 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> Another obvious conclusing is that the startup of python itself is 
>> taking over half a second, which means we can never get as fast as 
>> Objective-C w.r.t. startup times (heck, a Objective-C version of 
>> addressbook.py runs in less time than Python takes to get to reading 
>> addressbook.py, I'll add the Objective-C version to the repository).
>
> Is this with a static Python or a framework python? I still haven't 
> gotten around at looking at prebinding, so I don't think any is done. 
> Also, it may be possible to prebind extension modules (haven't 
> checked) which may also make a difference. If this is all possible it 
> should be fairly simple: one prebinding magic incantation in the main 
> Python Makefile and explaining distutils how to prebind dynamic 
> modules for the Python that was used to run the distutils.
Framework python 2.3, last CVS update was yesterday.

>
> And Bill wrote:
>> I used Sampler to monitor file operations and it appears to be that 
>> +bundleForClass: calls stat() and access() for each class -- likely 
>> for each Bundle -- to find the bundle for the class.
>
> 1. What is Sampler?
/Developer/Applications/Sampler.app

>
> 2. Could we globally override +bundleForClass: with a category or 
> somesuch and put a cache in there?
Bill?
> --
> - 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] posing

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

On Sunday, Jan 19, 2003, at 21:33 Europe/Amsterdam, bb...@ma... wrote:

> (Thinking out loud)
>
> Scratch that.    I see what is going on.
>
> The pyobj_ivar contains a reference to the Python instance that 
> effectively provides the Python side of the implementation of the 
> current class;  not just a binding to the class, but also to the 
> instance on the python side.

I thought you found a clever way around this. Sorry about not 
mentioning this before. You could of course store the reference to the 
python instance in an NSHashTable, but that would probably have a 
negative impact on performance.

>
> OK.
>
> That makes life a bit more difficult, but I *really* want posing to 
> work and, afaict, that instance variable is the only thing that is 
> holding this back.
>
> But this also raises a question regarding the eventual implementation 
> of categories.  Sort of.   With Categories, one needs to add Python 
> implemented methods to an already existing class.
>
> Rephrase:  Categories and posing are effectively the same problem:   
> they both imply that a class will preexist and that the category (or 
> posing class) will not add any instance variables within its 
> declaration.

With libFFI it is possible to implement categories without adding an 
instance variable. One of the features of libFFI is the possibility to 
define closures that look like normal functions. A method in a 
categorie can be implemented using a closure that contains a reference 
to the python function implementing the method.

The same trick could be used for mixed classes: 
__pyobjc_pythonImplementation__ would also be a closure.

Ronald

Re: [Pyobjc-dev] Autopsy of a ktrace

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

On Sunday, Jan 19, 2003, at 17:20 US/Eastern, Jack Jansen wrote:
> And Bill wrote:
>> I used Sampler to monitor file operations and it appears to be that 
>> +bundleForClass: calls stat() and access() for each class -- likely 
>> for each Bundle -- to find the bundle for the class.
> 1. What is Sampler?

/Developer/Applications/Sampler.app -- one of the various performance 
quantification tools that ship w/OS X developer.

> 2. Could we globally override +bundleForClass: with a category or 
> somesuch and put a cache in there?

No!   This would change the behavior of the Foundation in a fashion 
that *may* break Apple (or other's) code.   When embedding the Python 
interpreter in existing apps [I have a project started that does just 
that], we really, really, really want to avoid *any* categories or 
posing that *changes* the behavior of the existing API unless it is 
quite explicitly a change the developer intends.

b.bum

Re: [Pyobjc-dev] Autopsy of a ktrace

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

Replying to two messages at once:

On zondag, jan 19, 2003, at 15:40 Europe/Amsterdam, Ronald Oussoren 
wrote:
> Another obvious conclusing is that the startup of python itself is 
> taking over half a second, which means we can never get as fast as 
> Objective-C w.r.t. startup times (heck, a Objective-C version of 
> addressbook.py runs in less time than Python takes to get to reading 
> addressbook.py, I'll add the Objective-C version to the repository).

Is this with a static Python or a framework python? I still haven't 
gotten around at looking at prebinding, so I don't think any is done. 
Also, it may be possible to prebind extension modules (haven't checked) 
which may also make a difference. If this is all possible it should be 
fairly simple: one prebinding magic incantation in the main Python 
Makefile and explaining distutils how to prebind dynamic modules for 
the Python that was used to run the distutils.

And Bill wrote:
> I used Sampler to monitor file operations and it appears to be that 
> +bundleForClass: calls stat() and access() for each class -- likely 
> for each Bundle -- to find the bundle for the class.

1. What is Sampler?

2. Could we globally override +bundleForClass: with a category or 
somesuch and put a cache in there?
--
- 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] posing

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

(Thinking out loud)

Scratch that.    I see what is going on.

The pyobj_ivar contains a reference to the Python instance that 
effectively provides the Python side of the implementation of the 
current class;  not just a binding to the class, but also to the 
instance on the python side.

OK.

That makes life a bit more difficult, but I *really* want posing to 
work and, afaict, that instance variable is the only thing that is 
holding this back.

But this also raises a question regarding the eventual implementation 
of categories.  Sort of.   With Categories, one needs to add Python 
implemented methods to an already existing class.

Rephrase:  Categories and posing are effectively the same problem:   
they both imply that a class will preexist and that the category (or 
posing class) will not add any instance variables within its 
declaration.

Huh....

b.bum

On Sunday, Jan 19, 2003, at 15:22 US/Eastern, bb...@ma... wrote:
> On Saturday, Jan 18, 2003, at 02:23 US/Eastern, Ronald Oussoren wrote:
>> A -(PyObject*)__pyobjc_pythonImplementation is probably more usefull 
>> in the long run (return NULL in NSObject, the equivalent of the 
>> current self.__pyobjc_objc__ in mixed classes and the bridged python 
>> object in OC_PythonObject and friends)
> Right.
>
> Is there any per-instance significance to the additional instance var? 
>  I'm thinking not, but I'm not 100% sure.

Re: [Pyobjc-dev] posing

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

On Saturday, Jan 18, 2003, at 02:23 US/Eastern, Ronald Oussoren wrote:
> A -(PyObject*)__pyobjc_pythonImplementation is probably more usefull 
> in the long run (return NULL in NSObject, the equivalent of the 
> current self.__pyobjc_objc__ in mixed classes and the bridged python 
> object in OC_PythonObject and friends)

Right.

Is there any per-instance significance to the additional instance var?  
I'm thinking not, but I'm not 100% sure.

b.bum

Re: [Pyobjc-dev] Autopsy of a ktrace

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

I used Sampler to monitor file operations and it appears to be that 
+bundleForClass: calls stat() and access() for each class -- likely for 
each Bundle -- to find the bundle for the class.

Ouch.

Report #0 - Allocation for python (process 13776)
Stacks at 2003-01-19 11:25:41 -0500
Samples (displayed/total): 3345/3345
Call graph:
     1241 stat*
       1136 _NSFileAccessModes
         1136 _NSCouldBeBundle
           1130 _NSFrameworkPathFromLibraryPath
             1006 +[NSBundle bundleForClass:]
               1006 objc_loadBundle
                 1006 PyObject_Call
                   1006 do_call
                     1006 call_function
                       1006 eval_frame
                         1006 PyEval_EvalCodeEx
                           1006 PyEval_EvalCode
                             1006 PyImport_ExecCodeModuleEx
                               1006 load_source_module
......

     1137 access*
       1136 _NSFileAccessModes
         1136 _NSCouldBeBundle
           1130 _NSFrameworkPathFromLibraryPath
             1006 +[NSBundle bundleForClass:]
               1006 objc_loadBundle
                 1006 PyObject_Call
                   1006 do_call
                     1006 call_function
                       1006 eval_frame
                         1006 PyEval_EvalCodeEx

......

[Pyobjc-dev] Autopsy of a ktrace

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

I ran a ktrace on Examples/addressbook.py.

System: tibook 667Mhz, Python 2.3, PyObjC CVS-HEAD
Total runtime: 2.10 seconds (!)

The followig is based on the output of 'kdump -T', the relative times 
were calcuated using a awk-script. I wonder why Apple didn't add an 
option of this.

time 0.00s: Startup (in /usr/bin/env)
time 0.38s: open('addressbook.py')
time 0.47s: open('.../site.py')
time 0.56s: read(3, ...) -> contents of addressbook.py
time 0.58s: read(.../AddressBook/__init__.pyc)
time 0.59s: read(.../Foundation/__init__.pyc)
time 0.60s: read(.../objc/__init.pyc)
time 0.61s: open(.../objc/_objc.pyc)
time 0.61s: open(.../Version/2.3/Python)
time 0.63s: read(.../objc/_convenience.pyc)
time 0.65s: open(.../objc/_FoundationMapping.so)
time 0.66s: open(.../Foundation/_Foundation.so)
time 0.96s: Between here and previous open lots of references to 
Foundation.framework
time 0.97s: First referencee to AddressBook.framework
time 1.92s: Loaded support libraries, agian lots of references to 
various frameworks (including AppKit)
time 1.92s: First reference to AddressBook.data
time 2.10s: Done

The 'lots of references to ...' descriptions above refer to lines like 
those below, repeat many, many times (I've not counted them but it 
looks like hunderds of lines!!!):
2259 python 1.85493 CALL access(0xbfffd600,0x4)
2259 python 1.85496 NAMI "/System/Library/Frameworks/AppKit.framework"
2259 python 1.85501 RET access 0
2259 python 1.85526 CALL stat(0xbfffd600,0xbfffda10)
2259 python 1.85533 NAMI "/System/Library/Frameworks/AppKit.framework"
2259 python 1.85539 RET stat 0
2259 python 1.85544 CALL access(0xbfffd600,0x4)
2259 python 1.85547 NAMI "/System/Library/Frameworks/AppKit.framework"
2259 python 1.85552 RET access 0
2259 python 1.85576 CALL stat(0xbfffd600,0xbfffda10)
2259 python 1.85583 NAMI "/System/Library/Frameworks/AppKit.framework"
2259 python 1.85589 RET stat 0
2259 python 1.85592 CALL access(0xbfffd600,0x4)
2259 python 1.85596 NAMI "/System/Library/Frameworks/AppKit.framework"
2259 python 1.856 RET access 0

Obvious conclusion from the above: These 'strange' references eat up a 
lot of time, eliminating them would make this script significantly 
faster. But what causes this. My initial guess was: It wouldn't be 
objc_getClassList, would it?

Another obvious conclusing is that the startup of python itself is 
taking over half a second, which means we can never get as fast as 
Objective-C w.r.t. startup times (heck, a Objective-C version of 
addressbook.py runs in less time than Python takes to get to reading 
addressbook.py, I'll add the Objective-C version to the repository).

After modifying ObjC_GetClassList (in class-list.m) to try to use a 
static buffer of 1024 entries, and falling back to a malloc-ed buffer 
when that isn't good enough, I reran the ktrace and guess what: The 
number of lines in the output of kdump reduced from 23K to 22.5K lines 
so a guess objc_getClassList is doing something fishy. Sadly enough 
this didn't help with the runtime: This is still at 2.1 seconds. 
However: a simple Objective-C program doesn't confirm this: just 
calling objc_getClassList does not cause the strange sequence of calls 
I observed in the python script. But what else could be causing this?

Ronald

Re: [Pyobjc-dev] Startup time woes

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

On Saturday, Jan 18, 2003, at 23:22 Europe/Amsterdam, Just van Rossum 
wrote:

> [...] Still, a
> startup time of 3 seconds (let alone 10 with Python 2.2) for a trivial
> app with one trivial window is not really a great selling point :-(

10 seconds is pretty long, but I'd like to know how this scales before 
panicing ;-).

The Todo example is a more complicated application. On my system 
(667Mhz tibook) it launches in 2.7 seconds, while PythonBrowser 
launches in 2.4. Most of the difference seems to be in the time before 
calling NSApplicationMain (1.4 seconds vs. 1.1 seconds)

This seems to indicate that the launch-time for more compilicated apps 
is not that much worse than that of a simple app. However, that doesn't 
mean we shouldn't try to improve the performance of the bridge.

Ronald

Re: [Pyobjc-dev] Startup time woes

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

Just van Rossum wrote:

> Jack Jansen wrote:
> 
> > If running the profiler is difficult you could start with a ktrace
> > (which is supported since 10.2, yeah!). Start python, in another
> > window do "ktrace -p pid", do the Python bits you're interested in
> > and then do "ktrace -C". You'll only get a system call trace, but if
> > you show it with "kdump -T" you'll get timestamps and it may give an
> > idea where the time is going.
> 
> Hm, since this is about the startup time of an app bundle, I don't
> see how to get the pid in time to start ktrace. Hm, maybe the app
> should do something like os.system("ktrace -p %s" % os.getpid())?
> Would that work? After reading the man page: yeah, should work, -f
> <outfile> should come in handy.

Btw. this works great, except there's no way I can make any useful
judgment from the output :-( There's a _lot_ of stuff goin on. There are
lots of stats calls and other file system operations, so I'm it looks
like we can at least partly blame the sluggishness of HFS+ :-( Still, a
startup time of 3 seconds (let alone 10 with Python 2.2) for a trivial
app with one trivial window is not really a great selling point :-(

Is anyone using UFS and HFS side-by-side to see how much the file system
playes a role here? (This is assuming UFS is indeed much faster than
HFS+ on OSX, don't know how true that is.)

Just

Re: [Pyobjc-dev] Still struggling with NSOutlineView

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

Ronald Oussoren wrote:

> > Ah, nice, thanks. That may have been a problem, but it did work for
> > me before, as long as PythonItem was subclassed from NSObject. The
> > main issue is that it doesn't work when it _isn't_ subclassed from
> > NSObject: it crashes as soon as you click (hm, I seem to recall it
> > didn't crash before your patch, maybe other PyObjC changes play a
> > role...).
> 
> It crashes when PythonItem is not subclasses from NSObject because
> NSOutlineView stashes away the result of outlineView_child_ofItem_
> *without increasing its reference count*. Later on it uses this
> pointer. If PythonItem is not subclassed from NSObject the values
> seem by outlineView:child:ofItem: (e.g. the Objective-C
> implementation) is an autoreleased proxy object (instance of
> OC_PythonObject). The PythonItem instance does not contain a
> reference to this proxy and therefore this will be autoreleased on
> the next loop through the eventloop. If the outlineview tries to use
> the proxy object later on your application goes boom.

Ah, now that clears the whole thing up! Thanks much. Makes sense if you
understand what happens. That's a keeper for the PyObjC phrase book,
once we have one...

> > Erm, where do you see a __doc__ item that's expandable? __doc__ is
> > usually a stirng or None, neither of which should be expandable...
> 
> If I start the PythonBrowser.app the window is filled with a the
> globals of the module, one of these is the __doc__ (which of type
> NoneType and has value None). On my system it is shown as an
> expandable item, but it is not in fact expandable.
> 
> The problem is larger than that: class AutoBaseClass is not
> expandable, while NiceError is. This doesn't seem to be a problem
> with the script: I've added some print-statements and those print the
> expected results. This might indicate a problem with the bridge.

Hm, strange. Let me know if it turns out to be a bug in my program after
all...

Just

Re: [Pyobjc-dev] Still struggling with NSOutlineView

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

On Saturday, Jan 18, 2003, at 20:55 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> I found the problem: You didn't really hold onto the references to the
>> childeren.
>>
>> The attached version of PythonBrowser.py works a lot better.
>
> Ah, nice, thanks. That may have been a problem, but it did work for me
> before, as long as PythonItem was subclassed from NSObject. The main
> issue is that it doesn't work when it _isn't_ subclassed from NSObject:
> it crashes as soon as you click (hm, I seem to recall it didn't crash
> before your patch, maybe other PyObjC changes play a role...).

It crashes when PythonItem is not subclasses from NSObject because 
NSOutlineView stashes away the result of outlineView_child_ofItem_ 
*without increasing its reference count*. Later on it uses
this pointer. If PythonItem is not subclassed from NSObject the values 
seem by outlineView:child:ofItem: (e.g. the Objective-C implementation) 
is an autoreleased proxy object (instance of OC_PythonObject). The 
PythonItem instance does not contain a reference to this proxy and 
therefore this will be autoreleased on the next loop through the 
eventloop. If the outlineview tries to use the proxy object later on 
your application goes boom.

>
>> However,
>> when I try to expand the tree at a __doc__ item the program crashes
>> (AttributeError: No attribute childeren)
>
> Erm, where do you see a __doc__ item that's expandable? __doc__ is
> usually a stirng or None, neither of which should be expandable...

If I start the PythonBrowser.app the window is filled with a the 
globals of the module, one of these is the __doc__ (which of type 
NoneType and has value None). On my system it is shown as an expandable 
item, but it is not in fact expandable.

The problem is larger than that: class AutoBaseClass is not expandable, 
while NiceError is. This doesn't seem to be a problem with the script: 
I've added some print-statements and those print the expected results. 
This might indicate a problem with the bridge.

Ronald

Re: [Pyobjc-dev] Still struggling with NSOutlineView

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

Ronald Oussoren wrote:

> I found the problem: You didn't really hold onto the references to the 
> childeren.
> 
> The attached version of PythonBrowser.py works a lot better.

Ah, nice, thanks. That may have been a problem, but it did work for me
before, as long as PythonItem was subclassed from NSObject. The main
issue is that it doesn't work when it _isn't_ subclassed from NSObject:
it crashes as soon as you click (hm, I seem to recall it didn't crash
before your patch, maybe other PyObjC changes play a role...).

> However, 
> when I try to expand the tree at a __doc__ item the program crashes 
> (AttributeError: No attribute childeren)

Erm, where do you see a __doc__ item that's expandable? __doc__ is
usually a stirng or None, neither of which should be expandable...

Thanks,

Just

Re: [Pyobjc-dev] Still struggling with NSOutlineView

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

I found the problem: You didn't really hold onto the references to the 
childeren.

The attached version of PythonBrowser.py works a lot better. However, 
when I try to expand the tree at a __doc__ item the program crashes 
(AttributeError: No attribute childeren)

Ronald

P.S. This is without the calls to PyErr_NormalizeExceptions, it seems 
to work fine so far and I get a proper traceback.

Re: [Pyobjc-dev] ObjC exceptions, Python exceptions, the event loop

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

Btw. now that NSApplicationMain properly propagates exceptions back to
Python, the reason to have objc.setVerbose() is more or less gone.
Unless there are other application for it I suggest to get rid of it.
(I'd gladly do it myself.)

Just

Re: [Pyobjc-dev] ObjC exceptions, Python exceptions, the event loop

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

On Saturday, Jan 18, 2003, at 09:48 US/Eastern, Just van Rossum wrote:
> It's extremely rude what NSApplicationMain does, a finally clause as
> below will _only_ be called if there was an exception:
>
>     try:
>         sys.exit(AppKit.NSApplicationMain(sys.argv))
>     finally:
>         print "XXX exiting!"
>
> Blech! One for the phrase book...

I have ammended my already filed bug regarding NSApplicationMain()'s 
behavior regarding its arguments.

The damned function should be declared as:

void NSApplicationMain(void);

b.bum

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc/Modules/objc objc_util.m,1.10,1.11

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

On Saturday, Jan 18, 2003, at 09:41 US/Eastern, Just van Rossum wrote:
> Bill Bumgarner wrote:
>
>> Did the change to wrapping NSApplicationMain() work as expected?
>
> Yup, works like a charm, so it does indeed return as (I) expected.

Cool.   I'm surprised considering how broken argument handling is. :-)

In all seriousness, I believe there may be cases where the AppKit will 
exit directly -- I think I remember running into one.   I'll keep my 
eye out for it.   Not much we can do about it and, fortunately, the 
general expectation is that once control is passed to the AppKit, it'll 
never be returned to the caller anyway.

b.bum