History aware debugger
Locked
 
|
Dear All,
Rosario, a really smart student from University of Chile, is working on a history-aware debugger (sometimes called Omniscient debugging). Although this is still an early version of Rosario’s prototype and we are still unsure what we actually want (as you may guess, it all depends on the usage scenarios we want to cover), Rosario decided to do a small video, just to spark what has to be sparked :-D Thanks Andrei for offering his help on this! It is good to have you among us! Cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Even if it's an early stage it already looks good. We definitely need more live visualisations + profiling information into the debugger :) Cheers, Andrei On Wed, Dec 10, 2014 at 2:26 PM, Alexandre Bergel <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by abergel
Hi, This is some cool work. It's great to see what can be done once the basic infrastructure is moldable and open for extensions. @Rosario: I think that the method example is ingenious in that it is easy to explain the technical side of the debugger, but I would suggest to pick an example that exhibits a concrete problem that the debugger helps solve. For example, when we presented the moldable debugger we presented some concrete stories that helps the user understand the value of the tool: Here are some things I could observe: - you show the change in the variable value. You describe the color thing at the end of your demo, but this is probably one of the very first things you should mention :). Then again, it is not the color that is important, but the mechanism of identifying the change in value. I can imagine two stories in this direction: --- pick a case where you get an error due to a value that is not expected (for example, through a side effect). --- pick a case where a value that is expected to change, does not change. - you start by saying that you open the debugger by "profiling" two objects. You should focus on describing the meaning of this "profiling". Specifically, you should focus on the use case. A drawback I see is that I have to define the objects of interest before I start the debugger. That means that when I have a problem, I have to restart my scenario. There are valid situations when this is acceptable, but you have to explain. Another route you could go would be to say that there are scenarios when you do know upfront what variables you want to profile. For example, in a Playground, you might consider by default all variables defined in that playground. Or, you could say that once you are in a debugger because of a breakpoint, you could just pick dynamically the objects to be profiled from that point on. - the control flow is a little bit unclear. What does it show exactly? - finally, the visualization probably can be improved. As it is now, your visualization will quickly become color noisy because you mark all values. If the change of value is the most interesting thing, then perhaps you want to focus on that and simply mark the situations when value changes. In any case, keep it up and please feel free to "spam" us with the direction in which you want to take this :) Cheers, Doru On Wed, Dec 10, 2014 at 6:26 PM, Alexandre Bergel <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |