Ronald Oussoren added the comment:
The same fix also works with 2.7.
The attached patch is basically the same patch, but the special casing for OSX
is impacts other platforms even less than before.
--
Added file: http://bugs.python.org/file21247/issue11088-py27.txt
Ronald Oussoren added the comment:
The double execution is definitely caused by having multiple event, one of
which is a real keyboard event and the other one is a ghost one.
I'm seeing calls to save_as with 2 events: the first is a ghost event, with
type 35 and '??' as
Ronald Oussoren added the comment:
It's getting weirder by the minute. Not only do we get multiple events, we also
get additional keybindings we never asked for.
*Cmd+Ctrl+S also works as save as
*Cmd+Shift+S gives two save as events (as was already
Ronald Oussoren added the comment:
Please also add the platform you are using python on, and which installer you
used to install Python.
Assuming that you have a problem with IDLE:
If you used "Mac OS X 64-bit/32-bit Installer (3.2) for Mac OS X 10.6": did you
install a new copy
Ronald Oussoren added the comment:
The 10.4 SDK needs to be changed in 2.7, 3.1 and 3.2 as well: the most recent
version of Xcode no longer ships with the 10.4 SDK (and possibly without the
10.5 SDK as well, I'll writing this at the airport and haven't downloaded the
latest r
Ronald Oussoren added the comment:
I've filed Issue11485 for the SDK issue (the default SDK should be more sane
for normal use).
AFAIK that means it is not necessary to keep this issue open.
--
resolution: -> later
status: open -&
Ronald Oussoren added the comment:
Issue11485 is related to this.
As Ned noted Ned and I will look into this.
--
___
Python tracker
<http://bugs.python.org/issue11
Ronald Oussoren added the comment:
I haven't put much thought in a solution yet, but at this point I'd go for
three changes:
1) Give a clear warning when python was configured for i386/ppc
and Xcode4 is installed (instead of giving a vague compiler crash
due to crapping
Ronald Oussoren added the comment:
The site you mention requires client certificates to log on.
On my machine (OSX 10.6) urllib2 example just hangs. I haven't checked yet why
this happens, or if this also happens on other OS-es or releases.
Other HTTPS sites work fine for me though.
Ronald Oussoren added the comment:
I agree that the egg-info file should be removed in 3.3, especially because
distutils2 has a better way of specifying python version dependencies.
The OSX installers for 2.7, 3.1 and 3.2 should remove the egg-info file for
older releases, that way we at
Ronald Oussoren added the comment:
Ned: we could work around this platform issue by including openssl 1.0d in the
OSX installer. I'm not sure if that's acceptable for a bugfix release though.
--
___
Python tracker
<http://bu
Ronald Oussoren added the comment:
+1 on applying the patch.
I can do so on Sunday but feel to apply the patch before that.
--
___
Python tracker
<http://bugs.python.org/issue11
Ronald Oussoren added the comment:
Running the test in a separate process is a good idea.
The patch should be fine and fixes a problem on OSX, if the buildbot for
FreeBSD starts to complain we can always removing the #if that tests for that
platform
Ronald Oussoren added the comment:
On 07 Apr, 2011,at 07:03 PM, Alexander Belopolsky
wrote:
Alexander Belopolsky added the comment:
While you are at it, can you also fix the same issue with "python -m tkinter"?
Â
Sure, I can add a hack to that module as well.
Ronald
--
Ronald Oussoren added the comment:
Traditionally the functions in os are thin wrappers around OS functions, this
patch changes that for os.fsync.
Two nits wrt. the patch itself:
1) The behaviour on OSX should be documented in the stdlib reference,
that currently says that os.fsync will
Ronald Oussoren added the comment:
See <http://www.kernel.org/doc/man-pages/online/pages/man2/fsync.2.html> for
linux' behavior, in particular: linux doesn't guarantee that data gets writting
to the disk when you call fsync, only that the data gets pushed to the storage
devi
Ronald Oussoren added the comment:
This issue is very annoying when you use python's with different deployment
targets and should IMHO be fixed in the next release.
--
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release
Ronald Oussoren added the comment:
I've committed the fix in 2.7, 3.1, 3.2 and 3.3
--
assignee: -> ronaldoussoren
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<ht
Ronald Oussoren added the comment:
For pydebug builds the default stacksize should be increased, and prefer to do
this by unconditionally changing the stacksize.
W.r.t. the non-osx buildbot failures: it would be better if we could come up
with a solution that doesn't disable the tes
Ronald Oussoren added the comment:
Version 4 of the patch has two changes w.r.t version 3:
* Increase the stack size on OSX to ensure that tests pass with
--with-pydebug
* Only test the recursion behavior on OSX (where we know the bug is
fixed)
--
Added file: http
Ronald Oussoren added the comment:
That's rather annoying. I'm reopening the issue because of this.
I'm looking into the issue and will revert when I cannot find a solution soon.
--
resolution: fixed -> accepted
status: closed -> open
_
Ronald Oussoren added the comment:
This seems to be a bug in ntpath.samefile, in particular in this code:
# determine if two files are in fact the same file
try:
# GetFinalPathNameByHandle is available starting with Windows 6.0.
# Windows XP and non-Windows OS'es will
Ronald Oussoren added the comment:
I'm not sure what the right course of action is, revert my patch try to get
ntpath.samefile fixed and then reapply my patch or something else?
ntpath.samefile is definitely broken on XP:
* Create a file "a.txt"
* Start python3.2
>&
Ronald Oussoren added the comment:
The attached patch seems to fix ntpath.samefile (at least for the shutils
tests, I haven't run a full testsuite and cannot build python on a windows
machine anyway)
--
Added file: http://bugs.python.org/file21908/npath-fi
Ronald Oussoren added the comment:
I'm currrently running 'python -mtest.regrtest -uall' on an XP machine where
I've applied my test to a binary install of 3.2.
I'll apply my patch if that testrun indicates that I don't introduce other
problems, and I'
Ronald Oussoren added the comment:
I've committed my fix for ntpath.samefile for 3.3 and 3.2.
I've also filed a new issue because ntpath.samefile has no unittests.
--
___
Python tracker
<http://bugs.python.o
New submission from Ronald Oussoren :
Python 3.2 introduced ntpath.samefile, but the implementation is not tested in
test_ntpath.py. The same seems true of ntpath.sameopenfile.
As noted in #10684 ntpath.samefile is broken on XP, which would have been
caught by unittest. I've committed
Changes by Ronald Oussoren :
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10684>
___
___
Pyth
Ronald Oussoren added the comment:
I've attached a v2 of the patch which adresses Éric's comments.
I haven't changed the CompileError handling though, that would change a test
failure into a test error. IMHO test errors should only happend due to bugs in
the test code.
Add
Ronald Oussoren added the comment:
The attached patch implements the change that Marc-Andre proposed.
I intend to apply this patch to all active branches later today (after some
more testing)
--
keywords: +patch
Added file: http://bugs.python.org/file21916/issue10154.patch
Ronald Oussoren added the comment:
This shell-fragment lists which names in /usr/include/sys/errno don't exist in
errnomodule.h:
$ grep '#define[ ]*E' /usr/include/sys/errno.h |
awk '{ print $2 }' | grep -v '^ELAST$' |
while read name
Ronald Oussoren added the comment:
And the patch works properly, with the patch applied (except for the two names
I mentioned earlier):
$ DYLD_FRAMEWORK_PATH=$PWD ./python.exe
Python 3.3a0 (default:5fa92a47016c+, May 7 2011, 09:36:44)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file21728/unnamed
___
Python tracker
<http://bugs.python.org/issue10910>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
The problem is that pyport tries to replace the ctypes definion of the
isascii(ch) and related functions by a replacement that works better with UTF-8
on FreeBSD and OSX. That replacement is incompatible with the localfwd.h header.
The attached patch is a
Changes by Ronald Oussoren :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5154>
___
___
Python-bugs-
Ronald Oussoren added the comment:
There is not enough information in the description to even know which program
crashes, let alone to reproduce the problem.
I'm therefore closing this issues. Feel free to reopen the issue when you can
supply more information (see the questions in th
Ronald Oussoren added the comment:
Steffen, I don't understand your comment about "auto". Declaring variables as
"auto" is not necessary in C code and not used anywhere else in Python's source
code.
--
___
Python tr
Ronald Oussoren added the comment:
FWIW I'm in favor of shipping libedit as well with the 32-bit variant of the
installer. The installer for 10.6 can continue to use the system install,
that's good enough for to be used.
The download link for the copy in OSX 10.6.7
Ronald Oussoren added the comment:
I'll apply the patch late tonight (I won't be home until at least 22:30 CEST)
--
___
Python tracker
<http://bugs.python.
Changes by Ronald Oussoren :
--
versions: -Python 3.1
___
Python tracker
<http://bugs.python.org/issue9516>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
Attached the backport to 2.7 for my v2 patch.
--
Added file: http://bugs.python.org/file21997/issue9516-v2-python2.7.patch
___
Python tracker
<http://bugs.python.org/issue9
Ronald Oussoren added the comment:
I've applied the patches to 3.3, 3.2 and 2.7
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyt
New submission from Ronald Oussoren :
When I run the test suite on OSX (configure; make test) I get unexpected est
failures:
6 tests failed:
test_codecencodings_cn test_codecencodings_hk
test_codecencodings_jp test_codecencodings_kr
test_codecencodings_tw
When I run one of these
Ronald Oussoren added the comment:
I've verified the issue in a fresh download of revision c449d3c3e0da of the 2.7
branch.
I'm on OSX 10.6, but that's not really relevant for this issue.
If I'm using 'hg bisect' correctly (and that's a big if as I haven
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue10154>
___
___
Changes by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10154>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
I've applied a fix for #10154 and that also fixes this problem.
--
nosy: +ronaldoussoren
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python
Ronald Oussoren added the comment:
I've filed #9451707 about this in Apple's bug tracker.
BTW. I don't think this is a platform bug, neither the manpage nor the unix
specification at
<http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html> specify what
ha
Ronald Oussoren added the comment:
I don't really like this patch, but like crashes that cause data loss even
less...
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http:
Ronald Oussoren added the comment:
I'm not sure if Apple's tracking FreeBSD, but they at the very least heavily
borrow code (see <http://opensource.apple.com/source/Libc/Libc-594.9.4/> for
libc)
--
___
Python tracker
<htt
Ronald Oussoren added the comment:
This patch adds an flag to the configure script:
--without-framework-applications.
When this flag is used 'make install' will not create /Applications/Python 3.3,
and won't install IDLE.app and PythonLauncher.app
--
keywords: +pat
Ronald Oussoren added the comment:
On 27 Nov, 2010, at 0:42, Terry J. Reedy wrote:
>
> Terry J. Reedy added the comment:
>
> Is this a duplicate of other issues (close?)?
I don't know yet.
> Is this an Apple problem beyond our control (close?)?
This might be fixab
Ronald Oussoren added the comment:
Ned: I was thinking of Issue6075
The patch in that issue needs work, IIRC I was pretty sure at the time that the
patch was too large and changed more code that it should have.
Sadly enough I have barely had time to do any open-source work at all the last
New submission from Ronald Oussoren :
I just noticed that distutils creates an egg-info for the stdlib while
installing Python.
This definitely happens for Python 2.7 and Python 3.2 (both framework builds on
OSX).
In lib-dynload there is and egg-info file: "Python-2.7.1-py2.7.egg-info&
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
Ned: why does the patch change the signature of close_all_callback?
-def close_all_callback(self, event):
+def close_all_callback(self, *args, **kwds):
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
UTF-8 works on SuSE Enterprise Linux 9 and 10 as well.
BTW, neither UTF8 nor UTF-8 work on HPUX 10. That platform requires spelling it
as utf8.
This sadly enought means that this code doesn't work on HPUX 10:
>>> locale.setlocale
Ronald Oussoren added the comment:
Ned: never mind the command callback has a different signature than a
keybinding.
Committed the patch for 3.2 in r87119.
--
___
Python tracker
<http://bugs.python.org/issue10
Ronald Oussoren added the comment:
The patch binds the menu to Ctrl-Button-1 (that is, the way you open context
menu's on OSX systems with a single button), however rightclick still doens't
work (but does an X11-style paste operation).
I propose adding an explicit binding for b
Ronald Oussoren added the comment:
Merged to 3.1.x in r87120, merged to 2.7. in r87121.
Ned: thanks for looking into this, doubly so because Tk-on-OSX is involved.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
Ronald Oussoren added the comment:
Fixed in r87122.
Thanks you.
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ronald Oussoren added the comment:
(reopening to ensure glyph's message doesn't get lost)
--
status: closed -> open
___
Python tracker
<http://bugs.pyth
Ronald Oussoren added the comment:
Yet another prove of how much Tk sucks on OSX.
I'm not too happy about only binding Ctrl+, because users will expect
that this is means that works as well. But if we cannot disable the
default binding we'll have to live with
Ronald Oussoren added the comment:
Oops, 's/prove/proof/'
--
___
Python tracker
<http://bugs.python.org/issue10404>
___
___
Python-bugs-list mailing
Ronald Oussoren added the comment:
I agree with Martin that this is a tricky one.
The file is problematic because it is invalid XML[1], however Apple's tools are
perfectly happy to proces the file and as Mitchell notes plistlib exists to
interoperate with Apple's plist files.
I&#
New submission from Ronald Oussoren :
I ran into this issue while debugging why py2app doesn't work with python
3.2rc2. The reason seems to be a regression w.r.t. having the stdlib inside a
zipfile.
Note that I haven't tested this without going through py2app yet.
py2app basicly r
Ronald Oussoren added the comment:
The python32.zip file generated by py2app contains both files from the stdlib
and application files. I cannot avoid haveing non-ascii filenames when a
python package contains data files that have such names.
The patch in Issue10972 would be nice to have
Ronald Oussoren added the comment:
Data files can be anything that can be a data-file in a setuptools/distribute
setup.py file. Note that #10972 isn't necessary when python32.zip is build
using the zipfile module, _encodeFilenameFlags uses either ASCII or UTF-8 to
encode filenames an
Ronald Oussoren added the comment:
Michael: Why must the subprocess started by IDLE be in 32-bit mode if we'd run
IDLE in 32-bit mode? AFAIK there is no technical reason to do so.
Not that running IDLE in 32-bit mode is an option, it wouldn't fix the issue by
itself unless we'
Ronald Oussoren added the comment:
On 25 Jan, 2011, at 13:41, Michael Foord wrote:
>
> Michael Foord added the comment:
>
> Ronald: The subprocess also uses Tkinter (right?) so would also require
> 32bit.
Not AFAIK. I'm pretty sure I've had a 3-way build in the
Ronald Oussoren added the comment:
Use:
configure ...[other args]... MACOSX_DEPLOYMENT_TARGET=10.5
(or 10.6 when you're on a 10.6 system)
This will build using the deployment target you mention, and will automaticly
include the readline module using Apple's compatiblity wrap
Ronald Oussoren added the comment:
I'm -0 on removing extras. Having extra's at this location makes it easier to
discover them.
Adding a link to the documention is a good idea, it makes the documentation
easier to use without starting IDLE.
Adding an uninstall option would be nice
Ronald Oussoren added the comment:
Can you provide a script that shows the problem? Without such a script it will
be hard to reproduce, and fix, this problem.
--
___
Python tracker
<http://bugs.python.org/issue11
Ronald Oussoren added the comment:
'make install' works for me as well (OSX 10.6, configure
--prefix=/tmp/python32).
Could you attach the output of "make install", with some luck there will be a
clear indication of why the install doesn&#x
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
At first glance the current behaviour is correct:
1) Bundles aren't shared libraries, but plugin code. It should be
possible to load bundles, but I don't agree that find_library should try
to locate them, specially given
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Bill, even if find_library were to emulate the runtime linker it shouldn't
find objects of type MH_BUNDLE.
Those are not shared libraries, but explicitly meant to be used as code
resources for plugins. find_library should not
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Is this on OSX 10.4?
I'll fix this tonight or tomorrow (the latter would probably result in a
commit on sunday morning PST).
The fix will look like this:
#ifdef __LP64__
FSIORefNum fRefNum;
#else
SInt16
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This should be fixed in revision 63997.
--
resolution: accepted -> fixed
status: open -> pending
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Ronald Oussoren <[EMAIL PROTECTED]>:
test_distutils fails when you're not building in the root of the source
tree.
That is:
mkdir build
cd build
../configure
make
make check
This fails like this:
test test_distutils failed -- Traceback (most recen
New submission from Ronald Oussoren <[EMAIL PROTECTED]>:
test_list, and possible other tests, use a lot of memory when Python is
build in 64-bit mode. This causes heavy swapping when the machine doesn't
have a huge amount of memory.
I've filed this bug because an OSX box with
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This should be fixed on the trunk, I've introduced a new configure option
that makes it possible to build a 4-way universal build on OSX 10.5
Note that the default build will still be a 2-way universal build that
runs on 10.3.
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
components: +Tests -Distutils
type: -> behavior
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Unassigning because I don't have time to work on this.
The call to cachrsrc.py could probably be just removed from the
Makefiles, this is a script that works with MacOS resource files and if
the Mac-specific modules have b
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This is rather annoying, gcc doesn't accept multipe -isysroot flags on
10.4, yet we need to specify -isysroot during configure to ensure that
tests are done using the right SDK, otherwise most of configure will use
the sys
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
configure-patch-3381.txt should fix the issue, but I cannot test on 10.4
as I recently had to convert my only 10.4 machine to 10.5.
Added file: http://bugs.python.org/file10912/configure-patch-33
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Note to self: never rush a patch
configure-patch-3881-1.txt is the better patch, the other looks right but
using square brackets which don't survive autoconf.
BTW. the patch is only for configure.in, run autoconf to update
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Yet another version: configure-patch-3381-2.txt is a slight enhancement
of the first version.
This version also moves the calculation of MACOSX_DEPLOYMENT_TARGET a
lot
earlier in configure.in, to ensure that the right value is
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The attached patch should fix this issue. I cannot test on 10.4 though.
BTW. The patch only updates configure.in, run autoconf afterwards to
update the configure script itself.
Added file: http://bugs.python.org/file10914/configure
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
priority: -> deferred blocker
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The easiest way to test the configure bits would be to build on 10.5 with
--enable-universalsdk and --enable-universalsdk=/. Both should work on
10.5, while using different SDKs (with slightly different unix APIs).
However: it sho
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Forgot to upload updated patch
Added file: http://bugs.python.org/file10923/configure-patch-3381-2.txt
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
This patch is wrong, it drops the call to 'arch' entirely even when the
call is needed.
The suggestion for "ARCHPREFERENCE" won't work though, "arch" doesn't take
arguments at all on 10.4.
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Whoops, issue 3393 is a duplicate of this issue and notes that
Mac/IDLE/Makefile.in is also affected.
I've fixed that makefile in r65091.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The current trunk should be correct, there are no explicit calls to the
arch command left, all go through the configure replacement magic.
To test if everything is correct now someone should test the following
scenarios:
* Build --
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
BTW. There is a "--with-framework-name" argument to configure that makes
it possible to have several indepenend framework installations
___
Python tracker <[EMAIL PROTECTED]>
&
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Committed in r65183.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
The issue was introduced while moving universal-binary specific trickery
from pyconfig.h.in to a separate header file. Obviously I must have been
drunk at the time, because I didn't move the WORDS_BIGENDIAN bits
correctly.
T
New submission from Ronald Oussoren <[EMAIL PROTECTED]>:
I'm trying to build python 2.6 on a Mac OS X 10.3 system. This fails to
build the multiprocessing extension due to a missing definition of "struct
iovec".
It turns out that you have to include to get that de
Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
priority: -> critical
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4064>
___
__
New submission from Ronald Oussoren <[EMAIL PROTECTED]>:
When using a universal build of python on macosx
distutils.util.get_platform should use "fat" for the machine
architecture, instead of the architecture of the current machine.
That's not what's currently happe
201 - 300 of 2445 matches
Mail list logo
