pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Python/PyObjC on iOS

[James R E. <jam...@lr...>]

Le 9 sept. 2010 à 17:08, Ronald Oussoren a écrit :

> Now that Apple seems to allow writing apps in python I'm no longer opposed to including patches to enable PyObjC on iOS devices and would be willing to review and apply such patches.

Excellent news.  Let's hope that our interpretation of the announced developer agreement changes is accurate.

> Porting libffi is non-trivial if you are not familiar with low-level C code and assembly.  If there is already a port for a jailbroken environment is should be possible to get that to work in a "jailed" environment as well.

I tried rebuilding it myself, including the jailbreak patches, but for whatever reason, the version I used caused everything it touched to barf.  But I haven't looked at it in some time.  As you suggested, libffi pokes into the deep dark depths, which for me remain a mystery, so I'm not sure I really know how to go about debugging it.  Part of it may stem from our creating a fake cross-compilation environment by hand.  Yuck.

> BTW. How good/bad is the performance of Python code on iOS devices?  Performance and battery use are the primary reasons I'd be hesitant to use Python code on iOS devices for anything but prototypes.

Given the problems we faced with libffi, we were only able to get the core python libraries to load, so we weren't able to stress test it.  And without libffi, we wouldn't be able to get PyObjC running, so we back-burnered the project.  As such, I really can't comment on observed performance, but I would likewise be hesitant to use Python or PyObjC for anything but prototypes.

Cheers,
James

--
James R. Eagan
LRI — Bâtiment 490
Université de Paris-Sud XI          email: Jam...@lr...
91405 Orsay Cedex — France          web: http://www.lri.fr/~eaganj

Re: [Pyobjc-dev] Python/PyObjC on iOS

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

On 09 Sep, 2010,at 04:56 PM, James R Eagan <jam...@lr...> wrote:

You may have heard that Apple will be easing their restrictions on programming languages permitted on iOS. According to their press release[1], which is short on details:

> ... we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code.
 
Interesting...



This seems to open the possibility that we'll be able to use Python and PyObjC to develop iOS apps, at least as far as policy requirements go.
 
I've quickly browsed to the press release you link to and that seems to indicate that Apple will allow this.



Are there any projects in motion to get Python running on non-jailbroken iOS devices? I know Ronald has previously said he has no desire to work on iOS support for PyObjC or to include such changes to the SVN (now hg) because of the policy problems. Since Ronald is already overworked, I assume the first part of this won't change.
 
