pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] [ pyobjc-Bugs-3085651 ] Unsafe NSLog in PyObjCTools.Debugging.nsLogPythonException

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

Bugs item #3085651, was opened at 2010-10-11 21:21
Message generated for change (Tracker Item Submitted) made by kthomases
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=3085651&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: Ken Thomases (kthomases)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unsafe NSLog in PyObjCTools.Debugging.nsLogPythonException

Initial Comment:
In PyObjCTools.Debugging.nsLogPythonException, the exception is formatted into a string, which is then passed as the first/only argument to NSLog.  The problem is that NSLog treats its first argument as a format string.  The formatted exception may contain percent ('%') characters, which will be interpreted as format specifiers.  Since there are no arguments for those specifiers, an exception is thrown (during logging of an exception).

It results in something like this:

*** Exception occurred during exception handler ***
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjCTools/Debugging.py", line 83, in exceptionHandler_shouldLogException_mask_
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjCTools/Debugging.py", line 47, in nsLogPythonException
ValueError: Too few arguments for format string [cur:1/len:1]
2010-10-11 20:47:03.946 CrossOver[497:903] NSExceptionHandler has recorded the following exception:
OC_PythonException -- <type 'exceptions.KeyError'>: u'Key needs_download does not exist'
Stack trace:  0x96155d24  0x97082509  0x98c2a9f1  0x150b2cb8  0x1508c5fe  0x331d4  0x33500  0x32f73  0x97f8cf1e  0x9806c699  0x98068146  0x9806743d  0x980bca61  0x98065e93  0x98063e9c  0x97f7caff  0x255f06  0x97f105bb  0x97f085ed  0x25e676  0x83b10  0x2c92  0x1


When I add a proper format string (u'%@') to the NSLog call, the same path through my code produces a properly-logged exception:

2010-10-11 20:54:26.587 CrossOver[760:903] *** Python exception discarded!
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC/PyObjCTools/KeyValueCoding.py", line 213, in getKey
    raise KeyError, "Key %s does not exist" % (key,)
KeyError: u'Key needs_download does not exist'


You can see the '%s' in the traceback which is the "bomb" for the unsafe NSLog call.

It's probably a good idea to review all uses of NSLog for similar unsafe calling.  The first argument should always be a constant, not a run-time-computed string.

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

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

[Pyobjc-dev] [ pyobjc-Bugs-3077003 ] Misuse of strcmp() in -[OC_PythonString __realObject__]

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

Bugs item #3077003, was opened at 2010-09-28 01:39
Message generated for change (Tracker Item Submitted) made by kthomases
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=3077003&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: Ken Thomases (kthomases)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misuse of strcmp() in -[OC_PythonString __realObject__]

Initial Comment:
Relatively recently, -[OC_PythonString __realObject__] was improved to try to use an encoding which matches the Python default encoding.  Unfortunately, it was done incorrectly.  It uses strcmp() as though it were a strequals() function, but the return value of strcmp() has the opposite logical sense.  It's 0 when the strings are equal and non-zero when they differ.  The result was that it uses UTF-8 when the Python encoding is "ascii" and ASCII otherwise.  (That's actually not a terrible result, since on Mac OS X UTF-8 is almost always the correct encoding to use, even though it's not Python's default encoding.)

Anyway, I'm attaching a patch to correct the logic.

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

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

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

[Ben A. <be...@ar...>]

Relatedly, has anyone here looked at the possibility of compiling a variant of Python (without eval and exec, similar to RPython) to native iOS code? 

-- 

<http://artins.org/ben>

"Greatest weakness? It's possible that I am a little too awesome."  — Barack Obama

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