pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] NSString.localizedCaseInsensitiveCompare:

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

Shouldn't this work?

NSString.localizedCaseInsensitiveCompare_('foo','bar')

When I try it I get a complaint that the argument should be an NSString 
instead of a Python string.  I guess this means there is a signature 
missing somewhere?  I don't understand signatures well enough to correct it.

Really it would be better to be able to call
'foo'.localizedCaseInsensitiveCompare_('bar')
but I can see why that's unlikely to work...

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

On zondag, dec 22, 2002, at 21:05 Europe/Amsterdam, Just van Rossum 
wrote:
> Ok, got it through CVS as gcc/libffi.
>
[...]
> [python:~/code/gcc/libffi] just% ./configure
> loading cache ./config.cache
> checking for Cygwin environment... no
> checking for mingw32 environment... no
> configure: error: can not find install-sh or install.sh in ./../..
> ././../..
> [python:~/code/gcc/libffi] just%

You have to check out the *whole* gcc tree. At least, I tried for a 
while to fix libffi/configure to make it work standalone, but in the 
end I checked out the whole gcc tree, then built only libffi. That was 
a lot easier (at the cost of a bit extra disk space).
--
- 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] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

On Sunday, Dec 22, 2002, at 21:05 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> I got mine by doing a CVS checkout of the GCC trunk. Just downloading
>> a recent copy of GCC will probably work just as well. If you go the
>> CVS route, checking out 'gcc/libffi' instead of the entire gcc module
>> saves a lot of time.
>
> Ok, got it through CVS as gcc/libffi.
>
>> The configure in libffi will give a fatal error near the end of
>> configureing, just ignore the error. Libffi itself is already
>> configured by the time you encounter the error; it tries to patch a
>> file one level up in the directory tree.
>
> [python:~/code/gcc/libffi] just% ./configure
> loading cache ./config.cache
> checking for Cygwin environment... no
> checking for mingw32 environment... no
> configure: error: can not find install-sh or install.sh in ./../..
> ././../..
> [python:~/code/gcc/libffi] just%
>
> This doesn't create a Makefile. Any more things I need to do?

So much for untested advice... Appearently libffi depends more on files 
in the rest of GCC than I thought. I'll try to build a small archive 
containing everything that is needed to experiment with a 
libffi-enabled version of PyObjC.

Ronald

Re: [Pyobjc-dev] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

Ronald Oussoren wrote:

> I got mine by doing a CVS checkout of the GCC trunk. Just downloading
> a recent copy of GCC will probably work just as well. If you go the
> CVS route, checking out 'gcc/libffi' instead of the entire gcc module
> saves a lot of time.

Ok, got it through CVS as gcc/libffi.

> The configure in libffi will give a fatal error near the end of
> configureing, just ignore the error. Libffi itself is already
> configured by the time you encounter the error; it tries to patch a
> file one level up in the directory tree.

[python:~/code/gcc/libffi] just% ./configure 
loading cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
configure: error: can not find install-sh or install.sh in ./../..
././../..
[python:~/code/gcc/libffi] just% 

This doesn't create a Makefile. Any more things I need to do?

Just

Re: [Pyobjc-dev] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

On Sunday, Dec 22, 2002, at 20:29 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> Libffi is a library for dynamicly building stackframes and calling
>> existing C functions. One of my earlier checkins today added code
>> that uses libffi to call the superclass implementation of methods and
>> to build the entries in the method tables of Objective-C classes.
>> This allows us to do away with Modules/objc/register.m, a really
>> enormous file. The library is also necessary if you want to add
>> methods to pure Objective-C classes (which is simular to writing
>> Objective-C categories in Python).
>
> [...googling, checking the page at redhat.com...]
> Oooh, way cool! calldll done right! Must Have Python Interface ;-)

+1 on that.

>
>> The main disadvantage of libffi is that it is a 3th party library
>> that is not easily available: The current version is only available
>> as part of the GCC sourcetree.
>
> You wrote in libffi.txt:
>
>> To enable libFFI support:
>> - Build and install libffi 2.x, this is only available from a source
>> distribution of GCC.  Do NOT use the version from sources.redhat.com,
>> it doesn't support MacOS X at all.  The version I used (december
>> 2002) doesn't allow you to build a shared library on MacOSX. This is
>> not a problem, we don't want one anyway.
>
> Do you have a more specific pointer where you got your copy?

I got mine by doing a CVS checkout of the GCC trunk. Just downloading a 
recent copy of GCC will probably work just as well. If you go the CVS 
route, checking out 'gcc/libffi' instead of the entire gcc module saves 
a lot of time.

The configure in libffi will give a fatal error near the end of 
configureing, just ignore the error. Libffi itself is already 
configured by the time you encounter the error; it tries to patch a 
file one level up in the directory tree.

Ronald

Re: [Pyobjc-dev] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

Ronald Oussoren wrote:

> Libffi is a library for dynamicly building stackframes and calling
> existing C functions. One of my earlier checkins today added code
> that uses libffi to call the superclass implementation of methods and
> to build the entries in the method tables of Objective-C classes.
> This allows us to do away with Modules/objc/register.m, a really
> enormous file. The library is also necessary if you want to add
> methods to pure Objective-C classes (which is simular to writing
> Objective-C categories in Python).

[...googling, checking the page at redhat.com...]
Oooh, way cool! calldll done right! Must Have Python Interface ;-)

> The main disadvantage of libffi is that it is a 3th party library
> that is not easily available: The current version is only available
> as part of the GCC sourcetree.

You wrote in libffi.txt:

> To enable libFFI support:
> - Build and install libffi 2.x, this is only available from a source
> distribution of GCC.  Do NOT use the version from sources.redhat.com,
> it doesn't support MacOS X at all.  The version I used (december
> 2002) doesn't allow you to build a shared library on MacOSX. This is
> not a problem, we don't want one anyway.

Do you have a more specific pointer where you got your copy?

Just

Re: [Pyobjc-dev] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

On Sunday, Dec 22, 2002, at 19:53 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> Modified Files:
>>   setup.py
>> Log Message:
>> libffi support should be off by default
>
> Yet it does break the build: I apparently don't have libffi (I have no
> idea what it is even), and setup.py stops like this:
>
> [ ...losts of similar stuff omitted...]
> Modules/objc/libffi_support.m:399: parse error before "cif"

Ehmm, I really shouldn't check in code on sunday night... This checkin 
was really bogus, the patch actually _enables_ libffi support.

Libffi is a library for dynamicly building stackframes and calling 
existing C functions. One of my earlier checkins today added code that 
uses libffi to call the superclass implementation of methods and to 
build the entries in the method tables of Objective-C classes. This 
allows us to do away with Modules/objc/register.m, a really enormous 
file. The library is also necessary if you want to add methods to pure 
Objective-C classes (which is simular to writing Objective-C categories 
in Python).

The main disadvantage of libffi is that it is a 3th party library that 
is not easily available: The current version is only available as part 
of the GCC sourcetree.

Ronald 

Re: [Pyobjc-dev] Stripping _objc.so

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

On Sunday, Dec 22, 2002, at 19:48 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Dec 22, 2002, at 13:07 US/Eastern, Just van Rossum wrote:
> Ronald Oussoren wrote:
>>
>>> - setup.py: By default strip the .so files, this seriously reduces
>>> the size of module objc._objc.
>>
>> Is this such a good idea? Btw. bundlebuilder/buildapp.py has a --strip
>> option to strip all binaries when building standalone apps (indeed
>> helps a lot, size-wise), but I wouldn't do this do this for a library
>> install. Does it have any performance advantage to strip objc._objc?
>
> For the installer package-- for the version that goes in 
> site-packages-- I don't think stripping makes a huge difference.   It 
> will not significantly impact load times as the whole file is memory 
> mapped and the symbol table is basically just a big blob near the end. 
>  Nor will it affect runtime performance unless your system is 
> incredibly tight on RAM.
>
> The project builder copy files phases could be augmented to do the 
> strip, as well.

I forgot about stripping while building a '.app' bundle. I'll roll back 
this change.


Ronald

Re: [Pyobjc-dev] Stripping _objc.so

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

bb...@ma... wrote:

> For the installer package-- for the version that goes in
> site-packages-- I don't think stripping makes a huge difference.  

(Btw. is "python setup.py install" equivalent to what the installer
does?)

> It
> will not significantly impact load times as the whole file is memory
> mapped and the symbol table is basically just a big blob near the
> end. Nor will it affect runtime performance unless your system is
> incredibly tight on RAM.
> 
> The project builder copy files phases could be augmented to do the
> strip, as well.
> 
> Not having the symbols does make debugging more difficult in that gdb
> will be unable to fully resolve symbols, line numbers, etc...

I'm pretty sure it affects Console.app crash reports as well.

Just

[Pyobjc-dev] Build broken (Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.19,1.20)

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

