pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Error while building

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

On Monday, 4 August, 2003, at 19:28, b.bum wrote:

> On Monday, August 4, 2003, at 13:24, Ronald Oussoren wrote:
>> The CodeGenerator script tries to import objc and uses 
>> 'objc.lookUpClass' to detect if a typename denotes a class, if objc 
>> cannot be imported it uses a static list for that. That static list 
>> must be complete if we want to support installation of a complete 
>> PyObjC without a prior PyObjC installation, and therefore the import 
>> of objc shouldn't buy us anything. I'll update the code.
>
> Sounds like PyObjC has evolved to the point of needing pyobjc to build 
> pyobjc;  kind of like emacs builds temacs to gain access to a lisp 
> engine prior to building the full app... or the way gcc bootstraps 
> itself.

This actually is some very old code, I already had a mosty working 
bridge when I tackled wrapping global functions.

>
> Can we build the objc module, then generate the files, then build the 
> rest of the modules?

I don't think this is worth the trouble. You'd have to do difficult 
things with distutils to make this work.

I'm currently checking in a patch that removes the optional dependency 
on an installed PyObjC.

Ronald

Re: [Pyobjc-dev] Error while building

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

On Monday, August 4, 2003, at 13:24, Ronald Oussoren wrote:
> The CodeGenerator script tries to import objc and uses 
> 'objc.lookUpClass' to detect if a typename denotes a class, if objc 
> cannot be imported it uses a static list for that. That static list 
> must be complete if we want to support installation of a complete 
> PyObjC without a prior PyObjC installation, and therefore the import 
> of objc shouldn't buy us anything. I'll update the code.

Sounds like PyObjC has evolved to the point of needing pyobjc to build 
pyobjc;  kind of like emacs builds temacs to gain access to a lisp 
engine prior to building the full app... or the way gcc bootstraps 
itself.

Can we build the objc module, then generate the files, then build the 
rest of the modules?

b.bum

Re: [Pyobjc-dev] Error while building

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

On Monday, 4 August, 2003, at 16:47, b.bum wrote:

> I had a previous version of PyObjC installed (no surprises, there :), 
> updated from CVS, and did a 'sudo python setup.py install'....
>
> And the build crashed as shown below.   After removing the previously 
> installed version of PyObjC, the installation works fine.
>
> However, this indicates that we are picking up the previously 
> installed version during the build.   That could cause wonky, 
> non-deterministic, build failures.

The CodeGenerator script tries to import objc and uses 
'objc.lookUpClass' to detect if a typename denotes a class, if objc 
cannot be imported it uses a static list for that. That static list 
must be complete if we want to support installation of a complete 
PyObjC without a prior PyObjC installation, and therefore the import of 
objc shouldn't buy us anything. I'll update the code.

Ronald

[Pyobjc-dev] Error while building

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

I had a previous version of PyObjC installed (no surprises, there :),  
updated from CVS, and did a 'sudo python setup.py install'....

And the build crashed as shown below.   After removing the previously  
installed version of PyObjC, the installation works fine.

However, this indicates that we are picking up the previously installed  
version during the build.   That could cause wonky, non-deterministic,  
build failures.

b.bum

[bumboxinator:external/sourceforge/pyobjc] bbum% sudo python setup.py  
install
Password:
Performing task: Generating wrappers & stubs
Traceback (most recent call last):
   File "Scripts/CodeGenerators/cocoa_generator.py", line 15, in ?
     import func_builder
   File  
"/Volumes/Data/Users/bbum/bbum-developer/external/sourceforge/pyobjc/ 
Scripts/CodeGenerators/func_builder.py", line 16, in ?
     import AppKit
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/PyObjC/AppKit/__init__.py", line 33, in ?
     NSMakePoint = Foundaiton.NSMakePoint
NameError: name 'Foundaiton' is not defined
Task 'Generating wrappers & stubs' failed [256]

[Pyobjc-dev] Demo for GNUplotters

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

Hi,

I just made a screenshot and short movie for a little frontend I've
written for GNUplot. It's a nice sample for a future article I'm
thinking about:

   http://python.net/~gherman/tmp/GNUplotEddie1.jpg
   http://python.net/~gherman/tmp/GNUplotEddie1.mov (1.5 MB)

It has the usual philosophy: trying to be very minimal in terms of
the GUI, but very flexible in using it. The movie illustrates this
a little bit.

If people are interested I'll tidy it up a bit and make the program
available earlier. You need to install GNUplot first, which was
pretty easy using Fink, with only a little hack described here:
http://gamma.ethz.ch/install/mac/gnuplot but other sources indi-
cate you can also do without Fink.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"I=A0love=A0America=A0more=A0than=A0any=A0other=A0country=A0in=A0this=A0wo=
rld,=A0and,
exactly=A0for=A0this=A0reason,=A0I=A0insist=A0on=A0the=A0right=A0to=A0crit=
icize=A0her
perpetually." (James=A0Baldwin)

Re: [Pyobjc-dev] Fwd: Hard Objc-Runtime question: objc_getClassList lies to me...

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

There's no need to worry, I posted this here just in case anyone runs  
into this issue. Telling someone to look in our archives is a lot  
friendlier than asking them to dig through the macosx-dev and/or  
omni-group archives.

Ronald

On Wednesday, 30 July, 2003, at 00:18, b.bum wrote:

> File a bug.
>
> All things considered, linking is not a problem that most PyObjC  
> developers are faced with... disabling zerolink is not that onerous in  
> the context of PyObjC.
>
> Also -- it won't affect Frameworks as those classes are linked in  
> their entirety as a part of the loading of the prebound framework (I  
> think).
>
> b.bum
>
> On Monday, July 28, 2003, at 16:01, Jack Jansen wrote:
>
>>
>> On maandag, jul 28, 2003, at 13:43 Europe/Amsterdam, Ronald Oussoren  
>> wrote:
>>
>>> The message below has some technical information on ZeroLinking. On  
>>> a first reading, Zerolinking cannot be used with PyObjC as the  
>>> latter assumes that objc_getClassList returns all classes.
>>
>> Unless there is a way in which we can hook into ZeroLink, so we can  
>> make it defer to us for any classes it can't find. But even if that  
>> isn't possible, it seems that the following sentence also shows an  
>> escape route:
>>
>>>> If you need objc_getClassList() to return all of your classes, you  
>>>> can
>>>> * explicitly use them early on in your code
>>
>> --
>> - 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 -
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct; 
>> at.aspnet_072303_01/01
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] Fwd: Hard Objc-Runtime question: objc_getClassList lies to me...

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

