[Python-bugs-list] [Bug #110865] Reproducible crash of Mac IDE (PR#172)
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 28 Aug 2000 07:12:48 -0700
Bug #110865, was updated on 2000-Aug-01 14:40
Here is a current snapshot of the bug.
Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: Reproducible crash of Mac IDE (PR#172)
Details: Jitterbug-Id: 172
Submitted-By: Bruce.Sherwood@cmu.edu
Date: Fri, 7 Jan 2000 11:21:23 -0500 (EST)
Version: 1.5.2c1
OS: Mac 8.1
I'm writing tiny programs invoking Tkinter, to learn how to use it. If I open my
script from the Mac IDE and click "Run all" in the script title bar, the script
runs okay, but when I try to quit running, the entire IDE locks up. I have to do
an unpleasant Mac "Force quit" to get out. This is completely reproducible with
tiny programs containing "from Tkinter import *".
I've had to resort to the awkward strategem of saving the script, then dragging
the script file onto the Python interpreter. In that case I can quit normally.
It means that I'm only using the IDE as a (structured) text editor.
I don't have the quit problem in Mac IDE with scripts that don't invoke
Tkinter.
====================================================================
Audit trail:
Wed Jan 12 18:28:11 2000 guido sent reply 1
Wed Jan 12 18:28:24 2000 guido changed notes
Wed Jan 12 18:28:24 2000 guido moved from incoming to 3rdpartybug
Follow-Ups:
Date: 2000-Aug-01 14:41
By: none
Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: Reproducible crash of Mac IDE (PR#172)
Date: Wed Jan 12 18:28:11 2000
> Full_Name: Bruce Sherwood
> Version: 1.5.2c1
> OS: Mac 8.1
> Submission from: hejmo.rem.cmu.edu (128.2.83.199)
>
>
> I'm writing tiny programs invoking Tkinter, to learn how to use it. If I open
my
> script from the Mac IDE and click "Run all" in the script title bar, the
script
> runs okay, but when I try to quit running, the entire IDE locks up. I have to
do
> an unpleasant Mac "Force quit" to get out. This is completely reproducible
with
> tiny programs containing "from Tkinter import *".
>
> I've had to resort to the awkward strategem of saving the script, then
dragging
> the script file onto the Python interpreter. In that case I can quit
normally.
> It means that I'm only using the IDE as a (structured) text editor.
>
> I don't have the quit problem in Mac IDE with scripts that don't invoke
> Tkinter.
Bruce,
Are you using the default Python IDE or the separate (much nicer) IDE
by my brother Just?
In either case, you are probably better of trying to learn Tkinter on
a Unix or Windows platform; it is unfortunately notoriously unstable
on the Mac, and there's not a lot we can do about this.
--Guido van Rossum
-------------------------------------------------------
Date: 2000-Aug-01 14:41
By: none
Comment:
From: Just van Rossum <just@letterror.com>
Subject: Re: Reproducible crash of Mac IDE (PR#172)
Date: Thu, 13 Jan 2000 01:30:38 +0100
At 6:28 PM -0500 12-01-2000, Guido van Rossum wrote:
>> Full_Name: Bruce Sherwood
>> Version: 1.5.2c1
>> OS: Mac 8.1
>> Submission from: hejmo.rem.cmu.edu (128.2.83.199)
>>
>>
>> I'm writing tiny programs invoking Tkinter, to learn how to use it. If I
>>open
>my
>> script from the Mac IDE and click "Run all" in the script title bar, the
>script
>> runs okay, but when I try to quit running, the entire IDE locks up. I
>>have to
>do
>> an unpleasant Mac "Force quit" to get out. This is completely reproducible
>with
>> tiny programs containing "from Tkinter import *".
>>
>> I've had to resort to the awkward strategem of saving the script, then
>dragging
>> the script file onto the Python interpreter. In that case I can quit
>normally.
>> It means that I'm only using the IDE as a (structured) text editor.
>>
>> I don't have the quit problem in Mac IDE with scripts that don't invoke
>> Tkinter.
I'm sorry to inform you that the Mac Python IDE is not compatible with
Tkinter. At all. Conflicting event loops and all.
Sorry!
Just
-------------------------------------------------------
Date: 2000-Aug-01 14:41
By: none
Comment:
From: Bruce Sherwood <bas@andrew.cmu.edu>
Subject: Re: Reproducible crash of Mac IDE (PR#172)
Date: Wed, 12 Jan 2000 23:47:18 -0500
--On Thu, Jan 13, 2000 01:30 +0100 Just van Rossum <just@letterror.com>
wrote:
> I'm sorry to inform you that the Mac Python IDE is not compatible with
> Tkinter. At all. Conflicting event loops and all.
Thanks for the confirmation. At least now I won't keep suspecting it's me
the novice at fault!
Bruce Sherwood
-------------------------------------------------------
Date: 2000-Aug-01 14:41
By: none
Comment:
From: Bruce Sherwood <bas@andrew.cmu.edu>
Subject: Re: Reproducible crash of Mac IDE (PR#172)
Date: Thu, 13 Jan 2000 01:00:41 -0500
--On Wed, Jan 12, 2000 18:28 -0500 Guido van Rossum <bugs-py@python.org>
wrote:
> Bruce,
>
> Are you using the default Python IDE or the separate (much nicer) IDE
> by my brother Just?
>
> In either case, you are probably better of trying to learn Tkinter on
> a Unix or Windows platform; it is unfortunately notoriously unstable
> on the Mac, and there's not a lot we can do about this.
>
> --Guido van Rossum
I'm not sure of terminology. I was trying to use what is called (on disk)
"Python IDE" and whose About Box when running says "The Python Integrated
Development Environment" version 1.0 by Just. I don't think I've seen
anything else called IDE on the Mac. Just's note to me seems to confirm
that I was using his environment, which he explains won't work with
tkinter. So I'll stop trying that!
I didn't expect to hear directly from you, Guido, in response to my bug
report. Thanks for writing. Some colleagues and I were planning on talking
with you in depth about your strong interest in computer programming for
everybody, which is of deep concern to us, too. But we only just started
learning Python and were going to hold off from approaching you until we
knew enough not to seem total idiots. But since you took the time to write
to me, I'm encouraged to play the half-idiot and indicate our interest now.
We would welcome deeper discussion if you perceive a community of interest.
We're 200% in agreement with your stirring essay. Ordinary mortals ought to
be able to write computer programs! We ourselves have worked hard on this
problem for 30 years, with significant but little-known success in the
particular niche of college faculty and students writing interactive
graphics-oriented educational software. We're very impressed by the quality
of what you have done in creating Python, and we believe it can be a solid
foundation for programming for everybody. The exceptionally clean syntax,
uncluttered by semicolons and ends and brackets, is important for
nonexperts. We think Python has the potential to be a better foundation
than our own cT programming language, and we would like to explore ways in
which to contribute to the goal and vision you have articulated.
Not only do we have long and deep experience in making it possible for
nonexperts to write interactive graphics programs, but we are also involved
in teaching an introductory college physics course in which students do
graphics-oriented programming to carry out computer modeling of physical
systems. Many of these students have never written a program before (for
the reasons you discuss), yet toward the end of just two 50-minute periods
of instruction the students are writing a program to calculate and display
the motion of a spacecraft going from the Earth to the Moon. They do many
such computer modeling projects during the semester. And they do this on
Windows, Mac, and Linux, with the language, the graphics, and the
programming environment all identical on all machines, with trivially easy
installation and use, unplagued by problems of search paths, etc.
Concretely, here is what we can offer in support of your goal:
1) If a graphics-oriented, multiplatform, Python-based environment suitable
for novices can be developed, we have a physics course that we teach in
which its deployment could be tested. So we offer a potential testbed for
your DARPA project. I note in your essay your interest in what the
University of Chicago can provide as a testbed for teaching the language.
We can broaden the range of issues to include the case of a physics course
where little time can be spent teaching programming, since the focus is on
the physics, not the computer science, and where scientific graphics is
central to the enterprise.
2) We can contribute to the design of such an environment, based on our
long experience of developing and teaching and using a graphics-oriented,
multiplatform programming language accessible to nonexperts. One of my
colleagues can offer significant system expertise with the Mac (in addition
to expertise with Windows and Linux). Mac systems expertise seems to be in
short supply in the nation, yet the Mac is still very important in many
educational settings.
3) Another of my colleagues has a particularly strong interest in designing
and implementing powerful 3D scientific graphics in a way that would be
usable by novices, based on Python. The possibilities this opens up for our
physics course provide one of the main reasons for our interest in going
beyond what is practical within the structures of cT, mainly because cT is
not really object-oriented. Note that this is a different graphics issue
than the one explored by Randy Pausch: it isn't a question of using Python
to manipulate 3D models but doing such things as planetary orbits in 3D,
from first principles. An area that cries out for 3D visualization is
magnetism, where magnetic fields are inherently 3D objects. Another
colleague has produced 3D movies of electric and magnetic fields in space,
but these are not interactive and should be, when that is possible in the
future.
As I said, we weren't going to approach you until we knew more about
Python. One of the reasons I've signaled our interest prematurely is that
we find we need some guidance in the graphics area. We've been playing with
tkinter since it seemed to have the largest community, but apparently there
are LOTS of graphics environments in use with Python. We need some advice
on plausible directions to go for graphics, and what makes sense as a
foundation for extending to 3D scientific computer animation usable by
novices.
We believe that good novice-friendly graphics are absolutely critical to
computer programming for everybody. There certainly are some "everybodies"
who mostly want and need to sort lists or calculate mathematical functions
or search files. But in our experience what grabs most everybodies is the
instant gratification of starting with graphics. In the first 50 minutes of
instruction our students have blue balls bouncing around inside a red box.
This is powerful stuff and highly motivating. To us, graphics is utterly
central to the goal of computer programming for everybody. And it is
critical to our physics course.
Bruce Sherwood
Center for Innovation in Learning and Department of Physics
Carnegie Mellon University
http://cil.andrew.cmu.edu/bruce.sherwood.html
P.S. Sorry about reporting the tkinter bug with arcs to you rather than to
the Tk people. I didn't quite see how to report it to them and figured that
if I sent it to Python it would get to the right person eventually. I am
now using oval rather than arc to avoid the bug, though in an algorithmic
situation one might compute the extent of an arc, and if it comes out to be
360, too bad -- you'll get a line instead of an oval.
-------------------------------------------------------
Date: 2000-Aug-01 14:41
By: none
Comment:
Not much we can do about this, probably.
-------------------------------------------------------
Date: 2000-Aug-28 07:12
By: jhylton
Comment:
Just says that this is a known incompatibility, which he is working on. It is not a Python bug.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110865&group_id=5470