Closed c6a0e691-1f24-44e4-8cd9-f91c873df278 closed 5 years ago
Running life.py from the Free Python Games requires alt-Q twice, and the GUI keeps running after System.exit.
Running life2.py, (which is my clone, and I will happily share it if you want a great stress tester that gobbles 100% of a CPU core for as long as you want,) doesn't respond to alt-Q and requires a force quit.
Please create a small program that reproduces the problem. You should strip out everything that isn't needed. There's no way we can guess the problem without seeing the code.
send to you?
.
On Nov 10, 2018, at 14:41, Eric V. Smith \report@bugs.python.org\ wrote:
Eric V. Smith \eric@trueblade.com\ added the comment:
Please create a small program that reproduces the problem. You should strip out everything that isn't needed. There's no way we can guess the problem without seeing the code.
---------- nosy: +eric.smith
Python tracker \report@bugs.python.org\ \https://bugs.python.org/issue35211\
Here is the source, just simply Turtles...
https://github.com/grantjenks/free-python-games \https://github.com/grantjenks/free-python-games\
Attached life.py and life2.py
I don't know what cause the problem. I suspect there is more of a problem than just alt-Q
On Nov 10, 2018, at 15:08, Bob Moth \bmoth@icloud.com\ wrote:
send to you?
.
> On Nov 10, 2018, at 14:41, Eric V. Smith \report@bugs.python.org\ wrote: > > > Eric V. Smith \eric@trueblade.com\ added the comment: > > Please create a small program that reproduces the problem. You should strip out everything that isn't needed. There's no way we can guess the problem without seeing the code. > > ---------- > nosy: +eric.smith > > > Python tracker \report@bugs.python.org\ > \https://bugs.python.org/issue35211\ >
Please quote only the relevant parts of the original email while replying from email since it duplicates the content and makes your reply hard to read. Also I think the bug tracker doesn't support attachments from email so please attach them here from the UI.
Thanks
looking at the screen snapshot 'life.py alt-q once.jpg' -- the turtle code keeps running even though System.exit has been completed, and notice the traceback display in the shell caused by the alt-Q.
a second press of alt-Q terminates the shell and the turtle code.
I rewrote the life2.py using a class in order to eliminate global variable declarations, and some other things, such as bringing freegames.util#square() instream to be independent of freegames, carefully accounting for every pixel output, etc.
Works a little better but alt-Q has no effect whatsoever and it is necessary to Force Quit (mac terminology) or to switch to the shell window and quit that first.
Once this bug is fixed, wherever that might be, you might look into using mylife.py as an turtle example -- with whatever changes you like -- because it is interesting to use and it exercises the turtle and tkinter very strenuously. (just leave my name off it...)
Thanks for your hard work.
There seem to be at least two problems here.
One, you say that running the unmodified life.py requires two Quit keyboard shortcuts (usually CMD-Q). From the shell output you give, that problem is most likely due to the use of -i with python:
'/usr/local/bin/python3' -d -i '/Users/user2/Downloads/life.py'
-i means that the interpreter should enter its interactive mode after the script exists. With tkinter-based graphics apps like turtle, you probably do not want to do that as it will inhibit the normal Tk shutdown of the app.
https://docs.python.org/3/using/cmdline.html#cmdoption-i
Without -i, the unmodified life.py terminates fine for me.
Secondly, your modified life2.py does not terminate with a Quit even when running without -i. (Note that it *does* quit if you select Close from the applications's File menu or if you click on the red close button on the open window.) From a quick comparison of the unmodified Pygames life.py versus your modified life2.py version, it seems you have changed the order of operations in such a way that the sequence of turtle operations has changed and likely the underlying tkinter event loop is not being called properly thus either ignoring or suppressing the effect of the Quit keyboard shortcut. Suggest you revise your program to follow the sequence of turtle calls that the original does and be careful if you wish to introduce changes in that. If you do find what appears to be a bug in turtle or elsewhere in Python, feel free to re-open this with an example and an explanation. Good luck!
hi - i do not use ‘i’...just drag to launcher...
and sequence of commands is a good tip but smells like some kind of bug to me if the commands follow written rules.
thanks for looking -
Alas, the Launcher app can be problematic and doesn't get much love. If you open the Launcher app's Preferences, you'll probably see that the "Interactive mode after acript" option is ticked. Either unselect it or, if you feel comfortable using a Terminal window, just launch Python directly from a terminal shell:
python3 \~/Downloads/life.py
OK, thanks. The generated launcher shell command generated includes '-d -i' flags...
so I tried running without those and voila, life.py terminates normally. Yay. :-)
2nd, I reviewed the order of commands and I saw that life2.py and mylife.py (the +1 version) did not have a 'done()' or 'mainloop()' as the last line of the program. I added those, to no effect. Does nothing I can see. The other turtle commands appear to me to be "ok", given that the algorithm is different. For example, clear() used to be done every loop -- to erase the turtle tracks -- but that is now done just at the start because only changed cells are updated, and new life/new dead are just updated.
So, 50% solved. It is an interesting problem because *my code seems to be working and *python does not appear to be working right.
Thanks for the help. I might try pygame for a gui instead...this is getting weird.
You may might try asking on the freegames issue tracker or, better, on a more general support forum like Stackoverflow or Python-list. Because of the volume of issues reported here (and we are all volunteers), we really can't spend a lot of time helping debug individual programs. Sorry!
https://www.python.org/about/help/ https://stackoverflow.com https://mail.python.org/mailman/listinfo/python-list
Thanks. I appreciate the time and effort.
But I disagree with the characterization of this problem as 'Resolved'. Turtle is supposed to be simple enough for children yet no one can fix simple turtle code and stop an endless loop?
What is the rush to close issues?
Sorry, there isn't a particular rush to close issues as some of them stay open for years. And that's not good for anyone. "resolved" on the issue tracking does not necessarily mean a problem is resolved to everyone's satisfaction, it just means that it is no longer active in our backlog (which currently numbers over 6000). I don't claim to be a turtle expert but the bit of time I spent looking into this issue and my years of triaging Python issues lead me to conclude this is almost certainly a problem with your program and not with Python itself. We could leave it open but the chances that any other core developer would spend time looking further at it are slim. That's why I suggested asking on user forums where you are much more likely to get useful and more rapid feedback. And as I earlier suggested, if it *does* turn out to be a demonstrable problem with turtle or elsewhere in Python, you can easily reopen the issue and we can go from there. I hope that makes some sense!
And, by the way, if it turns out that the problem could have been avoided by better documentation, another option is to re-open the issue with suggested doc changes. Patches welcome!
Apparently the draw() function must call itself via ontimer.
That is not in the docs. But 56 variations later...I just copied Grant Jenks. Apparently he knows what's what.
And done() must be the last line.
If first omitted, only one draw loop executed, but it quits itself. With done(), it loops via ontimer().
\<pre>\<code> def draw(): myDrawCells() update() myComputeOneStep() ontimer(draw, LOOP_TIMER) setup(BOARD_SIDE, BOARD_SIDE, None, None) hideturtle() tracer(False) clear() myInitialize() draw() done() \</code>\</pre>
So now alt-Q works in life2DEBUG.py. attached.
Here is a debugged version of mylife, which cloned life2.py to use a class for turtle-ing. Note the difficulties at the end of the code -- ontimer(fun, delay) calls for a zero arg function, so draw() cannot be inside the class. Greatly annoying. But now we know.
mylife3.py is a suitable example, I think. If cleaned up to standards. I noticed there is a curses life.py example, which is very interesting and fun, but mylife3.py is more fun...and it has 2 different board topologies! And it would make a very good test program. Note that it sets the random seed which establishes the Cell patterns, so a test ought to be repeatable, at least on a given machine. I plan to use mylife3.py instead of a space heater this winter :)
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = None closed_at =
created_at =
labels = ['OS-mac', 'type-bug', 'expert-tkinter', '3.7']
title = 'Turtle Shutdown Problem(s)'
updated_at =
user = 'https://bugs.python.org/bmoth'
```
bugs.python.org fields:
```python
activity =
actor = 'bmoth'
assignee = 'none'
closed = True
closed_date =
closer = 'ned.deily'
components = ['macOS', 'Tkinter']
creation =
creator = 'bmoth'
dependencies = []
files = ['47920', '47922', '47923', '47924', '47925', '47926', '47927']
hgrepos = []
issue_num = 35211
keywords = []
message_count = 17.0
messages = ['329640', '329647', '329648', '329649', '329663', '329676', '329677', '329685', '329688', '329689', '329690', '329691', '329700', '329705', '329706', '329708', '329709']
nosy_count = 7.0
nosy_names = ['ronaldoussoren', 'gregorlingl', 'eric.smith', 'ned.deily', 'willingc', 'xtreak', 'bmoth']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue35211'
versions = ['Python 3.7']
```