File a bug.

All things considered, linking is not a problem that most PyObjC  
developers are faced with... disabling zerolink is not that onerous in  
the context of PyObjC.

Also -- it won't affect Frameworks as those classes are linked in their  
entirety as a part of the loading of the prebound framework (I think).

b.bum

On Monday, July 28, 2003, at 16:01, Jack Jansen wrote:

>
> On maandag, jul 28, 2003, at 13:43 Europe/Amsterdam, Ronald Oussoren  
> wrote:
>
>> The message below has some technical information on ZeroLinking. On a  
>> first reading, Zerolinking cannot be used with PyObjC as the latter  
>> assumes that objc_getClassList returns all classes.
>
> Unless there is a way in which we can hook into ZeroLink, so we can  
> make it defer to us for any classes it can't find. But even if that  
> isn't possible, it seems that the following sentence also shows an  
> escape route:
>
>>> If you need objc_getClassList() to return all of your classes, you  
>>> can
>>> * explicitly use them early on in your code
>
> --
> - 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 -
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct; 
> at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Problems documenting API using code introspection tools

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

On Tuesday, 29 July, 2003, at 20:09, Dinu Gherman wrote:

> Hi,
>
> when epydoc 2.0 was announced I immediately tried it on PyObjC, but
> as it seems it always fails doing proper code introspection for some
> parts of the code tree. I'm attaching a log of sample run below.
>
> I am pretty sure this is not a bug in epydoc and Edward Loper can't
> do any debugging without having a Mac, I guess. I'm making a wild
> estimate that there is too much magic going on in the __init__ files.
>
> Has anybody else succedeed in using a tool like epydoc (maybe pydoc)
> on the PyObjC code base?

I'm hunting a bug that affects pydoc, 'pydoc Foundation' crashes at the 
moment. Extracting documentation from the other modules seems to work 
fine.

There is some more comment in the trace below.

>
> Thanks,
>
> Dinu
>
> PS: http://epydoc.sourceforge.net/
Thanks, I hadn't seen epydoc before.

