pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] [Pythonmac-SIG] Installing Mysqldb Module on Python 2.5.1 on Mac OS X 10.5.8

[engelbert g. <gr...@us...>]

hi,

i am new on the mac too, but somehow managed to build mysqldb

as far as i remeber, it requires a mysql installation and the new xcode.

i did not install Mysqldb but copied it into my project directory
(which now bites back: py2app packages it but python only looks in
 usr/lib/...)

did it build ?

On Fri, Jul 30, 2010 at 4:23 PM, Muthoni Masinde
<mut...@gm...> wrote:
> Hello everyone,
> I am a new entrant to Python (but not new in programming).  I am trying to
> install the mysqldb module on my Mac OS in vain.  I have tried all the
> instructions in the README.
>
> I keep getting the following error
>
> setup_posix.py", line 32, in get_config
>     metadata, options = get_metadata_and_options()
>   File
> "/Users/Muthoni/phd2010/Thesis/software/Python/MySQL-python-1.2.3/setup_common.py",
> line 7, in get_metadata_and_options
>     metadata = dict(config.items('metadata'))
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ConfigParser.py",
> line 544, in items
> ConfigParser.NoSectionError: No section: 'metadata'
>
> Someone please help.
>
> Thank you very much,
> Muthoni
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pyt...@py...
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
>
>

Re: [Pyobjc-dev] [Pythonmac-SIG] Py2app too complex?

[Christopher B. <Chr...@no...>]

Greg Ewing wrote:
> I've been thinking for a while about creating something
> simpler that doesn't attempt any automatic module discovery
> at all. You would be required to construct a project file
> that explicitly lists all the required modules and libraries,
> including standard library modules.

I've thought for a while that there is way too much re-invention of the 
wheel with the various stand-alone builders. I'd love to see more 
flexibility, and ideally code sharing, by breaking down the process into 
the various parts:

1) the API for specifying what you need built -- py2app and py2exe at 
least share much )but not all) of this, though they are slightly 
incompatible. AFAIK, the rest are all different

2) Figuring out what needs to be included. py2app and bbfreeze both use 
modulegraph, though bb-freeze apparently forked it.

3) Actually building the bundle -- by definition this will be different 
on different platforms, and there are multiple ways of doing it on one 
platform

Anyway, ideally, each of these steps could share a common API, and so 
each bundle builder could mix and match the parts as they saw fit.

Getting everyone to cooperate is a big social, rather then technical 
problem, but py2app at least could be designed to allow each of these 
pieces to be replaceable. (maybe it already is -- I haven't poked into 
the code enough to know)

So, aside from allowing more code sharing, this approach would make it 
easier to plug in different pieces, like Greg's proposed manual 
specification of modules.

As for that proposal -- I agree with other posters that that really 
would be onerous. However, a hybrid would be great -- run some sort of 
automated tool that outputs an easy-to-read-and-edit text file that 
could be edited, and have the bundle builder use that. Then you culd 
e3dit it, write it frm scratch, whatever you like.

If nothing else, it would really help speed to be able to re-build an 
app without having to go through the process of determining what to 
include each time. I often find myself modifying the source a bit, 
knowing for sure that I haven't changed the dependencies, and then 
having to wait for py2app (or py2exe) to do the full analysis again.

Another idea I have for determining what to include is to take the 
opposite tack of source-code analysis -- run-time analysis:

You would run your app (or better yet, a test suite), and the tool would 
do a run-time examination of what's imported (would that be as simple as 
looking in sys.modules?). That way you would capture the dynamic imports 
that the source-code analysis misses. You would miss the conditional 
imports, but if you have a good test suite, you'd catch those too. (and 
if you don't, you'd have identified a hole in your tests). And you would 
miss the conditional imports that you really don't want ( I never want 
Tk just because I'm using PIL, for instance)

If you really wanted a I-don't-care-how-big-it-is-I-just-want-it-to-work 
version, you could use a superset of runt-time and source-code analysis.


I do want to be clear that py2app has been the best bundle builder I've 
used, and I really appreciate Ronald's effort to bring it up to speed again.


-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Pyobjc-dev] Py2app too complex?

[Ronald O. <ron...@ma...>]

On 1 Aug, 2010, at 13:59, Ronald Oussoren wrote:
>> 
>> I'm not sure I agree that no dependency finding would be a good thing.
>> Importing a stdlib modules often imports tons of other ones you don't
>> know about and manually figuring these dependencies out can be really
>> tedious. However, I think that using modulegraph instead of the
>> built-in modulefinder is a mistake. For one thing, modulegraph doesn't
>> support relative imports, yet.
> 
> Adding is possible, and will be done. I'm working on that right now to be honest, and that code should be done by the end of the day (including unittests).

The version of modulegraph in the repository now supports absolute and relative imports (with unittests)

Ronald

Re: [Pyobjc-dev] Py2app too complex?

[Ronald O. <ron...@ma...>]

On 31 Jul, 2010, at 10:56, Virgil Dupras wrote:

> On Sat, Jul 31, 2010 at 10:26 AM, Ronald Oussoren
> <ron...@ma...> wrote:
>> 
>> On 31 Jul, 2010, at 3:09, Greg Ewing wrote:
>> 
>>> Virgil Dupras wrote:
>>>> Is it possible that py2app is a little too complex for what
>>>> it does?
>>> 
>>> I think a lot of the complexity of py2app and py2exe come
>>> from trying to automatically figure out what modules and
>>> libraries need to be included.
>> 
>> I object to calling py2app complex, the code base is fairly easy to understand.   Have you even looked at the code base?
>> 
>>> 
>>> I've been thinking for a while about creating something
>>> simpler that doesn't attempt any automatic module discovery
>>> at all. You would be required to construct a project file
>>> that explicitly lists all the required modules and libraries,
>>> including standard library modules.
>> 
>> That is not simpler, it just shifts the complexity to the user. It is better to shift the complexity away from the user, that way the user does not have to reinvent the weel.
>> 
>> Ronald
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> 
>> 
> 
> I'm not sure I agree that no dependency finding would be a good thing.
> Importing a stdlib modules often imports tons of other ones you don't
> know about and manually figuring these dependencies out can be really
> tedious. However, I think that using modulegraph instead of the
> built-in modulefinder is a mistake. For one thing, modulegraph doesn't
> support relative imports, yet.

Adding is possible, and will be done. I'm working on that right now to be honest, and that code should be done by the end of the day (including unittests).

I don't agree that using modulefinder would be better. For one, modulefinder will never support setuptools trickery (see the zope.interface discussion on pythonmac-sig), while that can and will be added to modulegraph.

> Yeah, we could work on it, but why
> bother when modulefinder already does it? It's just more maintenance.
> I know modulegraph is supposed to be better, but I would *gladly* list
> my non-stdlib dependencies manually rather than pray that py2app finds
> them correctly. The way I work with py2app now is that whenever a
> dependency isn't found by py2app, I put an explicit import of it in my
> "main py file" in a section documented for being py2app workaround
> imports. It works, but I'm sure there's a more elegant way...

You can add an includes section to your setup.py file (see the includes argument on the command-line).

What would be better is to research why py2app doesn't find modules you use, or at least try to create a small sample that demonstrates the problem   I cannot fix issues if you don't report them.
> 
> I think distutils is supposed to let you list dependencies manually in
> the setup() call, but when I tried it I found it extremely
> non-working, at all. So yes, a reliable way to manually list
> dependencies would be a great thing.

setuptools has install_requires/setup_requires, but py2app does not have support for that yet (although setup_requires should ensure that the eggs your require are installed before py2app gets run).

You can also list includes/excludes in the py2app options dictionary:

	setup(
		options=dict(py2app=dict(
			include=['mymodule'],	
                ))
        )

Ronald

Ronald

Re: [Pyobjc-dev] Py2app too complex?

[Virgil D. <hs...@ha...>]

On Sat, Jul 31, 2010 at 10:26 AM, Ronald Oussoren
<ron...@ma...> wrote:
>
> On 31 Jul, 2010, at 3:09, Greg Ewing wrote:
>
>> Virgil Dupras wrote:
>>> Is it possible that py2app is a little too complex for what
>>> it does?
>>
>> I think a lot of the complexity of py2app and py2exe come
>> from trying to automatically figure out what modules and
>> libraries need to be included.
>
> I object to calling py2app complex, the code base is fairly easy to understand.   Have you even looked at the code base?
>
>>
>> I've been thinking for a while about creating something
>> simpler that doesn't attempt any automatic module discovery
>> at all. You would be required to construct a project file
>> that explicitly lists all the required modules and libraries,
>> including standard library modules.
>
> That is not simpler, it just shifts the complexity to the user. It is better to shift the complexity away from the user, that way the user does not have to reinvent the weel.
>
> Ronald
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

I'm not sure I agree that no dependency finding would be a good thing.
Importing a stdlib modules often imports tons of other ones you don't
know about and manually figuring these dependencies out can be really
tedious. However, I think that using modulegraph instead of the
built-in modulefinder is a mistake. For one thing, modulegraph doesn't
support relative imports, yet. Yeah, we could work on it, but why
bother when modulefinder already does it? It's just more maintenance.
I know modulegraph is supposed to be better, but I would *gladly* list
my non-stdlib dependencies manually rather than pray that py2app finds
them correctly. The way I work with py2app now is that whenever a
dependency isn't found by py2app, I put an explicit import of it in my
"main py file" in a section documented for being py2app workaround
imports. It works, but I'm sure there's a more elegant way...

I think distutils is supposed to let you list dependencies manually in
the setup() call, but when I tried it I found it extremely
non-working, at all. So yes, a reliable way to manually list
dependencies would be a great thing.

Virgil Dupras

Re: [Pyobjc-dev] Py2app too complex?

[Ronald O. <ron...@ma...>]

On 31 Jul, 2010, at 3:09, Greg Ewing wrote:

> Virgil Dupras wrote:
>> Is it possible that py2app is a little too complex for what
>> it does?
> 
> I think a lot of the complexity of py2app and py2exe come
> from trying to automatically figure out what modules and
> libraries need to be included.

I object to calling py2app complex, the code base is fairly easy to understand.   Have you even looked at the code base?

> 
> I've been thinking for a while about creating something
> simpler that doesn't attempt any automatic module discovery
> at all. You would be required to construct a project file
> that explicitly lists all the required modules and libraries,
> including standard library modules.

That is not simpler, it just shifts the complexity to the user. It is better to shift the complexity away from the user, that way the user does not have to reinvent the weel.  

Ronald

[Pyobjc-dev] Py2app too complex?

[Greg E. <gre...@ca...>]

Virgil Dupras wrote:
> Is it possible that py2app is a little too complex for what
> it does?

I think a lot of the complexity of py2app and py2exe come
from trying to automatically figure out what modules and
libraries need to be included.

I've been thinking for a while about creating something
simpler that doesn't attempt any automatic module discovery
at all. You would be required to construct a project file
that explicitly lists all the required modules and libraries,
including standard library modules.

This may sound onerous, but I don't think it would be if
you did it as part of the process of developing the code.
There would be a testing mode which would run the application
in an isolated environment using the current project settings.
If you did all your development that way, you would immediately
discover when something was missing and needed to be added
to the project.

Furthermore, you would be assured that if it works during
testing, it will also work when bundled -- something that
currently requires a separate testing step when using py2app
or py2exe, because you can never trust them to find all the
dependencies correctly.

Does anyone else think such a tool would be useful?

-- 
Greg

[Pyobjc-dev] Installing Mysqldb Module on Python 2.5.1 on Mac OS X 10.5.8

[Muthoni M. <mut...@gm...>]

Hello everyone,
I am a new entrant to Python (but not new in programming).  I am trying to
install the mysqldb module on my Mac OS in vain.  I have tried all the
instructions in the README.

I keep getting the following error

setup_posix.py", line 32, in get_config
    metadata, options = get_metadata_and_options()
  File
"/Users/Muthoni/phd2010/Thesis/software/Python/MySQL-python-1.2.3/setup_common.py",
line 7, in get_metadata_and_options
    metadata = dict(config.items('metadata'))
  File
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ConfigParser.py",
line 544, in items
ConfigParser.NoSectionError: No section: 'metadata'

Someone please help.

Thank you very much,
Muthoni

Re: [Pyobjc-dev] ANN: py2app 0.5

[Ronald O. <ron...@ma...>]

On 30 Jul, 2010,at 11:42 AM, Virgil Dupras <hs...@ha...> wrote:


Thanks a bunch Ronald, your work is very very much appreciated I
tried to build my app on a whole spanking new stack (Python 2.7,
pyobjc 2.3 and py2app 0.5.2) and it worked (I use the plugin feature).
I had, however, to erase the prebuilt files and re-build them.
 
That's odd, the prebuilt binaries should just work.



This brings a question: I noticed that you added several new prebuilt
for each architecture combination. I ask: why using prebuilt at all?
 
Because that allows you to built python apps on systems without Xcode.


Why not simply have the setup build the thing on the user machine upon
install? This way the user gets binaries that exactly correspond to
the cflags he used when building python. Are there cases where a
py2app user would want any other cflags?

I only recently discovered the pythonmac-sig and I saw your call for
help. It's sad that nobody answered yet, but I can't say I'm
surprised. Like I told you at EuroPython, I'd like to help but I have
a very hard time understanding py2app's convoluted code base
(distutils is probably to blame for that, god I hate
distutils/setuptools). I guess it's the same thing for other users.
 

py2app isn't that hard to understand, it is a fairly basic distutils extension.  The code base could use some cleanup and documentation though, it should be possible to simplify the code base without losing features.

I'm also not surprised that almost nobody reacted to my call for help, that's just how opensource works.  That means that the projects where I work on move forward very slowly because there is only one developer that has little time.

Folks, please don't forget that I do almost all my python work in my private time and don't get paid for doing it.  This includes py2app, pyobjc and also the Mac port of Python itself.  I'd love to spend more time on these projects, but that's not going happen without some kind of financial support. I have a donations link on the pyobjc website, but I don't know why I bothered adding it.



I also had an interesting discussion with Alex Morega. He was asking
me why I used py2app at all. He gave me a link
(http://github.com/alex-morega/tinymail and
http://github.com/alex-morega/WhizbangPlugin ) to his Python/Cocoa
apps which don't use any packaging. It turns out the reason he can get
away without py2app or bundlebuilder is because he uses the system
Python and doesn't have other dependencies, but it still raises
questions: Is it possible that py2app is a little too complex for what
it does?
 
IMO py2app doesn't do enough yet.  In Alex' use-case py2app is overkill because the application cooperates, that's not the case for most other applications (let alone system components like System Preferences).  py2app is also needed when building application bundles.

Py2app needs to be somewhat complex to centralize the knowlegde needed for building applications, that way the users of py2app don't have to worry about the right directory structure, packaging the right files, etc, etc.    

Py2app should also learn how to package apps that use setuptools/pkg_resources features like entry points, that way even more applications can be supported without hacks.


I was thinking maybe it would be a good idea to go toward code
simplification in py2app and that a good way to start would be to get
rid of distutils.
 
I don't think that would buy us much, although I'll probably try to split py2app into a generic library and the distutils plugin. That's mostly because I want to have a "py2app_standalone" script that can be used in Xcode templates.

Ronald

Re: [Pyobjc-dev] ANN: py2app 0.5

[Virgil D. <hs...@ha...>]

On Tue, Jul 27, 2010 at 9:13 PM, Ronald Oussoren <ron...@ma...> wrote:
> Hi,
>
> I've just uploaded py2app 0.5 and new versions of altgraph, modulegraph and macholib. I hope this solves most issues with py2app.   "easy_install-X.Y -U py2app" should install the software for you (where X.Y is your favorite version of Python)
>
> There is one new feature in this release: experimental support for python 3.   This basicly means that I managed to build a single application as a standalone application bundle, without much testing.   Alias builds and plugin bundles almost certainly don't work (the first because alias builds use the Carbon module which isn't available in python 3, the latter because I had to rewrite the C code in the application bundles and probably have to do the same for plugin bundles).
>
> Ronald
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Thanks a bunch Ronald, your work is very very much appreciated. I
tried to build my app on a whole spanking new stack (Python 2.7,
pyobjc 2.3 and py2app 0.5.2) and it worked (I use the plugin feature).
I had, however, to erase the prebuilt files and re-build them.

This brings a question: I noticed that you added several new prebuilt
for each architecture combination. I ask: why using prebuilt at all?
Why not simply have the setup build the thing on the user machine upon
install? This way the user gets binaries that exactly correspond to
the cflags he used when building python. Are there cases where a
py2app user would want any other cflags?

I only recently discovered the pythonmac-sig and I saw your call for
help. It's sad that nobody answered yet, but I can't say I'm
surprised. Like I told you at EuroPython, I'd like to help but I have
a very hard time understanding py2app's convoluted code base
(distutils is probably to blame for that, god I hate
distutils/setuptools). I guess it's the same thing for other users.

I also had an interesting discussion with Alex Morega. He was asking
me why I used py2app at all. He gave me a link
(http://github.com/alex-morega/tinymail and
http://github.com/alex-morega/WhizbangPlugin ) to his Python/Cocoa
apps which don't use any packaging. It turns out the reason he can get
away without py2app or bundlebuilder is because he uses the system
Python and doesn't have other dependencies, but it still raises
questions: Is it possible that py2app is a little too complex for what
it does?

I was thinking maybe it would be a good idea to go toward code
simplification in py2app and that a good way to start would be to get
rid of distutils.

In any case, if nobody's on it, I'd gladly take care of the
documentation modernization.

Virgil Dupras

Re: [Pyobjc-dev] [Pythonmac-SIG] ANN: py2app 0.5

[Tom M. <to...@de...>]

Hey,

I'd just like to say thanks - it's incredibly great to have some movement
and leadership here (plus this'll make the installation process of py2app
way less annoying - I got used to installing macholib, altgraph,
modulegraph, and py2app separately in their dependency order)

Tom

On Tue, Jul 27, 2010 at 3:13 PM, Ronald Oussoren <ron...@ma...>wrote:

> Hi,
>
> I've just uploaded py2app 0.5 and new versions of altgraph, modulegraph and
> macholib. I hope this solves most issues with py2app.   "easy_install-X.Y -U
> py2app" should install the software for you (where X.Y is your favorite
> version of Python)
>
> There is one new feature in this release: experimental support for python
> 3.   This basicly means that I managed to build a single application as a
> standalone application bundle, without much testing.   Alias builds and
> plugin bundles almost certainly don't work (the first because alias builds
> use the Carbon module which isn't available in python 3, the latter because
> I had to rewrite the C code in the application bundles and probably have to
> do the same for plugin bundles).
>
> Ronald
> _______________________________________________
> Pythonmac-SIG maillist  -  Pyt...@py...
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
>
>

Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Brendan S. (eTRIX) <bre...@et...>]

 On 28/07/10 5:13 AM, pyo...@li... wrote:
> Message: 5
> Date: Wed, 21 Jul 2010 23:21:16 +0200
> From: "Diez B. Roggisch" <de...@we...>
> Subject: Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile
> To: Ronald Oussoren <ron...@ma...>
> Cc: pyo...@li...
> Message-ID: <589...@we...>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> On Jul 20, 2010, at 6:46 PM, Ronald Oussoren wrote:
>
>> > 
>> > On 20 Jul, 2010, at 0:18, Diez B. Roggisch wrote:
>> > 
>>> >> 
>>> >> On Jul 20, 2010, at 1:09 AM, Martin K?hl wrote:
>>> >> 
>>>> >>> This can happen when trying to build a 64-bit version of PyObjC.
>>>> >>> Try exporting MACOSX_DEPLOYMENT_TARGET=10.5 before you install it.
>>> >> 
>>> >> 
>>> >> Worked slightly better - but now this happens:
>>> >> 
>>> >> Downloading http://pypi.python.org/packages/source/p/pyobjc-core/pyobjc-core-2.2b1.tar.gz#md5=a4cacd7c11cacbe8de9bd2f8fd9e3b75
>>> >> Processing pyobjc-core-2.2b1.tar.gz
>>> >> Running pyobjc-core-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-F2mLbI/pyobjc-core-2.2b1/egg-dist-tmp-IJEYZT
>>> >> warning: no previously-included files matching '.DS_Store' found anywhere in distribution
>>> >> warning: no previously-included files matching '*.pbxuser' found anywhere in distribution
>>> >> warning: no previously-included files matching '*.so' found anywhere in distribution
>>> >> cc1: error: unrecognized command line option "-Wno-long-double"
>> > 
>> > That's odd, all Apple compilers should support -Wno-long-double. Which OSX version are you on, which version of Xcode and which compiler are you using?
> snow leopard, 10.6.3, latest xcode,comes with this GCC:
>
> deets$ gcc --version
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)

I had the same problem when I tried to build/install pycrypto on OS X 10.6.
It seems that gcc-4.2 doesn't support -Wno-long-double anymore (well not
the apple built gcc-4.2).  It is available in gcc-4.0 (and probably
earlier versions).

My 'work around' was to do the following.
    $ export CC=gcc-4.0
    $ ### do my build (e.g. python setup.py install)
    $ unset CC

Check which versions you have installed with:
    $ ls -l /usr/bin/gcc*

I also had to install the 10.4u SDK from the Apple install DVDs, but I
think that was some pycrypto constraint.

Cheers, Brendan.

[Pyobjc-dev] ANN: py2app 0.5

[Ronald O. <ron...@ma...>]

Hi,

I've just uploaded py2app 0.5 and new versions of altgraph, modulegraph and macholib. I hope this solves most issues with py2app.   "easy_install-X.Y -U py2app" should install the software for you (where X.Y is your favorite version of Python)

There is one new feature in this release: experimental support for python 3.   This basicly means that I managed to build a single application as a standalone application bundle, without much testing.   Alias builds and plugin bundles almost certainly don't work (the first because alias builds use the Carbon module which isn't available in python 3, the latter because I had to rewrite the C code in the application bundles and probably have to do the same for plugin bundles).

Ronald

Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Diez B. R. <de...@we...>]

On Jul 20, 2010, at 6:46 PM, Ronald Oussoren wrote:

> 
> On 20 Jul, 2010, at 0:18, Diez B. Roggisch wrote:
> 
>> 
>> On Jul 20, 2010, at 1:09 AM, Martin Kühl wrote:
>> 
>>> This can happen when trying to build a 64-bit version of PyObjC.
>>> Try exporting MACOSX_DEPLOYMENT_TARGET=10.5 before you install it.
>> 
>> 
>> Worked slightly better - but now this happens:
>> 
>> Downloading http://pypi.python.org/packages/source/p/pyobjc-core/pyobjc-core-2.2b1.tar.gz#md5=a4cacd7c11cacbe8de9bd2f8fd9e3b75
>> Processing pyobjc-core-2.2b1.tar.gz
>> Running pyobjc-core-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-F2mLbI/pyobjc-core-2.2b1/egg-dist-tmp-IJEYZT
>> warning: no previously-included files matching '.DS_Store' found anywhere in distribution
>> warning: no previously-included files matching '*.pbxuser' found anywhere in distribution
>> warning: no previously-included files matching '*.so' found anywhere in distribution
>> cc1: error: unrecognized command line option "-Wno-long-double"
> 
> That's odd, all Apple compilers should support -Wno-long-double. Which OSX version are you on, which version of Xcode and which compiler are you using?

snow leopard, 10.6.3, latest xcode,comes with this GCC:

deets$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)

Diez

Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Ronald O. <ron...@ma...>]

On 20 Jul, 2010, at 0:18, Diez B. Roggisch wrote:

> 
> On Jul 20, 2010, at 1:09 AM, Martin Kühl wrote:
> 
>> This can happen when trying to build a 64-bit version of PyObjC.
>> Try exporting MACOSX_DEPLOYMENT_TARGET=10.5 before you install it.
> 
> 
> Worked slightly better - but now this happens:
> 
> Downloading http://pypi.python.org/packages/source/p/pyobjc-core/pyobjc-core-2.2b1.tar.gz#md5=a4cacd7c11cacbe8de9bd2f8fd9e3b75
> Processing pyobjc-core-2.2b1.tar.gz
> Running pyobjc-core-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-F2mLbI/pyobjc-core-2.2b1/egg-dist-tmp-IJEYZT
> warning: no previously-included files matching '.DS_Store' found anywhere in distribution
> warning: no previously-included files matching '*.pbxuser' found anywhere in distribution
> warning: no previously-included files matching '*.so' found anywhere in distribution
> cc1: error: unrecognized command line option "-Wno-long-double"

That's odd, all Apple compilers should support -Wno-long-double. Which OSX version are you on, which version of Xcode and which compiler are you using?

Ronald

Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Ronald O. <ron...@ma...>]

On 20 Jul, 2010, at 0:01, Diez B. Roggisch wrote:

> I just installed a vanilla python2.6 on my brand new mac book pro (os x 10.6.3), and it complained like this:
> 
> ....
> Running pyobjc-framework-SystemConfiguration-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-CeFX1Q/pyobjc-framework-SystemConfiguration-2.2b1/egg-dist-tmp-ZeeOUm
> <built-in>:0: warning: Mac OS X version 10.5 or later is needed for use of the new objc abi
> Modules/_manual.m: In function 'mod_SCDynamicStoreCreate':
> Modules/_manual.m:228: error: Mac OS X version 10.5 or later is needed for zerocost-exceptions
> error: Setup script exited with error: command 'gcc' failed with exit status 1
> 
> Hm. I've got 10.5 or later, don't I? Any suggestions more than welcome.

I just noticed this as well, I'll fix this once I have time to debug.   The problem is that the python.org installers are compiled with a OSX 10.3 as the deployment target and pyobjc tries to use an ObjC feature that isn't available there.

Ronald

> 
> Diez
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Diez B. R. <de...@we...>]

On Jul 20, 2010, at 1:09 AM, Martin Kühl wrote:

> This can happen when trying to build a 64-bit version of PyObjC.
> Try exporting MACOSX_DEPLOYMENT_TARGET=10.5 before you install it.


Worked slightly better - but now this happens:

Downloading http://pypi.python.org/packages/source/p/pyobjc-core/pyobjc-core-2.2b1.tar.gz#md5=a4cacd7c11cacbe8de9bd2f8fd9e3b75
Processing pyobjc-core-2.2b1.tar.gz
Running pyobjc-core-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-F2mLbI/pyobjc-core-2.2b1/egg-dist-tmp-IJEYZT
warning: no previously-included files matching '.DS_Store' found anywhere in distribution
warning: no previously-included files matching '*.pbxuser' found anywhere in distribution
warning: no previously-included files matching '*.so' found anywhere in distribution
cc1: error: unrecognized command line option "-Wno-long-double"

Diez

Re: [Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Martin K. <mar...@gm...>]

This can happen when trying to build a 64-bit version of PyObjC.
Try exporting MACOSX_DEPLOYMENT_TARGET=10.5 before you install it.

On Tue, Jul 20, 2010 at 01:01, Diez B. Roggisch <de...@we...> wrote:
> I just installed a vanilla python2.6 on my brand new mac book pro (os x 10.6.3), and it complained like this:
>
> ....
> Running pyobjc-framework-SystemConfiguration-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-CeFX1Q/pyobjc-framework-SystemConfiguration-2.2b1/egg-dist-tmp-ZeeOUm
> <built-in>:0: warning: Mac OS X version 10.5 or later is needed for use of the new objc abi
> Modules/_manual.m: In function 'mod_SCDynamicStoreCreate':
> Modules/_manual.m:228: error: Mac OS X version 10.5 or later is needed for zerocost-exceptions
> error: Setup script exited with error: command 'gcc' failed with exit status 1
>
> Hm. I've got 10.5 or later, don't I? Any suggestions more than welcome.
>
> Diez
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] pyobjc with vanilla py2.6 doesn't compile

[Diez B. R. <de...@we...>]

I just installed a vanilla python2.6 on my brand new mac book pro (os x 10.6.3), and it complained like this:

....
Running pyobjc-framework-SystemConfiguration-2.2b1/setup.py -q bdist_egg --dist-dir /var/folders/P4/P4526I2LGtKkYHJFKsUo2++++TI/-Tmp-/easy_install-CeFX1Q/pyobjc-framework-SystemConfiguration-2.2b1/egg-dist-tmp-ZeeOUm
<built-in>:0: warning: Mac OS X version 10.5 or later is needed for use of the new objc abi
Modules/_manual.m: In function 'mod_SCDynamicStoreCreate':
Modules/_manual.m:228: error: Mac OS X version 10.5 or later is needed for zerocost-exceptions
error: Setup script exited with error: command 'gcc' failed with exit status 1

Hm. I've got 10.5 or later, don't I? Any suggestions more than welcome.

Diez

Re: [Pyobjc-dev] import objc -> Symbol not found: _PyType_Modified

[anurag u. <anu...@ya...>]

Thanks a lot!

I will see i I can move to python 2.6, or will try to build older version of 
pyobjc.

I am new to Mac and confused by universal binary issue, I want to build a 
standalone version of my app which will run on intel/ppc etc

So I don't wanted to use System Python as per various threads 
e.g. http://aralbalkan.com/1675

py2app won't include system python with distributable.

I did not remove  /System/Library/Frameworks/Python.framework but when pyobjc 
build failed I thought things may be getting mixed so 
renamed  /System/Library/Frameworks/Python.framework temporarily as last resort, 
though my system worked perfectly after that :)

rgds
Anurag
 


----- Original Message ----
From: Ronald Oussoren <ron...@ma...>
To: anurag uniyal <anu...@ya...>
Cc: pyo...@li...
Sent: Fri, 16 July, 2010 8:01:20 PM
Subject: Re: [Pyobjc-dev] import objc -> Symbol not found: _PyType_Modified


On 16 Jul, 2010, at 8:36, anurag uniyal wrote:

> My system is Mac OS X 10.5.8 and I have installed python from 
> http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg because I do not 
>
> want to use System python (python which already comes installed with Mac OS X)

Why 2.5.4? That is an ancient release.
> 


> and have totally removed system python.

You have broken your system in a way that needs a reinstall to fix. Just like 
you cannot remove /usr/bin and expect the system to continue you cannot remove 
/System/Library/Frameworks/Python.framework.  


Furthermore there is no need whatsoever to remove the system install to use 
another version.

> 
> Now when I try to install pyobjc it installs, but on import gives error

I don't know why this happens and won't try to debug issues with ancient 
versions of Python. The next release of pyobjc, which will be released any day 
now, won't support python 2.5 at all because I use syntax that was introduced in 
2.6.  The release beyond that will have hard dependencies on features that 
cannot be implemented with CPython 2.5 at all.

Ronald

Re: [Pyobjc-dev] import objc -> Symbol not found: _PyType_Modified

[Ronald O. <ron...@ma...>]

On 16 Jul, 2010, at 8:36, anurag uniyal wrote:

> My system is Mac OS X 10.5.8 and I have installed python from 
> http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg because I do not 
> want to use System python (python which already comes installed with Mac OS X)

Why 2.5.4? That is an ancient release.
> 


> and have totally removed system python.

You have broken your system in a way that needs a reinstall to fix. Just like you cannot remove /usr/bin and expect the system to continue you cannot remove /System/Library/Frameworks/Python.framework.  

Furthermore there is no need whatsoever to remove the system install to use another version.

> 
> Now when I try to install pyobjc it installs, but on import gives error

I don't know why this happens and won't try to debug issues with ancient versions of Python. The next release of pyobjc, which will be released any day now, won't support python 2.5 at all because I use syntax that was introduced in 2.6.  The release beyond that will have hard dependencies on features that cannot be implemented with CPython 2.5 at all.

Ronald

Re: [Pyobjc-dev] Unable to build pyobjc

[Aahz <aa...@py...>]

On Fri, Jul 16, 2010, anurag uniyal wrote:
>
> I am not able to use pyobjc installed via easy_install(explained in earlier 
> email) so now I am trying to build pyobjc from trunk.
> My system is Mac OS X 10.5.8, Xcode 3.1.3 developer tools and I have installed 
> python from 
> http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg 

Although I'm using 2.6, the info I've previously posted about trying to
use PyObjC 2.2 should still be useful; check the archives.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..."  --Siobhan

Re: [Pyobjc-dev] Unable to build pyobjc

[Diez B. R. <de...@we...>]

Am 16.07.2010 um 09:33 schrieb anurag uniyal:

> Thanks for the reply.
>
> Though i am not sure what it means, do you mean using old checkout  
> of pyobjc may
> work?

Please answer to the list as well.

Yes, I guess either using an older version of pyobjc or a newer  
version of python might help. This is just a guess though.

Diez

[Pyobjc-dev] Unable to build pyobjc

[anurag u. <anu...@ya...>]

Hi,

I am not able to use pyobjc installed via easy_install(explained in earlier 
email) so now I am trying to build pyobjc from trunk.
My system is Mac OS X 10.5.8, Xcode 3.1.3 developer tools and I have installed 
python from 
http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg 


when i go to pyobjc-core folder and do 
$ python setup.py test

I get errors:

