Hi Thierry, On 10/4/2014 5:32 PM, Thierry Goubier wrote: > >> I do have specific tools I can use in such circumstances >> that you >> don't have. >> >> >> What kind of tools? I would be interested in learning about them >> and the >> analysis use cases they support. >> >> >> I have a trace tool for those situations (and also for parser work). >> >> >> What trace tool? Is an example available? > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > >> My original use case was: >> - Finding the bug in an error correction decoding algorithm which >> worked without error, but with non-satisfying results: lower than >> expected SNR. >> - Has then been used very successfully to explain the algorithm. >> - Was then used as the basis for a hardware design methodology by >> dynamic code traces of multithreaded programs >>
I am very interested in the "explaining the algorithm" aspect of your tool. Could you please talk a little about that? I think I had a similar use case - improving an algorithm working over a lot of data (so stepping through it with a debugger was unrealistic) - and my approach was to run two versions in parallel (the latest (best) available iteration in the implementation, known to work, versus the bleeding edge), with synchronization points for every iteration within the algorithm execution, so that I would catch (through a halt) any divergence as soon as it started, and from them on using the debugger. This worked quite well, but it did not help with explaining the working of the algorithm and I kept wishing I had a visualization that would help me get to an intuitive (and holistic, not just of the subparts) understanding of how the algorithm worked (in the style of Bret Victor's visualizations), but I did not know how to get to it. So, if you did manage to get to such a visualization (one that does not come from an already (pre-existing for the creator of the visualization) understanding of the algorithm), that would be fantastic Florin >> Other use cases I use it for: >> - Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text >> editor errors) where halt makes the image unusable. >> - Debugging code in Parsers when the code of a reduction is not >> working properly (somewhere deep in the AST). >> >> >> Is this more than a logger? > > Part of it is a logger, to record events. > > A second part of it is a code rewriting tool. You give it a method, it adds > the code to trace the execution and > recompiles the method. > > A third part is a viewer which links each recorded event with the expression > which generated it in the method. > > (The second part could be changed to use the Opal facilities instead of code > rewriting. There is probably work to be > done on the logger as well: remote logging via RS232, Jtag probes, etc...). > > Thierry > >
