From charles.hartman at conncoll.edu  Mon Feb  1 17:42:41 2010
From: charles.hartman at conncoll.edu (Charles Hartman)
Date: Mon, 1 Feb 2010 11:42:41 -0500
Subject: [Pythonmac-SIG] Fwd:  font-choice dialog in Snow Leopard
References: <7D641AAD-CB45-4A65-8596-8D943362524F@gmail.com>
Message-ID: <251CBD93-6896-42A8-A1D1-B6C9CCBB12B6@conncoll.edu>

Has anyone heard anything about when this release might happen?

Also, when it does happen, if I just rebuild my app with py2app, is it likely to work, or will I just break things worse?  I'm confused about the Snow Leopard/32-bit/64-bit issues.  I'm using the python.org version 2.6.4 of Python and (I think) the latest version of py2app.

> From: Cody Precord <codyprecord at gmail.com>
> Date: January 9, 2010 7:28:22 PM EST
> To: Charles Hartman <charles.hartman at conncoll.edu>
> Subject: Re: [Pythonmac-SIG] font-choice dialog in Snow Leopard
> 
> On Jan 9, 2010, at 6:23 PM, Charles Hartman wrote:
> 
>> I admit I haven't looked into it in detail yet, and I will, but maybe somebody can simplify the hunt.  In an app I last built with py2app under Leopard, a standard dialog to choose a font (using wxPython's wx.GetFontFromUser() ) appears on the screen for a brief flash and then vanishes when I run the executable under Snow Leopard.  I could begin by just rebuilding with py2app under Snow Leopard, but I'm nervous, given all the S.L. alarms I've seen here.
> 
> Its a bug in wxWidgets. It has been fixed already for the next 2.8 release (2.8.11).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100201/0890c593/attachment.htm>

From Chris.Barker at noaa.gov  Tue Feb  2 23:13:08 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 02 Feb 2010 14:13:08 -0800
Subject: [Pythonmac-SIG] Fwd:  font-choice dialog in Snow Leopard
In-Reply-To: <251CBD93-6896-42A8-A1D1-B6C9CCBB12B6@conncoll.edu>
References: <7D641AAD-CB45-4A65-8596-8D943362524F@gmail.com>
	<251CBD93-6896-42A8-A1D1-B6C9CCBB12B6@conncoll.edu>
Message-ID: <4B68A374.1060704@noaa.gov>

Charles Hartman wrote:
> Has anyone heard anything about when this release might happen?

well, there are preview builds for 2.9.0:

https://trac.orr.noaa.gov/trac/ResponderTools/wiki/TrajNotes/Regions

I'm not sure what the plans are for a 2.8.11

-Chris



> Also, when it does happen, if I just rebuild my app with py2app, is it 
> likely to work, or will I just break things worse?  I'm confused about 
> the Snow Leopard/32-bit/64-bit issues.  I'm using the python.org 
> <http://python.org> version 2.6.4 of Python and (I think) the latest 
> version of py2app.
> 
>> *From: *Cody Precord <codyprecord at gmail.com 
>> <mailto:codyprecord at gmail.com>>
>> *Date: *January 9, 2010 7:28:22 PM EST
>> *To: *Charles Hartman <charles.hartman at conncoll.edu 
>> <mailto:charles.hartman at conncoll.edu>>
>> *Subject: **Re: [Pythonmac-SIG] font-choice dialog in Snow Leopard*
>>
>> On Jan 9, 2010, at 6:23 PM, Charles Hartman wrote:
>>
>>> I admit I haven't looked into it in detail yet, and I will, but maybe 
>>> somebody can simplify the hunt.  In an app I last built with py2app 
>>> under Leopard, a standard dialog to choose a font (using wxPython's 
>>> wx.GetFontFromUser() ) appears on the screen for a brief flash and 
>>> then vanishes when I run the executable under Snow Leopard.  I could 
>>> begin by just rebuilding with py2app under Snow Leopard, but I'm 
>>> nervous, given all the S.L. alarms I've seen here.
>>
>> Its a bug in wxWidgets. It has been fixed already for the next 2.8 
>> release (2.8.11).
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


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

Chris.Barker at noaa.gov

From lackey at manoutoftime.org  Wed Feb  3 00:24:08 2010
From: lackey at manoutoftime.org (William R. Dickson)
Date: Tue, 2 Feb 2010 23:24:08 +0000 (UTC)
Subject: [Pythonmac-SIG] problem running py2app
References: <86D3A325-7304-4FA8-879D-2E9E906AC47C@gmail.com>
Message-ID: <loom.20100203T002200-837@post.gmane.org>

Attila Tajti <attila.tajti <at> gmail.com> writes:

> error: unpack requires a string argument of length 8
> > /Users/ata/Projects/MailArchiveButton/build/bdist.macosx-10.6-
universal/egg/macholib/ptypes.py(48)from_str()
> (Pdb) ^D

I'm getting the same error on my first attempt to build an app. Did
you get any response to this question?

Thanks,

-Bill


From attila.tajti at gmail.com  Wed Feb  3 07:50:48 2010
From: attila.tajti at gmail.com (Attila Tajti)
Date: Wed, 3 Feb 2010 07:50:48 +0100
Subject: [Pythonmac-SIG] problem running py2app
In-Reply-To: <loom.20100203T002200-837@post.gmane.org>
References: <86D3A325-7304-4FA8-879D-2E9E906AC47C@gmail.com>
	<loom.20100203T002200-837@post.gmane.org>
Message-ID: <309766EB-CD70-45B9-ACD6-ED3267079E2A@gmail.com>


On 2010.02.03., at 0:24, William R. Dickson wrote:

>> error: unpack requires a string argument of length 8
>>> /Users/ata/Projects/MailArchiveButton/build/bdist.macosx-10.6-
> universal/egg/macholib/ptypes.py(48)from_str()
>> (Pdb) ^D
> 
> I'm getting the same error on my first attempt to build an app. Did
> you get any response to this question?

I had no response, nor had I any serious attempts to fix it yet. I suggest to take a look at the article by Virgil Drupas. I had no time to test his version of py2app yet. (This was also mentioned on this list earlier by Kevin Walzer.)

http://www.hardcoded.net/articles/building-64-bit-pyobjc-applications-with-py2app.htm

Honestly this article disappointed me because of the problems with both memory consumption and necessity to use a separate 10.5 partition for the build system, so I started looking for another project for the time being. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100203/539e2bd1/attachment.htm>

From kw at codebykevin.com  Wed Feb  3 16:06:20 2010
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 03 Feb 2010 10:06:20 -0500
Subject: [Pythonmac-SIG] problem running py2app
In-Reply-To: <loom.20100203T002200-837@post.gmane.org>
References: <86D3A325-7304-4FA8-879D-2E9E906AC47C@gmail.com>
	<loom.20100203T002200-837@post.gmane.org>
Message-ID: <4B6990EC.5050308@codebykevin.com>

On 2/2/10 6:24 PM, William R.Dickson wrote:
> Attila Tajti<attila.tajti<at>  gmail.com>  writes:
>
>> error: unpack requires a string argument of length 8
>>> /Users/ata/Projects/MailArchiveButton/build/bdist.macosx-10.6-
> universal/egg/macholib/ptypes.py(48)from_str()
>> (Pdb) ^D
>
> I'm getting the same error on my first attempt to build an app. Did
> you get any response to this question?
>
> Thanks,
>
> -Bill


http://wiki.python.org/moin/MacPython/BundleBuilder

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From Chris.Barker at noaa.gov  Wed Feb  3 17:53:57 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 03 Feb 2010 08:53:57 -0800
Subject: [Pythonmac-SIG] Fwd:  font-choice dialog in Snow Leopard
In-Reply-To: <4B68A374.1060704@noaa.gov>
References: <7D641AAD-CB45-4A65-8596-8D943362524F@gmail.com>
	<251CBD93-6896-42A8-A1D1-B6C9CCBB12B6@conncoll.edu>
	<4B68A374.1060704@noaa.gov>
Message-ID: <4B69AA25.3080609@noaa.gov>



Christopher Barker wrote:
> I'm not sure what the plans are for a 2.8.11

now I am: This just from Robin Dunn on the wxPython list:

"""
It looks like wx 2.8.11 will be coming in the next couple weeks. 
wxPython should be not too long after that.
"""

-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

Chris.Barker at noaa.gov

From Chris.Barker at noaa.gov  Thu Feb  4 18:42:49 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 04 Feb 2010 09:42:49 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
Message-ID: <4B6B0719.3000604@noaa.gov>

Hi folks,

Peter Hanson, on the wxPython list, seems to have identified a bug in 
the gestalt module, that may be a Carbon issue. It's a bit of an unusual 
case: it freezes up wxPython, when wx is called from other than the main 
thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is 
calling Carbon, and doing so in the main thread, so you are then trying 
to call Carbon from more than one thread, which may be the cause of the 
problem. I've confirmed that if you call gestalt from the same thread as 
wxPython, there is no failure.

A link to Robin Dunn's assessment:

http://permalink.gmane.org/gmane.comp.python.wxpython/76590

As Carbon is deprecated anyway, I guess it's time for gestalt ( or 
platform.mac_ver ) to be re-written

I've tested on OS-X 10.4.11, Python 2.5 and Python2.6

Here is Peter's summary and sample code:

# Demonstration of application freeze on OSX.

# Running "python osx_freeze.py" shows the symptom:
# non-responsiveness after about 3 seconds.  In theory
# this will occur in any wxPython app which runs
# the GUI event loop in a thread other than the one
# in which the failing gestalt('sysu') call (see below)
# is first executed.

# Enabling any of these imports can trigger the problem
# as each one imports the next one down in the list.
# This will happen only with pkg_resources v0.6c10 or later
# although it's not pkg_resources' fault.
# import matplotlib.figure
# import matplotlib.axes
# import matplotlib.dates
# import pytz
# import pkg_resources

# The next import alone doesn't lead to failure,
# but the function call does.
# This same code is executed by pkg_resources starting
# with setuptools v0.6c10.
# from platform import mac_ver; mac_ver()

# The platform.mac_ver() call does the following, which
# is what ultimately leads to the failure.  Calls
# to gestalt() with 'sysa' (for example) do not
# trigger the problem, either because the problem is
# related to the 'sysu' itself, or to the fact that
# an exception is raised because the selector "sysu"
# is no longer recognized.
from gestalt import gestalt
try:
     print gestalt('sysu')
except Exception, ex:
     print 'gestalt call failed'

if __name__ == '__main__':
     def gui():
         import wx
         app = wx.App(False)
         frame = wx.Frame(None)
         wx.StaticText(frame, label='Goodbye, cruel world')
         frame.Show()
         app.MainLoop()

     import threading
     threading.Thread(target=gui).start()




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

Chris.Barker at noaa.gov

From aahz at pythoncraft.com  Thu Feb  4 18:59:47 2010
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 4 Feb 2010 09:59:47 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <4B6B0719.3000604@noaa.gov>
References: <4B6B0719.3000604@noaa.gov>
Message-ID: <20100204175947.GB4548@panix.com>

On Thu, Feb 04, 2010, Christopher Barker wrote:
>
> Peter Hanson, on the wxPython list, seems to have identified a bug in  
> the gestalt module, that may be a Carbon issue. It's a bit of an unusual  
> case: it freezes up wxPython, when wx is called from other than the main  
> thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is  
> calling Carbon, and doing so in the main thread, so you are then trying  
> to call Carbon from more than one thread, which may be the cause of the  
> problem. I've confirmed that if you call gestalt from the same thread as  
> wxPython, there is no failure.

I've already complained that mac_ver() causes a crash with
USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
but I'm pretty sure we're not using wx on Mac, just Windows (we're using
AppHelper).
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

import antigravity

From Chris.Barker at noaa.gov  Thu Feb  4 20:11:16 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 04 Feb 2010 11:11:16 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <4B6B0719.3000604@noaa.gov>
References: <4B6B0719.3000604@noaa.gov>
Message-ID: <4B6B1BD4.8050406@noaa.gov>

One more note from Peter:

"""
We've used all four combinations of OSX 10.4/10.5 and Python 2.5/2.6. 
I'm pretty sure even Python 3.1 would have the same problem (since the 
platform.py module does the same calls).

It seems to be independent of wxPython, other than that I'm using it to 
show the symptom.
"""

Christopher Barker wrote:
> Hi folks,
> 
> Peter Hanson, on the wxPython list, seems to have identified a bug in 
> the gestalt module, that may be a Carbon issue. It's a bit of an unusual 
> case: it freezes up wxPython, when wx is called from other than the main 
> thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is 
> calling Carbon, and doing so in the main thread, so you are then trying 
> to call Carbon from more than one thread, which may be the cause of the 
> problem. I've confirmed that if you call gestalt from the same thread as 
> wxPython, there is no failure.
> 
> A link to Robin Dunn's assessment:
> 
> http://permalink.gmane.org/gmane.comp.python.wxpython/76590
> 
> As Carbon is deprecated anyway, I guess it's time for gestalt ( or 
> platform.mac_ver ) to be re-written
> 
> I've tested on OS-X 10.4.11, Python 2.5 and Python2.6
> 
> Here is Peter's summary and sample code:
> 
> # Demonstration of application freeze on OSX.
> 
> # Running "python osx_freeze.py" shows the symptom:
> # non-responsiveness after about 3 seconds.  In theory
> # this will occur in any wxPython app which runs
> # the GUI event loop in a thread other than the one
> # in which the failing gestalt('sysu') call (see below)
> # is first executed.
> 
> # Enabling any of these imports can trigger the problem
> # as each one imports the next one down in the list.
> # This will happen only with pkg_resources v0.6c10 or later
> # although it's not pkg_resources' fault.
> # import matplotlib.figure
> # import matplotlib.axes
> # import matplotlib.dates
> # import pytz
> # import pkg_resources
> 
> # The next import alone doesn't lead to failure,
> # but the function call does.
> # This same code is executed by pkg_resources starting
> # with setuptools v0.6c10.
> # from platform import mac_ver; mac_ver()
> 
> # The platform.mac_ver() call does the following, which
> # is what ultimately leads to the failure.  Calls
> # to gestalt() with 'sysa' (for example) do not
> # trigger the problem, either because the problem is
> # related to the 'sysu' itself, or to the fact that
> # an exception is raised because the selector "sysu"
> # is no longer recognized.
> from gestalt import gestalt
> try:
>     print gestalt('sysu')
> except Exception, ex:
>     print 'gestalt call failed'
> 
> if __name__ == '__main__':
>     def gui():
>         import wx
>         app = wx.App(False)
>         frame = wx.Frame(None)
>         wx.StaticText(frame, label='Goodbye, cruel world')
>         frame.Show()
>         app.MainLoop()
> 
>     import threading
>     threading.Thread(target=gui).start()
> 
> 
> 
> 


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

Chris.Barker at noaa.gov

From nad at acm.org  Thu Feb  4 20:31:15 2010
From: nad at acm.org (Ned Deily)
Date: Thu, 04 Feb 2010 11:31:15 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
References: <4B6B0719.3000604@noaa.gov> <4B6B1BD4.8050406@noaa.gov>
Message-ID: <nad-FE9BB1.11311404022010@ger.gmane.org>

Note, Peter has opened a Python issue for the problem so it would be a 
good idea to document any additional information there:

http://bugs.python.org/issue7812

-- 
 Ned Deily,
 nad at acm.org


From aahz at pythoncraft.com  Thu Feb  4 20:34:43 2010
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 4 Feb 2010 11:34:43 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <4B6B1BD4.8050406@noaa.gov>
References: <4B6B0719.3000604@noaa.gov> <4B6B1BD4.8050406@noaa.gov>
Message-ID: <20100204193443.GA27064@panix.com>

On Thu, Feb 04, 2010, Christopher Barker wrote:
>
> One more note from Peter:
>
> """
> We've used all four combinations of OSX 10.4/10.5 and Python 2.5/2.6.  
> I'm pretty sure even Python 3.1 would have the same problem (since the  
> platform.py module does the same calls).
>
> It seems to be independent of wxPython, other than that I'm using it to  
> show the symptom.
> """

That's different from my issue, which only shows up on 10.6/Show Leopard.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

import antigravity

From hengist.podd at virgin.net  Fri Feb  5 13:01:46 2010
From: hengist.podd at virgin.net (has)
Date: Fri, 5 Feb 2010 12:01:46 +0000
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <mailman.42.1265367604.16460.pythonmac-sig@python.org>
References: <mailman.42.1265367604.16460.pythonmac-sig@python.org>
Message-ID: <297FFC17-FFEE-4334-85A7-815D522C1D78@virgin.net>

Christopher Barker wrote:

> Peter Hanson, on the wxPython list, seems to have identified a bug in the gestalt module, that may be a Carbon issue. It's a bit of an unusual case: it freezes up wxPython, when wx is called from other than the main thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is calling Carbon, and doing so in the main thread, so you are then trying to call Carbon from more than one thread, which may be the cause of the problem. I've confirmed that if you call gestalt from the same thread as wxPython, there is no failure.

Is wx/Mac not already built upon Carbon/Cocoa APIs? Cocoa's GUI APIs certainly aren't thread-safe - all calls must go through the main thread - and I doubt Carbon's GUI APIs are any different. So I'd hazard that Peter's just run afoul of that fundamental limitation of OS X's GUI APIs, and it's purely dumb luck that it didn't happen sooner. In which case, I think the only sensible solution is to rework his application code to ensure all GUI calls are made on the main thread, as I doubt the situation will improve any as wx moves to Cocoa.


> As Carbon is deprecated anyway, I guess it's time for gestalt ( or platform.mac_ver ) to be re-written


Python's Carbon modules are deprecated in 2.x and gone in 3.x, so its Carbon.gestalt module is a dead end for Python users. Mac OS X's gestalt APIs are not deprecated, however, so I don't see why platform.mac_ver would need changed.

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From ronaldoussoren at mac.com  Fri Feb  5 13:24:12 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 05 Feb 2010 13:24:12 +0100
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <101597280815443943223345633256075470937-Webmail@me.com>
References: <101597280815443943223345633256075470937-Webmail@me.com>
Message-ID: <142515694636891894926660879698801391930-Webmail@me.com>

 
On Friday, February 05, 2010, at 01:01PM, "has" <hengist.podd at virgin.net> wrote:
>Christopher Barker wrote:
>
>> Peter Hanson, on the wxPython list, seems to have identified a bug in the gestalt module, that may be a Carbon issue. It's a bit of an unusual case: it freezes up wxPython, when wx is called from other than the main thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is calling Carbon, and doing so in the main thread, so you are then trying to call Carbon from more than one thread, which may be the cause of the problem. I've confirmed that if you call gestalt from the same thread as wxPython, there is no failure.
>
>Is wx/Mac not already built upon Carbon/Cocoa APIs? Cocoa's GUI APIs certainly aren't thread-safe - all calls must go through the main thread - and I doubt Carbon's GUI APIs are any different. So I'd hazard that Peter's just run afoul of that fundamental limitation of OS X's GUI APIs, and it's purely dumb luck that it didn't happen sooner. In which case, I think the only sensible solution is to rework his application code to ensure all GUI calls are made on the main thread, as I doubt the situation will improve any as wx moves to Cocoa.

That's what I thought as well, Cocoa requires that GUI calls are made on the main thread.  There are some calls that are allowed on a secondary thread, but most of them require that the main thread runs a runloop as well.

<http://developer.apple.com/mac/library/documentation/cocoa/conceptual/Multithreading/AboutThreads/AboutThreads.html> seems to suggest that you can call Carbon APIs from a thread other than the main thread (that's the only way "Threads and Your User Interface" makes sense).

This means that creating the GUI in a secondairy thread may be safe for wx/Carbon, but will definitly break in wx/Cocoa. 
>
>
>> As Carbon is deprecated anyway, I guess it's time for gestalt ( or platform.mac_ver ) to be re-written
>
>
>Python's Carbon modules are deprecated in 2.x and gone in 3.x, so its Carbon.gestalt module is a dead end for Python users. Mac OS X's gestalt APIs are not deprecated, however, so I don't see why platform.mac_ver would need changed.

I will remove the offending gestalt call for 2.7 and 3.2 because the result isn't used on any supported platform. I might backport that change to 2.6 and 3.1.  The gestalt bindings won't go away.

Ronald


From hengist.podd at virgin.net  Fri Feb  5 14:39:31 2010
From: hengist.podd at virgin.net (has)
Date: Fri, 5 Feb 2010 13:39:31 +0000
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <142515694636891894926660879698801391930-Webmail@me.com>
References: <101597280815443943223345633256075470937-Webmail@me.com>
	<142515694636891894926660879698801391930-Webmail@me.com>
Message-ID: <ECF58009-E119-47E3-A216-14E295016693@virgin.net>


On Feb 5, 2010, at 12:24 PM, Ronald Oussoren wrote:

>> Is wx/Mac not already built upon Carbon/Cocoa APIs? Cocoa's GUI APIs certainly aren't thread-safe - all calls must go through the main thread - and I doubt Carbon's GUI APIs are any different. [...]
> 
> That's what I thought as well, Cocoa requires that GUI calls are made on the main thread.  There are some calls that are allowed on a secondary thread, but most of them require that the main thread runs a runloop as well.
> 
> <http://developer.apple.com/mac/library/documentation/cocoa/conceptual/Multithreading/AboutThreads/AboutThreads.html> seems to suggest that you can call Carbon APIs from a thread other than the main thread (that's the only way "Threads and Your User Interface" makes sense).

Reading that section, I'm not sure it does. It starts by talking about GUI APIs in general, then goes onto discussing QuickTime APIs. But while the QT APIs may deal with audio-visual resources, most aren't responsible for displaying them on screen, so I think maybe they have their messages crossed a bit.

Anyway, I think it's the case that unless Apple's documentation explicitly states that a given API is thread-safe, you should assume it isn't. Some are, some aren't; it's my impression that GUI-related APIs tend to fall in the latter camp, which seems not unreasonable when you consider how they work. Though I still reckon redesigning the code to do all GUI stuff on the main thread will be the best solution for the OP, painful as that might be.

Regards,

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From Chris.Barker at noaa.gov  Fri Feb  5 18:59:36 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Fri, 05 Feb 2010 09:59:36 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <297FFC17-FFEE-4334-85A7-815D522C1D78@virgin.net>
References: <mailman.42.1265367604.16460.pythonmac-sig@python.org>
	<297FFC17-FFEE-4334-85A7-815D522C1D78@virgin.net>
Message-ID: <4B6C5C88.1090704@noaa.gov>

has wrote:
> Is wx/Mac not already built upon Carbon/Cocoa APIs?

umm -- I'm not sure what that means... anyway:

The current wxMac is built on Carbon. The "unstable" version is built on 
Cocoa. The Cocoa version does not yet have wxPython bindings, and I'm 
not sure when it will be considered production ready/stable. But it will 
have to get there, as we all know that Carbon has been deprecated. So, 
for now, Carbon has to work, but in the future (for Python 3, for 
example), Cocoa-only is the way to go.

 > Cocoa's GUI APIs
> certainly aren't thread-safe - all calls must go through the main
> thread - and I doubt Carbon's GUI APIs are any different.

Well, we need to be clear about what thread-safe means. None of the wx 
back-ends are thread safe, I don't know if any GUI toolkit is -- it 
would be nice, but I guess it's just too hard. However, with wx, 
not-thread-safe means that all call must go through the SAME thread, 
which may NOT be the MAIN thread.

This is very useful for things like iPython, that let you run an 
interactive interpreter in the main thread, and all the gui calls are 
run in another (but all the same one) thread, so you can have an 
interactive interpreter, and GUI display. This is great for doing 
interactive plotting with matplotlib, for instance.

Do you really think that Cocoa does not support that? I know there is a 
Cocoa back-end for Matplotlib, though I don't know for sure if anyone is 
using with with iPython.


 > I think the only sensible solution is to
> rework his application code to ensure all GUI calls are made on the
> main thread,

I don't know why Peter is not running his GUI on the main thread, but as 
I've explained above, there are reasons not to.

If Robin Dunn is right, then a call to gestalt() is initializing enough 
of carbon in the main thread to break things later. This call wx made 
through platform.mac_ver, which was called by something in setuptools, 
which the OP has little control over. It seems to be that there should 
be a way to find out about the platform you are running on without 
initializing the GUI.

> Python's Carbon modules are deprecated in 2.x and gone in 3.x, so its
> Carbon.gestalt module is a dead end for Python users.

and yet that is what is being called by platform.mac_ver(), and thus by 
setuptools. Hence the problem.

> Mac OS X's gestalt APIs are not deprecated, however,

Then those should be used by platform.mac_ver

Ronald Oussoren wrote:

> This means that creating the GUI in a secondairy thread may be safe
> for wx/Carbon, but will definitly break in wx/Cocoa.

ouch! really? That is a major limitation -- are you sure that "main 
thread" really means main thread of the application, rather than "the 
thread the Cocoa was initialized in?"

> I will remove the offending gestalt call for 2.7 and 3.2 because the
> result isn't used on any supported platform. I might backport that
> change to 2.6 and 3.1.  The gestalt bindings won't go away.

Does this mean that you'll use the native OS-X gestalt calls, rather 
than the Carbon ones? Wouldn't that be required for 64 bit to work, anyway?

That would be great, and, I think, solve the problem at hand. We'll have 
to see about wxCocoa....

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

Chris.Barker at noaa.gov

From t.greenwoodgeer at gmail.com  Fri Feb  5 22:32:43 2010
From: t.greenwoodgeer at gmail.com (Todd)
Date: Fri, 05 Feb 2010 13:32:43 -0800
Subject: [Pythonmac-SIG] trouble getting window bounds via appscript
Message-ID: <4B6C8E7B.8000105@gmail.com>

I'd like to perform some window management via appscript on Mac OSX 
(10.6.2).

This is pretty straightforward using AppleScript (see code#1 below). 
However, my attempts to perform the same tasks in python appscript have 
failed:

1. get bounds of display
2. get bounds of foreground process

I can query the 'System Events' for the process list, and get the 
foremost process...however, I cannot get the bounds from the windows. 
(see code#2 below).

The appscript error is:
------------------------------------------------
CommandError: Command failed:
                 OSERROR: -1728
                 MESSAGE: Can't get reference.
                 OFFENDING OBJECT: 
app(u'/System/Library/CoreServices/System 
Events.app').application_processes[u'iTerm'].windows[u'todd at greenmachine: ~/Documents/projects/python/windowmanager'].bounds
                 COMMAND: app(u'/System/Library/CoreServices/System 
Events.app').application_processes[u'iTerm'].windows[u'todd at greenmachine: ~/Documents/projects/python/windowmanager'].bounds.get()
------------------------------------------------

Any advice out there?

-Todd



CODE#1 (AppleScript)
--------------------
"""
# no idea how to do this in appscript
tell application "Finder"
	set _b to bounds of window of desktop
	set display_x_size to item 3 of _b
	set display_y_size to item 4 of _b
end tell

# should be able to do this in appscript, but doesn't work
tell application cur_app
	tell front window
		set {x1, y1, x2, y2} to (get bounds)
	end tell
end tell
"""

CODE#2 (python appscript)
--------------------
"""
#! /Library/Frameworks/Python.framework/Versions/2.6/bin/python

# get the appscript bridge
from appscript import *

# define the service event
se = app(u'System Events')

import pdb


class WindowManager:
         def dumpWindowBounds(self):
                 for app in se.processes.get():
                         for win in app.windows.get():
                                 print win, win.bounds.get()

if __name__ == "__main__":
         wm = WindowManager()
         wm.dumpWindowBounds()

"""

From ronaldoussoren at mac.com  Fri Feb  5 22:33:44 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 05 Feb 2010 22:33:44 +0100
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <4B6C5C88.1090704@noaa.gov>
References: <mailman.42.1265367604.16460.pythonmac-sig@python.org>
	<297FFC17-FFEE-4334-85A7-815D522C1D78@virgin.net>
	<4B6C5C88.1090704@noaa.gov>
Message-ID: <A9A23E8C-9A61-4647-9CF1-305BE05A2343@mac.com>




On 5 feb 2010, at 18:59, Christopher Barker <Chris.Barker at noaa.gov>  
wrote:

>
> > Cocoa's GUI APIs
>> certainly aren't thread-safe - all calls must go through the main
>> thread - and I doubt Carbon's GUI APIs are any different.
>
> Well, we need to be clear about what thread-safe means. None of the  
> wx back-ends are thread safe, I don't know if any GUI toolkit is --  
> it would be nice, but I guess it's just too hard. However, with wx,  
> not-thread-safe means that all call must go through the SAME thread,  
> which may NOT be the MAIN thread.
>
> This is very useful for things like iPython, that let you run an  
> interactive interpreter in the main thread, and all the gui calls  
> are run in another (but all the same one) thread, so you can have an  
> interactive interpreter, and GUI display. This is great for doing  
> interactive plotting with matplotlib, for instance.
>
> Do you really think that Cocoa does not support that? I know there  
> is a Cocoa back-end for Matplotlib, though I don't know for sure if  
> anyone is using with with iPython.

Cocoa does not support this, the main thread has special signifance  
and the GUI runloop must be in that thread.

Ronald

>

From nad at acm.org  Fri Feb  5 23:21:07 2010
From: nad at acm.org (Ned Deily)
Date: Fri, 05 Feb 2010 14:21:07 -0800
Subject: [Pythonmac-SIG] trouble getting window bounds via appscript
References: <4B6C8E7B.8000105@gmail.com>
Message-ID: <nad-9226FB.14210605022010@ger.gmane.org>

In article <4B6C8E7B.8000105 at gmail.com>,
 Todd <t.greenwoodgeer at gmail.com> wrote:
> I'd like to perform some window management via appscript on Mac OSX 
> (10.6.2).
> 
> This is pretty straightforward using AppleScript (see code#1 below). 
> However, my attempts to perform the same tasks in python appscript have 
> failed:
> 
> 1. get bounds of display
> 2. get bounds of foreground process
> 
> I can query the 'System Events' for the process list, and get the 
> foremost process...however, I cannot get the bounds from the windows. 
> (see code#2 below).
> 
> The appscript error is:
> ------------------------------------------------
> CommandError: Command failed:
>                  OSERROR: -1728
>                  MESSAGE: Can't get reference.
>                  OFFENDING OBJECT: 
> app(u'/System/Library/CoreServices/System 
> Events.app').application_processes[u'iTerm'].windows[u'todd at greenmachine: 

You need to get a windows reference from each application's object, not 
from a System Events app object:

>>> bounds_tuple = app('Terminal').windows.first.bounds()
>>> print bounds_tuple
(675, 310, 1330, 820)

-- 
 Ned Deily,
 nad at acm.org


From t.greenwoodgeer at gmail.com  Sat Feb  6 07:39:40 2010
From: t.greenwoodgeer at gmail.com (Todd)
Date: Fri, 05 Feb 2010 22:39:40 -0800
Subject: [Pythonmac-SIG] trouble getting window bounds via appscript
In-Reply-To: <nad-9226FB.14210605022010@ger.gmane.org>
References: <4B6C8E7B.8000105@gmail.com>
	<nad-9226FB.14210605022010@ger.gmane.org>
Message-ID: <4B6D0EAC.6090807@gmail.com>

Ned,
Thanks! That unblocked me. I changed my code to enumerate over the 
applications, and then create an app instance from that.

// get the front most app from system events
se_app_name = se.processes...name.get()

// get the actual application
real_app = app(se_app_name)

// get the windows for the app
real_app.windows()

etc.

Works like a charm, tho some apps, like firefox, have a System Event 
name that I cannot simply call 'app(name)' on. I'll sort that out later.

Thanks again.
-Todd

On 2/5/10 2:21 PM, Ned Deily wrote:
> In article<4B6C8E7B.8000105 at gmail.com>,
>   Todd<t.greenwoodgeer at gmail.com>  wrote:
>> I'd like to perform some window management via appscript on Mac OSX
>> (10.6.2).
>>
>> This is pretty straightforward using AppleScript (see code#1 below).
>> However, my attempts to perform the same tasks in python appscript have
>> failed:
>>
>> 1. get bounds of display
>> 2. get bounds of foreground process
>>
>> I can query the 'System Events' for the process list, and get the
>> foremost process...however, I cannot get the bounds from the windows.
>> (see code#2 below).
>>
>> The appscript error is:
>> ------------------------------------------------
>> CommandError: Command failed:
>>                   OSERROR: -1728
>>                   MESSAGE: Can't get reference.
>>                   OFFENDING OBJECT:
>> app(u'/System/Library/CoreServices/System
>> Events.app').application_processes[u'iTerm'].windows[u'todd at greenmachine:
>
> You need to get a windows reference from each application's object, not
> from a System Events app object:
>
>>>> bounds_tuple = app('Terminal').windows.first.bounds()
>>>> print bounds_tuple
> (675, 310, 1330, 820)
>

From skip at pobox.com  Sat Feb  6 21:13:04 2010
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 6 Feb 2010 14:13:04 -0600
Subject: [Pythonmac-SIG] Test message ... please ignore
Message-ID: <19309.52560.70436.394694@montanaro.dyndns.org>


Testing a change to the footer.  You can ignore.

Skip

From email-reply-2 at danrabin.com  Wed Feb  3 03:24:51 2010
From: email-reply-2 at danrabin.com (Dan Rabin)
Date: Tue, 2 Feb 2010 18:24:51 -0800
Subject: [Pythonmac-SIG] problem running py2app
In-Reply-To: <loom.20100203T002200-837@post.gmane.org>
References: <86D3A325-7304-4FA8-879D-2E9E906AC47C@gmail.com>
	<loom.20100203T002200-837@post.gmane.org>
Message-ID: <1c052e511002021824n1a10259fh6ddc27e94cd0f5ac@mail.gmail.com>

I've tracked that down to a 32-vs-64-bit issue with some versions of
macholib.  I have found that the version that comes with py2app 0.4.4 works
for me now on an Intel Mac running 10.6.  IIRC the version from macports
isn't that recent.

  -- Dan Rabin

On Tue, Feb 2, 2010 at 3:24 PM, William R. Dickson
<lackey at manoutoftime.org>wrote:

> Attila Tajti <attila.tajti <at> gmail.com> writes:
>
> > error: unpack requires a string argument of length 8
> > > /Users/ata/Projects/MailArchiveButton/build/bdist.macosx-10.6-
> universal/egg/macholib/ptypes.py(48)from_str()
> > (Pdb) ^D
>
> I'm getting the same error on my first attempt to build an app. Did
> you get any response to this question?
>
> Thanks,
>
> -Bill
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100202/750befaf/attachment.htm>

From ronaldoussoren at mac.com  Sun Feb  7 11:30:15 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 07 Feb 2010 11:30:15 +0100
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <20100204175947.GB4548@panix.com>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
Message-ID: <3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>


On 4 Feb, 2010, at 18:59, Aahz wrote:

> On Thu, Feb 04, 2010, Christopher Barker wrote:
>> 
>> Peter Hanson, on the wxPython list, seems to have identified a bug in  
>> the gestalt module, that may be a Carbon issue. It's a bit of an unusual  
>> case: it freezes up wxPython, when wx is called from other than the main  
>> thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is  
>> calling Carbon, and doing so in the main thread, so you are then trying  
>> to call Carbon from more than one thread, which may be the cause of the  
>> problem. I've confirmed that if you call gestalt from the same thread as  
>> wxPython, there is no failure.
> 
> I've already complained that mac_ver() causes a crash with
> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
> but I'm pretty sure we're not using wx on Mac, just Windows (we're using
> AppHelper).

Have you filed a bug about that?  Not that doing that in the python.org tracker would result result in a satisfying resolution: mac_ver calls OSX APIs that don't work in child processes created with fork (but without exec) and that cannot be changed. This was safe in 10.5 and earlier as well,  10.6 is the first version that loudly complains that you do something unsafe. 

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100207/238e2c7f/attachment.bin>

From aahz at pythoncraft.com  Sun Feb  7 15:30:04 2010
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 7 Feb 2010 06:30:04 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
	<3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
Message-ID: <20100207143004.GA11255@panix.com>

On Sun, Feb 07, 2010, Ronald Oussoren wrote:
> On 4 Feb, 2010, at 18:59, Aahz wrote:
>> On Thu, Feb 04, 2010, Christopher Barker wrote:
>>> 
>>> Peter Hanson, on the wxPython list, seems to have identified a bug in  
>>> the gestalt module, that may be a Carbon issue. It's a bit of an unusual  
>>> case: it freezes up wxPython, when wx is called from other than the main  
>>> thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is  
>>> calling Carbon, and doing so in the main thread, so you are then trying  
>>> to call Carbon from more than one thread, which may be the cause of the  
>>> problem. I've confirmed that if you call gestalt from the same thread as  
>>> wxPython, there is no failure.
>> 
>> I've already complained that mac_ver() causes a crash with
>> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
>> but I'm pretty sure we're not using wx on Mac, just Windows (we're using
>> AppHelper).
> 
> Have you filed a bug about that?  Not that doing that in the
> python.org tracker would result result in a satisfying resolution:
> mac_ver calls OSX APIs that don't work in child processes created with
> fork (but without exec) and that cannot be changed. This was safe
> in 10.5 and earlier as well, 10.6 is the first version that loudly
> complains that you do something unsafe.

Not yet, I was hoping someone else could confirm the bug before filing.
If you think I should go ahead and file it, I will.  Do you know of any
other way to get the info that gestalt provides?  Are you saying that if
I called mac_ver() in the startup process it should work?
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

import antigravity

From Chris.Barker at noaa.gov  Mon Feb  8 07:27:45 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sun, 07 Feb 2010 22:27:45 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <A9A23E8C-9A61-4647-9CF1-305BE05A2343@mac.com>
References: <mailman.42.1265367604.16460.pythonmac-sig@python.org>
	<297FFC17-FFEE-4334-85A7-815D522C1D78@virgin.net>
	<4B6C5C88.1090704@noaa.gov>
	<A9A23E8C-9A61-4647-9CF1-305BE05A2343@mac.com>
Message-ID: <4B6FAEE1.1030304@noaa.gov>

Ronald Oussoren wrote:
>> This is very useful for things like iPython, that let you run an 
>> interactive interpreter in the main thread, and all the gui calls are 
>> run in another (but all the same one) thread, so you can have an 
>> interactive interpreter, and GUI display. This is great for doing 
>> interactive plotting with matplotlib, for instance.
>>
>> Do you really think that Cocoa does not support that? I know there is 
>> a Cocoa back-end for Matplotlib, though I don't know for sure if 
>> anyone is using with with iPython.
> 
> Cocoa does not support this, the main thread has special signifance and 
> the GUI runloop must be in that thread.

Darn. well, it will be interesting to see how this plays out then 
wxCocoa starts seeing wider use.

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

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Tue Feb  9 09:14:19 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 09 Feb 2010 09:14:19 +0100
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <20100207143004.GA11255@panix.com>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
	<3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
	<20100207143004.GA11255@panix.com>
Message-ID: <69F4EAEF-83DF-4394-8844-C717AB499628@mac.com>


On 7 Feb, 2010, at 15:30, Aahz wrote:

> On Sun, Feb 07, 2010, Ronald Oussoren wrote:
>> On 4 Feb, 2010, at 18:59, Aahz wrote:
>>> On Thu, Feb 04, 2010, Christopher Barker wrote:
>>>> 
>>>> Peter Hanson, on the wxPython list, seems to have identified a bug in  
>>>> the gestalt module, that may be a Carbon issue. It's a bit of an unusual  
>>>> case: it freezes up wxPython, when wx is called from other than the main  
>>>> thread. Robin Dunn suspects that it's a Carbon issue -- gestalt is  
>>>> calling Carbon, and doing so in the main thread, so you are then trying  
>>>> to call Carbon from more than one thread, which may be the cause of the  
>>>> problem. I've confirmed that if you call gestalt from the same thread as  
>>>> wxPython, there is no failure.
>>> 
>>> I've already complained that mac_ver() causes a crash with
>>> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
>>> but I'm pretty sure we're not using wx on Mac, just Windows (we're using
>>> AppHelper).
>> 
>> Have you filed a bug about that?  Not that doing that in the
>> python.org tracker would result result in a satisfying resolution:
>> mac_ver calls OSX APIs that don't work in child processes created with
>> fork (but without exec) and that cannot be changed. This was safe
>> in 10.5 and earlier as well, 10.6 is the first version that loudly
>> complains that you do something unsafe.
> 
> Not yet, I was hoping someone else could confirm the bug before filing.
> If you think I should go ahead and file it, I will.  

Filing a bug would help remind me that someone ran into an issue. I won't be able to fix the gestalt issue itself, but it is possible to work around it by calling different APIs to fetch the required information.

> Do you know of any
> other way to get the info that gestalt provides?  

That depends on what you want to know. Platform.mac_ver returns three values: system version, release info and CPU architecture. The second one is always ('', '', '') on OSX and can be ignored.

The system version can also be read from /System/Library/CoreServices/SystemVersion.plist

The CPU architecture can also be deduced from sys.byteorder (if that's "little" your on i386, otherwise you're on ppc). 



> Are you saying that if
> I called mac_ver() in the startup process it should work?

Calling mac_ver() in the startup process is safe.  The problem only affects child processes started using fork without exec.

Ronald
> -- 
> Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/
> 
> import antigravity
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100209/57eb4e57/attachment.bin>

From Chris.Barker at noaa.gov  Tue Feb  9 18:21:02 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 09 Feb 2010 09:21:02 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <69F4EAEF-83DF-4394-8844-C717AB499628@mac.com>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
	<3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
	<20100207143004.GA11255@panix.com>
	<69F4EAEF-83DF-4394-8844-C717AB499628@mac.com>
Message-ID: <4B71997E.907@noaa.gov>

Ronald Oussoren wrote:
> The CPU architecture can also be deduced from sys.byteorder (if that's "little" your on i386, otherwise you're on ppc). 

what about 32 vs 64 bit? Should that be reported by mac_ver() ?

Anyway, it looks like it would be pretty easy to re-write mac_ver().

-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

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Tue Feb  9 19:45:48 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 09 Feb 2010 19:45:48 +0100
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <4B71997E.907@noaa.gov>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
	<3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
	<20100207143004.GA11255@panix.com>
	<69F4EAEF-83DF-4394-8844-C717AB499628@mac.com> <4B71997E.907@noaa.gov>
Message-ID: <E94F788B-542C-4294-B37D-A9FA9076F05E@mac.com>


On 9 Feb, 2010, at 18:21, Christopher Barker wrote:

> Ronald Oussoren wrote:
>> The CPU architecture can also be deduced from sys.byteorder (if that's "little" your on i386, otherwise you're on ppc). 
> 
> what about 32 vs 64 bit? Should that be reported by mac_ver() ?

Mac_ver currently doesn't report that, the result is always the 32-bit variation of the code that is running (that is, a ppc executable will always see ppc as the machine type, even when running on an Intel mac).

> 
> Anyway, it looks like it would be pretty easy to re-write mac_ver().

Yes, and a bugreport with a patch would be appreciated (preferably before the start of 2.7 beta releases, that makes would make it easier to get the patch in).

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100209/d10637ef/attachment.bin>

From aahz at pythoncraft.com  Tue Feb  9 20:02:13 2010
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 9 Feb 2010 11:02:13 -0800
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <69F4EAEF-83DF-4394-8844-C717AB499628@mac.com>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
	<3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
	<20100207143004.GA11255@panix.com>
	<69F4EAEF-83DF-4394-8844-C717AB499628@mac.com>
Message-ID: <20100209190213.GA8139@panix.com>

On Tue, Feb 09, 2010, Ronald Oussoren wrote:
> On 7 Feb, 2010, at 15:30, Aahz wrote:
>> On Sun, Feb 07, 2010, Ronald Oussoren wrote:
>>> On 4 Feb, 2010, at 18:59, Aahz wrote:
>>>>
>>>> I've already complained that mac_ver() causes a crash with
>>>> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
>>>> but I'm pretty sure we're not using wx on Mac, just Windows (we're using
>>>> AppHelper).
>>> 
>>> Have you filed a bug about that?  Not that doing that in the
>>> python.org tracker would result result in a satisfying resolution:
>>> mac_ver calls OSX APIs that don't work in child processes created with
>>> fork (but without exec) and that cannot be changed. This was safe
>>> in 10.5 and earlier as well, 10.6 is the first version that loudly
>>> complains that you do something unsafe.
>> 
>> Not yet, I was hoping someone else could confirm the bug before filing.
>> If you think I should go ahead and file it, I will.  
> 
> Filing a bug would help remind me that someone ran into an issue. I
> won't be able to fix the gestalt issue itself, but it is possible
> to work around it by calling different APIs to fetch the required
> information.

http://bugs.python.org/issue7895

>> Do you know of any other way to get the info that gestalt provides?
>
> The system version can also be read from
> /System/Library/CoreServices/SystemVersion.plist

Thanks!

> The CPU architecture can also be deduced from sys.byteorder (if that's
> "little" your on i386, otherwise you're on ppc).

os.uname() seems to provide much of that info.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just        
refer to comments in code as 'lies'. :-)"

From barry at barrys-emacs.org  Wed Feb 10 00:44:54 2010
From: barry at barrys-emacs.org (Barry Scott)
Date: Tue, 9 Feb 2010 23:44:54 +0000
Subject: [Pythonmac-SIG] py2app missing import statement
Message-ID: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>

I've just started looking at py2app and I hit a problem with it failing to find
an import.

With a trivial program like:

---- a.py ----
import _bemacs
---------------

py2app does not include _bemacs. _bemacs is an extension in _bemacs.so.
Python can import this and it all works fine.

The xref output show that a.py does not import any thing.
I can find no message in the output abnout _bemacs.

Why is py2app unable to notice this import?

Barry


From barry at barrys-emacs.org  Wed Feb 10 10:48:49 2010
From: barry at barrys-emacs.org (Barry Scott)
Date: Wed, 10 Feb 2010 09:48:49 +0000
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
Message-ID: <1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>


On 9 Feb 2010, at 23:44, Barry Scott wrote:

> I've just started looking at py2app and I hit a problem with it failing to find
> an import.
> 
> With a trivial program like:
> 
> ---- a.py ----
> import _bemacs
> ---------------
> 
> py2app does not include _bemacs. _bemacs is an extension in _bemacs.so.
> Python can import this and it all works fine.
> 
> The xref output show that a.py does not import any thing.
> I can find no message in the output abnout _bemacs.
> 
> Why is py2app unable to notice this import?

I made a mistake and got my PYTHONPATH wrong hence
_bemacs cannot be found.

I guess that in the face of an import that cannot be found
py2app simply ignores it. What would be useful is to have
a message saying the import cannot be found.

I realise that this can lead to false positive messages
but it would be useful to point to errors.

Barry


From Chris.Barker at noaa.gov  Wed Feb 10 18:11:36 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 10 Feb 2010 09:11:36 -0800
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
	<1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
Message-ID: <4B72E8C8.6070404@noaa.gov>

Barry Scott wrote:
> I made a mistake and got my PYTHONPATH wrong hence
> _bemacs cannot be found.
> 
> I guess that in the face of an import that cannot be found
> py2app simply ignores it. What would be useful is to have
> a message saying the import cannot be found.
> 
> I realise that this can lead to false positive messages
> but it would be useful to point to errors.

I agree -- it really should issue a warning or something.

You can post a bug report/feature request on the pyobjc project at one 
at Sourceforge.

-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

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Thu Feb 11 13:06:15 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 11 Feb 2010 13:06:15 +0100
Subject: [Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug
In-Reply-To: <20100209190213.GA8139@panix.com>
References: <4B6B0719.3000604@noaa.gov> <20100204175947.GB4548@panix.com>
	<3D99B8F8-59BA-4F57-AA3E-14BEF7432E3C@mac.com>
	<20100207143004.GA11255@panix.com>
	<69F4EAEF-83DF-4394-8844-C717AB499628@mac.com>
	<20100209190213.GA8139@panix.com>
Message-ID: <8B48765D-F451-4618-9F0F-A7208B8900D3@mac.com>


On 9 Feb, 2010, at 20:02, Aahz wrote:
> 
> 
>> The CPU architecture can also be deduced from sys.byteorder (if that's
>> "little" your on i386, otherwise you're on ppc).
> 
> os.uname() seems to provide much of that info.

It does, and I hadn't expected that.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100211/1278b1f3/attachment.bin>

From ronaldoussoren at mac.com  Thu Feb 11 13:10:16 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 11 Feb 2010 13:10:16 +0100
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <4B72E8C8.6070404@noaa.gov>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
	<1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
	<4B72E8C8.6070404@noaa.gov>
Message-ID: <097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>


On 10 Feb, 2010, at 18:11, Christopher Barker wrote:

> Barry Scott wrote:
>> I made a mistake and got my PYTHONPATH wrong hence
>> _bemacs cannot be found.
>> I guess that in the face of an import that cannot be found
>> py2app simply ignores it. What would be useful is to have
>> a message saying the import cannot be found.
>> I realise that this can lead to false positive messages
>> but it would be useful to point to errors.
> 
> I agree -- it really should issue a warning or something.

It does print a warning, but one that's hidden in a lot of noise. Py2app currently logs everything it does, and that's mostly completely uninteresting.

> 
> You can post a bug report/feature request on the pyobjc project at one at Sourceforge.

And ideally you should include a patch. In this case that would be a patch that disables most of the logging in py2app (or rather replaces it with must more succint logging "building bundle", "copying python files", ...)

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100211/e2c9fe31/attachment.bin>

From Chris.Barker at noaa.gov  Thu Feb 11 19:57:10 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 11 Feb 2010 10:57:10 -0800
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
	<1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
	<4B72E8C8.6070404@noaa.gov>
	<097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>
Message-ID: <4B745306.8020009@noaa.gov>

Ronald Oussoren wrote:
> On 10 Feb, 2010, at 18:11, Christopher Barker wrote:
>> I agree -- it really should issue a warning or something.
> 
> It does print a warning, but one that's hidden in a lot of noise. Py2app currently logs everything it does, and that's mostly completely uninteresting.

Are you sure? That's what I assumed at first, but I did a test, and 
couldn't find a warning anywhere. I've enclosed my test and the py2app 
output. It's as simple as it gets:


#!/usr/bin/python

# this is a test of what happens when you try to use py2app when you 
can't find a module

import Some_non_existant_module

print "This works!"




I don't see any mention of a problem in the output, and when you run the 
resulting bundle, you get an import error, of course.

But in any case, having a less-verbose output option would be nice.

-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

Chris.Barker at noaa.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test.py
Type: application/x-python
Size: 163 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100211/dc66e406/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: application/x-python
Size: 306 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100211/dc66e406/attachment-0003.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100211/dc66e406/attachment-0001.txt>

From barry at barrys-emacs.org  Fri Feb 12 09:49:36 2010
From: barry at barrys-emacs.org (Barry Scott)
Date: Fri, 12 Feb 2010 08:49:36 +0000
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
	<1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
	<4B72E8C8.6070404@noaa.gov>
	<097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>
Message-ID: <F8185032-83F0-48FE-9487-7AC97BAC9C82@barrys-emacs.org>


On 11 Feb 2010, at 12:10, Ronald Oussoren wrote:

> 
> On 10 Feb, 2010, at 18:11, Christopher Barker wrote:
> 
>> Barry Scott wrote:
>>> I made a mistake and got my PYTHONPATH wrong hence
>>> _bemacs cannot be found.
>>> I guess that in the face of an import that cannot be found
>>> py2app simply ignores it. What would be useful is to have
>>> a message saying the import cannot be found.
>>> I realise that this can lead to false positive messages
>>> but it would be useful to point to errors.
>> 
>> I agree -- it really should issue a warning or something.
> 
> It does print a warning, but one that's hidden in a lot of noise. Py2app currently logs everything it does, and that's mostly completely uninteresting.

No it does not as Christ has confirmed.

> 
>> 
>> You can post a bug report/feature request on the pyobjc project at one at Sourceforge.
> 
> And ideally you should include a patch. In this case that would be a patch that disables most of the logging in py2app (or rather replaces it with must more succint logging "building bundle", "copying python files", ...)

And the messages should clearly show their severity. I use prefixes of Info: Warn: and Error: myself.

I have code in MEINC_Installer (http://sourceforge.net/projects/meinc-installer/) that knows which
imports are version and platform specific to filter out the noise you get when all missing imports
are printed.

See http://meinc-installer.svn.sourceforge.net/viewvc/meinc-installer/trunk/MEINC_Installer/Common/check_warning_file.py?revision=9&view=markup

This script is run over the output of MEINC installer to only tell you about genuine missing imports.

Barry


From Chris.Barker at noaa.gov  Fri Feb 12 18:17:24 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Fri, 12 Feb 2010 09:17:24 -0800
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <F8185032-83F0-48FE-9487-7AC97BAC9C82@barrys-emacs.org>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
	<1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
	<4B72E8C8.6070404@noaa.gov>
	<097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>
	<F8185032-83F0-48FE-9487-7AC97BAC9C82@barrys-emacs.org>
Message-ID: <4B758D24.4090902@noaa.gov>

Barry Scott wrote:
> And the messages should clearly show their severity. I use prefixes of Info: Warn: and Error: myself.

as they say : patches welcome!

> I have code in MEINC_Installer (http://sourceforge.net/projects/meinc-installer/)

Well, I've thought for ages that it would be better to have a single 
executable building system that worked on all the major platforms. The 
actual executable building stage would have to unique, of course, but 
the module finding, etc could be the same.

Both bbfreeze and PyInstaller have a start of a Mac version, I don't 
know about MEINC_Installer.

It would be great if someone would work on one of those, or merge Py2app 
with one of them, or put some real work into py2App -- I wish I had more 
time and energy for it, but I don't.

-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

Chris.Barker at noaa.gov

From barry at barrys-emacs.org  Sat Feb 13 12:24:34 2010
From: barry at barrys-emacs.org (Barry Scott)
Date: Sat, 13 Feb 2010 11:24:34 +0000
Subject: [Pythonmac-SIG] py2app missing import statement
In-Reply-To: <4B758D24.4090902@noaa.gov>
References: <048E687E-97FA-4761-ABDF-078824BEF931@barrys-emacs.org>
	<1D6459C2-C5AE-4789-B652-C6BFE7267ED0@barrys-emacs.org>
	<4B72E8C8.6070404@noaa.gov>
	<097B05DF-4014-4A47-864A-4D373FA6B5AB@mac.com>
	<F8185032-83F0-48FE-9487-7AC97BAC9C82@barrys-emacs.org>
	<4B758D24.4090902@noaa.gov>
Message-ID: <B73C5960-EAA2-4E62-812F-EFC9E4B6068C@barrys-emacs.org>


On 12 Feb 2010, at 17:17, Christopher Barker wrote:

> Barry Scott wrote:
>> And the messages should clearly show their severity. I use prefixes of Info: Warn: and Error: myself.
> 
> as they say : patches welcome!

Like you have don't have the spare time work on this problem.

> 
>> I have code in MEINC_Installer (http://sourceforge.net/projects/meinc-installer/)
> 
> Well, I've thought for ages that it would be better to have a single executable building system that worked on all the major platforms. The actual executable building stage would have to unique, of course, but the module finding, etc could be the same.
> 
> Both bbfreeze and PyInstaller have a start of a Mac version, I don't know about MEINC_Installer.

MEINC_Installer is WIndows and unix only, because I use MEINC_Installer in many projects
I keep it going but have no plans to add Mac Support.


> 
> It would be great if someone would work on one of those, or merge Py2app with one of them, or put some real work into py2App -- I wish I had more time and energy for it, but I don't.

Sharing the common analysis code for a set of platform specific back ends would be a good solution.

Barry


From aahz at pythoncraft.com  Sun Feb 14 03:05:20 2010
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 13 Feb 2010 18:05:20 -0800
Subject: [Pythonmac-SIG] Python Complier
In-Reply-To: <83E275FF-F6C2-4BE3-A5C8-8C9B1B71D1F9@CPHSolutions.com>
References: <mailman.49.1263553203.1555.pythonmac-sig@python.org>
	<83E275FF-F6C2-4BE3-A5C8-8C9B1B71D1F9@CPHSolutions.com>
Message-ID: <20100214020520.GB25324@panix.com>

[late response]

On Fri, Jan 15, 2010, Chuck Hauge wrote:
>
>   File "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/util.py", line 101, in copy_file
>     zf, zp = path_to_zip(source)
>   File "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/util.py", line 133, in path_to_zip
>     raise DistutilsFileError(path)
> DistutilsFileError: /private/tmp/GNS3-0.7RC1-src
> > /Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/util.py(133)path_to_zip()
> -> raise DistutilsFileError(path)
> (Pdb) q
> Traceback (most recent call last):
>   File "/usr/local/bin/py2applet", line 8, in <module>
>     load_entry_point('py2app==0.4.3', 'console_scripts', 'py2applet')()
>   File "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/script_py2applet.py", line 134, in main
>     build(args, scripts, data_files, options)
>   File "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/script_py2applet.py", line 187, in build
>     target.appdir,
> AttributeError: 'Target' object has no attribute 'appdir'

This looks like setup.py for GNS3 is expecting to use a later setuptools
than what's in py2app 0.4.3 or is depending on a setuptools extension
(such as py2exe creates).  Try installing a later setuptools, maybe.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just        
refer to comments in code as 'lies'. :-)"

From news at xiao-yu.com  Mon Feb 15 03:37:42 2010
From: news at xiao-yu.com (Xiao Yu)
Date: Sun, 14 Feb 2010 21:37:42 -0500
Subject: [Pythonmac-SIG] py2app/PyQt/64-bit/Mach-O
In-Reply-To: <4B39356A.3080205@codebykevin.com>
References: <CFD3D91B-C056-48EF-BFB3-5BBF8155E31E@xiao-yu.com>	
	<4B1DB1B7.3080507@codebykevin.com>
	<65fadfc30912071913o33210161n24bde05ead131f03@mail.gmail.com>
	<4B1DC5C9.7070606@codebykevin.com>
	<A2BA838F-CCD1-4457-B74B-4A055F413592@acm.org>
	<4B38284F.4000203@codebykevin.com>
	<AFA59FEC-9234-46CD-9D8E-601A2A967B9B@acm.org>
	<4B38429B.90603@codebykevin.com>
	<C304A2EC-24D0-448B-993F-FA99D7DA2302@acm.org>
	<4B39356A.3080205@codebykevin.com>
Message-ID: <9F7A9897-9932-44B3-BD4D-46DADA6053F1@xiao-yu.com>

Old issue, but I pretty much gave up on Qt4, but I just realised that I can't even compile a one line program like print "hello".

running py2app
*** filtering dependencies ***
252 total
30 filtered
4 orphaned
222 remaining
*** create binaries ***
skipping python loader for extension '_AE'
skipping python loader for extension '_Evt'
skipping python loader for extension '_File'
skipping python loader for extension '_bisect'
skipping python loader for extension '_codecs_cn'
skipping python loader for extension '_codecs_hk'
skipping python loader for extension '_codecs_iso2022'
skipping python loader for extension '_codecs_jp'
skipping python loader for extension '_codecs_kr'
skipping python loader for extension '_codecs_tw'
skipping python loader for extension '_collections'
skipping python loader for extension '_functools'
skipping python loader for extension '_heapq'
skipping python loader for extension '_locale'
skipping python loader for extension '_multibytecodec'
skipping python loader for extension '_random'
skipping python loader for extension '_struct'
skipping python loader for extension '_weakref'
skipping python loader for extension 'array'
skipping python loader for extension 'binascii'
skipping python loader for extension 'bz2'
skipping python loader for extension 'cPickle'
skipping python loader for extension 'cStringIO'
skipping python loader for extension 'datetime'
skipping python loader for extension 'fcntl'
skipping python loader for extension 'itertools'
skipping python loader for extension 'math'
skipping python loader for extension 'operator'
skipping python loader for extension 'select'
skipping python loader for extension 'strop'
skipping python loader for extension 'time'
skipping python loader for extension 'unicodedata'
skipping python loader for extension 'zlib'
*** byte compile python files ***
skipping byte-compilation of /Users/****/Development/Python/Curses/test.py to test.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/StringIO.py to StringIO.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/UserDict.py to UserDict.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/__future__.py to __future__.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/_abcoll.py to _abcoll.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/_strptime.py to _strptime.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/_threading_local.py to _threading_local.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/abc.py to abc.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/base64.py to base64.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/bdb.py to bdb.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/bisect.py to bisect.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/calendar.py to calendar.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/cmd.py to cmd.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/codecs.py to codecs.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/collections.py to collections.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/copy.py to copy.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/copy_reg.py to copy_reg.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/difflib.py to difflib.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/dis.py to dis.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/doctest.py to doctest.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/dummy_thread.py to dummy_thread.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/__init__.py to encodings/__init__.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/aliases.py to encodings/aliases.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/ascii.py to encodings/ascii.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/base64_codec.py to encodings/base64_codec.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/big5.py to encodings/big5.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/big5hkscs.py to encodings/big5hkscs.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/bz2_codec.py to encodings/bz2_codec.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/charmap.py to encodings/charmap.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp037.py to encodings/cp037.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1006.py to encodings/cp1006.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1026.py to encodings/cp1026.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1140.py to encodings/cp1140.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1250.py to encodings/cp1250.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1251.py to encodings/cp1251.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1252.py to encodings/cp1252.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1253.py to encodings/cp1253.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1254.py to encodings/cp1254.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1255.py to encodings/cp1255.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1256.py to encodings/cp1256.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1257.py to encodings/cp1257.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp1258.py to encodings/cp1258.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp424.py to encodings/cp424.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp437.py to encodings/cp437.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp500.py to encodings/cp500.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp737.py to encodings/cp737.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp775.py to encodings/cp775.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp850.py to encodings/cp850.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp852.py to encodings/cp852.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp855.py to encodings/cp855.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp856.py to encodings/cp856.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp857.py to encodings/cp857.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp860.py to encodings/cp860.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp861.py to encodings/cp861.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp862.py to encodings/cp862.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp863.py to encodings/cp863.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp864.py to encodings/cp864.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp865.py to encodings/cp865.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp866.py to encodings/cp866.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp869.py to encodings/cp869.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp874.py to encodings/cp874.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp875.py to encodings/cp875.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp932.py to encodings/cp932.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp949.py to encodings/cp949.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/cp950.py to encodings/cp950.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/euc_jis_2004.py to encodings/euc_jis_2004.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/euc_jisx0213.py to encodings/euc_jisx0213.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/euc_jp.py to encodings/euc_jp.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/euc_kr.py to encodings/euc_kr.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/gb18030.py to encodings/gb18030.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/gb2312.py to encodings/gb2312.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/gbk.py to encodings/gbk.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/hex_codec.py to encodings/hex_codec.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/hp_roman8.py to encodings/hp_roman8.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/hz.py to encodings/hz.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/idna.py to encodings/idna.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_jp.py to encodings/iso2022_jp.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_jp_1.py to encodings/iso2022_jp_1.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_jp_2.py to encodings/iso2022_jp_2.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_jp_2004.py to encodings/iso2022_jp_2004.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_jp_3.py to encodings/iso2022_jp_3.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_jp_ext.py to encodings/iso2022_jp_ext.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso2022_kr.py to encodings/iso2022_kr.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_1.py to encodings/iso8859_1.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_10.py to encodings/iso8859_10.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_11.py to encodings/iso8859_11.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_13.py to encodings/iso8859_13.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_14.py to encodings/iso8859_14.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_15.py to encodings/iso8859_15.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_16.py to encodings/iso8859_16.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_2.py to encodings/iso8859_2.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_3.py to encodings/iso8859_3.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_4.py to encodings/iso8859_4.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_5.py to encodings/iso8859_5.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_6.py to encodings/iso8859_6.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_7.py to encodings/iso8859_7.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_8.py to encodings/iso8859_8.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_9.py to encodings/iso8859_9.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/johab.py to encodings/johab.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/koi8_r.py to encodings/koi8_r.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/koi8_u.py to encodings/koi8_u.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/latin_1.py to encodings/latin_1.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_arabic.py to encodings/mac_arabic.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_centeuro.py to encodings/mac_centeuro.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_croatian.py to encodings/mac_croatian.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_cyrillic.py to encodings/mac_cyrillic.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_farsi.py to encodings/mac_farsi.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_greek.py to encodings/mac_greek.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_iceland.py to encodings/mac_iceland.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_latin2.py to encodings/mac_latin2.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_roman.py to encodings/mac_roman.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_romanian.py to encodings/mac_romanian.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mac_turkish.py to encodings/mac_turkish.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/mbcs.py to encodings/mbcs.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/palmos.py to encodings/palmos.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/ptcp154.py to encodings/ptcp154.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/punycode.py to encodings/punycode.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/quopri_codec.py to encodings/quopri_codec.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/raw_unicode_escape.py to encodings/raw_unicode_escape.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/rot_13.py to encodings/rot_13.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/shift_jis.py to encodings/shift_jis.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/shift_jis_2004.py to encodings/shift_jis_2004.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/shift_jisx0213.py to encodings/shift_jisx0213.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/string_escape.py to encodings/string_escape.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/tis_620.py to encodings/tis_620.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/undefined.py to encodings/undefined.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/unicode_escape.py to encodings/unicode_escape.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/unicode_internal.py to encodings/unicode_internal.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_16.py to encodings/utf_16.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_16_be.py to encodings/utf_16_be.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_16_le.py to encodings/utf_16_le.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_32.py to encodings/utf_32.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_32_be.py to encodings/utf_32_be.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_32_le.py to encodings/utf_32_le.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_7.py to encodings/utf_7.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_8.py to encodings/utf_8.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_8_sig.py to encodings/utf_8_sig.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/uu_codec.py to encodings/uu_codec.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/zlib_codec.py to encodings/zlib_codec.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/functools.py to functools.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/genericpath.py to genericpath.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/getopt.py to getopt.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/gettext.py to gettext.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/heapq.py to heapq.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/inspect.py to inspect.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/keyword.py to keyword.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/linecache.py to linecache.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py to locale.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/opcode.py to opcode.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py to optparse.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py to os.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pdb.py to pdb.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pickle.py to pickle.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/Carbon/AE.py to Carbon/AE.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/Carbon/AppleEvents.py to Carbon/AppleEvents.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/Carbon/Events.py to Carbon/Events.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/Carbon/Evt.py to Carbon/Evt.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/Carbon/File.py to Carbon/File.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/Carbon/__init__.py to Carbon/__init__.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/posixpath.py to posixpath.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pprint.py to pprint.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/quopri.py to quopri.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/random.py to random.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.py to re.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/repr.py to repr.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shlex.py to shlex.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/bootstrap/argv_emulation.py to argv_emulation.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/bootstrap/boot_app.py to boot_app.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/bootstrap/chdir_resource.py to chdir_resource.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/bootstrap/disable_linecache.py to disable_linecache.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/sre.py to sre.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/sre_compile.py to sre_compile.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/sre_constants.py to sre_constants.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/sre_parse.py to sre_parse.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/stat.py to stat.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/string.py to string.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/stringprep.py to stringprep.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/struct.py to struct.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subprocess.py to subprocess.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tempfile.py to tempfile.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/textwrap.py to textwrap.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py to threading.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/token.py to token.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tokenize.py to tokenize.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/traceback.py to traceback.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/types.py to types.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py to unittest.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/warnings.py to warnings.pyc
skipping byte-compilation of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/weakref.py to weakref.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_AE.py to _AE.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_Evt.py to _Evt.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_File.py to _File.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_bisect.py to _bisect.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_codecs_cn.py to _codecs_cn.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_codecs_hk.py to _codecs_hk.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_codecs_iso2022.py to _codecs_iso2022.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_codecs_jp.py to _codecs_jp.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_codecs_kr.py to _codecs_kr.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_codecs_tw.py to _codecs_tw.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_collections.py to _collections.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_functools.py to _functools.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_heapq.py to _heapq.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_locale.py to _locale.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_multibytecodec.py to _multibytecodec.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_random.py to _random.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_struct.py to _struct.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/_weakref.py to _weakref.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/array.py to array.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/binascii.py to binascii.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/bz2.py to bz2.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/cPickle.py to cPickle.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/cStringIO.py to cStringIO.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/datetime.py to datetime.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/fcntl.py to fcntl.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/itertools.py to itertools.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/math.py to math.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/operator.py to operator.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/select.py to select.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/strop.py to strop.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/time.py to time.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/unicodedata.py to unicodedata.pyc
skipping byte-compilation of /Users/****/Development/Python/Curses/build/bdist.macosx-10.6-i386/python2.6-standalone/app/temp/zlib.py to zlib.pyc
*** creating application bundle: test ***
copying test.py -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6/config
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/Makefile -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6/config
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/Setup -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6/config
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/Setup.local -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6/config
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/Setup.config -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6/config
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/include
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/include/python2.6
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyconfig.h -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/include/python2.6
copying build/bdist.macosx-10.6-i386/python2.6-standalone/app/site-packages.zip -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Resources/lib/python2.6/lib-dynload
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python -> /Users/****/Development/Python/Curses/dist/test.app/Contents/MacOS/python
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/Resources
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/include
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/include/python2.6
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/lib
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6
creating /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Info.plist -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/Resources
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyconfig.h -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/include/python2.6
copying /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/Makefile -> /Users/****/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/build_app.py", line 589, in _run
    self.run_normal()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/build_app.py", line 660, in run_normal
    self.create_binaries(py_files, pkgdirs, extensions, loader_files)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app/build_app.py", line 768, in create_binaries
    mm.mm.run_file(runtime)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachOGraph.py", line 66, in run_file
    m = self.createNode(MachO, pathname)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachOStandalone.py", line 23, in createNode
    res = super(FilteredMachOGraph, self).createNode(cls, name)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/altgraph/ObjectGraph.py", line 148, in createNode
    m = cls(name, *args, **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachO.py", line 63, in __init__
    self.load(file(filename, 'rb'))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachO.py", line 78, in load
    self.load_header(fh, 0, size)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachO.py", line 108, in load_header
    hdr = MachOHeader(self, fh, offset, size, magic, hdr, endian)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachO.py", line 148, in __init__
    self.load(fh)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/MachO.py", line 161, in load
    header = self.mach_header.from_fileobj(fh, **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/ptypes.py", line 44, in from_fileobj
    return cls.from_str(f.read(cls._size_), **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/ptypes.py", line 48, in from_str
    return cls.from_tuple(struct.unpack(endian + cls._format_, s), **kw)
error: unpack requires a string argument of length 32
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/macholib/ptypes.py(48)from_str()
-> return cls.from_tuple(struct.unpack(endian + cls._format_, s), **kw)

I thought I might have messed up my Python install but now I'm pretty sure I have a standard MacPort's Python 2.6.4 and py2app 4.3. I tried both export VERSIONER_PYTHON_PREFER_32_BIT=yes and no. Any pointers to building a 32-bit program?

Regards,
Xiao


On 28/12/2009, at 5:47 PM, Kevin Walzer wrote:

> On 12/28/09 12:39 PM, Marc-Antoine Parent wrote:
>>> It's just Tkinter--I have a four-way build (32/64 bit for PPC and Intel) of Tcl/Tk.
>> 
>> 
>> Hmmm.... I tried adding Tkinter to my "includes". Interestingly, the framework did not get added; apparently because it is a system framework.
>> I then tried adding it explicitly with the "frameworks" option of py2app; still not included.
> 
> py2app doesn't add stuff in /System because it can't be redistributed (those are Apple-provided bits).
> 
>> I had an old 32bit build of Tcl/Tk frameworks in /Library, that one got added without issues.
> 
>> I also tried moving the /System/Library/Frameworks/Tcl,Tk to /Library/Frameworks; that also worked without a hitch.
> 
> Yes, that should work.
> 
>> Can I ask you where you got your Tcl/Tk?
>> And more to the point, do you really need it, since it's been part of /System since 10.4?
> 
> I built it myself, and I do need my own build because I want 64-bit. The version in /System is ancient (c. 2005)  and doesn't support 64-bit.
>> 
> sr/bin/strip: the __LINKEDIT segment does not cover the end of the file (can't be processed) in: /Users/maparent/OpenSource/leo-editor/dist/leo-editor.app/Contents/Frameworks/QtXmlPatterns.framework/Versions/4/QtXmlPatterns (for architecture x86_64)
>> 
>> The solution for me is to wipe the "dist" directory and start fresh. ("build" is not an issue.)
>> Would you mind trying that, just in case?
> 
> That didn't work, unfortunately.
> 
> I've tried the maxheader trick before in the past, and it hasn't worked, but I don't feel like recompiling Tcl/Tk this time. Too much work when bundlebuilder is an easier, functioning solution.
> 
> In the meantime, you might want to ping Ronald Oussoren with your patches--I'm sure that others will find them useful.
> 
> --Kevin
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From aahz at pythoncraft.com  Tue Feb 16 18:33:51 2010
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 16 Feb 2010 09:33:51 -0800
Subject: [Pythonmac-SIG] py2app/PyQt/64-bit/Mach-O
In-Reply-To: <9F7A9897-9932-44B3-BD4D-46DADA6053F1@xiao-yu.com>
References: <4B1DB1B7.3080507@codebykevin.com>
	<65fadfc30912071913o33210161n24bde05ead131f03@mail.gmail.com>
	<4B1DC5C9.7070606@codebykevin.com>
	<A2BA838F-CCD1-4457-B74B-4A055F413592@acm.org>
	<4B38284F.4000203@codebykevin.com>
	<AFA59FEC-9234-46CD-9D8E-601A2A967B9B@acm.org>
	<4B38429B.90603@codebykevin.com>
	<C304A2EC-24D0-448B-993F-FA99D7DA2302@acm.org>
	<4B39356A.3080205@codebykevin.com>
	<9F7A9897-9932-44B3-BD4D-46DADA6053F1@xiao-yu.com>
Message-ID: <20100216173351.GA12140@panix.com>

On Sun, Feb 14, 2010, Xiao Yu wrote:
>
> I thought I might have messed up my Python install but now I'm pretty
> sure I have a standard MacPort's Python 2.6.4 and py2app 4.3. I tried
> both export VERSIONER_PYTHON_PREFER_32_BIT=yes and no. Any pointers to
> building a 32-bit program?

Why not use python.org's 2.6.4?
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just        
refer to comments in code as 'lies'. :-)"

From norman at khine.net  Tue Feb 16 20:25:52 2010
From: norman at khine.net (Norman Khine)
Date: Tue, 16 Feb 2010 20:25:52 +0100
Subject: [Pythonmac-SIG] build on OS X 10.6.2
Message-ID: <9c2c8ffb1002161125o3cc12acdt91f1b50117fe40b2@mail.gmail.com>

Hello,

I have three python versions, one that came with OS X, one from
MacPorts and one which I compiled with:

./configure --prefix=$HOME

All works fine, but I don't understand when I change my .profile so that

export PYTHON=$HOME/bin/python

and try to build for example swftools, swftools only finds the MacPorts python

How do I force swftools to use the $HOME/bin/python python version?

I tried ./configure --prefix=$HOME PYTHON=$HOME/bin/python

but it did not work!

Thanks

Norman

From news at xiao-yu.com  Tue Feb 16 23:18:31 2010
From: news at xiao-yu.com (Xiao Yu)
Date: Tue, 16 Feb 2010 17:18:31 -0500
Subject: [Pythonmac-SIG] py2app/PyQt/64-bit/Mach-O
In-Reply-To: <20100216173351.GA12140@panix.com>
References: <4B1DB1B7.3080507@codebykevin.com>
	<65fadfc30912071913o33210161n24bde05ead131f03@mail.gmail.com>
	<4B1DC5C9.7070606@codebykevin.com>
	<A2BA838F-CCD1-4457-B74B-4A055F413592@acm.org>
	<4B38284F.4000203@codebykevin.com>
	<AFA59FEC-9234-46CD-9D8E-601A2A967B9B@acm.org>
	<4B38429B.90603@codebykevin.com>
	<C304A2EC-24D0-448B-993F-FA99D7DA2302@acm.org>
	<4B39356A.3080205@codebykevin.com>
	<9F7A9897-9932-44B3-BD4D-46DADA6053F1@xiao-yu.com>
	<20100216173351.GA12140@panix.com>
Message-ID: <1F4AF019-B2C9-4485-BFCB-BD1799AA208A@xiao-yu.com>

Just tried again. Python from python.org and py2app, all built from source. Python is built with i386 and x86_64 and as a framework. 

copying /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/Makefile -> /Users/xiao/Development/Python/Curses/dist/test.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app-0.4.3-py2.7.egg/py2app/build_app.py", line 589, in _run
    self.run_normal()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app-0.4.3-py2.7.egg/py2app/build_app.py", line 660, in run_normal
    self.create_binaries(py_files, pkgdirs, extensions, loader_files)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/py2app-0.4.3-py2.7.egg/py2app/build_app.py", line 768, in create_binaries
    mm.mm.run_file(runtime)
  File "build/bdist.macosx-10.5-intel/egg/macholib/MachOGraph.py", line 66, in run_file
    m = self.createNode(MachO, pathname)
  File "build/bdist.macosx-10.5-intel/egg/macholib/MachOStandalone.py", line 23, in createNode
    res = super(FilteredMachOGraph, self).createNode(cls, name)
  File "build/bdist.macosx-10.5-intel/egg/altgraph/ObjectGraph.py", line 148, in createNode
    m = cls(name, *args, **kw)
  File "build/bdist.macosx-10.5-intel/egg/macholib/MachO.py", line 63, in __init__
    self.load(file(filename, 'rb'))
  File "build/bdist.macosx-10.5-intel/egg/macholib/MachO.py", line 73, in load
    self.load_fat(fh)
  File "build/bdist.macosx-10.5-intel/egg/macholib/MachO.py", line 81, in load_fat
    self.fat = fat_header.from_fileobj(fh)
  File "build/bdist.macosx-10.5-intel/egg/macholib/ptypes.py", line 44, in from_fileobj
    return cls.from_str(f.read(cls._size_), **kw)
  File "build/bdist.macosx-10.5-intel/egg/macholib/ptypes.py", line 48, in from_str
    return cls.from_tuple(struct.unpack(endian + cls._format_, s), **kw)
error: unpack requires a string argument of length 8
> /Users/xiao/Development/Python/Curses/build/bdist.macosx-10.5-intel/egg/macholib/ptypes.py(48)from_str()
-> return cls.from_tuple(struct.unpack(endian + cls._format_, s), **kw)

Still a similar problem. The program is just print "hello". Anyone else have this problem?

Xiao

On 16/02/2010, at 12:33 PM, Aahz wrote:

> On Sun, Feb 14, 2010, Xiao Yu wrote:
>> 
>> I thought I might have messed up my Python install but now I'm pretty
>> sure I have a standard MacPort's Python 2.6.4 and py2app 4.3. I tried
>> both export VERSIONER_PYTHON_PREFER_32_BIT=yes and no. Any pointers to
>> building a 32-bit program?
> 
> Why not use python.org's 2.6.4?
> -- 
> Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/
> 
> "At Resolver we've found it useful to short-circuit any doubt and just        
> refer to comments in code as 'lies'. :-)"
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


From Chris.Barker at noaa.gov  Wed Feb 17 19:35:14 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 17 Feb 2010 10:35:14 -0800
Subject: [Pythonmac-SIG] build on OS X 10.6.2
In-Reply-To: <9c2c8ffb1002161125o3cc12acdt91f1b50117fe40b2@mail.gmail.com>
References: <9c2c8ffb1002161125o3cc12acdt91f1b50117fe40b2@mail.gmail.com>
Message-ID: <4B7C36E2.7020002@noaa.gov>

Norman Khine wrote:
> I have three python versions, one that came with OS X, one from
> MacPorts and one which I compiled with:
> 
> ./configure --prefix=$HOME
> 
> All works fine, but I don't understand when I change my .profile so that
> 
> export PYTHON=$HOME/bin/python
> 
> and try to build for example swftools, swftools only finds the MacPorts python

I've never seen a environment variable called "PYTHON", there is a 
"PYTHONHOME" and "PYTHONPATH" (and others). In any case, I think they 
are all used by Python once it is started, but don't specify how to 
start it.


> How do I force swftools to use the $HOME/bin/python python version?

That all depends on how swftools does its build -- so I'd think it's a 
question for that list. If it is building with distutils (setup.py), 
then you just have to make sure you run the setup.py with the python you 
want to build for

-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

Chris.Barker at noaa.gov

From aahz at pythoncraft.com  Thu Feb 18 23:07:57 2010
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 18 Feb 2010 14:07:57 -0800
Subject: [Pythonmac-SIG] py2app/PyQt/64-bit/Mach-O
In-Reply-To: <1F4AF019-B2C9-4485-BFCB-BD1799AA208A@xiao-yu.com>
References: <4B1DC5C9.7070606@codebykevin.com>
	<A2BA838F-CCD1-4457-B74B-4A055F413592@acm.org>
	<4B38284F.4000203@codebykevin.com>
	<AFA59FEC-9234-46CD-9D8E-601A2A967B9B@acm.org>
	<4B38429B.90603@codebykevin.com>
	<C304A2EC-24D0-448B-993F-FA99D7DA2302@acm.org>
	<4B39356A.3080205@codebykevin.com>
	<9F7A9897-9932-44B3-BD4D-46DADA6053F1@xiao-yu.com>
	<20100216173351.GA12140@panix.com>
	<1F4AF019-B2C9-4485-BFCB-BD1799AA208A@xiao-yu.com>
Message-ID: <20100218220757.GA7639@panix.com>

On Tue, Feb 16, 2010, Xiao Yu wrote:
>
> Just tried again. Python from python.org and py2app, all built from
> source. Python is built with i386 and x86_64 and as a framework.

No, I meant using the python.org DMG, just to make sure you've got a
properly built Python.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just        
refer to comments in code as 'lies'. :-)"

From livingstonemark at gmail.com  Fri Feb 19 09:10:15 2010
From: livingstonemark at gmail.com (Mark Livingstone)
Date: Fri, 19 Feb 2010 18:10:15 +1000
Subject: [Pythonmac-SIG] Crossfold Validation
Message-ID: <d9183eda1002190010w3c48bdbfkbd2a23fa1fa4ad9d@mail.gmail.com>

Hi Guys,

I am looking for suggestions! I am doing some experimentation and want
to know if there are any utilities available that will take a file as
input, get the num folds and num times, and do the slice and dice file
operation ready then for training / testing?

I imagine it wouldn't be difficult to write but why reinvent the
wheel! Naturally my training / testing will also be on a Mac / Python.

Thanks in advance and have a great weekend guys!

MarkL

From dr.j.norman at gmail.com  Thu Feb 18 20:20:18 2010
From: dr.j.norman at gmail.com (Jason Norman)
Date: Thu, 18 Feb 2010 14:20:18 -0500
Subject: [Pythonmac-SIG]  Installing Cantera
Message-ID: <9F3DD51C-F3A0-43FA-91D5-413C729E3605@gmail.com>

I have the same problem - did anyone have an answer?

From robinson at cmrr.umn.edu  Fri Feb 19 18:43:01 2010
From: robinson at cmrr.umn.edu (robinson at cmrr.umn.edu)
Date: Fri, 19 Feb 2010 11:43:01 -0600 (CST)
Subject: [Pythonmac-SIG] py2app pytz error
Message-ID: <47293.172.16.23.253.1266601381.squirrel@www.cmrr.umn.edu>

'lo, all.

I've been digging around in the archives a bit, but haven't been able to
find a solution to my problem. Any advice would be very much appreciated.

I'm trying to create a mac .app on an ubuntu-based system. I've got the
pytz module and am using py2app4.3, setuptools-0.6c11, and python 2.5.2.

However, I get the "No module named pytz.zoneinfo" error when running:

>python setup.py py2app

I tried adding the following lines to my setup.py file without success:

import pytz
pytz.zoneinfo = pytz.tzinfo
pytz.zoneinfo.UTC = pytz.UTC

Nothing shows up in /dist, and the directories in build are empty. Help!

Cheers,
Paul





Center for Magnetic Resonance Research
University of Minnesota
2021 Sixth Street SE
Minneapolis, MN 55455
612-625-2427




From Chris.Barker at noaa.gov  Fri Feb 19 20:43:44 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Fri, 19 Feb 2010 11:43:44 -0800
Subject: [Pythonmac-SIG] py2app pytz error
In-Reply-To: <47293.172.16.23.253.1266601381.squirrel@www.cmrr.umn.edu>
References: <47293.172.16.23.253.1266601381.squirrel@www.cmrr.umn.edu>
Message-ID: <4B7EE9F0.6080400@noaa.gov>

robinson at cmrr.umn.edu wrote:
> I'm trying to create a mac .app on an ubuntu-based system.

That really can't be done -- not without a LOT of work building tools to 
re-write paths in shared libraries, etc. You need to build a *.app on a 
Mac. Also, all the binary components of your app- python itself, any 
complied modules, etc, would all have to be mac-compatible. gcc suport 
cross-compilation, but I think the version apple ships has a lot of 
extra stuff in it, so I doubt a stock gcc on Ubuntu could do it.

> I've got the
> pytz module and am using py2app4.3, setuptools-0.6c11, and python 2.5.2.
> 
> However, I get the "No module named pytz.zoneinfo" error when running:
> 
>> python setup.py py2app

Oddly. That's not an error I'd expect, and this one probably simple, but 
  I don't think it makes any sense to even try to go down this road.

-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

Chris.Barker at noaa.gov

From aahz at pythoncraft.com  Sat Feb 20 01:29:16 2010
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 19 Feb 2010 16:29:16 -0800
Subject: [Pythonmac-SIG] Crossfold Validation
In-Reply-To: <d9183eda1002190010w3c48bdbfkbd2a23fa1fa4ad9d@mail.gmail.com>
References: <d9183eda1002190010w3c48bdbfkbd2a23fa1fa4ad9d@mail.gmail.com>
Message-ID: <20100220002916.GA2494@panix.com>

On Fri, Feb 19, 2010, Mark Livingstone wrote:
> 
> I am looking for suggestions! I am doing some experimentation and want
> to know if there are any utilities available that will take a file as
> input, get the num folds and num times, and do the slice and dice file
> operation ready then for training / testing?

You will need to expand your jargon if you want anyone unfamiliar with
this specific operation to provide assistance.  (I.e. I have no clue what
you're talking about.)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just        
refer to comments in code as 'lies'. :-)"

From robert.kern at gmail.com  Sat Feb 20 02:12:41 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 19 Feb 2010 19:12:41 -0600
Subject: [Pythonmac-SIG] Crossfold Validation
In-Reply-To: <20100220002916.GA2494@panix.com>
References: <d9183eda1002190010w3c48bdbfkbd2a23fa1fa4ad9d@mail.gmail.com>
	<20100220002916.GA2494@panix.com>
Message-ID: <hlncu7$5al$1@ger.gmane.org>

On 2010-02-19 18:29 PM, Aahz wrote:
> On Fri, Feb 19, 2010, Mark Livingstone wrote:
>>
>> I am looking for suggestions! I am doing some experimentation and want
>> to know if there are any utilities available that will take a file as
>> input, get the num folds and num times, and do the slice and dice file
>> operation ready then for training / testing?
>
> You will need to expand your jargon if you want anyone unfamiliar with
> this specific operation to provide assistance.  (I.e. I have no clue what
> you're talking about.)

It's really off-topic for this list, but K-fold cross-validation is a way of 
testing how well some prediction method will perform. Roughly, you split up the 
data into K chunks. You use K-1 chunks to train your method and test on the 
remaining chunk. You then repeat this K times with each chunk playing the role 
of the test chunk exactly once. Then you average the performance of your 
prediction method over each of the K tests.

Mark, I recommend that you join the scipy-users mailing list. We'll be happy to 
field your data analysis questions over there. These kinds of questions really 
are unrelated to the Apple platform even if you intend to do the analysis on an 
Apple machine.

   http://www.scipy.org/Mailing_Lists

You may also want to check the SpamBayes project. Their validation framework 
might be applicable to your problem set.

   http://spambayes.sourceforge.net/

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From mk0423 at towb.de  Sat Feb 20 17:50:04 2010
From: mk0423 at towb.de (Tobias Weber)
Date: Sat, 20 Feb 2010 17:50:04 +0100
Subject: [Pythonmac-SIG] Storing path as alias
Message-ID: <C93401A7-59C2-46BD-A5D5-0EDDD0BF07E8@towb.de>

Hi,
how do I store an unbreakable alias instead of a POSIX path?

There's mactypes.Alias in appscript, but it doesn't look serializable.

I could use NDAlias via pyobjc and get an NSData out.

From hengist.podd at virgin.net  Sun Feb 21 15:20:17 2010
From: hengist.podd at virgin.net (has)
Date: Sun, 21 Feb 2010 14:20:17 +0000
Subject: [Pythonmac-SIG] Storing path as alias
In-Reply-To: <mailman.42.1266750002.8972.pythonmac-sig@python.org>
References: <mailman.42.1266750002.8972.pythonmac-sig@python.org>
Message-ID: <0EAB9073-9C08-4D7C-A6B3-B2DBAFDA0881@virgin.net>

Tobias Weber wrote:

> how do I store an unbreakable alias instead of a POSIX path?
> 
> There's mactypes.Alias in appscript, but it doesn't look serializable.

mactypes.Alias doesn't provide flatten/unflatten APIs, but it's just a wrapper around aem.ae.AEDesc, which does. Check their docstrings for more information.


> I could use NDAlias via pyobjc and get an NSData out.

NSURL has a 'bookmark' feature in 10.6+.

HTH

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From mk0423 at towb.de  Sun Feb 21 19:22:19 2010
From: mk0423 at towb.de (Tobias Weber)
Date: Sun, 21 Feb 2010 19:22:19 +0100
Subject: [Pythonmac-SIG] Storing path as alias
In-Reply-To: <0EAB9073-9C08-4D7C-A6B3-B2DBAFDA0881@virgin.net>
References: <mailman.42.1266750002.8972.pythonmac-sig@python.org>
	<0EAB9073-9C08-4D7C-A6B3-B2DBAFDA0881@virgin.net>
Message-ID: <072458EA-3CD0-4E94-874F-89C2B289ADB6@towb.de>

On 21.02.2010, at 15:20, has wrote:

Thanks! I made working examples for both, but I guess the first has AppleScript limitations like requiring a UI context.

> mactypes.Alias doesn't provide flatten/unflatten APIs, but it's just a wrapper around aem.ae.AEDesc, which does.

import base64

import mactypes, aem

# Raises ValueError.
alias = mactypes.Alias("/Users/towb/test")
data = alias.desc.flatten()
string = base64.b64encode(data)

# Now store, move and rename file, load back.

data = buffer(base64.b64decode(string))
# aem.ae.MacOSError -50 if bad.
desc = aem.ae.unflattendesc(data)
# makewithdesc does not raise.
alias = mactypes.Alias.makewithdesc(desc)
# aem.ae.MacOSError -43 if lost.
print alias.path

> NSURL has a 'bookmark' feature in 10.6+.

import base64

from Foundation import *

url = NSURL.fileURLWithPath_("/Users/towb/test")
data = url.bookmarkDataWithOptions_includingResourceValuesForKeys_relativeToURL_error_(
   0, None, None, None)
if not data:
   raise IOError("file not found")
string = base64.b64encode(data)

# Now store, move and rename file, load back.

data = buffer(base64.b64decode(string))
url = NSURL.URLByResolvingBookmarkData_options_relativeToURL_bookmarkDataIsStale_error_(
   data, (1 << 8), None, None, None)
   # Named constants don't work?
if not url:
   raise StandardError("bad or lost")
print url.path()


From loredo at astro.cornell.edu  Mon Feb 22 04:40:52 2010
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Sun, 21 Feb 2010 22:40:52 -0500
Subject: [Pythonmac-SIG] Problems installing Python-2.7a3 on 10.6.2
Message-ID: <1266810052.4b81fcc464636@astrosun2.astro.cornell.edu>


Hi folks-

I've tried installing an intel framework universal build of
Py-2.7a3 on Snow Leopard 10.6.2 (i.e., i386 + x86_64).  I 
used this configure:

./configure --prefix=/usr/local/tmp --enable-framework --with-framework-name=PythonAlpha  --enable-universalsdk=/ --
with-universal-archs=intel

"make" works fine, and "make test" appears acceptable (although
there is an error):

347 tests OK.
1 test failed:
    test_macostools
33 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn
    test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_curses test_dl test_epoll test_gl
    test_imageop test_imgfile test_largefile test_linuxaudiodev
    test_ossaudiodev test_pep277 test_py3kwarn test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
1 skip unexpected on darwin:
    test_dl

"make install" works fine.  But the installed executable won't run.
I put /Library/Frameworks/PythonAlpha.framework/Versions/2.7/bin at
the front of my PATH.  Then:

$ which python
/Library/Frameworks/PythonAlpha.framework/Versions/2.7/bin/python
$ python
python: posix_spawn: python: Unknown error: 0

I also tried directly executing (with full paths) python, python2.7,
python2, and python-32 in the framework /bin/ directory, all with
the same posix_spawn error.  I also tried directly executing those
pythons in /usr/local/tmp, with the same result.

Any ideas what is preventing the installed versions from running
when the "make'd" version ran fine?  Are the non-standard paths
an issue?  I don't want to install into the usual /usr/local
paths, since I'm using homebrew to handle /usr/local.

Thanks,
Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

From loredo at astro.cornell.edu  Mon Feb 22 04:33:20 2010
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Sun, 21 Feb 2010 22:33:20 -0500
Subject: [Pythonmac-SIG] Problems installing 32-bit Py-2.6.4 framework on
	10.6.2
Message-ID: <1266809600.4b81fb00be931@astrosun2.astro.cornell.edu>


Hi folks,

I've been attempting to install a 32-bit version of Python-2.6.4
on Snow Leopard 10.6.2.  I'd like to install it from source (a
32-bit binary built for 10.3+ is at Python.org).  Unfortunately,
I haven't yet figured out a way to get an accessible 32-bit
interpreter built on Snow Leopard.

I have the latest SL Xcode installed, including the 10.4 SDK.
Here's what I've tried.

Installing with the following configuration to build an
"intel" universal framework:

$ ./configure --prefix=/usr/local/tmp --enable-framework --with-universal-archs=intel --enable-universalsdk=/

does indeed produce a universal Python with 32-bit (i386) and 
64-bit (x86_64) versions in a bundle, but there is no way to
access the 32 bit executable (the defaults variable that Apple
implemented to provide access to 32-bit 2.6.1 is proprietary and
has no effect on non-Apple installations; the Python.org solution 
is to install a separate python-32 executable but this was not 
backported to 2.6.4).

So I've tried building an "all" universal binary, which should
produce ppc and intel versions of both bit-widths.  This configure:

$ ./configure --prefix=/usr/local/tmp --with-universal-archs=all --enable-universalsdk=/

produces an error during the configure:

..
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t)
See `config.log' for more details.

The config.log indicates a problem building ppc64 libraries while
linking one of the conftest programs (many "missing required architecture 
ppc64 in file" messages).

So I've tried just building a 32-bit universal framework (I cannot
see from the docs any way to build just a 32-bit i386 build):

$ ./configure --prefix=/usr/local/tmp --enable-framework --with-framework-name=Python32  --enable-universalsdk --with-
universal-archs=32-bit

(By the way, this produces a config error if I set MACOSX_DEPLOYMENT_TARGET=10.6,
but not if I don't set the target.)  In this case "make" immediately
fails with errors compiling Modules/python.c:

-----
gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-strict-aliasing -fno-common -dynamic -
DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o 
./Modules/python.c
In file included from Include/Python.h:58,
                 from ./Modules/python.c:3:
Include/pyport.h:480: warning: ?struct winsize? declared inside parameter list
Include/pyport.h:481: warning: ?struct winsize? declared inside parameter list
In file included from Include/unicodeobject.h:4,
                 from Include/Python.h:85,
                 from ./Modules/python.c:3:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory
In file included from Include/Python.h:58,
                 from ./Modules/python.c:3:
Include/pyport.h:480: warning: ?struct winsize? declared inside parameter list
Include/pyport.h:481: warning: ?struct winsize? declared inside parameter list
In file included from Include/unicodeobject.h:4,
                 from Include/Python.h:85,
                 from ./Modules/python.c:3:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory
lipo: can't figure out the architecture type of: /var/folders/Hv/Hvx6V3reHlqGUIlS1r9NS++++TI/-Tmp-//ccbAkLni.out
make: *** [Modules/python.o] Error 1
-----

The offending line in the 10.4sdk stdarg.h is:

#include_next <stdarg.h>

I don't know what this does, and thus have no clue how to diagnose
why the stdarg.h it is looking for cannot be found.

Any clues?

Also, is there a way to build i386 without building ppc-32?

Thanks,
Tom

PS:  What is the role of MACOSX_DEPLOYMENT_TARGET?  Was it only a
one-time fix for Leopard installs that should be disregarded post-Leopard?
I ask because NumPy does a check on its value.  I don't think
the check is consequential, but to avoid warning messages NumPy
installers are encouraged to set MACOSX_DEPLOYMENT_TARGET=10.6 for
Snow Leopard when installing NumPy.  I thought this was "inherited"
from Python itself.


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

From nad at acm.org  Mon Feb 22 19:04:57 2010
From: nad at acm.org (Ned Deily)
Date: Mon, 22 Feb 2010 10:04:57 -0800
Subject: [Pythonmac-SIG] Problems installing 32-bit Py-2.6.4 framework
	on 10.6.2
Message-ID: <AECDDAD6-8EFB-4F90-AFB8-996A73D461FA@acm.org>

[Resending, possibly lost in transit]

In article <1266809600.4b81fb00be931 at astrosun2.astro.cornell.edu>,
  Tom Loredo <loredo at astro.cornell.edu> wrote:
 > I've been attempting to install a 32-bit version of Python-2.6.4
 > on Snow Leopard 10.6.2.  I'd like to install it from source (a
 > 32-bit binary built for 10.3+ is at Python.org).  Unfortunately,
 > I haven't yet figured out a way to get an accessible 32-bit
 > interpreter built on Snow Leopard.

The python.org 2.6.4 is intended for 10.3.9 through 10.6.  If you want a
32-bit version, it should suit your needs just fine; there shouldn't be
any reason to build it yourself.

That said, if you really want to do so:

 > I have the latest SL Xcode installed, including the 10.4 SDK.
 > Here's what I've tried.
 >
 > Installing with the following configuration to build an
 > "intel" universal framework:
 >
 > $ ./configure --prefix=/usr/local/tmp --enable-framework
 > --with-universal-archs=intel --enable-universalsdk=/
 >
 > does indeed produce a universal Python with 32-bit (i386) and
 > 64-bit (x86_64) versions in a bundle, but there is no way to
 > access the 32 bit executable (the defaults variable that Apple
 > implemented to provide access to 32-bit 2.6.1 is proprietary and
 > has no effect on non-Apple installations; the Python.org solution
 > is to install a separate python-32 executable but this was not
 > backported to 2.6.4).

That will likely be fixed for 2.6.5 which is planned to be released in
mid-March.

 > So I've tried building an "all" universal binary, which should
 > produce ppc and intel versions of both bit-widths.

But that will have the same problem: on 10.6 in the absence of
additional application plist information, a 64-bit variant will be given
preference.  The pre-10.6 4-way universal scheme of producing
pythonxx-32 and pythonxx-64 variants also does not work on 10.6 without
modification.

 > $ ./configure --prefix=/usr/local/tmp --with-universal-archs=all
 > --enable-universalsdk=/
[...]
 > $ ./configure --prefix=/usr/local/tmp --enable-framework
 > --with-framework-name=Python32  --enable-universalsdk --with-
 > universal-archs=32-bit

Don't use --enable-universalsdk or --enable-universalsdk=/.  Always
specify the full path to the appropriate SDK.

This error:
 > (By the way, this produces a config error if I set
 > MACOSX_DEPLOYMENT_TARGET=10.6,

and this error:
 > #include_next <stdarg.h>

are caused by problems when the configure script implicitly selects the
wrong value for MACOSX_DEPLOYMENT_TARGET based on the value of
--enable-universalsdk.  You can avoid these errors by using the explicit
SDK path and explicitly setting MACOSX_DEPLOYMENT_TARGET.  Appropriate
combinations are:

        export MACOSX_DEPLOYMENT_TARGET=10.3
or    export MACOSX_DEPLOYMENT_TARGET=10.4
with .configure --enable-universalsdk=/Developer/SDKs/ 
MacOSX10.4u.sdk ...

export MACOSX_DEPLOYMENT_TARGET=10.5
.configure --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk ...

export MACOSX_DEPLOYMENT_TARGET=10.6
.configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk ...

 > Also, is there a way to build i386 without building ppc-32?

Probably not at the moment.  I think the only way on 10.6 is for
configure to set only -arch i386 and I don't think there is a way to
force that without modifying configure.  I'll make sure to check that
out before 2.6.5.

 > PS:  What is the role of MACOSX_DEPLOYMENT_TARGET?  Was it only a
 > one-time fix for Leopard installs that should be disregarded post- 
Leopard?

No.  MACOSX_DEPLOYMENT_TARGET indicates to gcc and friends what the
*minimum* OS X release level that the executable being produced should
be able to run on.   The python.org installers are intentionally built
this way so one installer image and executable will work on a range of
operations systems. (In some respects, python's needs are simpler than
most GUI applications which is why it can get away with specifying 10.3
while using the 10.4u SDK.)

 > I ask because NumPy does a check on its value.  I don't think
 > the check is consequential, but to avoid warning messages NumPy
 > installers are encouraged to set MACOSX_DEPLOYMENT_TARGET=10.6 for
 > Snow Leopard when installing NumPy.  I thought this was "inherited"
 > from Python itself.

I can't speak to what special things NumPy might do but, in general when
installing packages with conventional C extension modules, Distutils
will ensure that the same values for MACOSX_DEPLOYMENT_TARGET and for
the SDK will be used for C compiles as were used when building python
itself.

--
   Ned Deily
   nad at acm.org  --  []




From nad at acm.org  Mon Feb 22 19:06:26 2010
From: nad at acm.org (Ned Deily)
Date: Mon, 22 Feb 2010 10:06:26 -0800
Subject: [Pythonmac-SIG] Problems installing Python-2.7a3 on 10.6.2
Message-ID: <937EBBDB-F059-4A36-8329-AE99FDFC2AF4@acm.org>

[resending, possibly lost in transit]

In article <1266810052.4b81fcc464636 at astrosun2.astro.cornell.edu>,
  Tom Loredo <loredo at astro.cornell.edu> wrote:
 > I've tried installing an intel framework universal build of
 > Py-2.7a3 on Snow Leopard 10.6.2 (i.e., i386 + x86_64).  I
 > used this configure:
 >
 > ./configure --prefix=/usr/local/tmp --enable-framework
 > --with-framework-name=PythonAlpha  --enable-universalsdk=/ --
 > with-universal-archs=intel
[...]
 > $ which python
 > /Library/Frameworks/PythonAlpha.framework/Versions/2.7/bin/python
 > $ python
 > python: posix_spawn: python: Unknown error: 0
 >
 > I also tried directly executing (with full paths) python, python2.7,
 > python2, and python-32 in the framework /bin/ directory, all with
 > the same posix_spawn error.  I also tried directly executing those
 > pythons in /usr/local/tmp, with the same result.
 >
 > Any ideas what is preventing the installed versions from running
 > when the "make'd" version ran fine?  Are the non-standard paths
 > an issue?  I don't want to install into the usual /usr/local
 > paths, since I'm using homebrew to handle /usr/local.

Did you try building without using the --with-framework-name option?
That's not an option that gets tested much.  There should not be a need
to use it since different versions of python (2.6, 2.7, 3.1, etc) can
co-exist without problem in the same framework.  The only potential
issue are the unversioned symlinks in /usr/local/bin/, i.e.
/usr/local/bin/python will likely get overridden by the most recently
installed python 2.x.  Either adjust manually or stick to using the
versioned symlinks, /usr/local/bin/python2.7 etc. or set your PATH to
put the appropriate framework bin directory prior to /usr/local/bin.  If
it appears that the --with-framework-name option is the problem, please
open an issue on the python.org bug tracker.

--
   Ned Deily
   nad at acm.org  --  []




From norman at khine.net  Mon Feb 22 20:22:10 2010
From: norman at khine.net (Norman Khine)
Date: Mon, 22 Feb 2010 20:22:10 +0100
Subject: [Pythonmac-SIG] setting the default pathon path
Message-ID: <9c2c8ffb1002221122i3b6f211etd67c82533f3c038b@mail.gmail.com>

hello,
on my 10.6.2 i have compiled python 2.6.4 with the following options:

$ ./configure --prefix= $HOME/

all works fine, but with one exception.

i am trying to build SWFTools and have the following option:

$ ./configure --prefix=$HOME PYTHON=$HOME/bin/python

but this still finds the default MacPorts python. how do i temporarily
change my system so that the default python is  $HOME/bin/python

i have tried to change the symlink files, i also have in my .profile
export PYTHON=$HOME/bin/python:$PYTHON

but still does not work:
$ which python
/opt/local/bin/python

what am i missing?

thanks

norman

--
%>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or
chr(97+(ord(c)-83)%26) for c in ",adym,*)&uzq^zqf" ] )

From nad at acm.org  Mon Feb 22 21:30:49 2010
From: nad at acm.org (Ned Deily)
Date: Mon, 22 Feb 2010 12:30:49 -0800
Subject: [Pythonmac-SIG] setting the default pathon path
References: <9c2c8ffb1002221122i3b6f211etd67c82533f3c038b@mail.gmail.com>
Message-ID: <nad-4AE9A6.12304922022010@dough.gmane.org>

In article 
<9c2c8ffb1002221122i3b6f211etd67c82533f3c038b at mail.gmail.com>,
 Norman Khine <norman at khine.net> wrote:
>[...]how do i temporarily
> change my system so that the default python is  $HOME/bin/python
> 
> i have tried to change the symlink files, i also have in my .profile
> export PYTHON=$HOME/bin/python:$PYTHON

Have you tried putting that in .bash_profile instead?  If it still 
doesn't work, try modifying your PATH in .bash_profile:

   export PATH="$HOME/bin":$PATH

-- 
 Ned Deily,
 nad at acm.org


From hengist.podd at virgin.net  Mon Feb 22 22:15:01 2010
From: hengist.podd at virgin.net (has)
Date: Mon, 22 Feb 2010 21:15:01 +0000
Subject: [Pythonmac-SIG] Storing path as alias
In-Reply-To: <mailman.54.1266836403.14685.pythonmac-sig@python.org>
References: <mailman.54.1266836403.14685.pythonmac-sig@python.org>
Message-ID: <AA79DAB7-3AF1-43C9-9920-731C3D5E51EF@virgin.net>

Tobias Weber wrote:

> Thanks! I made working examples for both, but I guess the first has AppleScript limitations like requiring a UI context.

No, a Window Manager connection is not required.

HTH

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From towb at celvina.de  Sun Feb 21 19:21:55 2010
From: towb at celvina.de (Tobias Weber)
Date: Sun, 21 Feb 2010 19:21:55 +0100
Subject: [Pythonmac-SIG] Storing path as alias
In-Reply-To: <0EAB9073-9C08-4D7C-A6B3-B2DBAFDA0881@virgin.net>
References: <mailman.42.1266750002.8972.pythonmac-sig@python.org>
	<0EAB9073-9C08-4D7C-A6B3-B2DBAFDA0881@virgin.net>
Message-ID: <9CB57090-A3B4-46E2-B6CC-9375902AF1DA@celvina.de>

On 21.02.2010, at 15:20, has wrote:

Thanks! I made working examples for both, but I guess the first has AppleScript limitations like requiring a UI context.

> mactypes.Alias doesn't provide flatten/unflatten APIs, but it's just a wrapper around aem.ae.AEDesc, which does.

import base64

import mactypes, aem

# Raises ValueError.
alias = mactypes.Alias("/Users/towb/test")
data = alias.desc.flatten()
string = base64.b64encode(data)

# Now store, move and rename file, load back.

data = buffer(base64.b64decode(string))
# aem.ae.MacOSError -50 if bad.
desc = aem.ae.unflattendesc(data)
# makewithdesc does not raise.
alias = mactypes.Alias.makewithdesc(desc)
# aem.ae.MacOSError -43 if lost.
print alias.path

> NSURL has a 'bookmark' feature in 10.6+.

import base64

from Foundation import *

url = NSURL.fileURLWithPath_("/Users/towb/test")
data = url.bookmarkDataWithOptions_includingResourceValuesForKeys_relativeToURL_error_(
    0, None, None, None)
if not data:
    raise IOError("file not found")
string = base64.b64encode(data)

# Now store, move and rename file, load back.

data = buffer(base64.b64decode(string))
url = NSURL.URLByResolvingBookmarkData_options_relativeToURL_bookmarkDataIsStale_error_(
    data, (1 << 8), None, None, None)
    # Named constants don't work?
if not url:
    raise StandardError("bad or lost")
print url.path()


From joe at bastarde.at  Wed Feb 24 16:28:59 2010
From: joe at bastarde.at (brennsuppa)
Date: Wed, 24 Feb 2010 07:28:59 -0800 (PST)
Subject: [Pythonmac-SIG]  C Extension Scipy/Numpy
Message-ID: <27714231.post@talk.nabble.com>


Hi,

I want to gain performance by using C for the computation of some arrays.
To do that I used this as a help:
http://www.scipy.org/Cookbook/C_Extensions/NumPy_arrays

Now I want to wirte a subroutine for the calculations with several arrays.
But I don't know how to pass the arrays to the subroutine.

e.g. i have cin1, cin2, cin3, cin4 and cout

cout = do_anything(cin1, cin2, cin3, cin4)

and do_anything would be like:

double **do_anything(cin1[][n], cin2[][n], cin3[][n], cin4[][n])

for rows
for columns
add cin1,cin2,cin3,cin4
return value

this throws an error "conflicting types for do_anything"

regards,
joe
-- 
View this message in context: http://old.nabble.com/C-Extension-Scipy-Numpy-tp27714231p27714231.html
Sent from the Python - pythonmac-sig mailing list archive at Nabble.com.


From zachary.pincus at yale.edu  Thu Feb 25 22:20:24 2010
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Thu, 25 Feb 2010 16:20:24 -0500
Subject: [Pythonmac-SIG] C Extension Scipy/Numpy
In-Reply-To: <27714231.post@talk.nabble.com>
References: <27714231.post@talk.nabble.com>
Message-ID: <B6F8D5CF-4E7E-4D3E-872F-6E4F68087095@yale.edu>

Hi,

Probably better to:
(1) Ask this on the numpy mailing list, and
(2) Provide a complete, compilable example of the offending code.

Also, you may find it easier to write a pure-C routine and call into  
it using ctypes (getting pointers via numpy arrays' ctypes  
attributes), or alternately, use cython to write the routine.

Zach


On Feb 24, 2010, at 10:28 AM, brennsuppa wrote:

>
> Hi,
>
> I want to gain performance by using C for the computation of some  
> arrays.
> To do that I used this as a help:
> http://www.scipy.org/Cookbook/C_Extensions/NumPy_arrays
>
> Now I want to wirte a subroutine for the calculations with several  
> arrays.
> But I don't know how to pass the arrays to the subroutine.
>
> e.g. i have cin1, cin2, cin3, cin4 and cout
>
> cout = do_anything(cin1, cin2, cin3, cin4)
>
> and do_anything would be like:
>
> double **do_anything(cin1[][n], cin2[][n], cin3[][n], cin4[][n])
>
> for rows
> for columns
> add cin1,cin2,cin3,cin4
> return value
>
> this throws an error "conflicting types for do_anything"
>
> regards,
> joe
> -- 
> View this message in context: http://old.nabble.com/C-Extension-Scipy-Numpy-tp27714231p27714231.html
> Sent from the Python - pythonmac-sig mailing list archive at  
> Nabble.com.
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


From Chris.Barker at noaa.gov  Thu Feb 25 22:53:05 2010
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Thu, 25 Feb 2010 13:53:05 -0800
Subject: [Pythonmac-SIG] C Extension Scipy/Numpy
In-Reply-To: <27714231.post@talk.nabble.com>
References: <27714231.post@talk.nabble.com>
Message-ID: <4B86F141.7050503@noaa.gov>

brennsuppa wrote:
> I want to gain performance by using C for the computation of some arrays.
> To do that I used this as a help:
> http://www.scipy.org/Cookbook/C_Extensions/NumPy_arrays

I highly recommend that you use Cython instead:

http://wiki.cython.org/tutorials/numpy

It is much easier, and you are much more likely to make mistakes with 
reference counting, etc, if you do it by hand. Trust me on this.

With Cython, you can either do all your calculations with Cython, or 
have C routines that do the real work, and use Cython to call them. I'd 
do the former unless your C code is already written (and not trivial). 
In  either case, Cython can handle the conversion from python types to C 
types, and all the reference counting for you.


> Now I want to wirte a subroutine for the calculations with several arrays.
> But I don't know how to pass the arrays to the subroutine.
> 
> e.g. i have cin1, cin2, cin3, cin4 and cout
> 
> cout = do_anything(cin1, cin2, cin3, cin4)
> 
> and do_anything would be like:
> 
> double **do_anything(cin1[][n], cin2[][n], cin3[][n], cin4[][n])
> 
> for rows
> for columns
> add cin1,cin2,cin3,cin4
> return value

Trivial in Cython -- in straight C,  you need to pass in the arrays as 
PyObjects, check if they are the type of arrays you want, and then get 
the pointers to the data blocks for you to pass to your c function.

Cython will do (almost) all of that for you.

-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

Chris.Barker at noaa.gov

From joe at bastarde.at  Fri Feb 26 10:28:15 2010
From: joe at bastarde.at (Josef Sonderegger)
Date: Fri, 26 Feb 2010 10:28:15 +0100 (CET)
Subject: [Pythonmac-SIG] =?utf-8?q?=5B_C_Extension_Scipy/Numpy?=
In-Reply-To: <4B86F141.7050503@noaa.gov>
Message-ID: <20100226092815.86A77106011@dd21600.kasserver.com>

> I highly recommend that you use Cython instead:

> It is much easier, and you are much more likely to make mistakes with 
> reference counting, etc, if you do it by hand. Trust me on this.

There are a few version I tried, but because of the very high mathematical effort I need the fastest solution, wich is doing it by hand.
I have a C-Version already - but I will try Cython again by calling my C routines.

Thank you so far ;)
joe






From zachary.pincus at yale.edu  Fri Feb 26 15:21:35 2010
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Fri, 26 Feb 2010 09:21:35 -0500
Subject: [Pythonmac-SIG] [ C Extension Scipy/Numpy
In-Reply-To: <20100226092815.86A77106011@dd21600.kasserver.com>
References: <20100226092815.86A77106011@dd21600.kasserver.com>
Message-ID: <03CF2CA8-7CFD-4F07-B991-8495B47B35DD@yale.edu>

>> I highly recommend that you use Cython instead:
>
>> It is much easier, and you are much more likely to make mistakes with
>> reference counting, etc, if you do it by hand. Trust me on this.
>
> There are a few version I tried, but because of the very high  
> mathematical effort I need the fastest solution, wich is doing it by  
> hand.
> I have a C-Version already - but I will try Cython again by calling  
> my C routines.

If you already have the C code compiled into a shared library, calling  
into the library with ctypes might be even easier. Especially since  
numpy arrays have handy attributes for getting pointers-to-data as  
ctypes objects.

Zach

From massimodisasha at yahoo.it  Sat Feb 27 12:11:07 2010
From: massimodisasha at yahoo.it (Massimo Di Stefano)
Date: Sat, 27 Feb 2010 12:11:07 +0100
Subject: [Pythonmac-SIG] PyTables installation problems
Message-ID: <31E5FDC0-3AA4-4324-A7FB-BFF673C3600A@yahoo.it>

Hi All,


tring to install Pytables on a mac osx 10.6.2 i get this error :

In [1]: from tables import *
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in <module>
  File "tables/__init__.py", line 56, in <module>
    from tables.utilsExtension import getPyTablesVersion, getHDF5Version
ImportError: No module named utilsExtension


In [2]:


Have you any clue on how to fix it ?
Googling a bit i see it's a "common" problem, but i can't yet find a solution to fix it.

Thanks for any suggestion,

Massimo.

From vze26m98 at optonline.net  Sat Feb 27 20:46:15 2010
From: vze26m98 at optonline.net (Charles Turner)
Date: Sat, 27 Feb 2010 14:46:15 -0500
Subject: [Pythonmac-SIG] Issue with DEVONthink and ASDictionary
Message-ID: <583208CE-2D72-4909-85DF-F1935802E8BD@optonline.net>

Hi-

Not sure if this is the best place to ask this question, but  
ASDictionary can't complete its production of a dictionary for  
DEVONthink Pro Office. See the screenshot here, as I couldn't copy the  
ASD log for some reason:

<http://vze26m98.net/devon/asdictionary.png>

Does anyone have an insight as to what's going wrong?

Leopard 10.5.8, Apple system Python, DTPO 2.01...

Thanks, Charles