>
>
> [localhost:python2.2/site-packages/PyObjC] dinu% ll total 280
> drwxr-xr-x  13 dinu  staff    442 Jul 29 19:57 Foundation/
[snip]
> -rw-r--r--   1 dinu  staff  10843 Nov 22  2002 plistlib.py
> [localhost:python2.2/site-packages/PyObjC] dinu%
> [localhost:python2.2/site-packages/PyObjC] dinu%
> [localhost:python2.2/site-packages/PyObjC] dinu% sudo epydoc --debug 
> --pdf Foundation/
> Password:
> Importing 23 modules.
>   [.......................]
> Building API documentation for 23 modules.
>   [....
> Warning: UID conflict detected: Foundation.NSStringFromClass
> Warning: UID conflict detected: Foundation.NSSelectorFromString
These are caused by unnecessary definitions, these functions are 
defined in python but there are also generated wrappers in 
Foundation._Foundation. I'll remove the unnecessary pure-python 
version.

I get another message when running 'epydoc Foundation':

Warning: __builtin__.type.__new__ appears to override itself

epydoc __builtin__ gives the same warning (with some others). This is 
with Python 2.3 (b1)



> ...Traceback (most recent call last):
>   File "/usr/bin/epydoc", line 8, in ?
>     cli()
[snip]
>   File "/usr/lib/python2.2/site-packages/epydoc/uid.py", line 448, in 
> _findname
>     objname = obj.__name__
> AttributeError: No attribute __name__
I fixed this one over the weekend, objc.objc_class didn't have a 
__name__ attribute.

Ronald

Re: [Pyobjc-dev] Problems documenting API using code introspection tools

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

On Tuesday, 29 July, 2003, at 20:43, Bob Ippolito wrote:

> On Tuesday, Jul 29, 2003, at 14:09 America/New_York, Dinu Gherman 
> wrote:
>
> I dunno about you, but I get bus errors from pydoc on ObjC!
>
> [crack:~] bob% pydoc Foundation
> Bus error
>
> This is python 2.3rc2 and a CVS of ObjC from this week.  I believe I 
> may have filed a bug about this in sf.net already?

You did, and I still haven't found the problem ;-( 'pydoc AppKit' works 
better using a current CVS (a very current CVS, the relevant fix was 
checked in this weekend and there is a lag between checkins and the 
availability of those changes on the anonymous CVS servers).

Ronald

Re: [Pyobjc-dev] Problems documenting API using code introspection tools

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

On Tuesday, Jul 29, 2003, at 14:09 America/New_York, Dinu Gherman wrote:

> Hi,
>
> when epydoc 2.0 was announced I immediately tried it on PyObjC, but
> as it seems it always fails doing proper code introspection for some
> parts of the code tree. I'm attaching a log of sample run below.
>
> I am pretty sure this is not a bug in epydoc and Edward Loper can't
> do any debugging without having a Mac, I guess. I'm making a wild
> estimate that there is too much magic going on in the __init__ files.
>
> Has anybody else succedeed in using a tool like epydoc (maybe pydoc)
> on the PyObjC code base?

I dunno about you, but I get bus errors from pydoc on ObjC!

[crack:~] bob% pydoc Foundation
Bus error

This is python 2.3rc2 and a CVS of ObjC from this week.  I believe I 
may have filed a bug about this in sf.net already?

-bob

[Pyobjc-dev] Problems documenting API using code introspection tools

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

Hi,

when epydoc 2.0 was announced I immediately tried it on PyObjC, but
as it seems it always fails doing proper code introspection for some
parts of the code tree. I'm attaching a log of sample run below.

I am pretty sure this is not a bug in epydoc and Edward Loper can't
do any debugging without having a Mac, I guess. I'm making a wild
estimate that there is too much magic going on in the __init__ files.

Has anybody else succedeed in using a tool like epydoc (maybe pydoc)
on the PyObjC code base?

Thanks,

Dinu

PS: http://epydoc.sourceforge.net/


[localhost:python2.2/site-packages/PyObjC] dinu% ll total 280
drwxr-xr-x  13 dinu  staff    442 Jul 29 19:57 Foundation/
drwxr-xr-x   5 dinu  staff    170 Jul 23 12:55 PreferencePanes/
drwxr-xr-x  15 dinu  staff    510 Jul 23 12:55 PyObjCTools/
drwxr-xr-x  17 dinu  staff    578 Jul 23 12:55 ./
-rw-r--r--   1 dinu  staff    124 Jul 23 12:55 __init__.pyc
-rw-r--r--   1 dinu  staff      0 Jul 23 12:54 __init__.py
drwxr-xr-x  58 dinu  staff   1972 Jul 22 08:44 ../
drwxr-xr-x   4 root  staff    136 Jun 18 14:52 ScreenSaver/
drwxr-xr-x   7 dinu  staff    238 Jun 18 14:52 InterfaceBuilder/
drwxr-xr-x   8 dinu  staff    272 Jun 18 14:52 AddressBook/
drwxr-xr-x  17 dinu  staff    578 Jun 18 14:52 AppKit/
drwxr-xr-x  14 dinu  staff    476 Jun 18 14:52 objc/
-rwxr-xr-x   1 root  staff  43932 Jun 18 14:51 autoGIL.so*
-rw-r--r--   1 dinu  staff  30760 May 30 20:09 bundlebuilder.pyc
-rw-r--r--   1 root  staff  24310 May  6 15:49 bundlebuilder.py
-rw-r--r--   1 dinu  staff  22592 May  2 21:57 plistlib.pyc
-rw-r--r--   1 dinu  staff  10843 Nov 22  2002 plistlib.py
[localhost:python2.2/site-packages/PyObjC] dinu%
[localhost:python2.2/site-packages/PyObjC] dinu%
[localhost:python2.2/site-packages/PyObjC] dinu% sudo epydoc --debug 
--pdf Foundation/
Password:
Importing 23 modules.
   [.......................]
Building API documentation for 23 modules.
   [....
Warning: UID conflict detected: Foundation.NSStringFromClass
Warning: UID conflict detected: Foundation.NSSelectorFromString
...Traceback (most recent call last):
   File "/usr/bin/epydoc", line 8, in ?
     cli()
   File "/usr/lib/python2.2/site-packages/epydoc/cli.py", line 90, in cli
     docmap = _make_docmap(modules, options)
   File "/usr/lib/python2.2/site-packages/epydoc/cli.py", line 455, in 
_make_docmap
     try: d.add(module)
   File "/usr/lib/python2.2/site-packages/epydoc/objdoc.py", line 2837, 
in add
     self._add(objID)
   File "/usr/lib/python2.2/site-packages/epydoc/objdoc.py", line 2850, 
in _add
     self._add(link.target())
   File "/usr/lib/python2.2/site-packages/epydoc/objdoc.py", line 2843, 
in _add
     self.add_one(objID)
   File "/usr/lib/python2.2/site-packages/epydoc/objdoc.py", line 2786, 
in add_one
     self.data[objID] = ClassDoc(objID, self._verbosity)
   File "/usr/lib/python2.2/site-packages/epydoc/objdoc.py", line 1514, 
in __init__
     self._base_order = [make_uid(b) for b in base_order]
   File "/usr/lib/python2.2/site-packages/epydoc/uid.py", line 726, in 
make_uid
     uid = ObjectUID(object)
   File "/usr/lib/python2.2/site-packages/epydoc/uid.py", line 399, in 
__init__
     name = self._findname()
   File "/usr/lib/python2.2/site-packages/epydoc/uid.py", line 448, in 
_findname
     objname = obj.__name__
AttributeError: No attribute __name__

--
Dinu C. Gherman
......................................................................
"I am a gentlemen: I live by robbing the poor." (George Bernard Shaw)

Re: [Pyobjc-dev] tutorial_reading.txt

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

On Monday, Jul 28, 2003, at 16:51 America/New_York, Jack Jansen wrote:

> Folks,
> has anyone looked at Doc/tutorial_reading.txt yet? It is a 
> half-finished tutorial intended to help people without an ObjC 
> background to get some basic idea of the Cocoa design philosophy and 
> apply that to reading one or a few of the existing PyObjC examples.
>
> I'd like some feedback to what is there already, plus suggestions on 
> what more should go in. And: if you think the whole idea is silly 
> anyway, or incorrectly structured, or whatever: also please let me 
> know.

As far as what you've got already, I just read through it quickly and 
here's some short comments:

Model-View-Controller:
--------------------------------
IIRC, Swing is both popular and MVC-ish (speaking from memory not 
experience).  Might be worth mentioning the difference between MVC and 
Document/View (a la MFC).  And of course, it's quite possible that you 
can or should do MVC style in Carbon, win32api, wxWindows, etc. but the 
APIs themselves are low level and do not facilitate/encourage this 
directly :)

The NIB file:
-----------------
You should definitely compare a NIB to a pickle... where awakeFromNib: 
(you should correct this, btw, your doc says awakeFromNIB:) is very 
similar in nature to __setstate__, but it happens after all objects 
have been unserialized (IIRC there's another method that the NSCoder(?) 
protocols use to do the up-front stuff).

As far as direction/etc. I'll try and get back to you on that after I 
get some time and put some thought into it.

-bob

[Pyobjc-dev] tutorial_reading.txt

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

Folks,
has anyone looked at Doc/tutorial_reading.txt yet? It is a 
half-finished tutorial intended to help people without an ObjC 
background to get some basic idea of the Cocoa design philosophy and 
apply that to reading one or a few of the existing PyObjC examples.

I'd like some feedback to what is there already, plus suggestions on 
what more should go in. And: if you think the whole idea is silly 
anyway, or incorrectly structured, or whatever: also please let me know.
--
- 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] Fwd: Hard Objc-Runtime question: objc_getClassList lies to me...

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

On maandag, jul 28, 2003, at 13:43 Europe/Amsterdam, Ronald Oussoren 
wrote:

> The message below has some technical information on ZeroLinking. On a 
> first reading, Zerolinking cannot be used with PyObjC as the latter 
> assumes that objc_getClassList returns all classes.

Unless there is a way in which we can hook into ZeroLink, so we can 
make it defer to us for any classes it can't find. But even if that 
isn't possible, it seems that the following sentence also shows an 
escape route:

>> If you need objc_getClassList() to return all of your classes, you can
>> * explicitly use them early on in your code

--
- 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] Fwd: Hard Objc-Runtime question: objc_getClassList lies to me...

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

The message below has some technical information on ZeroLinking. On a 
first reading, Zerolinking cannot be used with PyObjC as the latter 
assumes that objc_getClassList returns all classes.

Begin forwarded message:

> From: Greg Parker <gp...@ap...>
> Date: Sun, 27 Jul 2003 19:13:27 -0700
> To: mha...@ma...
> Cc: coc...@li...
> Subject: Re: Hard Objc-Runtime question: objc_getClassList lies to 
> me...
>
> Martin wrote:
> > The first time I call -allClasses I don't get "DWTClassListerTest
> > included in the results, though it works after the call to
> > objc_lookUpClass. :(
> >
> > Well... The Runtime obviously knows about the class I am asking it,
> > because I can look it up via "objc_lookupClass", but how can I get
> > all of these classes without knowing their name beforehand?
>
> As you've already discovered, this behavior is a side effect of
> ZeroLink. Here's some more details about what's going on.
>
> (Terminology note: an `image` is any Mach-O file with binary code in 
> it,
> like an application, library, or bundle. Mach-O images are subdivided
> into `modules`. Each module typically corresponds to a single source
> code file.)
>
> objc_getClassList() returns all of the classes that have been
> registered with the Objective-C runtime. Ordinarily, all classes in
> an image are loaded together when that image is loaded into the 
> process.
> Thus objc_getClassList() will show all classes in all of Foundation
> once Foundation is loaded.
>
> When running with ZeroLink, the Objective-C runtime (as well as C
> and C++) is lazier. Instead of loading all classes in an image
> together, the runtime only loads all classes in an individual
> module; other classes in other modules in the same image are left
> alone.
>
> objc_lookUpClass() used to simply check whether a class had been
> loaded yet. It now has a side-effect when running with ZeroLink:
> if the class has not been loaded yet but ZeroLink can find it,
> then ZeroLink will bring it in.
>
> In your code, the "missing" class is presumably in a different
> source file and thus in a different Mach-O module. The class is
> not yet loaded when objc_getClassList() is called the first time,
> and objc_lookUpClass() forces ZeroLink to load it before the second
> objc_getClassList() call.
>
> If you need objc_getClassList() to return all of your classes, you can
> * explicitly use them early on in your code
> * link your program with -single_module
> * turn off ZeroLink in your project
>
>
> --
> Greg Parker     gp...@ap...     Java & Objective-C
> _______________________________________________
> cocoa-dev mailing list | coc...@li...
> Help/Unsubscribe/Archives: 
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>

[Pyobjc-dev] [ pyobjc-Bugs-777308 ] Introspection of PyObjC modules crashes

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

Bugs item #777308, was opened at 2003-07-24 21:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=777308&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Introspection of PyObjC modules crashes

Initial Comment:
Running OS X 10.2.6
Jack's latest Python 2.3rc1-8
PyObjC compiled from July 23rd CVS snapshot, not using 
XCode

Using help or pydoc on Foundation or WebKit causes a Bus 
Error.  This is the traceback from "import WebKit; 
help(WebKit)" from the interactive prompt under gdb.  I 
imagine the traceback for "import Foundation; 
help(Foundation)" would do the same thing.  This behavior 
probably happens with all the PyObjC modules, but I haven't 
verified this.

Program received signal EXC_BAD_ACCESS, Could not 
access memory.
PyObject_GenericGetAttr (obj=0x88030, name=0xbaa48) at 
/Users/jack/src/python-rc/Objects/object.c:1399
1399    /Users/jack/src/python-rc/Objects/object.c: No such 
file or directory.
        in /Users/jack/src/python-rc/Objects/object.c
(gdb) bt
#0  PyObject_GenericGetAttr (obj=0x88030, 
name=0xbaa48) at /Users/jack/src/python-rc/Objects/
object.c:1399
#1  0x10009a24 in PyObject_IsInstance (inst=0x88030, 
cls=0x21b7d0) at /Users/jack/src/python-rc/Objects/
abstract.c:2059
#2  0x1006ce14 in builtin_isinstance (self=0x100f79f0, 
args=0x1) at /Users/jack/src/python-rc/Python/
bltinmodule.c:1871
#3  0x100770d4 in call_function (pp_stack=0xbfffd57c, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3439
#4  0x10074cac in eval_frame (f=0x41a980) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#5  0x10075fc4 in PyEval_EvalCodeEx (co=0x11bc60, 
globals=0x1, locals=0x2, args=0x53a6f4, argcount=3, 
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) 
at /Users/jack/src/python-rc/Python/ceval.c:2663
#6  0x10025a64 in function_call (func=0x11bc60, arg=0x3, 
kw=0x41aacc) at /Users/jack/src/python-rc/Objects/
funcobject.c:504
#7  0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#8  0x10076f68 in PyEval_CallObjectWithKeywords 
(func=0x12db70, arg=0x53a6e8, kw=0x0) at /Users/jack/
src/python-rc/Python/ceval.c:3346
#9  0x0020214c in ObjC_UpdateConvenienceMethods ()
#10 0x00208d24 in PyObjCClass_CheckMethodList ()
#11 0x0020a2a0 in PyObjCClass_HasPythonImplementation 
()
#12 0x1006b6b0 in builtin_hasattr (self=0x100f79f0, 
args=0x1) at /Users/jack/src/python-rc/Python/
bltinmodule.c:706
#13 0x100770d4 in call_function (pp_stack=0xbfffddbc, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3439
#14 0x10074cac in eval_frame (f=0x3073b0) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#15 0x10077324 in fast_function (func=0x100f79f0, 
pp_stack=0x8, n=1, na=268678736, nk=269551160) at /
Users/jack/src/python-rc/Python/ceval.c:3518
#16 0x100771ac in call_function (pp_stack=0xbfffdf4c, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3458
#17 0x10074cac in eval_frame (f=0x364c00) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#18 0x10077324 in fast_function (func=0x100f79f0, 
pp_stack=0x6, n=1, na=268678736, nk=269551160) at /
Users/jack/src/python-rc/Python/ceval.c:3518
#19 0x100771ac in call_function (pp_stack=0xbfffe0dc, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3458
#20 0x10074cac in eval_frame (f=0x36f8c0) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#21 0x10075fc4 in PyEval_EvalCodeEx (co=0x56f920, 
globals=0x1, locals=0x2, args=0x365c5c, argcount=2, 
kws=0x365c64, kwcount=0, defs=0x5f095c, defcount=1, 
closure=0x0) at /Users/jack/src/python-rc/Python/
ceval.c:2663
#22 0x100773b8 in fast_function (func=0x100f79f0, 
pp_stack=0x4, n=3562588, na=268678736, nk=269551160) 
at /Users/jack/src/python-rc/Python/ceval.c:3529
#23 0x100771ac in call_function (pp_stack=0xbfffe2fc, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3458
#24 0x10074cac in eval_frame (f=0x365ac0) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#25 0x10075fc4 in PyEval_EvalCodeEx (co=0x5460e0, 
globals=0x1, locals=0x2, args=0x10, argcount=3, kws=0x0, 
kwcount=0, defs=0x6047e4, defcount=2, closure=0x0) at /
Users/jack/src/python-rc/Python/ceval.c:2663
#26 0x10025a64 in function_call (func=0x5460e0, arg=0x3, 
kw=0x365c0c) at /Users/jack/src/python-rc/Objects/
funcobject.c:504
#27 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#28 0x10077940 in ext_do_call (func=0x601630, 
pp_stack=0x4802224c, flags=991940, na=1, nk=0) at /
Users/jack/src/python-rc/Python/ceval.c:3713
#29 0x10074da0 in eval_frame (f=0xf2160) at /Users/jack/
src/python-rc/Python/ceval.c:2151
#30 0x10075fc4 in PyEval_EvalCodeEx (co=0x4746a0, 
globals=0x1, locals=0x2, args=0x10bf94, argcount=3, 
kws=0x10bfa0, kwcount=0, defs=0x5ff0dc, defcount=1, 
closure=0x0) at /Users/jack/src/python-rc/Python/
ceval.c:2663
#31 0x100773b8 in fast_function (func=0x100f79f0, 
pp_stack=0x88030, n=1097620, na=268678736, 
nk=269551160) at /Users/jack/src/python-rc/Python/
ceval.c:3529
#32 0x100771ac in call_function (pp_stack=0xbfffe7bc, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3458
#33 0x10074cac in eval_frame (f=0x10be20) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#34 0x10075fc4 in PyEval_EvalCodeEx (co=0x546de0, 
globals=0x1, locals=0x2, args=0xc, argcount=2, 
kws=0x388690, kwcount=0, defs=0x5face4, defcount=2, 
closure=0x0) at /Users/jack/src/python-rc/Python/
ceval.c:2663
#35 0x100773b8 in fast_function (func=0x100f79f0, 
pp_stack=0x5facec, n=12, na=268678736, nk=269551160) 
at /Users/jack/src/python-rc/Python/ceval.c:3529
#36 0x100771ac in call_function (pp_stack=0xbfffe9dc, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3458
#37 0x10074cac in eval_frame (f=0x388530) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#38 0x10077324 in fast_function (func=0x100f79f0, 
pp_stack=0x9, n=2, na=268678736, nk=269551160) at /
Users/jack/src/python-rc/Python/ceval.c:3518
#39 0x100771ac in call_function (pp_stack=0xbfffeb6c, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3458
#40 0x10074cac in eval_frame (f=0x7e670) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#41 0x10075fc4 in PyEval_EvalCodeEx (co=0x54f120, 
globals=0x1, locals=0x2, args=0x5fcbcc, argcount=2, 
kws=0x41acd0, kwcount=0, defs=0x5ff51c, defcount=1, 
closure=0x0) at /Users/jack/src/python-rc/Python/
ceval.c:2663
#42 0x10025a64 in function_call (func=0x54f120, arg=0x2, 
kw=0x7e7bc) at /Users/jack/src/python-rc/Objects/
funcobject.c:504
#43 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#44 0x10015bb4 in instancemethod_call (func=0x601b30, 
arg=0x5fcbc0, kw=0x536f60) at /Users/jack/src/python-rc/
Objects/classobject.c:2432
#45 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#46 0x10015138 in instance_call (func=0x3, arg=0x118e70, 
kw=0x536f60) at /Users/jack/src/python-rc/Objects/
classobject.c:1998
#47 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#48 0x10077940 in ext_do_call (func=0x5fc710, 
pp_stack=0x48024284, flags=3, na=0, nk=0) at /Users/
jack/src/python-rc/Python/ceval.c:3713
#49 0x10074da0 in eval_frame (f=0xe0780) at /Users/jack/
src/python-rc/Python/ceval.c:2151
#50 0x10075fc4 in PyEval_EvalCodeEx (co=0x95660, 
globals=0x1, locals=0x2, args=0xa7c90, argcount=2, 
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) 
at /Users/jack/src/python-rc/Python/ceval.c:2663
#51 0x10025a64 in function_call (func=0x95660, arg=0x2, 
kw=0xe08cc) at /Users/jack/src/python-rc/Objects/
funcobject.c:504
#52 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#53 0x10015bb4 in instancemethod_call (func=0x95df0, 
arg=0x121350, kw=0x0) at /Users/jack/src/python-rc/
Objects/classobject.c:2432
#54 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#55 0x10015138 in instance_call (func=0x1, arg=0xac430, 
kw=0x0) at /Users/jack/src/python-rc/Objects/
classobject.c:1998
#56 0x1000c724 in PyObject_Call (func=0x100f79f0, 
arg=0x1, kw=0x48424248) at /Users/jack/src/python-rc/
Objects/abstract.c:1755
#57 0x100774dc in do_call (func=0xa9620, 
pp_stack=0x9f648, na=705584, nk=269451716) at /Users/
jack/src/python-rc/Python/ceval.c:3644
#58 0x100771c4 in call_function (pp_stack=0xbffff7bc, 
oparg=1) at /Users/jack/src/python-rc/Python/ceval.c:3460
#59 0x10074cac in eval_frame (f=0x51470) at /Users/jack/
src/python-rc/Python/ceval.c:2116
#60 0x10075fc4 in PyEval_EvalCodeEx (co=0x11b520, 
globals=0x1, locals=0x2, args=0x0, argcount=0, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at /Users/
jack/src/python-rc/Python/ceval.c:2663
#61 0x10078e38 in PyEval_EvalCode (co=0x100f79f0, 
globals=0x1, locals=0x48424248) at /Users/jack/src/python-
rc/Python/ceval.c:537
#62 0x100a9c98 in run_node (n=0x0, filename=0x1 
<Address 0x1 out of bounds>, globals=0xa29c0, 
locals=0xa29c0, flags=0x100f9d94) at /Users/jack/src/
python-rc/Python/pythonrun.c:1205
#63 0x100a917c in PyRun_InteractiveOneFlags 
(fp=0x11b520, filename=0x100e77b8 "<stdin>", 
flags=0x515bc) at /Users/jack/src/python-rc/Python/
pythonrun.c:697
#64 0x100a8f5c in PyRun_InteractiveLoopFlags 
(fp=0x118f94, filename=0x91158 "", flags=0x100e8f88) at /
Users/jack/src/python-rc/Python/pythonrun.c:630
#65 0x100aa9d4 in PyRun_AnyFileExFlags (fp=0xa0000cd4, 
filename=0x100e77b8 "<stdin>", closeit=333244, 
flags=0xbffffb10) at /Users/jack/src/python-rc/Python/
pythonrun.c:593
#66 0x100b5c14 in Py_Main (argc=603980418, argv=0x0) at 
/Users/jack/src/python-rc/Modules/main.c:415
#67 0x00001b5c in _start ()
#68 0x000019dc in start ()


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

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

[Pyobjc-dev] !¢FMortgage Rates At 40 year Low AA r

[Jason <hea...@se...>]

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html;charset=3Diso-8859-=
1">
<HTML>
<HEAD>
<TITLE>Get Cash Out!</TITLE>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859=
-1">
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
<CENTER>
<TABLE BORDER=3D"0" CELLPADDING=3D"0" CELLSPACING=3D"0">
<TR>
<TD COLSPAN=3D"2">
<A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort=
gage4321.com/debt/images/top1.gif" WIDTH=3D"550" HEIGHT=3D"76" BORDER=3D"0=
"></A></TD>
</TR>
<TR>
<TD>
<A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort=
gage4321.com/debt/images/photo.jpg" WIDTH=3D"238" HEIGHT=3D"188" BORDER=3D=
"0"></A></TD>
<TD>
<A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort=
gage4321.com/debt/images/copy.gif" WIDTH=3D"312" HEIGHT=3D"188" BORDER=3D"=
0"></A></TD>
</TR>
<TR>
<TD COLSPAN=3D"2">
<A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort=
gage4321.com/debt/images/nofees.gif" WIDTH=3D"550" HEIGHT=3D"45" BORDER=3D=
"0"></A></TD>
</TR>
<TR>
<TD COLSPAN=3D"2">
<A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort=
gage4321.com/debt/images/rates.gif" WIDTH=3D"550" HEIGHT=3D"41" BORDER=3D"=
0"></A></TD>
</TR>
</TABLE>
</CENTER>
</BODY><BR>
</HTML><br><br>fw t jniwpnzj bkevj
 g flg nzcnnaxszt