Ronald Oussoren wrote:

> Modified Files:
>   setup.py 
> Log Message:
> libffi support should be off by default

Yet it does break the build: I apparently don't have libffi (I have no
idea what it is even), and setup.py stops like this:

[ ...losts of similar stuff omitted...]
Modules/objc/libffi_support.m:399: parse error before "cif"
Modules/objc/libffi_support.m:400: `ffi_type' undeclared (first use in
this function)
Modules/objc/libffi_support.m:400: `arglist' undeclared (first use in
this function)
Modules/objc/libffi_support.m:513: `ffi_type_pointer' undeclared (first
use in this function)
Modules/objc/libffi_support.m:635: `cif' undeclared (first use in this
function)
Modules/objc/libffi_support.m:635: `FFI_DEFAULT_ABI' undeclared (first
use in this function)
Modules/objc/libffi_support.m:637: `FFI_OK' undeclared (first use in
this function)
Modules/objc/libffi_support.m:645: warning: implicit declaration of
function `ffi_call'
Modules/objc/libffi_support.m:645: warning: implicit declaration of
function `FFI_FN'
error: command 'gcc' failed with exit status 1

Just

[Pyobjc-dev] Stripping _objc.so

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

On Sunday, Dec 22, 2002, at 13:07 US/Eastern, Just van Rossum wrote:
Ronald Oussoren wrote:
>
>> - setup.py: By default strip the .so files, this seriously reduces
>> the size of module objc._objc.
>
> Is this such a good idea? Btw. bundlebuilder/buildapp.py has a --strip
> option to strip all binaries when building standalone apps (indeed
> helps a lot, size-wise), but I wouldn't do this do this for a library
> install. Does it have any performance advantage to strip objc._objc?

For the installer package-- for the version that goes in 
site-packages-- I don't think stripping makes a huge difference.   It 
will not significantly impact load times as the whole file is memory 
mapped and the symbol table is basically just a big blob near the end.  
Nor will it affect runtime performance unless your system is incredibly 
tight on RAM.

The project builder copy files phases could be augmented to do the 
strip, as well.

Not having the symbols does make debugging more difficult in that gdb 
will be unable to fully resolve symbols, line numbers, etc...

b.bum

[Pyobjc-dev] Re: [Pyobjc-checkins] CVS: pyobjc setup.py,1.18,1.19

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

Ronald Oussoren wrote:

> - setup.py: By default strip the .so files, this seriously reduces
> the size of module objc._objc.

Is this such a good idea? Btw. bundlebuilder/buildapp.py has a --strip
option to strip all binaries when building standalone apps (indeed
helps a lot, size-wise), but I wouldn't do this do this for a library
install. Does it have any performance advantage to strip objc._objc?

Just

Re: [Pyobjc-dev] Faster module loading

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

 
On Saturday, Dec 21, 2002, at 08:44AM, Jack Jansen <Jac...@or...> wrote:

>On vrijdag, dec 20, 2002, at 22:21 Europe/Amsterdam, Ronald Oussoren 
>wrote:
>> - Loading AppKit and Foundation is significantly faster (well over 
>> 100% faster)
>
>Uhm.... So now it finishes loading long before you do the import? 
>That's not bad! :-)

Guido's time machine?

Re: [Pyobjc-dev] ANN: PyObjC 0.8

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

On vrijdag, dec 20, 2002, at 22:27 Europe/Amsterdam, Bill Bumgarner 
wrote:

> [I posted everwhere BUT pyobjc-dev... versiontracker, cocoa-dev, my 
> 'blog, etc...   Whoops! Anywhere else?  freshmeat.net and some others, 
> I'm sure.]

Here's a few more locations where you may want to post it (from my 
MacPython list; I'd be interested in getting your complete list too, 
just to check which ones I'm missing). You may want to skip the Apple 
product guides until a 1.0 release is ready, but python-announce and 
adcnews I think you should do for 0.8.
    pyt...@py...
    ad...@ap...
    http://guide.apple.com/usindex.lasso
    http://www.apple.com/downloads/macosx/submit
--
- 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] Faster module loading

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

On vrijdag, dec 20, 2002, at 22:21 Europe/Amsterdam, Ronald Oussoren 
wrote:
> - Loading AppKit and Foundation is significantly faster (well over 
> 100% faster)

Uhm.... So now it finishes loading long before you do the import? 
That's not bad! :-)
--
- 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] Cocoa documentation browser

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