gcc -arch ppc -arch i386 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp 
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c 
Modules/objc/formal-protocol.m -o 
build/temp.macosx-10.3-i386-2.5/Modules/objc/formal-protocol.o 
-DPyObjC_STRICT_DEBUGGING -DMACOSX -DPyObjC_BUILD_RELEASE=1005 -no-cpp-precomp 
-DMACOSX -g -fexceptions -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wformat=2 -W -Wpointer-arith -Wmissing-declarations -Wnested-externs 
-Wno-long-long -Wno-import -isysroot / -Ibuild/codegen/ -Ilibffi-src/include 
-Ilibffi-src/powerpc 
-I/Users/agyey/Downloads/pyobjc_trunk/pyobjc/pyobjc-core/build/libxml/include/libxml2

Modules/objc/formal-protocol.m: In function 'proto_new':
Modules/objc/formal-protocol.m:221: warning: initialization discards qualifiers 
from pointer target type
Modules/objc/formal-protocol.m: At top level:
Modules/objc/formal-protocol.m:499: warning: implicit declaration of function 
'PyVarObject_HEAD_INIT'
Modules/objc/formal-protocol.m:500: error: initializer element is not constant
Modules/objc/formal-protocol.m:500: error: (near initialization for 
'PyObjCFormalProtocol_Type.ob_refcnt')
Modules/objc/formal-protocol.m:500: error: syntax error before string constant
Modules/objc/formal-protocol.m:501: warning: initialization makes pointer from 
integer without a cast
Modules/objc/formal-protocol.m:504: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:509: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:516: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:519: warning: initialization makes pointer from 
integer without a cast
Modules/objc/formal-protocol.m:520: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:527: warning: initialization makes integer from 
pointer without a cast
Modules/objc/formal-protocol.m:529: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:537: warning: initialization makes integer from 
pointer without a cast
Modules/objc/formal-protocol.m:550: warning: missing initializer
Modules/objc/formal-protocol.m:550: warning: (near initialization for 
'PyObjCFormalProtocol_Type.tp_subclasses')
Modules/objc/formal-protocol.m: In function 'do_verify':
Modules/objc/formal-protocol.m:639: warning: passing argument 2 of 
'signaturesEqual' discards qualifiers from pointer target type
Modules/objc/formal-protocol.m: In function 'proto_new':
Modules/objc/formal-protocol.m:221: warning: initialization discards qualifiers 
from pointer target type
Modules/objc/formal-protocol.m: At top level:
Modules/objc/formal-protocol.m:499: warning: implicit declaration of function 
'PyVarObject_HEAD_INIT'
Modules/objc/formal-protocol.m:500: error: initializer element is not constant
Modules/objc/formal-protocol.m:500: error: (near initialization for 
'PyObjCFormalProtocol_Type.ob_refcnt')
Modules/objc/formal-protocol.m:500: error: syntax error before string constant
Modules/objc/formal-protocol.m:501: warning: initialization makes pointer from 
integer without a cast
Modules/objc/formal-protocol.m:504: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:509: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:516: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:519: warning: initialization makes pointer from 
integer without a cast
Modules/objc/formal-protocol.m:520: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:527: warning: initialization makes integer from 
pointer without a cast
Modules/objc/formal-protocol.m:529: warning: initialization from incompatible 
pointer type
Modules/objc/formal-protocol.m:537: warning: initialization makes integer from 
pointer without a cast
Modules/objc/formal-protocol.m:550: warning: missing initializer
Modules/objc/formal-protocol.m:550: warning: (near initialization for 
'PyObjCFormalProtocol_Type.tp_subclasses')
Modules/objc/formal-protocol.m: In function 'do_verify':
Modules/objc/formal-protocol.m:639: warning: passing argument 2 of 
'signaturesEqual' discards qualifiers from pointer target type
lipo: can't figure out the architecture type of: /var/tmp//ccVTuAUA.out
error: command 'gcc' failed with exit status 1

What could be the reason ?

Thanks for the help.

-Anurag

[Pyobjc-dev] import objc -> Symbol not found: _PyType_Modified

[anurag u. <anu...@ya...>]

My system is Mac OS X 10.5.8 and I have installed python from 
http://www.python.org/ftp/python/2.5.4/python-2.5.4-macosx.dmg because I do not 
want to use System python (python which already comes installed with Mac OS X) 
and have totally removed system python.

Now when I try to install pyobjc it installs, but on import gives error

    Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27) 
    [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import objc
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/pyobjc_core-2.2-py2.5-macosx-10.3-i386.egg/objc/__init__.py",
 line 22, in <module>
        _update()
      File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/pyobjc_core-2.2-py2.5-macosx-10.3-i386.egg/objc/__init__.py",
 line 19, in _update
        import _objc
    ImportError: 
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/pyobjc_core-2.2-py2.5-macosx-10.3-i386.egg/objc/_objc.so,
 2): 
    Symbol not found: _PyType_Modified
      Referenced from: 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/pyobjc_core-2.2-py2.5-macosx-10.3-i386.egg/objc/_objc.so

      Expected in: dynamic lookup

If it is of help, here are the warnings while doing "easy_install pyobjc"

    Running pyobjc-core-2.2/setup.py -q bdist_egg --dist-dir 
/var/folders/tW/tWnuazCRFjexteMIweC5H++++TI/-Tmp-/easy_install-jttwg4/pyobjc-core-2.2/egg-dist-tmp-vuhvjT

    warning: no directories found matching 'Scripts'
    warning: no directories found matching 'setup-lib'
    warning: no directories found matching 'source-deps'
    warning: no previously-included files matching '.DS_Store' found anywhere in 
distribution
    warning: no previously-included files matching '*.pyc' found anywhere in 
distribution
    warning: no previously-included files matching '*.so' found anywhere in 
distribution
    libffi-src/powerpc/ppc-ffi_darwin.c:95: warning: no previous prototype for 
'ffi_prep_args'
    libffi-src/powerpc/ppc-ffi_darwin.c:819: warning: no previous prototype for 
'ffi_closure_helper_DARWIN'
    libffi-src/powerpc/ppc-ffi_darwin.c: In function 
'ffi_closure_helper_DARWIN':
    libffi-src/powerpc/ppc-ffi_darwin.c:854: warning: comparison between signed 
and unsigned
    libffi-src/powerpc/ppc-ffi_darwin.c:910: warning: pointer of type 'void *' 
used in arithmetic
    libffi-src/powerpc/ppc-ffi_darwin.c:910: warning: pointer of type 'void *' 
used in arithmetic
    libffi-src/x86/x86-ffi_darwin.c:39: warning: no previous prototype for 
'ffi_prep_args'
    libffi-src/x86/x86-ffi_darwin.c:178: warning: function declaration isn't a 
prototype
    libffi-src/x86/x86-ffi_darwin.c:186: warning: function declaration isn't a 
prototype
    Modules/objc/objc-class.m: In function 'PyObjCClass_New':
    Modules/objc/objc-class.m:1416: warning: implicit declaration of function 
'PyType_Modified'
    Modules/objc/objc-class.m:1416: warning: nested extern declaration of 
'PyType_Modified'
    Modules/objc/objc-class.m: In function 'PyObjCClass_New':
    Modules/objc/objc-class.m:1416: warning: implicit declaration of function 
'PyType_Modified'
    Modules/objc/objc-class.m:1416: warning: nested extern declaration of 
'PyType_Modified
    Modules/objc/OC_PythonObject.m: In function '-[OC_PythonObject 
replacementObjectForKeyedArchiver:]':
    Modules/objc/OC_PythonObject.m:1370: warning: conflicting types for 
'-(NSObject *)replacementObjectForKeyedArchiver:(NSKeyedArchiver *)archiver'
    Modules/objc/OC_PythonObject.h:102: warning: previous declaration of 
'-(NSObject *)replacementObjectForKeyedArchiver:(NSObject *)archiver'
    Modules/objc/OC_PythonObject.m: In function '-[OC_PythonObject 
replacementObjectForCoder:]':
    Modules/objc/OC_PythonObject.m:1376: warning: conflicting types for 
'-(NSObject *)replacementObjectForCoder:(NSCoder *)archiver'
    Modules/objc/OC_PythonObject.h:103: warning: previous declaration of 
'-(NSObject *)replacementObjectForCoder:(NSObject *)archiver'
    Modules/objc/OC_PythonObject.m: In function '-[OC_PythonObject 
replacementObjectForPortCoder:]':
    Modules/objc/OC_PythonObject.m:1382: warning: conflicting types for 
'-(NSObject *)replacementObjectForPortCoder:(NSPortCoder *)archiver'
    Modules/objc/OC_PythonObject.h:104: warning: previous declaration of 
'-(NSObject *)replacementObjectForPortCoder:(NSObject *)archiver'
    Modules/objc/OC_PythonObject.m: In function '-[OC_PythonObject 
replacementObjectForKeyedArchiver:]':
    Modules/objc/OC_PythonObject.m:1370: warning: conflicting types for 
'-(NSObject *)replacementObjectForKeyedArchiver:(NSKeyedArchiver *)archiver'
    Modules/objc/OC_PythonObject.h:102: warning: previous declaration of 
'-(NSObject *)replacementObjectForKeyedArchiver:(NSObject *)archiver'
    Modules/objc/OC_PythonObject.m: In function '-[OC_PythonObject 
replacementObjectForCoder:]':
    Modules/objc/OC_PythonObject.m:1376: warning: conflicting types for 
'-(NSObject *)replacementObjectForCoder:(NSCoder *)archiver'
    Modules/objc/OC_PythonObject.h:103: warning: previous declaration of 
'-(NSObject *)replacementObjectForCoder:(NSObject *)archiver'
    Modules/objc/OC_PythonObject.m: In function '-[OC_PythonObject 
replacementObjectForPortCoder:]':
    Modules/objc/OC_PythonObject.m:1382: warning: conflicting types for 
'-(NSObject *)replacementObjectForPortCoder:(NSPortCoder *)archiver'
    Modules/objc/OC_PythonObject.h:104: warning: previous declaration of 
'-(NSObject *)replacementObjectForPortCoder:(NSObject *)archiver'
    Modules/objc/test/protocol.m:19: warning: incomplete implementation of class 
'OC_TestProtocolClass'
    Modules/objc/test/protocol.m:19: warning: method definition for '-method2:' 
not found
    Modules/objc/test/protocol.m:19: warning: method definition for '-method1' 
not found
    Modules/objc/test/protocol.m:19: warning: class 'OC_TestProtocolClass' does 
not fully implement the 'OC_TestProtocol' protocol
    Modules/objc/test/protocol.m:19: warning: incomplete implementation of class 
'OC_TestProtocolClass'
    Modules/objc/test/protocol.m:19: warning: method definition for '-method2:' 
not found
    Modules/objc/test/protocol.m:19: warning: method definition for '-method1' 
not found
    Modules/objc/test/protocol.m:19: warning: class 'OC_TestProtocolClass' does 
not fully implement the 'OC_TestProtocol' protocol
    Modules/objc/test/testclassandinst.m: In function 
'+[PyObjC_TestUnallocatable 
allocWithZone:]':Modules/objc/test/testclassandinst.m: In function 
'+[PyObjC_TestUnallocatable allocWithZone:]':
    Modules/objc/test/testclassandinst.m:22: warning: unused parameter 'zone'
    Modules/objc/test/testclassandinst.m:22: warning: unused parameter 'zone'

rgds
Anurag