Re: [Pyobjc-dev] Anyone using Foundation.NSRectFillList?

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

On woensdag, jul 23, 2003, at 18:22 Europe/Amsterdam, b.bum wrote:
>> The current interface accepts a string containing the struct.pack-ed 
>> representation of an array of NSRects,
>> it should accept a sequence of NSRects instead.
>
> If you are talking about a sequence of python tuples/lists, it should 
> not though accepting both would certainly be preferable.
>
> That implementation came out of my quest to see how fast I could get 
> individual pixels to the screen.  The answer is an array of 1x1 
> rectangles passed to NSRectFillList().   Packing/unpacking across the 
> bridge is painfully slow -- an order of magnitude slower -- than using 
> an array of of struct packed floats.

What a lot of packages do nowadays (PyOpenGL for instance) is accept 
Numeric arrays. Numeric (and probably its upcoming successor NumArray 
too) exports its API in such a way that if a third-party package has 
Numeric available at compile time it does not need to have it available 
at runtime. At runtime you can use a hack to test for Numeric 
availability and query it for its API addresses if it is available.

The hack is fairly well hidden in preprocessor magic, so your code 
looks basically normal.
--
- 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] Wrong spelling of tableView_objectValueForTableColumn_row_()?

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

On Wednesday, July 23, 2003, at 12:49 PM, Ronald Oussoren wrote:

> On Wednesday, 23 July, 2003, at 14:02, Zachery Bir wrote:
>
>> On Wednesday, July 23, 2003, at 06:40 AM, Zachery Bir wrote:
>>
>>> Nope, this is off CVS. Your TableModel doesn't extend 
>>> NSTableDataSource, either. Oh, poo. I wonder if I'm using a 1.0b1 
>>> example and 0.9. Yup.
>>
>> Now using 1.0b1+ on all my pythons: /sw/bin/python (2.2.2), 
>> /usr/bin/python (2.2), and /usr/local/bin/python (2.3b2).
>>
>> Running TableModel.app gets me this crash log (it generates this when 
>> I use /sw/bin/python and /usr/bin/python, but not 
>> /usr/local/bin/python):
>
> Is this for an unmodified TableModel example, or is this part of you 
> application? The TableModel works for me.

Unmodified TableModel all three times. The only one that worked was 
when using 2.3b2. Using fresh copies from the Examples/ directory, each 
named TableModel-2.2, TableModel-2.2.2, and TableModel-2.3, I got two 
more tracebacks, one for 2.2 and one for 2.2.2. These are all built 
directly (no --link) and separately (the first time, I just kept 
rebuilding the app in the same directory).

**********

Date/Time:  2003-07-23 13:02:12 -0400
OS Version: 10.2.6 (Build 6L60)
Host:       gorilla