I just came across 
<http://homepage2.nifty.com/hoshi-takanori/cocoa-browser/>, a pretty 
nifty browser for the Cocoa documentation.

I'm already dreaming of combining this with Python's introspection 
features to allow an IDE to show you the documentation of an object (in 
the complete context of the object hierarchy) at the press of a 
button...
--
- 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] ANN: PyObjC 0.8

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

Ronald Oussoren wrote:

> pyt...@py...?

That should be pyt...@py....

Just

Re: [Pyobjc-dev] ANN: PyObjC 0.8

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

On Friday, Dec 20, 2002, at 22:27 Europe/Amsterdam, Bill Bumgarner 
wrote:

> [I posted everwhere BUT pyobjc-dev... versiontracker, cocoa-dev, my 
> 'blog, etc...   Whoops! Anywhere else?  freshmeat.net and some others, 
> I'm sure.]
pyt...@py...?

Ronald

[Pyobjc-dev] Also available...

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

... I also added a set of language specifications that add syntax 
highlighting and python file type recognition to the December Developer 
tools release of Project Builder -- see the files area of PyObjC.

b.bum

[Pyobjc-dev] ANN: PyObjC 0.8

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

[I posted everwhere BUT pyobjc-dev... versiontracker, cocoa-dev, my  
'blog, etc...   Whoops! Anywhere else?  freshmeat.net and some others,  
I'm sure.]

PyObjC version 0.8 is now available for download.

See...

     http://pyobjc.sourceforge.net/

... for more information.

The installer package includes a Project Builder project template for  
easily creating new Cocoa-Python projects.

PyObjC fully supports creating full featured Cocoa applications written  
in pure Python.  There are aspects of PyObjC that are more powerful  
than Cocoa in pure Obj-C (the ability to automatically define  
classes/outlets based on the contents of a NIB file, for example).

PyObjC requires OS X 10.2 or greater.  10.1 support is possible and  
will likely happen soon-- contact me if you need 10.1 support and are  
willing to do a bit of grunt work to generate the appropriate files  
(easy to do).

PyObjC also provides an awesome environment for exploring frameworks:

 >>> from objc import *
 >>> from Foundation import *
 >>> b =  
NSBundle.bundleWithPath_("/System/Library/PrivateFrameworks/ 
PBXCore.framework")
 >>> b.principalClass()
<objective-c class PBXProducerTarget at 0xa9030034>
 >>> NSBundle.searchPathsForSupportFilesWithSubpath_("FooBar")
(
     "/Volumes/Data/Users/bbum/Developer/ProjectBuilder Extras/FooBar",
     "/Network/Developer/ProjectBuilder Extras/FooBar",
     "/Developer/ProjectBuilder Extras/FooBar"
)
 >>> PBXProject = lookUpClass("PBXProject")
 >>> p =  
PBXProject.projectWithFile_("/Developer/Examples/AppKit/TextEdit/ 
TextEdit.pbproj")
 >>> p.targets()
(<PBXApplicationTarget:0x00a76830:6FE2093EFE93D5F211CA2CEA:name='TextEdi 
t'>)
 >>> p.buildStyles()
(
      
<PBXBuildStyle:0x00a77d30:011ADBA3FF9FD52E11CA0C5D:name='Development':bu 
ildSettings.count=2>,
      
<PBXBuildStyle:0x00a82180:011ADBA4FF9FD52E11CA0C5D:name='Deployment':bui 
ldSettings.count=1>
)

[Pyobjc-dev] Faster module loading

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

Now that 0.8 is out (btw. I haven't seen an official announcement yet, 
just the update on pyobjc.sf.net) I've pushed a number of changes into 
CVS (those of you subscribed to pyobjc-checkins may have noticed this 
<grin>).

User-visible changes are:
- objc.[gs]etVerbose
   Controls a verbosity flag. If this flag is true the core module will 
be slightly
   more verbose. Currently this means that it will print a traceback 
when translating
   an exception from Python to Objective-C
- objc.loadBundle, and no Foundation.load_bundle
   The former is a C function that implements the same functionality as 
the latter
   (well actually slightly more functionality). It is also somewhat 
faster.
- Loading AppKit and Foundation is significantly faster (well over 100% 
faster)

Ronald

[Pyobjc-dev] PyObjC 0.8 Out the Door [and 10.1 support]!

[<bb...@fr...>]

I'm posting the news item now and am going to do the release stuff via 
SF.   I *did* make the change to the source for importing the inc's 
based on system version.   Compilation on 10.1 may actually work now, 
but you will lose *all* enums, functions, and other bits that are 
automatically generated.  For full support, it is a matter of 
converting all the blocks that look like....

#if MAC_OS_X_VERSION_10_2 <= MAC_OS_X_VERSION_MAX_ALLOWED
#include "_App_Functions.inc"
#endif

.... to ....

#if MAC_OS_X_VERSION_10_2 <= MAC_OS_X_VERSION_MAX_ALLOWED
#include "_App_Functions.inc"
#else
#include "_App_Functions_10_1.inc"
#endif

... and auto-generating the appropriate .inc files on 10.1.  If someone 
with access to a 10.1 system can run the generators and send me the 
resulting set of files + patches, I'll be happy to commit.

The generator scripts should eventually be changed to better support 
10.1 vs. 10.2 generation.  Or not-- once generated the files shouldn't 
change, certainly not for 10.1.

This has the advantage of laying the foundation for the inevitable API 
additions in 10.3. :-)

b.bum

Re: [Pyobjc-dev] PyObjC 0.8 Release Candidate

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

On Thursday, Dec 19, 2002, at 15:50 Europe/Amsterdam, Bill Bumgarner 
wrote:

> I'm going to go ahead and change the way that automatically generated 
> files are used such that it should be obvious what the 10.1 files 
> should be named.  If someone can generate 10.1 headers, I would be 
> happy to plug 'em in.

Please do so after releasing 0.8. BTW. I've installed at the release 
candidate and it looks fine.
>
> Given that 10.1 requires a full python installation from a third party 
> and that it is very likely that the pyobjc module built for one 
> installation will not be compatible with another installation due to 
> linking problems, I don't think it is worthwhile to go down the path 
> of building a PyObjC.pkg for 10.1.

Agreed. If someone is adventureous enough to build Python for 10.1 she 
can also build PyObjC.

Ronald

Re: [Pyobjc-dev] PyObjC 0.8 Release Candidate

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

I'm going to go ahead and change the way that automatically generated 
files are used such that it should be obvious what the 10.1 files 
should be named.  If someone can generate 10.1 headers, I would be 
happy to plug 'em in.

Given that 10.1 requires a full python installation from a third party 
and that it is very likely that the pyobjc module built for one 
installation will not be compatible with another installation due to 
linking problems, I don't think it is worthwhile to go down the path of 
building a PyObjC.pkg for 10.1.

With that said, it could be done relatively easily, if anyone so 
desires.   It should even be possible to build 10.1 compatible binaries 
on 10.2 given the way that Apple's compatibility headers work.

b.bum

On Wednesday, Dec 18, 2002, at 13:26 US/Eastern, Ronald Oussoren wrote:
> On Wednesday, Dec 18, 2002, at 17:27 Europe/Amsterdam, Jiva DeVoe 
> wrote:
>> On Tuesday, December 17, 2002, at 09:57  PM, Bill Bumgarner wrote:
>>> No, not currently.   Two issues:
>>>
>>> (1) you'll need a third party install of Python 2.2 or greater.  
>>> Fink or the MacPython community can supply such a beast.
>>>
>>> (2) you will need to regenerate the automatically generated types 
>>> and enums based on the 10.1 headers.  This is easier than it sounds, 
>>> but requires steps that have not been well documented.
>>
>> Is it documented at all?
> Not at all at the moment. Luckily regenerating isn't too hard. Basicly 
> it is:
> $ cd Modules/Cocoa && scripts/cocoa_generator.py
>
> This will generate a number of files (the '.inc' files in 
> Modules/Cocoa). Hopefully you won't have to edit the results.
>> I'll second the request for information on how to run it on 10.1.x... 
>> please point us in the right direction on this.
>
> I'd like to support 10.1.x, but I don't have time to work on that 
> right now. Patches to add that support out of the box are of course 
> welcome ;-) ;-)

Re: [Pyobjc-dev] Does PyObjC have a wiki?

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

GO!

On Wednesday, Dec 18, 2002, at 17:19 US/Eastern, Jiva DeVoe wrote:

> If not, I'd like to set one up.  Specifically, since I see a big issue 
> right now being documentation related, I think having a Wiki, where we 
> can all contribute tips/etc would be cool.  Any objections?
>
> I have the server space and wiki software (moinmoin) already, so it's 
> just a matter of saying "Go"
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Order your Holiday Geek Presents 
> Now!
> Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated 
> Soap,
> MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
> T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
Do the voices in my head bother you?