Ned Deily n...@acm.org added the comment:
Note, r77031 and r77032 cause compile errors for OS X deployment targets of
10.4 or earlier. See Issue7658 for details and patch.
--
___
Python tracker rep...@bugs.python.org
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've committed the completed patch as r77031 (trunk) and r77032 (py3k)
I will not backport to 2.6 and 3.1 because this is not a bugfix.
--
resolution: - accepted
stage: needs patch - committed/rejected
status: open - closed
Ronald Oussoren ronaldousso...@mac.com added the comment:
FWIW: I now have a 2.7 tree with the new pythonw on my machine, open
issues are:
* Ensure IDLE.app gets build in such a way that the GUI works for
all supported universal binaries (including a 4-way build on 10.5,
where the system
Ned Deily n...@acm.org added the comment:
Another reminder: when implementing, make sure platform.architecture()
always returns the correct results for bits. It seems the Apple patches
in 10.6 don't handle that (it seems to always report 64-bit), probably
because the code in
Ned Deily n...@acm.org added the comment:
For people searching the bug tracker, I've modified the title of the
issue to make it clearer that there is a problem here on OS X 10.6 Snow
Leopard with multiple architecture builds.
As Ronald mentions above, the effect of using the pythonw launcher
Changes by Ned Deily n...@acm.org:
--
versions: +Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6834
___
___
Changes by Robin robi...@gmail.com:
--
nosy: +robince
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6834
___
___
Python-bugs-list mailing list
Ronald Oussoren ronaldousso...@mac.com added the comment:
Ned: I'm planning to use the attached version of pythonw, or a slightly
updated one, for 2.7 and 3.2. This version will not be used for 2.6.5 or
3.1.2 due to backward compatibility constraints.
I will look into the OSX launching issues
Martin v. Löwis mar...@v.loewis.de added the comment:
This version uses posix_spawn rather than execv to start the real
interpreter.
In what way is that better? It creates a new process (IIUC); therefore,
I think that using it is worse than using execv. Anybody killing the
pythonw process
Ronald Oussoren ronaldousso...@mac.com added the comment:
The attached file 'pythonw.c' is a first version of a better pythonw
executable.
This version uses posix_spawn rather than execv to start the real
interpreter. The main advantage of the new implementation is that 'arch
-ppc pythonw'
Ronald Oussoren ronaldousso...@mac.com added the comment:
Let me first explain in more detail why pythonw is needed in the first
place: MacOSX only allows access to a large number of GUI-related APIs
from application bundles (the symbols are of course always available,
but the APIs fail when
New submission from Ronald Oussoren ronaldousso...@mac.com:
Note: this is mostly a reminder for myself to clean up the pythonw stub
executable
The current implementation of pythonw on OSX uses exec to start an
executable inside the framework, this is needed to be able to use GUI
Martin v. Löwis mar...@v.loewis.de added the comment:
Can you kindly report how architecture selection works? Is there a
separate binary which execs? Some other magic?
Asking primarily out of curiosity, but if it's a launcher, then
(sym)linking it into a virtualenv might be sufficient.
13 matches
Mail list logo