I'm not working on this and probably won't for the foreseeable future (basicly because I'm overloaded as it is).  Now that Apple seems to allow writing apps in python I'm no longer opposed to including patches to enable PyObjC on iOS devices and would be willing to review and apply such patches.



I've actually worked a bit on building a running Python interpreter on iOS suitable for use with ad-hoc distribution. My requirements are to be able to run a Python-based application in an iOS device without jailbreaking. This is possible, at least for the core of Python, as long as no dylibs are needed. Unfortunately, that means that C modules that are normally dynamically loaded on import must be statically built into the interpreter. For many libraries, that's easy enough, but most of the code I've seen to actually build relies on "magic" jailbroken ports of things like libffi that I have not been able to reliably build for non-jailbroken environments.
 
Porting libffi is non-trivial if you are not familiar with low-level C code and assembly.  If there is already a port for a jailbroken environment is should be possible to get that to work in a "jailed" environment as well.

BTW. How good/bad is the performance of Python code on iOS devices?  Performance and battery use are the primary reasons I'd be hesitant to use Python code on iOS devices for anything but prototypes.



I'm happy to continue working on this project, but I'd rather not re-invent the wheel or duplicate efforts if others are already working in parallel.

James

[1]: http://www.apple.com/pr/library/2010/09/09statement.html

--
James R. Eagan
LRI — Bâtiment 490
Université de Paris-Sud XI email: Jam...@lr...
91405 Orsay Cedex — France web: http://www.lri.fr/~eaganj

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sfnet/sfu/intel-thread-sfd
_______________________________________________
Pyobjc-dev mailing list
Pyo...@li...
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Python/PyObjC on iOS

[James R E. <jam...@lr...>]

You may have heard that Apple will be easing their restrictions on programming languages permitted on iOS.  According to their press release[1], which is short on details:

> ... we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code.

This seems to open the possibility that we'll be able to use Python and PyObjC to develop iOS apps, at least as far as policy requirements go.

Are there any projects in motion to get Python running on non-jailbroken iOS devices?  I know Ronald has previously said he has no desire to work on iOS support for PyObjC or to include such changes to the SVN (now hg) because of the policy problems.  Since Ronald is already overworked, I assume the first part of this won't change.

I've actually worked a bit on building a running Python interpreter on iOS suitable for use with ad-hoc distribution.  My requirements are to be able to run a Python-based application in an iOS device without jailbreaking.  This is possible, at least for the core of Python, as long as no dylibs are needed.  Unfortunately, that means that C modules that are normally dynamically loaded on import must be statically built into the interpreter.  For many libraries, that's easy enough, but most of the code I've seen to actually build relies on "magic" jailbroken ports of things like libffi that I have not been able to reliably build for non-jailbroken environments.

I'm happy to continue working on this project, but I'd rather not re-invent the wheel or duplicate efforts if others are already working in parallel.

James

[1]: http://www.apple.com/pr/library/2010/09/09statement.html

--
James R. Eagan
LRI — Bâtiment 490
Université de Paris-Sud XI          email: Jam...@lr...
91405 Orsay Cedex — France          web: http://www.lri.fr/~eaganj

Re: [Pyobjc-dev] Python 3 + pyobjc_unicode + strptime = crash

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

On 8 Sep, 2010, at 14:39, Virgil Dupras wrote:

> On Wed, Sep 8, 2010 at 2:19 PM, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> On 8 Sep, 2010, at 11:38, Virgil Dupras wrote:
>> 
>>> Hi,
>>> 
>>> (Sorry for not submitting it to the tracker, I don't remember my old
>>> SF login, I dislike SF and I want to avoid dealing with it.)
>> 
>>> 
>>> I uncovered a bug today. Under Python 3, when using a pyobjc_unicode
>>> with strptime, I get a this crash:
>>> 
>>> Traceback (most recent call last):
>>>  File "pyobjc_strptime_bug.py", line 6, in <module>
>>>    print(datetime.strptime(s, '%Y-%m-%d'))
>>>  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_strptime.py",
>>> line 335, in _strptime
>>>    data_string[found.end():])
>>> ValueError: unconverted data remains: o
>>> 
>>> I created a script that reproduces the bug:
>>> 
>>> from Foundation import NSString
>>> s = NSString.alloc().initWithString_('2010-09-08')
>>> print(type(s))
>>> # Very interesting, the bug only shows up if datetime is imported here
>>> instead of at the top
>>> from datetime import datetime
>>> print(datetime.strptime(s, '%Y-%m-%d'))
>> 
>> This works for me, with python 3.1 and 3.2. Both of them 32-bit builds.   IIRC both python versions don't run the tip of the tree, but that shouldn't matter.
>> 
>> What version of Python and PyObjC do you use? Which architecture are you using (32-bit, intel, 3-way, ...)?
>> 
>> The most likely reason for the odd behaviour is that the constructor for pyobjc_unicode fails to initalize one of the fields in the unicode structs, or at least not exactly the same as the initializer for the real unicode type.
>> 
>> Ronald.
>> 
> 
> I use PyObjC's trunk at r2558 and Python 3.1.2, build in 32bit and
> 64bit intel arches (when I run it, it runs in 64bit). I fiddled around
> to figure out how to run python under 32bit mode, to no avail. The
> "arch" command doesn't seem to work for me...

Could you test r2592 of pyobjc-core (the current HEAD).   I could reproduce the issue with a 64-bit of python 3.2 and r2592 fixes the problem by ensuring that the internal buffer of pyobjc_unicode is NUL terminated. 

Ronald

Re: [Pyobjc-dev] Python 3 + pyobjc_unicode + strptime = crash

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

On 8 Sep, 2010, at 14:39, Virgil Dupras wrote:

> On Wed, Sep 8, 2010 at 2:19 PM, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> On 8 Sep, 2010, at 11:38, Virgil Dupras wrote:
>> 
>>> Hi,
>>> 
>>> (Sorry for not submitting it to the tracker, I don't remember my old
>>> SF login, I dislike SF and I want to avoid dealing with it.)
>> 
>>> 
>>> I uncovered a bug today. Under Python 3, when using a pyobjc_unicode
>>> with strptime, I get a this crash:
>>> 
>>> Traceback (most recent call last):
>>>  File "pyobjc_strptime_bug.py", line 6, in <module>
>>>    print(datetime.strptime(s, '%Y-%m-%d'))
>>>  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_strptime.py",
>>> line 335, in _strptime
>>>    data_string[found.end():])
>>> ValueError: unconverted data remains: o
>>> 
>>> I created a script that reproduces the bug:
>>> 
>>> from Foundation import NSString
>>> s = NSString.alloc().initWithString_('2010-09-08')
>>> print(type(s))
>>> # Very interesting, the bug only shows up if datetime is imported here
>>> instead of at the top
>>> from datetime import datetime
>>> print(datetime.strptime(s, '%Y-%m-%d'))
>> 
>> This works for me, with python 3.1 and 3.2. Both of them 32-bit builds.   IIRC both python versions don't run the tip of the tree, but that shouldn't matter.
>> 
>> What version of Python and PyObjC do you use? Which architecture are you using (32-bit, intel, 3-way, ...)?
>> 
>> The most likely reason for the odd behaviour is that the constructor for pyobjc_unicode fails to initalize one of the fields in the unicode structs, or at least not exactly the same as the initializer for the real unicode type.
>> 
>> Ronald.
>> 
> 
> I use PyObjC's trunk at r2558 and Python 3.1.2, build in 32bit and
> 64bit intel arches (when I run it, it runs in 64bit). I fiddled around
> to figure out how to run python under 32bit mode, to no avail. The
> "arch" command doesn't seem to work for me...

You have to use "arch /Library/Framework/Python.framework/Versions/3.1/Resources/Python.app/Contents/MacOS/Python" (I'm typing the path from memory and may therefore by mistaken about the exact path, but the idea should be clear).

In 3.2 (and 2.7) the arch command does work (on Leopard or later, Tiger doesn't expose the functionality we need)

Arch doesn't work the python command on your shell's search path because that does nothing but execv the real interpreter (the one I buried deep inside the framework). That is needed to trick Apple's framework into believing that the interpreter is a real application and can have access to the window server.   

The wrapper executable in 3.2 and 2.7 uses posix_spawn instead of execv, which gives more control over how the real executable is started and that makes it possible to ensure that the real executable is started using the same architecture as was used to execute the wrapper. 

Ronald

Re: [Pyobjc-dev] Python 3 + pyobjc_unicode + strptime = crash

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

On Wed, Sep 8, 2010 at 2:19 PM, Ronald Oussoren <ron...@ma...> wrote:
>
> On 8 Sep, 2010, at 11:38, Virgil Dupras wrote:
>
>> Hi,
>>
>> (Sorry for not submitting it to the tracker, I don't remember my old
>> SF login, I dislike SF and I want to avoid dealing with it.)
>
>>
>> I uncovered a bug today. Under Python 3, when using a pyobjc_unicode
>> with strptime, I get a this crash:
>>
>> Traceback (most recent call last):
>>  File "pyobjc_strptime_bug.py", line 6, in <module>
>>    print(datetime.strptime(s, '%Y-%m-%d'))
>>  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_strptime.py",
>> line 335, in _strptime
>>    data_string[found.end():])
>> ValueError: unconverted data remains: o
>>
>> I created a script that reproduces the bug:
>>
>> from Foundation import NSString
>> s = NSString.alloc().initWithString_('2010-09-08')
>> print(type(s))
>> # Very interesting, the bug only shows up if datetime is imported here
>> instead of at the top
>> from datetime import datetime
>> print(datetime.strptime(s, '%Y-%m-%d'))
>
> This works for me, with python 3.1 and 3.2. Both of them 32-bit builds.   IIRC both python versions don't run the tip of the tree, but that shouldn't matter.
>
> What version of Python and PyObjC do you use? Which architecture are you using (32-bit, intel, 3-way, ...)?
>
> The most likely reason for the odd behaviour is that the constructor for pyobjc_unicode fails to initalize one of the fields in the unicode structs, or at least not exactly the same as the initializer for the real unicode type.
>
> Ronald.
>

I use PyObjC's trunk at r2558 and Python 3.1.2, build in 32bit and
64bit intel arches (when I run it, it runs in 64bit). I fiddled around
to figure out how to run python under 32bit mode, to no avail. The
"arch" command doesn't seem to work for me...

Re: [Pyobjc-dev] Python 3 + pyobjc_unicode + strptime = crash

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

On 8 Sep, 2010, at 11:38, Virgil Dupras wrote:

> Hi,
> 
> (Sorry for not submitting it to the tracker, I don't remember my old
> SF login, I dislike SF and I want to avoid dealing with it.)

> 
> I uncovered a bug today. Under Python 3, when using a pyobjc_unicode
> with strptime, I get a this crash:
> 
> Traceback (most recent call last):
>  File "pyobjc_strptime_bug.py", line 6, in <module>
>    print(datetime.strptime(s, '%Y-%m-%d'))
>  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_strptime.py",
> line 335, in _strptime
>    data_string[found.end():])
> ValueError: unconverted data remains: o
> 
> I created a script that reproduces the bug:
> 
> from Foundation import NSString
> s = NSString.alloc().initWithString_('2010-09-08')
> print(type(s))
> # Very interesting, the bug only shows up if datetime is imported here
> instead of at the top
> from datetime import datetime
> print(datetime.strptime(s, '%Y-%m-%d'))

This works for me, with python 3.1 and 3.2. Both of them 32-bit builds.   IIRC both python versions don't run the tip of the tree, but that shouldn't matter.

What version of Python and PyObjC do you use? Which architecture are you using (32-bit, intel, 3-way, ...)?

The most likely reason for the odd behaviour is that the constructor for pyobjc_unicode fails to initalize one of the fields in the unicode structs, or at least not exactly the same as the initializer for the real unicode type.

Ronald.

[Pyobjc-dev] Python 3 + pyobjc_unicode + strptime = crash

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

Hi,

(Sorry for not submitting it to the tracker, I don't remember my old
SF login, I dislike SF and I want to avoid dealing with it.)

I uncovered a bug today. Under Python 3, when using a pyobjc_unicode
with strptime, I get a this crash:

Traceback (most recent call last):
  File "pyobjc_strptime_bug.py", line 6, in <module>
    print(datetime.strptime(s, '%Y-%m-%d'))
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/_strptime.py",
line 335, in _strptime
    data_string[found.end():])
