<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Nov 16, 2015, at 5:54 AM, Terry Reedy <<a href="mailto:tjreedy@udel.edu" class="">tjreedy@udel.edu</a>> wrote:</div><div class=""><div class="">On 10/27/2015 5:27 AM, Terry Reedy wrote:<br class=""><blockquote type="cite" class="">On 10/26/2015 1:15 AM, Terry Reedy wrote:<br class=""><blockquote type="cite" class="">On 10/22/2015 12:25 PM, Mark Roseman wrote:<br class=""><blockquote type="cite" class="">A few incremental issues still to be reviewed/integrated:<br class=""></blockquote></blockquote><br class="">Since pushing 12+ patches for 10 issues in 2 weeks (September/October),<br class="">I have focused on Python/IDLE startup problems. The changes for Windows<br class="">in 3.5.0 introduced some new ones, some of which affect IDLE. For<br class="">instance, when IDLE starts from the icon, the usual case, it starts in<br class="">/Windows/system32 instead of the install directory. Two or three people<br class="">reported problems with this. These multiple unanticipated new problems<br class="">have made me a bit more cautious. Making IDLE pretty is not much good<br class="">if people cannot run it.<br class=""></blockquote></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Or if it’s that ugly and horrible, not having it start could save them the pain. ;-)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">24455 (fix-mainloop2.patch) fix debugger crash caused by nested main<br class="">loops<br class=""></blockquote></blockquote></blockquote><br class="">I am looking at this now. Review and questions:<br class="">Issue 15347 has fix-nested-mainloop.patch, superceded by<br class="">Issue 24455, fix-mainloop2.patch. This has 2 tk calls.<br class="">self.root.tk.call('vwait', '::idledebugwait')<br class="">self.root.tk.call('set', '::idledebugwait', '1')<br class=""><br class="">My naive guess is that the second is sets a variable to 1 and the first waits (how long, indefinitely?) until it is set to 1. Please verify/explain here or perhaps better on the issue. I dislike committing code I don't understand, and that future maintainers might also have a problem with. Say something on the issue and I will add a comment referring to it.<br class=""></div></div></blockquote><div><br class=""></div><div>The code in the patch for 24455 has this comment on it:</div><div><br class=""></div><div><pre style="word-wrap: break-word; white-space: pre-wrap;" class="">+ # Nested main loop: Tkinter's main loop is not reentrant, so use
+ # Tcl's vwait facility, which reenters the event loop until an
+ # event handler sets the variable we're waiting on
</pre><div class=""><br class=""></div><div class="">This creates a new (in this case, nested) event loop. That event loop will only be terminated when that variable is written to. Or in other words:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>loop forever</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>pull next event from the event queue</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>process that event</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if processing that event caused the variable we’re watching to be set (to anything)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>break out of the loop</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So in this context, we’re essentially sitting in that code at the vwait until we press a button on the UI to continue, etc. </div><div class=""><br class=""></div><div class="">This is because what’s actually happening is our other interpreter is busy running our program, which calls back into us on every statement, i.e.:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>about to run first statement</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>—> callback to program</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>run first statement</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>about to run second statement</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>—> callback to program</div><div class=""><br class=""></div><div class="">If we didn’t do the nested loop (i.e. not return from the callback) we’d run through our program start to finish.</div><div class=""><br class=""></div><div class="">The vwait replaces self.root.mainloop which it turns out cannot be called in a reentrant fashion (it modifies various global state variables).</div><div class=""><br class=""></div><div class="">FYI: documentation on vwait: <a href="https://www.tcl.tk/man/tcl/TclCmd/vwait.htm" class="">https://www.tcl.tk/man/tcl/TclCmd/vwait.htm</a></div></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">#15347 also has remove-interacting-debugger.patch, to be applied on top of preceding. Do you consider this also ready to go?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Issue15348 has two patches by Roger Serwy. What relation, if any, is there between your two and his? Supercede? Address different though seemingly related issues?<br class=""></div></div></blockquote><div><br class=""></div><div>Roger’s patches try to work around the bad behaviour caused by the (broken) nested mainloop. Mine actually fix the underlying root cause so Roger’s patches are then no longer needed.</div><div><br class=""></div><div>The horrific comment in run() in fix-mainloop2.patch describes things in a bit more detail in terms of what was happening before and what’s changed.</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">25313 (missingtheme.patch) isolate code to default to ‘idle classic’ on<br class="">missing theme in one place<br class=""></blockquote></blockquote><br class="">I am nearly done with my alternative patch. That is about next on my<br class="">agenda.<br class=""></blockquote><br class="">Done<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">24750 (mainwin3.patch) correct visual inconsistencies in editor window<br class="">(most jarring and noticeable on mac<br class=""></blockquote></blockquote></blockquote><br class="">Done<br class=""></div></div></blockquote></div><br class=""><div class="">Thank you kindly on the latter (as you know, was my pet annoyance) :-)</div><div class=""><br class=""></div><div class="">Mark</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>