I am leaving on a vacation with my family this Saturday. Sorry for not announcing it earlier - buying a 'last-minute' deals is becoming a habit in our family. I am taking my laptop with me so I will definitely continue to work. However, I am worried about the internet connection - I might be lucky and there might be one in the hotel, but if you do not hear from me for the following two weeks, know that I have not vanished - I have just failed to find an internet cafe.
The upcoming plan is to work on spitting the debugger to two processes. This goes hand-in-hand with solving the asynchronous issues. First, I will work on making the code ready for the change, then I will 'fake' the two processes just by running in two threads with minimal communication between them and finally I will really split it to two processes and use remoting for communication. This as a whole is huge task.
The first thing I plan to do is to get the local variables pad ready. At the moment it is simple synchronous clear/fill/redraw algorithm. This needs to be changed so that it is doing continuous update - just deleting everything looks bad when the redrawing is done in parallel. This is not as simple as it looks - objects can change types, arrays can change size, variables can go out of scope, etc... I tried to detect and handle these cases in SharpDevelop but it was not very neat. I will try a different approach this time - ignore the meaning; basically just gradually copy one text tree over other.
Doing a remote call for every single variable that needs to be updated might be too expensive. I want to create a data tree in the non-GUI process and work with it. The tree will internally remember any operations done on it (node added, node removed, value updated). The GUI process will then regularly request the set all recent updates and it will use these to update the pad. The same approach can work for all the pads.
Other data that needs to be transferred to the GUI process is currently executed line, state of the debuggee (running/stopped) and the new text in the console pad. It should not be difficult to pack all these data into one class and send it in one go. This should cover one direction of the interprocess communication.