Command:    python
PID:        11410

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
  #0   0x00017c24 in PyType_GenericNew
  #1   0x0005a948 in PyEval_EvalCode
  #2   0x0005c634 in PyEval_EvalCodeEx
  #3   0x0005db9c in PyEval_GetFuncDesc
  #4   0x0005b314 in PyEval_EvalCode
  #5   0x0005c634 in PyEval_EvalCodeEx
  #6   0x0005db9c in PyEval_GetFuncDesc
  #7   0x0005b314 in PyEval_EvalCode
  #8   0x0005c634 in PyEval_EvalCodeEx
  #9   0x0005db9c in PyEval_GetFuncDesc
  #10  0x0005b314 in PyEval_EvalCode
  #11  0x0005c634 in PyEval_EvalCodeEx
  #12  0x00058a80 in PyEval_EvalCode
  #13  0x00027e90 in PyRun_FileExFlags
  #14  0x00026ef4 in PyRun_SimpleFileExFlags
  #15  0x000069f0 in Py_Main
  #16  0x00002970 in start
  #17  0x000027f0 in start

PPC Thread State:
   srr0: 0x00017c24 srr1: 0x0200f030                vrsave: 0x00000000
    xer: 0x00000000   lr: 0x00017a88  ctr: 0x00038910   mq: 0x00000000
     r0: 0x00000000   r1: 0xbffff3b0   r2: 0x002604fc   r3: 0x00000010
     r4: 0x00000000   r5: 0x00000000   r6: 0x0005b398   r7: 0x0025e9f8
     r8: 0x00103010   r9: 0x00366bd0  r10: 0x00000000  r11: 0x00000000
    r12: 0x00038910  r13: 0x0000007d  r14: 0x0069306c  r15: 0x00000000
    r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00693084
    r20: 0x00120cb6  r21: 0x0010e700  r22: 0x00000002  r23: 0x00692f20
    r24: 0x00000000  r25: 0x0024e1ac  r26: 0x006b4860  r27: 0x0025dd78
    r28: 0x0036efc0  r29: 0x0013c950  r30: 0x006b4860  r31: 0x00017a78

**********

Date/Time:  2003-07-23 13:02:31 -0400
OS Version: 10.2.6 (Build 6L60)
Host:       gorilla

Command:    python
PID:        11413

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
  #0   0x0001bc00 in subtype_dealloc
  #1   0x00074318 in eval_frame
  #2   0x00075ee0 in PyEval_EvalCodeEx
  #3   0x00076fc0 in fast_function
  #4   0x00074b8c in eval_frame
  #5   0x00075ee0 in PyEval_EvalCodeEx
  #6   0x00076fc0 in fast_function
  #7   0x00074b8c in eval_frame
  #8   0x00075ee0 in PyEval_EvalCodeEx
  #9   0x00076fc0 in fast_function
  #10  0x00074b8c in eval_frame
  #11  0x00075ee0 in PyEval_EvalCodeEx
  #12  0x00078a04 in PyEval_EvalCode
  #13  0x0002c2f0 in run_node
  #14  0x0002ba9c in PyRun_SimpleFileExFlags
  #15  0x000061b8 in Py_Main
  #16  0x000021d4 in _start (crt.c:267)
  #17  0x00002054 in start

PPC Thread State:
   srr0: 0x0001bc00 srr1: 0x0000f030                vrsave: 0x00000000
    xer: 0x20000000   lr: 0x0001baac  ctr: 0x0004add0   mq: 0x00000000
     r0: 0x00000000   r1: 0xbffff340   r2: 0x00000000   r3: 0x00000000
     r4: 0x00000000   r5: 0x00000000   r6: 0x0001c78c   r7: 0x000daddc
     r8: 0x00000000   r9: 0x00004000  r10: 0x00000000  r11: 0x00000000
    r12: 0x00000000  r13: 0x0050fd6c  r14: 0x00000000  r15: 0x000c22e0
    r16: 0x00000000  r17: 0x00000000  r18: 0x00000001  r19: 0x00000002
    r20: 0x0050fc20  r21: 0x00000000  r22: 0x00000002  r23: 0x0001ba8c
    r24: 0x007216e0  r25: 0x000057fb  r26: 0x0036cb50  r27: 0x000015eb
    r28: 0x00000000  r29: 0x00364760  r30: 0x0028f1ac  r31: 0x0001ba9c

Re: [Pyobjc-dev] Anyone using Foundation.NSRectFillList?

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

On Wednesday, July 23, 2003, at 9:46 AM, Ronald Oussoren wrote:
> The current implementation (checked in this morning, MEST) accepts the 
> 'old' style arguments as well as a sequence of python tuples 
> representing NSRects.

Cool.

> Speed is an issue of course, but I'd expect that using the new 
> arguments would be as fast as struct.pack + old arguments. That is, 
> unless you draw the same rects over and over again. I'll leave the 
> old-style arguments in for when speed is really important.

Excellent.   When I have a moment to breathe, I'll dust off the old 
example and fix it up to actually show the drawing speed in the window 
with the drawing + a popup to select between different styles of 
drawing.

Similar wrapping should also exist for the rest of the NSGraphics 
functional API, but that should likely be held off until we know 
exactly what performance advantages, if any, are gained through the 
different calling styles.

b.bum

Re: [Pyobjc-dev] Wrong spelling of tableView_objectValueForTableColumn_row_()?

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

On Wednesday, 23 July, 2003, at 14:02, Zachery Bir wrote:

> On Wednesday, July 23, 2003, at 06:40 AM, Zachery Bir wrote:
>
>> Nope, this is off CVS. Your TableModel doesn't extend 
>> NSTableDataSource, either. Oh, poo. I wonder if I'm using a 1.0b1 
>> example and 0.9. Yup.
>
> Now using 1.0b1+ on all my pythons: /sw/bin/python (2.2.2), 
> /usr/bin/python (2.2), and /usr/local/bin/python (2.3b2).
>
> Running TableModel.app gets me this crash log (it generates this when 
> I use /sw/bin/python and /usr/bin/python, but not 
> /usr/local/bin/python):

Is this for an unmodified TableModel example, or is this part of you 
application? The TableModel works for me.

Ronald

Re: [Pyobjc-dev] Anyone using Foundation.NSRectFillList?

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

On Wednesday, 23 July, 2003, at 18:22, b.bum wrote:

> On Tuesday, July 22, 2003, at 12:16 PM, Ronald Oussoren wrote:
>> I just noticed that the interface of the wrapped NSRectFillList is a 
>> bit odd. Is anyone using this function at the moment, I'd like to 
>> clean up the interface.
>>
>> The current interface accepts a string containing the struct.pack-ed 
>> representation of an array of NSRects,
>> it should accept a sequence of NSRects instead.
>
> If you are talking about a sequence of python tuples/lists, it should 
> not though accepting both would certainly be preferable.

The current implementation (checked in this morning, MEST) accepts the 
'old' style arguments as well as a sequence of python tuples 
representing NSRects.

>
> That implementation came out of my quest to see how fast I could get 
> individual pixels to the screen.  The answer is an array of 1x1 
> rectangles passed to NSRectFillList().   Packing/unpacking across the 
> bridge is painfully slow -- an order of magnitude slower -- than using 
> an array of of struct packed floats.
>
> I have been meaning to turn the app I used to do the testing into an 
> example.   Using NSBezierPath generated about 10,000 points every 2 
> seconds... NSBitmapImageRep could plot around 25,000 or something.... 
> NSRectFillList as currently implemented could do 250,000 points every 
> 2 seconds.

Speed is an issue of course, but I'd expect that using the new 
arguments would be as fast as struct.pack + old arguments. That is, 
unless you draw the same rects over and over again. I'll leave the 
old-style arguments in for when speed is really important.

Ronald

Re: [Pyobjc-dev] Anyone using Foundation.NSRectFillList?

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

On Tuesday, July 22, 2003, at 12:16 PM, Ronald Oussoren wrote:
> I just noticed that the interface of the wrapped NSRectFillList is a 
> bit odd. Is anyone using this function at the moment, I'd like to 
> clean up the interface.
>
> The current interface accepts a string containing the struct.pack-ed 
> representation of an array of NSRects,
> it should accept a sequence of NSRects instead.

If you are talking about a sequence of python tuples/lists, it should 
not though accepting both would certainly be preferable.

That implementation came out of my quest to see how fast I could get 
individual pixels to the screen.  The answer is an array of 1x1 
rectangles passed to NSRectFillList().   Packing/unpacking across the 
bridge is painfully slow -- an order of magnitude slower -- than using 
an array of of struct packed floats.

I have been meaning to turn the app I used to do the testing into an 
example.   Using NSBezierPath generated about 10,000 points every 2 
seconds... NSBitmapImageRep could plot around 25,000 or something.... 
NSRectFillList as currently implemented could do 250,000 points every 2 
seconds.

b.bum

Re: [Pyobjc-dev] Wrong spelling of tableView_objectValueForTableColumn_row_()?

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

On Wednesday, Jul 23, 2003, at 14:02 Europe/Amsterdam, Zachery Bir 
wrote:

> On Wednesday, July 23, 2003, at 06:40 AM, Zachery Bir wrote:
>
>> Nope, this is off CVS. Your TableModel doesn't extend 
>> NSTableDataSource, either. Oh, poo. I wonder if I'm using a 1.0b1 
>> example and 0.9. Yup.
>
> Now using 1.0b1+ on all my pythons: /sw/bin/python (2.2.2), 
> /usr/bin/python (2.2), and /usr/local/bin/python (2.3b2).
>
> Running TableModel.app gets me this crash log (it generates this when 
> I use /sw/bin/python and /usr/bin/python, but not 
> /usr/local/bin/python):

Sounds like an instance of the borrowed reference problem[*], but then 
I would expect it to happen with 2.3b2 too...

[*] there are a number of Cocoa routines that keep a reference to an 
object you pass in, but without doing the retain(). For ObjC programs 
this tends to be harmless, but not for PyObjC programs. A quick check 
to see whether this is the problem is to keep a reference to the Python 
object, that will work around this problem.
--
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] Wrong spelling of tableView_objectValueForTableColumn_row_()?

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

On Wednesday, July 23, 2003, at 06:40 AM, Zachery Bir wrote:

> Nope, this is off CVS. Your TableModel doesn't extend 
> NSTableDataSource, either. Oh, poo. I wonder if I'm using a 1.0b1 
> example and 0.9. Yup.

Now using 1.0b1+ on all my pythons: /sw/bin/python (2.2.2), 
/usr/bin/python (2.2), and /usr/local/bin/python (2.3b2).

Running TableModel.app gets me this crash log (it generates this when I 
use /sw/bin/python and /usr/bin/python, but not /usr/local/bin/python):

Date/Time:  2003-07-23 07:49:39 -0400
OS Version: 10.2.6 (Build 6L60)
Host:       gorilla

Command:    python
PID:        11289

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
  #0   0x0001bc00 in subtype_dealloc
  #1   0x00074318 in eval_frame
  #2   0x00075ee0 in PyEval_EvalCodeEx
  #3   0x00076fc0 in fast_function
  #4   0x00074b8c in eval_frame
  #5   0x00075ee0 in PyEval_EvalCodeEx
  #6   0x00076fc0 in fast_function
  #7   0x00074b8c in eval_frame
  #8   0x00075ee0 in PyEval_EvalCodeEx
  #9   0x00076fc0 in fast_function
  #10  0x00074b8c in eval_frame
  #11  0x00075ee0 in PyEval_EvalCodeEx
  #12  0x00078a04 in PyEval_EvalCode
  #13  0x0002c2f0 in run_node
  #14  0x0002ba9c in PyRun_SimpleFileExFlags
  #15  0x000061b8 in Py_Main
  #16  0x000021d4 in _start (crt.c:267)
  #17  0x00002054 in start

PPC Thread State:
   srr0: 0x0001bc00 srr1: 0x0000f030                vrsave: 0x00000000
    xer: 0x20000000   lr: 0x0001baac  ctr: 0x0004add0   mq: 0x00000000
     r0: 0x00000000   r1: 0xbffff360   r2: 0x00000000   r3: 0x00000000
     r4: 0x00000000   r5: 0x00000000   r6: 0x0001c78c   r7: 0x000daddc
     r8: 0x00000000   r9: 0x00004000  r10: 0x00000000  r11: 0x00000000
    r12: 0x00000000  r13: 0x0070aadc  r14: 0x00000000  r15: 0x000c22e0
    r16: 0x00000000  r17: 0x00000000  r18: 0x00000001  r19: 0x00000002
    r20: 0x0070a990  r21: 0x00000000  r22: 0x00000002  r23: 0x0001ba8c
    r24: 0x00721300  r25: 0x000057fb  r26: 0x0036caa0  r27: 0x000015eb
    r28: 0x00000000  r29: 0x003646b0  r30: 0x0028f1ac  r31: 0x0001ba9c