New submission from Ned Deily:
OS 10.8 Mountain Lion includes a new feature that "helps protect users from
downloading and installing malicious software" by providing a mechanism for
developers to sign their installable objects with a unique Apple-signed
Developer ID certificate. T
Ned Deily added the comment:
An additional point: the 3.3.0 Installer README and python.org web pages need
to be updated to incorporate 10.8 installation information as necessary prior
to final release. (in progress)
Also, s/singing/signing
New submission from Ned Deily:
The current situation with Tcl/Tk on OS X is less than ideal. The
Apple-supplied versions of the Cocoa-based Aqua Tk 8.5 on 10.6 was unusable
with IDLE and most Tkinter applications. The 10.7 and 10.8 versions are better
but still have serious crashers that
Ned Deily added the comment:
Yes, it would have to be a subset since some of the stuff in the ActiveTcl
releases is unavailable anyway. But the current ActiveTcl installer dmgs are
around 24Mb while the 3.3.0 installers are a little less than 20Mb. Even if it
were to double the size, 40Mb
Ned Deily added the comment:
This appears to be the same issue as raised in Issue12669. Apparently it is
not fixed.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
The "chr() arg not in range(0x11)" from test_unget_wch is due to a bug in
ncurses < 5.8; see Issue15037.
--
___
Python tracker
<http://bugs.pytho
New submission from Ned Deily:
With 3.3.0b2, when IDLE is started from a command line using
an OS X framework build (such as provided by the python.org
installers), the Aqua Tk menu customization is no longer being
performed, for example, no Preferences menu item, an extra Options
menu, etc. It
Ned Deily added the comment:
Applied for 3.3.0rc1
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ned Deily added the comment:
I took a quick look at the issue and I could reproduce by doing a "make
install" of 3.3.0b1 then a build and "make install" of 3.3.0b2 in the same
locations. Doing a clean 3.3.0b2 build and install produce the expected
results. It appears t
Ned Deily added the comment:
What version of 10.8 are you seeing those messages with? And do you see them
without the patch applied?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
On current OS X systems (tested on OS X 10.7.4), the 2-finger scrolling gesture
scrolls IDLE text editor windows with long files, tested with current versions
of ActiveTcl 8.5 and ActiveTcl 8.4. So I think the issue can be closed.
--
nosy: +ned.deily
Ned Deily added the comment:
The patch looks good to me. Thanks for setting up the infrastructure to allow
reproducible testing!
--
stage: needs patch -> commit review
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
To be clear, I've eliminated the problem for the OS X installer builds by
supplying newer versions of libncursesw so I wasn't planning on doing anything
more on this issue myself. It should be easy enough to reproduce on most
platforms by installing nc
Ned Deily added the comment:
An update: ActiveState has released a Tcl/Tk 8.5.12.1 for OS X and, while it
fixes a similar crash-on-copy from within the Wish shell, it doesn't fix the
crash-on-copy from within tkinter and IDLE. Plus, I notice now there's also
another regression in 8
Changes by Ned Deily :
--
nosy: +ned.deily
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15730>
___
___
Python-bugs-list mai
Ned Deily added the comment:
I believe the issue Ronald is referring to is Issue9670. I tried your test
program with a current MacPorts Python 2.7.3 and Django 1.4 and, as Ross saw,
it failed gracefully with a "maximum recursion depth exceeded while calling a
Python object" except
Ned Deily added the comment:
As Ronald is aware, there is also the issue that Apple has deprecated use of
OpenSSL in OS X:
"Although OpenSSL is commonly used in the open source community, OpenSSL does
not provide a stable API from version to version. For this reason, although OS
X pro
Ned Deily added the comment:
Patch LGTM and I verified that it does indeed install the pickles properly on
both a vanilla Linux build/install and with an OS X framework build/install.
(Note that, as expected, previously installed versioned pickles in the install
library directory are not
Ned Deily added the comment:
The patch as it stands causes _ctypes build failures when using the 10.4u SDK
as in the traditional 10.3+ 32-bit-only installer configuration. Apparently,
in ppc-ffi_darwin.c, the skip that the patch removes was because
OSCacheControl.h doesn't exist in the
Ned Deily added the comment:
Keep in mind that Python itself does not release with nor mandate a specific
version of sqlite3. When building CPython yourself, it will use what version
is found on your system. Distributors of built Pythons, including the
python.org Windows and OS X installers
Ned Deily added the comment:
The magic for building the standard library's dynamically loaded extensions is
in the top-level setup.py. It uses Distutils to do the work with a lot of
hacking around in setup.py. Without modifying setup.py, it can be a little
tricky to override the s
New submission from Ned Deily:
Setting the environment variable PYTHONEXECUTABLE can cause the interpreter to
crash with a segfault or to otherwise fail during initialization. Another
manifestation is the failure of test test_osx_env with:
AssertionError: -10 != 2 : expected PYTHONEXECUTABLE
Ned Deily added the comment:
I just noticed another anomaly in the patch. In x86-ffi_darwin.c there appears
to be some bogus code duplicating ffi_prep_args. Could you review and clean up
the patch before we apply it?
--
stage: needs patch -> commit rev
Ned Deily added the comment:
Fixes applied for release in 2.7.4, 3.2.4, and 3.3.0.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: compile error ->
versions: +Python 2.7, Python 3.2
___
Py
Ned Deily added the comment:
Fix applied for 3.3.0. All build-installer fixes will be backported for 2.7.4
and 3.2.4.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue15776>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Sorry, I meant this part of the patch:
diff --git a/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c
b/Modules/_ctypes/libffi_osx/
--- a/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c
+++ b/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c
@@ -35,6 +35,8
Ned Deily added the comment:
Bah, I just noticed that you built --with-pydebug enabled. That hides the
problem. I was fooled myself there. But I've since verified that the failure
still exists when built on 10.7 with Xcode 4.4.1 so the patch should
Changes by Ned Deily :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue15785>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Ned Deily added the comment:
Because tests should be runnable from installed Pythons (including binary -only
installations), tests should not assume that a Python source directory is
available nor make any assumptions about the location of the Python executable
itself.
--
nosy
Ned Deily added the comment:
Actually, IDLE does have code to look for an on-disk copy of the html-formatted
Python documentation set but the paths are platform-specific and, in the Linux
case, are out-of-date for some distributions at least. For Linux platforms it
looks for `index.html` in
Ned Deily added the comment:
Here's a patch to update the doc paths to include current ones for
Debian/Ubuntu and Fedora. The patch will have to be tweaked a bit for 3.2/2.7
to change sys.base_prefix to sys.prefix.
--
keywords: +patch
stage: needs patch -> patch review
Ad
Changes by Ned Deily :
Removed file: http://bugs.python.org/file27051/issue15808_idle_doc_paths.patch
___
Python tracker
<http://bugs.python.org/issue15808>
___
___
Pytho
Changes by Ned Deily :
Added file: http://bugs.python.org/file27052/issue15808_idle_doc_paths.patch
___
Python tracker
<http://bugs.python.org/issue15808>
___
___
Pytho
Ned Deily added the comment:
The sysconfigdata problem is already documented in two open issues: Issue14774
and Issue15298.
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
Can you give the steps to reproduce this issue? Also, what platform and file
system are in use? I can guess what an underlying problem might be but I
haven't been able to reproduce the failure myself.
--
nosy: +ned.
Ned Deily added the comment:
Thanks for the details. Moving to ext4, I was still not seeing the problem as
Grammar.txt and the pickle file have the same nanosecond ctime but that may be
due to running in a vm environment or other factors. Manually touching
Grammar.txt, not surprisingly, does
Ned Deily added the comment:
Issue15591 perhaps?
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15830>
___
___
Python-bugs-list mailin
Ned Deily added the comment:
The problem here is in the "libinstall" Makefile target and that hidden
dependency within lib2to3 that, as Tomi notes, causes lib2to3 to try to
recreate the pickles anytime it runs if it thinks they are out of date. The
fixes for Issue15645 cause the r
New submission from Ned Deily:
With the recent activity around making out-of-tree builds work, while
investigating Issue15822 I realized that the lib2to3 grammar pickle files are
being built in the source directory by the libinstall target step of the main
Makefile rather than in the build
Ned Deily added the comment:
I did it that way to ensure that the touch is executed after the copies. And
the touch needs to be optional because the creation of the pickles can
optionally fail.
--
___
Python tracker
<http://bugs.python.
Ned Deily added the comment:
Right you are, thanks! I had that in an earlier version. Are you able to
verify the fix?
--
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
The crash on opening Preferences is an unresolved regression with OS X
ActiveTcl 8.5.12.1, the current ActiveTcl Community Edition, that causes Tk to
crash when selecting the IDLE Preferences.. command. The regression was also
in ActiveState 8.5.12 but not in
Ned Deily added the comment:
This is a duplicate of Issue15037. test_unget_wch fails when linked with
ncurses versions earlier than 5.8, which is the case with the Apple-supplied
versions of ncurses in OS X versions through 10.8. (The python.org OS X
installers for Python 3.3.x link with
Ned Deily added the comment:
Different version of libncurses, different compiler and run time, different
version and build options of Python 3.3, etc. The bug in ncurses causes junk to
be stored and/or returned. In the one case, the junk triggered an overflow
error, in the other, no overflow
Ned Deily added the comment:
David, can you verify that you do have ActiveTcl 8.5.12 (.0 or .1) installed
and that the problem no longer occurs if you disable ActiveTk by moving it as
described above? When Preference is failing, the following Terminal shell
command:
grep TK_PATCH_LEVEL
Ned Deily added the comment:
Hmm, sorry, I don't know of an easy fool-proof way to automatically log
everything you type in IDLE. But it's pretty easy to manually save the
contents of the IDLE shell window at the end: with the keyboard focus on the
Python Shell window, selec
Ned Deily added the comment:
> Can that possibly be right??
Yes. That's the version of ncurses that Apple ships with current versions of OS
X. You can build it yourself and install into /usr/local and rebuild python.
For ncurses 5.9, something like:
./configure --enable-widec
Changes by Ned Deily :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue15858>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
What behavior do you expect? By accident, I found your reply to this
StackOverflow question. I take it from that that you think tkinter should be
quoting curly braces found in strings. If that is what you mean, can you
specify the set of characters that need to
Ned Deily added the comment:
The problem is a regression in the latest version of ActiveTcl 8.5 for OS X,
specifically 8.5.12.1 (and I believe the previous version 8.5.12.0). It has
nothing directly to do with Python or how you might build Python other than
whether _tkinter.so dynamically
Ned Deily added the comment:
I agree as well. The bigger question is, as Eric suggests, is this the only
such case when mapping between Python and Tcl elements? Since Bryan is a
well-known Tcl and Tkinter expert, his insights on that would be very useful
Ned Deily added the comment:
I like Martin's suggested approach. It is explicit and much cleaner than the
changes we introduced for Issue15645 as well as the original. The applied
changes revert the previous changes and instead implement an explicit build of
the two pickles directly i
Changes by Ned Deily :
--
status: pending -> open
Removed file: http://bugs.python.org/file27084/issue15822_33.patch
___
Python tracker
<http://bugs.python.org/issu
Ned Deily added the comment:
This problem is resolved by the fixes for Issue15822 which implements a more
explicit way of installing the grammar pickles.
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> installe
Ned Deily added the comment:
>Is it really possible that the pickle is created after calculation of the
>wildcard expansion?
With the current GNUmake, it seems it is not possible. GNUmake appears to
serializes the individual steps in a target's recipe although I did not find a
Changes by Ned Deily :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15822>
___
___
Python-bugs-list mailing list
Unsubscri
Ned Deily added the comment:
AFAIK, the pickles are created with exactly the same permissions as the cached
pyc and pyo files have been all along. So, if you propose to change the
permissions for the pickles, the compileall steps should be changed as well
Ned Deily added the comment:
BTW, AFAICT, you'll get exactly the same behavior (with distribute failing due
to pickle write permission) with earlier releases, like 3.2.3, if you happen to
do a "make install" with an inappropriate umask value. So it appears that
setting uma
Ned Deily added the comment:
It seems to me this is just a special case of the more general issue of
building multiple versions of the same distribution, say with multiple versions
of Python 2. In general, anytime you change your build environment, you should
start with no existing build
Ned Deily added the comment:
I have not been able to reproduce the behavior you report using various Pythons
on OS X 10.8 or on OS X 10.5. Can you give more specifics on the environment
that fails for you?
I certainly don't claim to have any experience with these tty/pty modules or
wit
Ned Deily added the comment:
Sorry, all I can tell you is that, for me, your test produces an empty string
as output with either Python 2.7 or 3.3 and, if I remove the time.sleep() call
or remove the os.close(slave), "testing" or b"testing" is output. I'm not s
Ned Deily added the comment:
This problem was caused by a conflict between the expat parser included with
Python and the expat parser included with the MacPorts ports of the obsolete
pyxml package. The MacPorts project has subsequently deleted the py*-xml
ports. A solution for this issue is
Ned Deily added the comment:
The link has since been fixed thanks to your suggestion.
--
components: +Tests -None
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue15
Ned Deily added the comment:
Out of curiosity, has anyone checked whether this is also an issue with any of
the supported BSD's? There have been other issues which were detected first on
OS X but turned out to be more general BSD vs Linux differences, rather than OS
X
Ned Deily added the comment:
I believe Georg maintains cronjobs for updating the docs.
--
___
Python tracker
<http://bugs.python.org/issue15949>
___
___
Python-bug
Ned Deily added the comment:
OS X 10.4 (and presumably earlier versions) also does not handle the low
switchinterval gracefully. Monitoring system activity and running with -v,
test_threaded_import does seem to progress but *very* slowly (I quit after 45
minutes with the test only partially
Ned Deily added the comment:
This is due to a bug in the current Cocoa Tk as released in ActiveTcl 8.5.12.1
(and 8.5.12). Try installing the previous ActiveTcl version, 8.5.11.1, which I
just discovered is still available here:
http://downloads.activestate.com/ActiveTcl/releases/8.5.11.1
Ned Deily added the comment:
What operating system are you using? Which python 3.2 are you using (i.e. a
particular installer downloaded from python.org, built from source, etc)? If
known, which version of Tcl/Tk are you using?
--
nosy: +ned.deily
Ned Deily added the comment:
With 3.2.3 (on OS X), if I open a new edit window, enter a few files, save the
file, set a breakpoint on a line, then save the file again (with or without
having debug on), the following exception occurs but IDLE keeps running:
Exception in Tkinter callback
Changes by Ned Deily :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue16034>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Odd, it works for me. Check to make sure it really got installed:
$ cd /Library/Frameworks/Tk.framework/
$ grep PATCH tkConfig.sh
TK_PATCH_LEVEL='.11'
You could manually delete the frameworks and try installing again:
$ cd /Library/Frameworks
$
Ned Deily added the comment:
Thanks for the additional information! I can now reproduce a hang using just
Ctrl-5 on a US keyboard input method. Ctrl-5 is the default IDLE keyboard
accelerator for the "Tabify Region" menu item under the "Format" menu cascade
for an ed
Ned Deily added the comment:
This is due to a bug in the current Cocoa Tk as released in ActiveTcl 8.5.12.1
(and 8.5.12). Try installing the previous ActiveTcl version, 8.5.11.1:
http://downloads.activestate.com/ActiveTcl/releases/8.5.11.1/
--
nosy: +ned.deily
resolution
Changes by Ned Deily :
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16032>
___
___
Python-bugs-
Ned Deily added the comment:
As far as I know, this is currently only an issue if you use the llvm-gcc-4.2
compiler on OS X to do a debug mode build. That compiler is no longer
maintained by Apple and is known to miscompile Python 3.3 builds. There are
checks in configure.ac for 3.3 to
Ned Deily added the comment:
A popup menu on every invocation of IDLE would be a very user-unfriendly thing
to do. If it's possible that a print to stderr might not be visible to a user,
another solution might be to use the approach in Lib/idlelib/macosxSupport.py
tkVersionWarning
Ned Deily added the comment:
While there isn't a fix available for Tk yet, there is now a viable workaround.
It turns out that ActiveState does make the last couple of their Community
Edition ActiveTcl releases available if you know where to look for them. So
I've updated the info
Ned Deily added the comment:
Just a reminder that we support configurations where there are both big-endian
and little-endinan binaries in the *same* executable file: for example, Mac OS
X 32-bit-only universal binaries (.so, .dylib, .exe) contain both i386 and ppc
code in the same file. So
Ned Deily added the comment:
Christian: That's right because there is only one configure execution in the OS
X universal builds and only compiler call per module just like a normal
single-architecture unix build. Under the covers, the Apple compiler driver
transparently makes mul
Ned Deily added the comment:
I've been able to isolate the problem to a particular Tk checkin and have
opened an Tk issue with details here:
https://sourceforge.net/tracker/?func=detail&aid=3575681&group_id=12997&atid=112997
--
_
Ned Deily added the comment:
I've been able to build Cocoa Tk and isolate the crash regression to a
particular Tk checkin. This Tk issue contains the details:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&a
Ned Deily added the comment:
I've not seen any reports of this behavior before. Can you try two things?
One, try temporarily disabling your current IDLE preferences. Quit IDLE, then
from a terminal shell, type something like:
mv ~/.idlerc ~/.idlerc-disabled
then launch IDLE and tr
Changes by Ned Deily :
--
nosy: -ned.deily
___
Python tracker
<http://bugs.python.org/issue10551>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
components: +Windows
nosy: +brian.curtin, loewis, tim.golden
___
Python tracker
<http://bugs.python.org/issue16188>
___
___
Python-bug
Changes by Ned Deily :
--
nosy: +serwy
___
Python tracker
<http://bugs.python.org/issue15853>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Ned Deily added the comment:
Thanks for the patch, Kevin. It does need to be updated a bit for the current
2.7 branch as there have been changes since 2.7.3. Can you outline what you
believe the problem is that your patch is trying to workaround? Certainly,
nothing that IDLE or any other
Ned Deily added the comment:
In current OS X releases, it is true that the system Pythons as shipped by
Apple do not include the .py files in
/System/Library/Frameworks/Python.framework; only .pyc and .pyo files are
present. However, those .py files are added when you install the "Co
Ned Deily added the comment:
There is *no* way to install Python using a python.org installer and *not* have
the .py files installed. You would have to go in and remove those files
yourself. You should be able to see the .py files yourself by looking at
/Library/Frameworks/Python.framework
Ned Deily added the comment:
Thank you for the report. There does seem to be a regression in the 3.3
version of IDLE. Using the OS X version of bin/idle3.3 and selecting menu item
File -> Path Browser results in the following exception:
Exception in Tkinter callback
Traceback (most rec
Ned Deily added the comment:
The demo scripts in the Tools directory were cleaned up earlier in Python 3 and
moved. redemo.py is still included in the 3.2 and later source distributions
in the Tools/demo directory. The builders of binary installers and third-party
distributors of Python 3.x
Ned Deily added the comment:
I don't think this is a documentation issue. I think it's more likely a
Windows installer issue since I don't see the file installed in the current
python.org 3.3 Windows distribution. But I was waiting for confirmation from
the OP that he is us
Ned Deily added the comment:
The patch should not unconditionally use `python2` since many distributions do
not yet install a `python2` link to the interpreter nor is there one when
running python2.7 from a build directory. The Makefile could conditionally try
`python2` and then fall back to
Ned Deily added the comment:
Thanks for the update. So I think the bigger issue here is there something that
should be changed in the Windows installer to accommodate the demo changes in
Python 3. Adding the Windows experts and deassigning from docs.
--
assignee: docs@python
Changes by Ned Deily :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue16244>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ned Deily :
--
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue16256>
___
___
Python-bugs-lis
Ned Deily added the comment:
I'm still not keen on working around a Tk crash by modifying IDLE especially
when we know exactly which Tk change set caused the regression. On the other
hand, I sympathize with Kevin regarding the complexity of trying to track down
and fix things involving
Ned Deily added the comment:
There seems to be a bootstrap issue here. Building with ./configure
--with-pydebug --prefix=... on OS X in a clean source directory (hg purge
--all), 'make' makes it to building the static libpython .a but then dies on
the sysconfig generate-posix-vars
Ned Deily added the comment:
Keep in mind that tear-off menus are not supported on IDLE on OS X when using
Aqua Tk (either Carbon or Cocoa), the standard these days. That's primarily
because Aqua Tk uses native OS X menu bars which appear once at the top of the
desktop, not in each w
Ned Deily added the comment:
I've committed Roger's fix for release in 3.3.1 and 3.4.0. Thanks, Roger. I
did not apply the proposed test since, as it stands, it would never be run by
test.regrtest without establishing a idlelib test runner infrastructure as
proposed by Issue1
4501 - 4600 of 6927 matches
Mail list logo
