This is an Engineering Notebook post. Feel free to ignore. It is a reworking of comments in #915 <https://github.com/leo-editor/leo-editor/issues/915>, presented here to a wider audience.
*Significance* This work shows how to communicate between different threads using two queues. Python's queue.Queue class is designed for exactly this purpose. The *command queue* contains commands *to* the debugger. The *request queue* contains requests *from* the debugger. The global listener method handles the request queue at idle time. It is a bit ugly, but it might be called the simplest thing that could possibly work. As I write this, I realize that this listener should be a function, not a method. Indeed, the listener runs in Leo's main thread, while the rest of the Xdb class runs in the subsidiary thread. In fact, listener doesn't use any ivars, which is good because doing so would not be thread safe. Pyzo's yoton framework creates inter-*process *communication using separate *threads*. I understand what yoton is doing a bit better after doing this work. *Simple code* This code was far easier and simpler than I imagined. The only complications due to outline structure were in the following methods: - NumberBar.mousePressEvent and NumberBar.paintBlock draw the breakpoint icon. - Xdb.show_line places the cursor on the line containing the breakpoint. This uses existing code: gotoCommands.find_file_line - The db-b command calls a new method, goto.node_offset_to_file_line, which scans the external file, looking for line with desired offset. - When the debugger stops in a file not contained in the outline, Xdb.make_at_file_node creates an `@file` or `@auto` node, depending on whether the file looks like it has Leo sentinel comments. - The Xdb.get_gnx_from_file helper allows Xdb.make_at_file_node to recreate the proper gnx for the newly-created `@file` node. *A buglet* There seems to be no easy way to prevent the user from changing the outline after breakpoints are set. This results in the breakpoint icons appearing in the wrong places. That is, Leo does not inform the debugger that code has changed. The workaround is obvious: don't change the code under test while running the debugger! *Summary* I understand the issues involved in using multiple threads more fully now. This will be useful later on. Postponing gui-related issues is a trick worth remembering. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
