Ronald Oussoren 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 you are calling them
Ronald Oussoren added the comment:
Fixed in r74672 (trunk), r74681 (2.6), r74682 (3.x) and r74683 (3.1)
With the default configure flags you'll end up with a 64-bit build of
Python on Snow Leopard, including a 64-bit copy of IDLE.
--
resolution: accepted -> fixed
stage: ->
Ronald Oussoren added the comment:
I've attached a new patch "arch-intel-v2.patch" that relects my current
thinking about this patch.
This adds two new options to the "--with-univeral-archs" option for
configure: "intel" and "3-way". The former
Ronald Oussoren added the comment:
This seems to be a problem with Apple's copy of Python or with your
machine.
Could you try the following:
* In terminal.app run /usr/bin/python
* Then use 'import objc' from Python's prompt.
* Does this work or does it give the same tra
Ronald Oussoren added the comment:
I'm closing this issue because the user does not respond to my questions
and because I don't agree there is a problem.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<htt
Ronald Oussoren added the comment:
Build Applet is not present in Python 3 because the implementation uses
Python modules that aren't present in Python 3 (in particular the long
deprecated Carbon bindings).
The best alternative to the Build Applet functionality is py2app, but that
is
Ronald Oussoren added the comment:
I found an easier way to test with a 64-bit Tcl/Tk: run Snow Leopard ;-)
--
___
Python tracker
<http://bugs.python.org/issue6
Ronald Oussoren added the comment:
This will be fixed in the next release of 2.6 and 2.7: bundlebuilder
shouldn't have tried to copy version.plist in the first place.
The actual revisions in which this was fixed: r74684 (trunk), r74685 (2.6)
--
resolution: -> fix
Ronald Oussoren added the comment:
The zipfile is technically incorrect, the zipfile specification prescribes
that all filenames use '/' as the directory separator.
Even without that caveat the file is corrupt because the zipfile directory
header and the per-file header don'
Ronald Oussoren added the comment:
Could you retry the build after cleaning the target directory?
I've seem simular failures in the past and haven't been able to find the
root cause of that problem.
--
___
Python tracker
<http://bu
Ronald Oussoren added the comment:
You're right. I've fixed this in r74686.
--
___
Python tracker
<http://bugs.python.org/issue6802>
___
___
Python-b
Ronald Oussoren added the comment:
As mentioned before I'm closing this as "won't fix" because this is an
issue with Apple's copy of Python, not the one shipped by us (the generic
Python tree doesn't even compile correctly when using libedit)
--
resolut
Ronald Oussoren added the comment:
Closing this bug as it is for an old version of Python and I cannot
reproduce this issue.
--
resolution: -> works for me
status: open -> closed
versions: +Python 2.5
___
Python tracker
<http://bugs.p
Ronald Oussoren added the comment:
Could you provide an example that shows why adding support for the -rpath
option on OSX would be useful? (As in a set of source files that shows how
this support would be used).
As I mentioned before the OSX support for -rpath behaves completely
different
Ronald Oussoren added the comment:
The warning does not occur on recent versions of OSX (10.5, 10.6),
therefore closing the issue.
--
nosy: +ronaldoussoren
resolution: -> out of date
status: open -> closed
___
Python tracker
Ronald Oussoren added the comment:
Closing this issue, the patch is no longer needed because the current
Makefiles already have DESTDIR support.
--
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
___
Pytho
Changes by Ronald Oussoren :
--
nosy: -ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue1445781>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
This is no longer a problem with 2.6.x from SVN and Xcode 3.2 (on OSX
10.6). I haven't tested if the problem is still present on other versions
of OSX, but I'd say it is pretty safe to assume that this was a toolchai
Changes by Ronald Oussoren :
--
nosy: -ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue1677>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
I've applied the fixed version of my patch in r74687 (3.x) and r74688
(3.1).
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.pyt
Ronald Oussoren added the comment:
The patches look acceptable on first glance.
Which configurations of Tk have you tested? IMHO IDLE should work with the
following configurations:
* Tk.framework as supplied with OSX 10.4, 10.5 and 10.6
* The current releases of Tk 8.4 and 8.5 installed in
Ronald Oussoren added the comment:
The (untested) attached patch ("setup-tk-archs.patch") updates the code in
setup.py to automaticly detect the architectures that are supported by the
Tk framework and passes '-arch' flags to the compiler for the intersection
of the conf
Ronald Oussoren added the comment:
alan: I don't quite understand which filename you want to use when the
name in the per-file header and the central directory don't match.
Where in the standard is this prescribed? I couldn't find anything in
the PKWare zipfile appnote [1]
Changes by Ronald Oussoren :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue1584>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
If I understand you correctly the same also happens with the current
version in subversion.
To reproduce:
* Start IDLE.app
* Open a new window
The new window opens, but (1) without a proper titlebar, and (2) this
makes it impossible to further interact
Ronald Oussoren added the comment:
I'm about to test the patches on a 10.4 system with Tk 8.4 and will report
back with the results.
These patches might be useful to issue 6864, that issue says IDLE blocks
on 10.6 and that problem seems to be fixed in python-trunk + Kevin'
Ronald Oussoren added the comment:
I wouldn't mind having a proper patch and doing away with the need for
GNU's readline.
IMHO the patch should try to stay as close to GNU readline's interface
as possible, and should therefore fix the off-by-one difference you
mention.
BTW
Ronald Oussoren added the comment:
I'm +1 on merging this functionality.
See also: issue6872
As I mentioned there we should ensure that readline linked to libedit
has the same semantics as readline linked to GNU readline, and because
the configuration file of libedit has a different f
Ronald Oussoren added the comment:
Committed in 74806 (trunk), 74807 (2.6), 74808 (3.x), 74809 (3.1)
--
keywords: -needs review, patch
resolution: -> fixed
stage: -> committed/rejected
type: -> feature request
___
Python track
Changes by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue6245>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
I just commited a fix for this, the patch is present in all 4 active
branches (2.6, 2.7, 3.1, 3.2)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: crash -> behavior
__
Ronald Oussoren added the comment:
It seems that CoreFoundation doesn't like being loaded on a secondairy
thread:
#0 0x7fff8301bb90 in __CFInitialize ()
#1 0x7fff5fc0d5ce in
__dyld__ZN16ImageLoaderMachO11doImageInitERKN11ImageLoader11LinkContextE
()
#2 0x7fff5fc0d6
Ronald Oussoren added the comment:
purpleidea : Whether or not indexes should be 0-based in general is beyond
the scope of this issue.
--
___
Python tracker
<http://bugs.python.org/issue6
Ronald Oussoren added the comment:
This probably means that the ctypes code in urllib.py needs to be ported
to C, although we won't know if that helps until said C code is written
:-(
Doing that would be a good idea anyway, while trying to create a
workaround I noticed that the ctypes
Ronald Oussoren added the comment:
The attached patch is a slightly cleaner version of your patch. What I
don't like is that I'm also using runtime detection of libedit, I'd
prefer compile-time detection but that doesn't seem possible without
doing that dtection in s
Ronald Oussoren added the comment:
I've added an updated patch to issue 6877 that implements the same 1-based
indexing as GNU's readline and also adds a note to the documentation to
warn users about the possibility of linking the readline module to
libedit.
That patch would, pos
Changes by Ronald Oussoren :
--
priority: -> release blocker
___
Python tracker
<http://bugs.python.org/issue6851>
___
___
Python-bugs-list mailing list
Un
New submission from Ronald Oussoren :
When I compile the trunk on MacOS X 10.6 I get a compile (or rather
link) error in ctypes:
ld: in build/temp.macosx-10.5-fat3-
2.7/Users/ronald/Projects/python/python-trunk-
clean/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o, unsupported
encoding in
Changes by Ronald Oussoren :
--
priority: -> release blocker
___
Python tracker
<http://bugs.python.org/issue6864>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
Annoyingly PyObjC suffers from the same issue. I hadn't noticed this yet
because I've been linked to the system copy of libffi the last couple of
months.
Luckily Apple has already released the source code for libffi in 10.6
Ronald Oussoren added the comment:
The attached patch seems to fix the issue, but needs further testing.
Warning: the patch is not entirely clean, the patch contains an
unrelated change to setup.py.
The patch replaces some code that uses ctypes to read configuration data
using the
Ronald Oussoren added the comment:
kevin: do you know if there is a plain Tcl script that shows the bug? If
there is we can file a bugreport with Apple that clearly shows a problem
in the Tk framework and hence makes it more likely that the issue will get
fixed
Ronald Oussoren added the comment:
Mark: yes those functions need to be changed as well.
--
___
Python tracker
<http://bugs.python.org/issue6877>
___
___
Pytho
Ronald Oussoren added the comment:
Jesse: is this something you can look into?
This is a crash of multiprocessing on MacOSX 10.6 with a 64-bit build of
python.
--
assignee: ronaldoussoren -> jnoller
nosy: +jnoller
___
Python tracker
&l
Ronald Oussoren added the comment:
Thanks. I'll fix this over the weekend.
--
___
Python tracker
<http://bugs.python.org/issue6934>
___
___
Python-bugs-l
Ronald Oussoren added the comment:
Jesse: Apple can fix their own copy of python (which is 2.6.1), I was more
worried about the upcoming 2.6.3 release.
I'll file a bug with Apple and poke their Python maintainer once 2.6.3 is
rel
Changes by Ronald Oussoren :
--
assignee: jnoller -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue6937>
___
___
Python-bugs-list mai
Ronald Oussoren added the comment:
Thomas: I haven't fixed anything yet.
The error only happens when building a PPC binary (either a single-
architecture build on a PPC machine or a fat binary).
The error occurs in assembly files that contain manually constructed C++
exception stack u
Ronald Oussoren added the comment:
The attached patch was not 100% correct in the error handling in the
set_proxies functions. That is fixed in the actually commit.
Committed as r74962 (trunk), r74963 (2.6).
--
resolution: accepted -> fixed
stage: needs patch -> committed/re
Ronald Oussoren added the comment:
I've just committed a fix for another issue and that completely removes
the ctypes-based code that causes this issue (replacing it by a C
extension)
Therefore this issue should no longer occur and hence can be closed.
--
resolution: -&g
Ronald Oussoren added the comment:
I've fixed this issue in all 4 active branches.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: compile error -> behavior
versions: +Python 2.6, Python 2.7 -Python 3.0
_
Ronald Oussoren added the comment:
To build universal build of Python use "--enable-universalsdk" or "--
enable-universalsdk=/" (the former defaults to the 10.4 SDK, which
doesn't support a 64-bit build). You can then use the "--with-
universal-archs" opt
New submission from Ronald Oussoren :
The documentation for the readline module is a bit too minimal.
1) function 'add_history' is described at the end of the documentation,
not near the other functions for manipulation the history stack.
2) the index for remove_histor
Ronald Oussoren added the comment:
Mark: it turns out that GNU readline has a rather odd interface, only
the index of get_history_item is 1-based, all others are 0-based. This
is not mentioned in the documentation (neither that of the readline
module or the GNU documentation).
I've att
Ronald Oussoren added the comment:
Committed my latest version of the patch as r74970 (trunk) and r74971
(3.2)
Barry: what's your opinion on a backport of this to 2.6?
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/i
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: -> committed/rejected
type: crash -> compile error
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
This is a duplicate of issue 6877, I'm therefore closing this one.
I've just committed a slightly updated patch from that issue to the trunk
and 3.2.
--
resolution: -> duplicate
status: open -> closed
__
Ronald Oussoren added the comment:
This should be fixed in the trunk and 2.6 branches due to autodetection of
the -arch_only flag (which was needed for OSX 10.6 support)
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
resolution: -> fixed
status: open ->
Ronald Oussoren added the comment:
The value of sys.path is rather strange, it includes both the system
Python.framework and one in /Library/Frameworks.
Have you installed a copy of Python (for example by using the 2.6.2
installer on the Python.org website)? If so, have you added symbolic
Ronald Oussoren added the comment:
I've merged the latest copy of Apple's version of libffi into libffi_osx,
that ensures that libffi compiles again on OSX 10.6.
Checked in in r74972 (trunk), r74973 (2.6), r74974 (3.x), r74975 (3.1).
--
resolution: -> fixed
stage:
Ronald Oussoren added the comment:
I've svnmerge-d the patch in r74976.
BTW. Thanks for checking the various Tk releases on 10.5/10.6.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
I agree that we should mention in the news file that Apple's version of
Tk 8.5 in Snow Leopard causes problems with IDLE.
W.r.t. Tk 8.4 vs. 8.5: the 2.6 binary releases will be linked to Tk 8.4
because of two reasons. Firstly all 2.6 releases upto now
Ronald Oussoren added the comment:
To explain my previous entry about shipping 8.4 and 8.5 versions of
_tkinter, one way to implement this is:
* Build two copies of _tkinter.so: _tkinter84.so and _tkinter85.so
* Add _tkinter.py to Lib/plat-mac with the following contents:
try
Ronald Oussoren added the comment:
The problem is *not* reproducible using the trunk (2.7).
I haven't been able to isolate the change that fixes the issue. As a
quick hack I replaced _tkinter.so and Lib/idlelib/*.py in a 2.6 tree by
the same files from the trunk. That didn't fix
Ronald Oussoren added the comment:
I'm re-prioritizing this as "high" because the binary installer won't
suffer from this issue and there is no straightforward bugfix.
--
priority: release blocker -> high
___
Python tracker
Changes by Ronald Oussoren :
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.pytho
Ronald Oussoren added the comment:
This should have been closed, although readline shouldn't crash either.
Brett: What version of OSX do you use? Readline works fine for me on OSX
10.6 without GNU readline.
BTW. The crashlog indicates you are no longer using GNU readline, but
use s
Ronald Oussoren added the comment:
It should be possible to tweak distutils to do the right thing for
upcoming releases, distutils already contains some special code to allow
building extensions for a univeral build on 10.3.9 (where the compiler
doesn't support universal builds at all
Ronald Oussoren 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' wor
Ronald Oussoren added the comment:
Better yet:
otool -vL $(python -c 'import readline; print readline.__file__')
(Replace "python" by the interpreter that your actually using).
I'm still interested to know the OS release as well.
--
_
Ronald Oussoren added the comment:
I've tested with readline 6 on OSX 10.6 as well. Both that and the system
readline (libedit emulation) work just fine for me.
The current behaviour for me:
* When GNU readline is present in /usr/local it gets used
* Otherwise libedit gets
Ronald Oussoren added the comment:
As Ned noticed the readline failure is expected unless you have installed
GNU readline in /usr/local. The system readline is not supported in the
2.6 branch, it will be supported in 2.7 (at least on Snow Leopard)
I've commited a fix for the Nav.c erro
Ronald Oussoren added the comment:
Zvezdan: I did not have to pass additional arguments to get readline, the
default machinery automaticly picks up libraries in /usr/local.
I'd love to have a way to restrict the default compiler and linker search
paths to system locations (e.g. exclude
Ronald Oussoren added the comment:
There is a much easier solution for the 2.6.3 release: ensure that CC=gcc-
4.0 when building the installer.
That requires minimal changes to the build machinery and should be safe
enough.
The only change to distutils I do want to make for 2.6.3 is to detect
Ronald Oussoren added the comment:
r75022 (trunk) and r75023 (2.6) add the other half of my proposal:
distutils will ignore -isysroot SDKPATH when SDKPATH is not present on the
current system.
That combined with explicit compilation using gcc-4.0 should solve these
build issues with the OSX
Ronald Oussoren added the comment:
Committed in r75147 (trunk) and r75148 (2.6)
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
Michael: please file a new issue for this, your problem seems to be
unrelated to this one.
In that issue include information about:
1) The python version you are using
2) The version of MacOSX
3) The version of Xcode (open /Developer/Applications/Xcode.app
Ronald Oussoren added the comment:
Michael: Again, please file a new issue for your problem because it is not
related to this one.
I'm removing myself from the nosy-list for this bug.
--
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
I have tried to apply the patches to python's trunk, but they don't apply
cleanly at all.
Could you please rework the patches into a single larger patch that
applies to the trunk.
--
___
Python trac
Changes by Ronald Oussoren :
--
nosy: -ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue4064>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
Fredrik: OSX 10.6 was released after Python 3.1.1. I know that we had to
apply a number of patches to the 2.6 branch to get that to compile
properly on 10.6, and those should have been forward ported to the 3.1
branch.
Could you please do a checkout of the
Ronald Oussoren added the comment:
The crash happens whenever you import code on a secondairy thread.
I consider this a platform bug in the implementation of dlopen, because
the crash also occurs with this variant on test():
def test():
print "DL"
p = os.path.join(os.pa
Ronald Oussoren added the comment:
This seems to be a known issue: importing extensions in a thread fails on
OSX 10.6 (with a hard crash of the interpreter). The crash in inside the
initialisation function for an Apple framework.
I haven't been able to determine if the problem is in P
Ronald Oussoren added the comment:
Barry: this should be a release blocker, I introduced the problem around
or after 2.6.3 :-(
When do you cut rc2? I probably won't be able to provide a patch myself
until Saturday afternoon (CEST).
--
priority: -> release
Ronald Oussoren added the comment:
I've attached a patch for the trunk that fixes the issue and passes
test_urllib.py on the trunk.
What I haven't done yet is write some unittests that actually test
different proxy configurations, that would require changing the
SystemConfiga
Ronald Oussoren added the comment:
I've posted a patch for this in Issue7149.
--
___
Python tracker
<http://bugs.python.org/issue7044>
___
___
Python-bugs-l
Ronald Oussoren added the comment:
Fixed in r75483 (2.6), 75482 (trunk)
--
resolution: accepted -> fixed
stage: -> committed/rejected
type: -> behavior
___
Python tracker
<http://bugs.python.o
Changes by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7149>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
Fixed in r75482 (trunk) and r75483 (2.6)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
The root cause for this issue is Apple's broken installer system: Apple
does have a package installer, but does not provide tools to uninstall
packages.
I'm reluctant to provide an uninstaller as part of the Python project,
such a tool wou
Ronald Oussoren added the comment:
The fixes will be in 3.1.2 and 3.2 when those are released. I don't know
when that it though, until than you can build the version in the
repository.
The 3.1 branch tends to be stable, developers are supposed to only port
bugfixes to this branch
Changes by Ronald Oussoren :
--
assignee: ronaldoussoren ->
components: -Macintosh, Windows
___
Python tracker
<http://bugs.python.org/issue1646838>
___
_
Ronald Oussoren added the comment:
I agree with Ned that neither ~/.local nor /etc are a good fit for OSX,
sadly enough I wasn't paying attention when ~/.local was added as python
already had a per-user directory on OSX: ~/Library/Python.
The common unix directories are often not a good
Ronald Oussoren 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 though, it w
Changes by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue1628484>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
I don't think so. stdio on OSX has a fdiscard function, but that's not
exposed to Python.
I tend to explicitly synchronize on prompts when communicating with an
interactive program over a pipe. That is, read until you found the prompt,
then send
Ronald Oussoren added the comment:
The "graphics" module runs Tk in a separate thread, which means it
accesses the Apple GUI frameworks from a thread that is not the main
thread.
This is AFAIK not supported by Apple, which would explain why it doesn't
work.
I'll lo
Ronald Oussoren added the comment:
<http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Mul
tithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/u
id/1057i-CH12-SW1> summarizes the thread safety aspects for Apple GUI
programs.
Basic
Ronald Oussoren added the comment:
The patch looks good to me.
IMHO this should be backported to 2.6 as well.
--
keywords: +needs review
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue7
Ronald Oussoren added the comment:
I've tested a backport of the patch to 2.6 (just replace set_proxy by
_set_proxy in the patch) and the resulting version of urllib2 can login to
the proxy (as expected).
Thanks for the patch.
--
___
P
1801 - 1900 of 2445 matches
Mail list logo
