[Idle-dev] pending changes

[Mark Roseman]

> On Nov 16, 2015, at 5:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 10/27/2015 5:27 AM, Terry Reedy wrote:
>> On 10/26/2015 1:15 AM, Terry Reedy wrote:
>>> On 10/22/2015 12:25 PM, Mark Roseman wrote:
>>>> A few incremental issues still to be reviewed/integrated:
>> 
>> Since pushing 12+ patches for 10 issues in 2 weeks (September/October),
>> I have focused on Python/IDLE startup problems.  The changes for Windows
>> in 3.5.0 introduced some new ones, some of which affect IDLE.  For
>> instance, when IDLE starts from the icon, the usual case, it starts in
>> /Windows/system32 instead of the install directory.  Two or three people
>> reported problems with this.  These multiple unanticipated new problems
>> have made me a bit more cautious.  Making IDLE pretty is not much good
>> if people cannot run it.


Or if it’s that ugly and horrible, not having it start could save them the pain. ;-)


>> 
>>>> 24455 (fix-mainloop2.patch) fix debugger crash caused by nested main
>>>> loops
> 
> I am looking at this now.  Review and questions:
> Issue 15347 has fix-nested-mainloop.patch, superceded by
> Issue 24455, fix-mainloop2.patch.  This has 2 tk calls.
> self.root.tk.call('vwait', '::idledebugwait')
> self.root.tk.call('set', '::idledebugwait', '1')
> 
> 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.

The code in the patch for 24455 has this comment on it:

+        # 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

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:

	loop forever
		pull next event from the event queue
		process that event
		if processing that event caused the variable we’re watching to be set (to anything)
			break out of the loop


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. 

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.:

	about to run first statement
		—> callback to program
	run first statement
	about to run second statement
		—> callback to program

If we didn’t do the nested loop (i.e. not return from the callback) we’d run through our program start to finish.

The vwait replaces self.root.mainloop which it turns out cannot be called in a reentrant fashion (it modifies various global state variables).

FYI: documentation on vwait: https://www.tcl.tk/man/tcl/TclCmd/vwait.htm


> #15347 also has remove-interacting-debugger.patch, to be applied on top of preceding.  Do you consider this also ready to go?

Yes


> 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?

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.

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.



> 
>>>> 25313 (missingtheme.patch) isolate code to default to ‘idle classic’ on
>>>> missing theme in one place
>> 
>> I am nearly done with my alternative patch.  That is about next on my
>> agenda.
> 
> Done
> 
>>>> 24750 (mainwin3.patch) correct visual inconsistencies in editor window
>>>> (most jarring and noticeable on mac
> 
> Done

Thank you kindly on the latter (as you know, was my pet annoyance) :-)

Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20151117/8d88ff8d/attachment.html>