-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2 installer fails smoke test #86674
Comments
An IDLE installation manual smoke test gives odd behavior when run on macOS using the Tcl/Tk 8.6.10 introduced with the new macOS universal2 installer variant as of 3.9.1rc1. The test behaves as expected (without the duplicate and spurious error messages) when run using the traditional macOS 10.9 installer variant that includes Tcl/Tk 8.6.8 built on macOS 10.9. The test consists of:
As we are planning to introduce the universal2 installer variant on 3.8.x and 3.10 to natively support Apple Silicon Macs and macOS 11 Big Sur, a quick resolution of this issue is important. While automated tests in the test suite show no new failures, it would be good to manually exercise IDLE in the new installer configuration to look for other unusual behaviors. |
This issue exposed and is affected by an existing system and version independent bug. With that fixed as in PR 23570, running a file with "print('output')" with the new 3.9.1rc1 universal binary results in the following. output
The normal output is ========= RESTART: /Users/.../tem1.py =========
I am investigating how 'RESTART' is being printed after 'output', even though the restart function is called before the compiled tem1 is sent to be executed. |
After hours of failure to understand crazy 'impossible' behavior, I went back to 'timing issue' and this code. def run_module_event(self, event):
if macosx.isCocoaTk():
# Tk-Cocoa in MacOSX is broken until at least
# Tk 8.5.9, and without this rather
# crude workaround IDLE would hang when a user
# tries to run a module using the keyboard shortcut
# (the menu item works fine).
self.editwin.text_frame.after(200,
lambda: self.editwin.text_frame.event_generate(
'<<run-module-event-2>>'))
return 'break'
else:
return self._run_module_event(event) When I used the Run menu instead of F5, the problem went away. The problem also went away when I added 'and 0' to the condition above to disable the workaround. 3.8 also works fine with the workaround disabled. Ned, if you verify enough to agree, I will get rid of the wrapper and remove the leading '_' from the real handler. |
PR 23577 makes fix suggested above for easier review. |
The new tk/tkinter bug in the macOS11 U2 build, other than those reported in bpo-42507 and bpo-42541, is that pressing F5 causes the corresponding pseudoevent handler, run_module_event, to be called twice. (Its code is above.) The interval between calls is about 1 millesecond -- .7 to 1.1 in 5 tries. See this by adding the following at the top of the function's and subtracting after running code with or without syntax error. Adding multiple prints in _run_module_event shows the following for code that compiles. With the 200 millesecond cocoa delay, the two calls run interleaved closely interleaved. I don't understand the details, but the result is the scrambled and incorrect output given above. With no delay as with PR 23577, the first call calls restart_subprocess in _run_module_event. Then call 2 gets to the top of this function, then call 1 appears to finish, and call 2 is somehow aborted. With a syntax error, the 2nd call, redisplaying the error, is not aborted. F5 resulting in two calls is not unique, even though I have not yet seen overt double call effects. In Shell, Control-F6 restarts. A print in its event handler shows that it is called twice even though there is only 1 restart. A possible kludge workaround would be to call perf_counter when the class is created and for Cocoa, each run_module call. Return when new-old < 2milliseconds. But the double call should be fixed as it could show up elsewhere. |
The new commit to PR 23577 works around the double run_module_event call. Removing the delay changed timings, so I instead measured the time between closing the errorbox and the 2nd call. The allowed difference had to be increased to .015, so I selected .05 to be safer. |
I believe that this issue is done. Please open a new one if more is needed. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: