I get this question from time to time. At first I was puzzled. It is so natural for a debugger to be implemented this way. What do they ask me in the first place? Then I realized that Process Simulate users are not software developers. They expect a regular viewer to present them with all the debugging functionality without being aware of the technical details that allow debuggers to work. Further confusion comes from the fact that we already have such a viewer - the Robot Program Viewer. It does exactly this, isn't it? It already provides debugging functionality for robotic programs. Why should SCL be any different?
I agree this is confusing. Here is how I see it: The Robot Program Viewer tries to mimic a debugger but it is not a debugger. I find it not only strange but in fact intimidating.
To better explain my point of view I must bring some light on debuggers in general:
Debuggers work by halting the thread that executes the code. This means that the thread is blocked until the debugger allows it to continue. When the execution is stopped the debugger can analyze the call stack of the thread, presenting all stack frames (function calls) on it. For each stack frame it can show the values of the local variables within it. It can evaluate expressions in the context of a particular stack frame. It can also modify the state of the variables in the stack frame.
If the thread is running the call stack jumps up and down all the time and there is no way for a debugger to show the current state of the code since it changes all the time. This is why we have breakpoints on the first place.
As we know Process Simulate is mostly a single threaded application. What will happen if we halt the one thread that does the work? Everything will stop. If the debugger was a viewer it will also freeze and the user will have no way to resume the execution. This is why the debuggers are designed to run in a separate process. They stay active while the process (thread) being debugged is on halt.
The debugger offers you the ability to trace the code line by line. Go inside a function or get out of it. You can also continue the execution once its stopped.
How does this apply to the Robot Program Viewer? Short answer is: It does not. Breakpoints in RPV pause the simulation instead of halting the thread. This way the thread stays active to serve the UI but how can I see the call stack if it is still active? Even without breakpoints I can monitor the variables (when it works) while the simulation is running. How is this possible? How are these values related to the code that is running in the background? You cannot say. You cannot trace the code or go inside a function. Should I put a breakpoint on every line? Instead of regular debugger controls I am using the simulation controls ?!?
You see. All this seem like a big workaround to me.
In contrast I would like to emphasize on the way the Java Script debugger works in Google Chrome. If you hit F12 in the browser you'll be presented with a debugger that is pretty similar to the SCL debugger. The only difference is that it is not a separate application. It runs within the browser. How did they do it? Well they were pretty clever when designing the architecture. Every tab in the browser is actually a separate process. This means that the Java Script that runs the site is running in a separate process. And since it is a separate process we can have the debugger in the main one - the browser. There are again two processes but from the user's perspective they look like one.
If we could somehow make our simulation run in a separate process we could do the same. Unfortunately the architecture of Process Simulate is not designed for this so the only option that we have is to have the debugger run in a separate process.
Leaving all this aside I wonder why users want the debugger to be a viewer? It is quite expensive in terms of screen space. If it was a viewer it would be very likely that users undock it on another screen. Isn't it the same as having a separate application on the other screen? I may get an answer one day ...
Now you know why!
Comments