Hi Thierry,
On 10/6/2014 9:37 AM, Thierry Goubier wrote: > Hi Florin, > > you're in for some interesting questions :) > > First, I did not have a methodology for finding the issue (or explaining the > algorithm) when I started, and I didn't > have one afterwards; you need to look into the WhyLine stuff for that (they > do a lot better, but I don't have the time > to reimplement their tool). > Thanks for pointing it out. It is indeed interesting, but not what I had in mind. I am not talking about debugging here so much. I am quite good at that, and I find it natural to build tools that help me do it (and of course, Smalltalk debuggers are very good already (restarting a method/block pretty much gives you the benefits of stepping backwards)), but debugging broken behavior is more about mapping an internalized model of the execution with what's really happening, seeing where they diverge. You are just checking that what you think you know is true. Of course, when you find out it's not, you gain insight/experience. But what to do when there is nothing to check? What if, like in the situation you mentioned, the algorithm is already working (so it's producing the correct/expected results)? But you still want to make it better.... What I want help with is what I am not as good at. I want to literally "see" what's wrong (not good enough) with the picture, since the brain has those very powerful visual pattern matching capabilities. They remain unused when you are lost in the minutiae of the debugger, where you only see text and numbers, the granularity/level of abstraction is too low. Profilers are a little better - they also succinctly capture the execution tree, and I have also used traces for hard to debug sequences. Coming back to the WhyLine example, they already had something to (visually) look at: objects colliding. Other times, the visual representation is obvious/implied (say an algorithm for driving a car on a given course - even if all you are given are coordinates, it is common sense that you would draw the course on the screen and watch the car as it makes progress when the algorithm ticks). In many algorithms you don't have that. How do you find, in such cases, what pictures/graphs/animations to look at? For an algorithm one obvious candidate would be to the dynamic behavior of the main data structures used (although, say you do this for the car example and compare and contrast visualizing the data structures used by the algorithm vs visualizing the car moving, or the objects colliding). And you still have to find the right scale and level of abstraction. > But I noticed that understanding an algorithm is easy (relatively) when: > > - You can easily move repeatedly to any point in an execution stream of that > algorithm (i.e. ubiquitous debugging: > step forward, backward, jump at any point back and forth, any number of > times). > > - At each point, you are given the precise point in the source code > (debugger-like) > > - At each point, you get significant values: assignments, arguments, return > values > > Representation is easy: an execution is a tree. A sequence in this execution > is items at the same level in the tree. > Calls are subtrees, as well as iterations. Gui is simple: a tree on the left, > code pane on the right. See an example > underway: I'm trying to find a bug in LayoutFrame, so I traced > LayoutFrame>>transform: (without breaking Morphic). > This is for exploration at the moment, and not comparing values. And on a > single method, and highlighting is broken in > Pharo 4 :( > > In the value tracking idea, what we thought then in the place I worked in at > that time, is that we could study > comparing / diffing trace trees to see where the two versions of the > algorithm diverges. We didn't follow up and it > wasn't published. I have new visualisations on Roassal now, but they are for > static analysis of multitask C code. > > Does that give you ideas? > > Thierry The discussion is good, thank you. I don't think I have found the answers yet, but looking for them is fun too Florin