ValueError: unconverted data remains: o

I created a script that reproduces the bug:

from Foundation import NSString
s = NSString.alloc().initWithString_('2010-09-08')
print(type(s))
# Very interesting, the bug only shows up if datetime is imported here
instead of at the top
from datetime import datetime
print(datetime.strptime(s, '%Y-%m-%d'))

As the comment says in the script, the interesting thing is that the
crash only happens if the datetime import happens after the allocation
of the NSString. If you move the import at the top, the crash doesn't
happen anymore and the function behaves as expected.

For now, the workaround I do in my project is to explicitly cast my
input to str() and it works.

Virgil Dupras

Re: [Pyobjc-dev] Python defined type in C code

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

On 30 Aug, 2010, at 15:23, Ken Brooks wrote:

> I am making a package that consists of one module written in C and two others written in Python. The C module has functions that should take parameters of a class type written in one of the Python modules. What is the most appropriate way of dealing with this? How can I "import" a Python module into my C context?

The easiest way is to define a base class in Objective-C and implement the python class as a subclass of that class:

In ObjC:

@interface MyObject : NSObject
{
}

-(id)myMethod;
@end
@implementation MyObject
// No method implementation here
@end

In Python:

class MyRealObject (objc.lookUpClass("MyObject")):
   def myMethod(self):
       print "Doing it"


Then design the C API to accept instances of the ObjC base class. The primary advantage of this approach is that this gets you the right prototypes in the C code.

BTW. All of this assumes that you're using PyObjC and that your "C" code is actually Objective-C.

Ronald


> 
> Ken 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Python defined type in C code

[Ken B. <kb...@sp...>]

I am making a package that consists of one module written in C and two 
others written in Python. The C module has functions that should take 
parameters of a class type written in one of the Python modules. What is the 
most appropriate way of dealing with this? How can I "import" a Python 
module into my C context?

Ken 

[Pyobjc-dev] [ pyobjc-Bugs-3052283 ] 2.3 fails to build on Tiger

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

Bugs item #3052283, was opened at 2010-08-24 23:38
Message generated for change (Tracker Item Submitted) made by josh_root
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=3052283&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joshua Root (josh_root)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3 fails to build on Tiger

Initial Comment:
One of our users reported that PyObjC 2.3 fails to build on Tiger like so:

Modules/objc/objc-class.m: In function 'PyObjCClass_ListProperties':
Modules/objc/objc-class.m:1823: error: 'objc_property_t' undeclared (first use in this function)

Downstream bug report: http://trac.macports.org/ticket/26120

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

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

[Pyobjc-dev] py2app and related packages on bitbucket

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

Hi,

I've converted the repositories for py2app and related packages to mercurial and posted them on bitbucket. The new home pages are:

py2app: http://bitbucket.org/ronaldoussoren/py2app
macholib: http://bitbucket.org/ronaldoussoren/macholib
modulegraph: http://bitbucket.org/ronaldoussoren/modulegraph
altgraph: http://bitbucket.org/ronaldoussoren/altgraph

I have disabled the wiki for now, but did enable the issue tracker.

The pyobjc repository will also be converted to mercurial, but that's a more complicated process due to the more complicated history in that repository.

Ronald

Re: [Pyobjc-dev] Docs unhelpful

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

On 16 Aug, 2010,at 09:18 AM, James R Eagan <jam...@lr...> wrote:

Hi Andrew,

You may find the PyObjC tutorial useful. In particular, this section : http://pyobjc.sourceforge.net/documentation/pyobjc-core/intro.html#accessing-python-objects-from-objective-c

You can typically use a python unicode (or str if you absolutely positively know you'll never ever have any non ASCII, but you don't) wherever an NSString is expected. 

James

--
Envoyé de mon mobile / Sent from my mobile

Le 14 août 2010 à 21:31, Andrew Pennebaker <andrew.pennebaker@gmailcom> a écrit :

> I know ObjC, and I know Python. What I do not know is:
> 
> * How to convert between NSString and Python string.
 
Could you explain what you're trying to do?   PyObjC will automaticly translate datatypes when calling methods.


> * How to convert (id) something into an NSString (and then to a Python string).

> * How to create an NSArray of NSStrings using NSArray.arrayWithObjects and Python strings.
 

anArray = [u"foo", u"bar"]

PyObjC will provide an NSArray subclass when that array is passed to Objective-C code.

When you need a real NSArray, for example because you use Key-Value Observation:

anArray = NSMutableArray.arrayWithArray_([u"foo", u"bar"])

> * Whether None is an acceptable substitute for ObjC's nil.
 
Yes, and that is documented in PyObjC documentation.


> 
> None of these are found in the PyObjC docs. Instead, I just see which things aren't implemented yet. That's extremely unhelpful.
 
The documentation needs work, but all of this is documented in the pyobjc-core documentation (in particular in the introduction).

Ronald

Re: [Pyobjc-dev] Docs unhelpful

[James R E. <jam...@lr...>]

Hi Andrew,

You may find the PyObjC tutorial useful. In particular, this section :  http://pyobjc.sourceforge.net/documentation/pyobjc-core/intro.html#accessing-python-objects-from-objective-c

You can typically use a python unicode (or str if you absolutely positively know you'll never ever have any non ASCII, but you don't) wherever an NSString is expected. 

James

--
Envoyé de mon mobile / Sent from my mobile

Le 14 août 2010 à 21:31, Andrew Pennebaker <and...@gm...> a écrit :

> I know ObjC, and I know Python. What I do not know is:
> 
> * How to convert between NSString and Python string.
> * How to convert (id) something into an NSString (and then to a Python string).
> * How to create an NSArray of NSStrings using NSArray.arrayWithObjects and Python strings.
> * Whether None is an acceptable substitute for ObjC's nil.
> 
> None of these are found in the PyObjC docs. Instead, I just see which things aren't implemented yet. That's extremely unhelpful.
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Docs unhelpful

[Andrew P. <and...@gm...>]

I know ObjC, and I know Python. What I do not know is:

* How to convert between NSString and Python string.
* How to convert (id) something into an NSString (and then to a Python
string).
* How to create an NSArray of NSStrings using NSArray.arrayWithObjects and
Python strings.
* Whether None is an acceptable substitute for ObjC's nil.

None of these are found in the PyObjC docs. Instead, I just see which things
aren't implemented yet. That's extremely unhelpful.

[Pyobjc-dev] PyObjC plans for the near future

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

Hi,

I'll work on the following items in the nearish future:

(Mostly non-technical)

1) Migrate the repositories for PyObjC and py2app to mercurial with the repositories hosted on bitbucket

This gives two major advantages:

* a bugtracker that doesn't suck

* easier for others to prepare patches in private repositories

The hard part of the migration is not the technical migration itself, that's basicly just running 'hg convert' on the existing repositories but adjusting my workflow and making sure that I actually now how to work with mercurial branches.

2) Migrate all documentation to sphinx and flesh out the documentation

3) Rebuild the official website based on the sphinx documentation. I'll probably use my MobileMe account for that (with a custom domainname). The hard part of this is building a website L&F that I like, which means something different than the current website. On the technical side I can basicly reuse the current website management scripts with some fairly small adjustments.

(Programming related)

4) Work on properly testing py2app and related packages

I've started on this and want to end up with full test coverage to ensure that the tools work as intended.  Recent new features like support for pip-style namespace packages and relative imports were implemented after adding tests for them.

5) Add better support for setuptools to py2app

This will consist of two parts: (1) ensure that you can specify dependencies in the egg-files that should be satisfied before running py2app, either by reusing 'install_requires' or by adding a 'requires' option to the py2app configuration; and (2) add options for including whole eggs including meta-data into bundles.

6) Add a py2app_standalone command that can be used in Xcode templates

7) Ensure that all tests pass on the 2.3 branch of pyobjc and release pyobjc 2.3.1

8) Add code for making ObjC properties available as python properties (simular to objc.object_property, but for native properties)

9) Replace the code that looks for ObjC methods, replace the somewhat greedy searching code by a lazy scanner. That should
reduce memory usage and increase speed (both for initialization and for method calls)

10) Research a way to reduce the memory usage for the "bridgesupport" files

This will likely result in compiling the XML files into something more convenient and dropping the dependency on libxml.

I don't know in what timeframe all of this will happen, the list is longish and my time is limited. I do hope that I'll manage to release PyObjC 2.4 this year, but that is noted based on any kind of planning on my part.

In the longer run I'd like to experiment with a branch/fork of CPython that integrates PyObjC into the interpreter and replaces the memory management code by the Objective-C garbage collector, simular to what MacRuby does for ruby.  This would primarily help in reducing the remaining memory management problems (such as dealing with the weak-references used by NSOutlineViews), and may be a patch towards a Python interpreter without a GIL.    This is definitely something that will move forward very slowly, as it requires a significant amount of work.

Ronald

P.S. Please consider donating to PyObjC if you use it commercially. This can be done using the Paypal donations button on <http://pyobjc.sourceforge.net>.   Donations would help me find ways to spend more time on PyObjC, which would help moving the project forward faster.  Almost all work on PyObjC is done by me in my private time.

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

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

On Jul 28, 2010, at 2:27 AM, Brendan Simon (eTRIX) wrote:

> 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.

That helped a bit, I get this:

tequila:GH28 deets$ export CC=gcc-4.0
tequila:GH28 deets$ export MACOSX_DEPLOYMENT_TARGET=10.5
tequila:GH28 deets$ /Library/Frameworks/Python.framework/Versions/2.6/bin/easy_install-2.6   "pyobjc==2.2b1"
Searching for pyobjc==2.2b1
Best match: pyobjc 2.2b1
Processing pyobjc-2.2b1-py2.6.egg
pyobjc 2.2b1 is already the active version in easy-install.pth

Using /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc-2.2b1-py2.6.egg
Processing dependencies for pyobjc==2.2b1
Searching for pyobjc-core==2.2b1
Reading http://pypi.python.org/simple/pyobjc-core/
Reading http://pyobjc.sourceforge.net/
Reading http://pyobjc.sourceforge.net/software/index.php
Best match: pyobjc-core 2.2b1
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-YC_qFZ/pyobjc-core-2.2b1/egg-dist-tmp-krQzse
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
Modules/objc/formal-protocol.m: In function 'proto_new':
Modules/objc/formal-protocol.m:170: warning: 'protocol_name' is deprecated (declared at /usr/include/objc/Protocol.h:38)
Modules/objc/formal-protocol.m:171: warning: 'protocol_name' is deprecated (declared at /usr/include/objc/Protocol.h:38)
Modules/objc/formal-protocol.m:177: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:180: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:183: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:184: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:187: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:189: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:193: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:197: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:200: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:204: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:207: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:210: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:214: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:224: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:225: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:230: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:231: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:238: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:239: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:240: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:245: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:246: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:247: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:270: warning: 'protocol_name' is deprecated (declared at /usr/include/objc/Protocol.h:38)
Modules/objc/formal-protocol.m:271: warning: 'protocol_name' is deprecated (declared at /usr/include/objc/Protocol.h:38)
Modules/objc/formal-protocol.m:274: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:275: warning: 'protocol_list' is deprecated (declared at /usr/include/objc/Protocol.h:39)
Modules/objc/formal-protocol.m:278: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:279: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:280: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:285: warning: 'instance_methods' is deprecated (declared at /usr/include/objc/Protocol.h:40)
Modules/objc/formal-protocol.m:288: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:289: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:290: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m:295: warning: 'class_methods' is deprecated (declared at /usr/include/objc/Protocol.h:41)
Modules/objc/formal-protocol.m: At top level:
Modules/objc/formal-protocol.m:509: warning: missing initializer
Modules/objc/formal-protocol.m:509: warning: (near initialization for 'PyObjCFormalProtocol_Type.tp_version_tag')
Modules/objc/function.m:322: warning: missing initializer
Modules/objc/function.m:322: warning: (near initialization for 'PyObjCFunc_Type.tp_version_tag')
Modules/objc/informal-protocol.m:207: warning: missing initializer
Modules/objc/informal-protocol.m:207: warning: (near initialization for 'PyObjCInformalProtocol_Type.tp_version_tag')
Modules/objc/instance-var.m: In function 'ivar_descr_set':
Modules/objc/instance-var.m:168: warning: unused variable 'ocName'
Modules/objc/instance-var.m: At top level:
Modules/objc/instance-var.m:326: warning: missing initializer
Modules/objc/instance-var.m:326: warning: (near initialization for 'PyObjCInstanceVariable_Type.tp_version_tag')
Modules/objc/method-accessor.m:421: warning: missing initializer
Modules/objc/method-accessor.m:421: warning: (near initialization for 'PyObjCMethodAccessor_Type.tp_version_tag')
Modules/objc/method-imp.m:349: warning: missing initializer
Modules/objc/method-imp.m:349: warning: (near initialization for 'PyObjCIMP_Type.tp_version_tag')
Modules/objc/method-signature.m:94: warning: missing initializer
Modules/objc/method-signature.m:94: warning: (near initialization for 'PyObjCMethodSignature_Type.tp_version_tag')
Modules/objc/module.m: In function 'PyObjC_objc_sync_notify':
Modules/objc/module.m:1442: warning: 'objc_sync_notify' is deprecated (declared at /usr/include/objc/objc-sync.h:39)
Modules/objc/module.m: In function 'PyObjC_objc_sync_notifyAll':
Modules/objc/module.m:1467: warning: 'objc_sync_notifyAll' is deprecated (declared at /usr/include/objc/objc-sync.h:40)
Modules/objc/module.m: In function 'PyObjC_objc_sync_wait':
Modules/objc/module.m:1494: warning: 'objc_sync_wait' is deprecated (declared at /usr/include/objc/objc-sync.h:38)
Modules/objc/objc-class.m:49: warning: missing initializer
Modules/objc/objc-class.m:49: warning: (near initialization for 'nsdata_as_buffer.bf_getbuffer')
Modules/objc/objc-class.m:56: warning: missing initializer
Modules/objc/objc-class.m:56: warning: (near initialization for 'nsmutabledata_as_buffer.bf_getbuffer')
Modules/objc/objc-class.m:1162: warning: missing initializer
Modules/objc/objc-class.m:1162: warning: (near initialization for 'PyObjCClass_Type.tp_version_tag')
Modules/objc/objc-NULL.m:63: warning: missing initializer
Modules/objc/objc-NULL.m:63: warning: (near initialization for 'PyObjC_NULL_Type.tp_version_tag')
Modules/objc/objc-object.m:708: warning: missing initializer
Modules/objc/objc-object.m:708: warning: (near initialization for 'PyObjCObject_Type.base.ht_type.tp_version_tag')
Modules/objc/objc-object.m:717: warning: missing initializer
Modules/objc/objc-object.m:717: warning: (near initialization for 'PyObjCObject_Type.base.as_buffer.bf_getbuffer')
Modules/objc/objc_inject.m:55: warning: 'NSAddImage' is deprecated (declared at /usr/include/mach-o/dyld.h:230)
Modules/objc/objc_inject.m:56: warning: 'NSLookupSymbolInImage' is deprecated (declared at /usr/include/mach-o/dyld.h:182)
Modules/objc/objc_inject.m:57: warning: 'NSAddressOfSymbol' is deprecated (declared at /usr/include/mach-o/dyld.h:188)
Modules/objc/objc_inject.m:59: warning: 'NSCreateObjectFileImageFromFile' is deprecated (declared at /usr/include/mach-o/dyld.h:145)
Modules/objc/objc_inject.m:60: warning: 'NSLinkModule' is deprecated (declared at /usr/include/mach-o/dyld.h:161)
Modules/objc/objc_inject.m:61: warning: 'NSLinkEditError' is deprecated (declared at /usr/include/mach-o/dyld.h:217)
Modules/objc/objc_inject.m: In function 'INJECT_EventLoopTimerEntry':
Modules/objc/objc_inject.m:418: error: 'struct <anonymous>' has no member named '__builtin___snprintf_chk'
Modules/objc/objc_inject.m: In function 'objc_inject':
Modules/objc/objc_inject.m:470: warning: 'NSAddImage' is deprecated (declared at /usr/include/mach-o/dyld.h:230)
Modules/objc/objc_inject.m:484: warning: 'NSCreateObjectFileImageFromFile' is deprecated (declared at /usr/include/mach-o/dyld.h:145)
Modules/objc/objc_inject.m:484: warning: 'NSCreateObjectFileImageFromFile' is deprecated (declared at /usr/include/mach-o/dyld.h:145)
Modules/objc/objc_inject.m:485: warning: 'NSLinkModule' is deprecated (declared at /usr/include/mach-o/dyld.h:161)
Modules/objc/objc_inject.m:485: warning: 'NSLinkModule' is deprecated (declared at /usr/include/mach-o/dyld.h:161)
Modules/objc/objc_inject.m:486: warning: 'NSLinkEditError' is deprecated (declared at /usr/include/mach-o/dyld.h:217)
Modules/objc/objc_inject.m:486: warning: 'NSLinkEditError' is deprecated (declared at /usr/include/mach-o/dyld.h:217)
error: Setup script exited with error: command 'gcc-4.0' failed with exit status 1


Diez

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

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

On 3 Aug, 2010, at 18:24, Christopher Barker wrote:

> Ronald Oussoren wrote:
>> AFAIK Bob intented py2app to be compatible with py2exe when
>> specifying what to build. That won't always work though due
>> to differences between the two platforms.
> 
> There are differences that are because of platform. I think datafiles 
> are handles differently at least.
> 
> If you want to consider those bugs, I could try to dig into some of my 
> setups and identify the issues I've found -- but that won't be for a 
> couple weeks at least (vacation!)

This has no hurry, but I at least want to know about differences and document them.  And all differences that don't have a good reason should probably be fixed.

> 
> 
>> It might be useful to think about a cleaner way to specify what to
>> build, I don't particularly like the current way and especially not when
>> building more complex applications.
> 
> agreed -- though it's no horrible.
> 
>> I totally agree that is would be better to try to get the various
>> stand-alone builders to at least share code for the common
>> functionality. A common API for the various components would help
>> with that, but it would IMHO be better to actually merge the various
>> components.
> 
> Me too, but that requires cooperation, which may be hard to come by. I'd 
> at least contact the ebb-freeze guy (Ralf?) -- he seemed a little 
> confused about how to share code -- for instance, he said he couldn't 
> use py2exe's code for including the icon because of licensing, but it 
> looked like the license was compatible to me. With a little 
> encouragement, maybe he'd be glad to share more.

My first goal is to go through the py2app stack to fix small issues and add proper testing, after that I'm open for cooperation. 

Ronald

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

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

Ronald Oussoren wrote:
> AFAIK Bob intented py2app to be compatible with py2exe when
> specifying what to build. That won't always work though due
 > to differences between the two platforms.

There are differences that are because of platform. I think datafiles 
are handles differently at least.

If you want to consider those bugs, I could try to dig into some of my 
setups and identify the issues I've found -- but that won't be for a 
couple weeks at least (vacation!)


> It might be useful to think about a cleaner way to specify what to
> build, I don't particularly like the current way and especially not when
> building more complex applications.

agreed -- though it's no horrible.

> I totally agree that is would be better to try to get the various
> stand-alone builders to at least share code for the common
> functionality. A common API for the various components would help
> with that, but it would IMHO be better to actually merge the various
> components.

Me too, but that requires cooperation, which may be hard to come by. I'd 
at least contact the ebb-freeze guy (Ralf?) -- he seemed a little 
confused about how to share code -- for instance, he said he couldn't 
use py2exe's code for including the icon because of licensing, but it 
looked like the license was compatible to me. With a little 
encouragement, maybe he'd be glad to share more.

-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] [Pythonmac-SIG] ANN: py2app 0.5

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

On 2 Aug, 2010, at 23:55, Russell E. Owen wrote:

> 
> 
> P.S. I'm curious about the virtualenv improvements. I use virtualenv to 
> develop my code, but when I've got the appropriate environment set up if 
> I build the application using py2app I always get the appended traceback 
> (even witih py2app 0.5.2).
> 
> To work around it I have my setup.py script add a few necessary bits to 
> sys.path and I build from a fresh login with no virtual environment set 
> up.
> 
> No big deal, but if there is a way to make the build work even when the 
> required packages are setup using virutalenv, I'd like to know about it.

That's strange, I have build a couple of applications using virtualenvs. I don't use pip though and have patches to virtualenv that might change its behavior enough the explain the difference.  Another set of patches to push upstream...

Ronald

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

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

On 1 Aug, 2010, at 19:29, Christopher Barker wrote:

> 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

AFAIK Bob intented py2app to be compatible with py2exe when specifying what to build. That won't always work though due to differences between the two platforms.

It might be useful to think about a cleaner way to specify what to build, I don't particularly like the current way and especially not when building more complex applications.

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

Correct. I don't know what py2exe uses, it might use the stdlib modulefinder.

> 
> 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.

I totally agree that is would be better to try to get the various stand-alone builders to at least share code for the common functionality. A common API for the various components would help with that, but it would IMHO be better to actually merge the various components.

Ronald

Re: [Pyobjc-dev] typo in pyobjc_setup.py ?

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

On 3 Aug, 2010, at 5:15, Scott Lasley wrote:

> Is there a typo in this line in pyobjc_setup.py
>            open(os.path.join(include_rot, 'pyobjc-api.h'), 'w').write(data)
> Should it be
>            open(os.path.join(include_root, 'pyobjc-api.h'), 'w').write(data)

Your right, that's a type. Thanks for the fix,

Ronald

[Pyobjc-dev] typo in pyobjc_setup.py ?

[Scott L. <sl...@sp...>]

Is there a typo in this line in pyobjc_setup.py
            open(os.path.join(include_rot, 'pyobjc-api.h'), 'w').write(data)
Should it be
            open(os.path.join(include_root, 'pyobjc-api.h'), 'w').write(data)

Thanks for pyobjc,
Scott

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

[Matthias B. <mat...@gm...>]

Christopher Barker wrote:
> 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:
> 
> [...]
> 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.

Is anyone here familiar with Py++ [1]? What Christopher describes
reminded me very much of that tool. Py++ is not a tool to produce
standalone packages like py2app does, instead it's a tool to generate
Python bindings for C/C++ libraries, but it seems their inner workings
share similarities. Just like py2app has to find out what modules get
imported by an application, Py++ needs to find out what
functions/classes are in a library and which of them need to be turned
into Python functions/classes. Py++ does that by running gccxml on the
header files to extract the contents of the files which is then further
processed. For simple libraries it might be enough to let Py++ just
convert everything it finds in the headers, but for more complex
libraries you want to customize that and leave out some stuff.
Now the thing is, Py++ is not implemented as a standalone tool you just
run on some input files, but instead, it's a framework for writing
wrapper generators. This means, the user writes the main script (in
Python) which invokes Py++ functionality and this means the actual
control of the entire process is in the user's hands.
In simple cases, it's enough to leave everything up to Py++ which means
your main script will be very short. But if you want to, you can
intercept any step in the processing pipeline and modify the data. For
example, as mentioned above, the first step is to get the declarations
from the header files which builds a tree of declarations that's stored
in memory. Before the tree is passed on, your main script can inspect
and modify it. You could even choose to skip that gccxml step entirely
and produce the declaration tree by some other means. Subsequent Py++
steps just work on that tree, it doesn't matter anymore who created it.
After that, the wrapper source code is generated which is again a tree
of text blocks. Before this tree is written to disk to generate the
source files, you can again intercept this and modify the tree.
This design makes Py++ very flexible because you can inject your own
logic into the pipeline to tailer the process to your needs.
Now it sounds like exactly the same thing could be done in py2app (which
I have never used so far, by the way, but from reading the mails here it
sounds like it doesn't already provide this sort of flexibilty). Its
first step is to find out what modules need to be included. If this
produces a well-defined data structure with an API to modify/create it
and the user gets the chance to modify that data before it's passed on
(or even recreate it from scratch), then all use-cases that have been
mentioned here could be handled by the same tool.

Sorry if this all doesn't make any sense or py2app already has different
means of achieving this flexibilty. As I said, I haven't used py2app yet
(but it's on my todo list to try it out), it's just because
Christopher's mail sounded so much like Py++ that I thought I'd chime in
for a moment.

Cheers,

- Matthias -

[1] http://www.language-binding.net/

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

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

Thank you Gruber,
Let me try your suggestion out
Muthoni


On Mon, Aug 2, 2010 at 12:23 PM, engelbert gruber <
gr...@us...> wrote:

> 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
> >
> >
>