3 ms·

Craig Latta did something very similar in software for visualising the object memory of a running Smalltalk: https://thiscontext.com/a-detailed-description-of-s

by tonyg 7y ago

Craig Latta did something very similar in software for visualising the object memory of a running Smalltalk: https://thiscontext.com/a-detailed-description-of-spoons-object-memory-visualization-tools/ https://thiscontext.com/a-detailed-description-of-spoons-obj... "When I got the current [Smalltalk image] down to about 450 kilobytes, I realized that I could render it as a reasonably-sized picture (within 800 by 600 pixels). I was interested in doing this mostly because I’d never seen a graphical representation of the Smalltalk object memory before. As I proceeded, I found it enabled some pretty useful things." There's a video (https://www.youtube.com/watch?v=1Uh8v7IzXJk https://www.youtube.com/watch?v=1Uh8v7IzXJk) and even a 3D visualization of the object graph.

peterkelly 7y ago
The 3d images remind me of something I put together a while back, showing the evolution of the object heap when performing graph reduction on simple lambda calculus expressions: https://www.youtube.com/watch?v=ZebxyrCb1ug https://www.youtube.com/watch?v=ZebxyrCb1ug
westoncb 7y ago
Interesting how many different directions people have gone in doing something along these lines... Since 2014 I've been building a system with a similar objective, but focusing on 1) visualizing at (hopefully) the most useful level of abstraction 2) making the time-evolution of objects in memory clear and navigable. Video and details here: http://symbolflux.com/projects/avd http://symbolflux.com/projects/avd My system works by monitoring/rendering explicitly defined data structures (something like `Lucidity.monitor(my_tree_data_structure)`), but more generally I think of the tool that we're missing as a kind of 'abstractoscope'--some means of automatically transforming the contents of a running program's representation in memory into something comprehensible by humans. The problem feels to me sort of like needing a microscope--we need a relatively passive instrument in order to monitor the behavior of running programs (which are not visible to the naked eye). The problem in this case is that we have too much information instead of too little though, so our instrument needs to automatically discard irrelevant information (i.e. abstract) for us, rather than magnifying.

by tonyg 7y ago

peterkelly 7y ago

The 3d images remind me of something I put together a while back, showing the evolution of the object heap when performing graph reduction on simple lambda calculus expressions: https://www.youtube.com/watch?v=ZebxyrCb1ug https://www.youtube.com/watch?v=ZebxyrCb1ug

westoncb 7y ago

Interesting how many different directions people have gone in doing something along these lines... Since 2014 I've been building a system with a similar objective, but focusing on 1) visualizing at (hopefully) the most useful level of abstraction 2) making the time-evolution of objects in memory clear and navigable. Video and details here: http://symbolflux.com/projects/avd http://symbolflux.com/projects/avd My system works by monitoring/rendering explicitly defined data structures (something like `Lucidity.monitor(my_tree_data_structure)`), but more generally I think of the tool that we're missing as a kind of 'abstractoscope'--some means of automatically transforming the contents of a running program's representation in memory into something comprehensible by humans. The problem feels to me sort of like needing a microscope--we need a relatively passive instrument in order to monitor the behavior of running programs (which are not visible to the naked eye). The problem in this case is that we have too much information instead of too little though, so our instrument needs to automatically discard irrelevant information (i.e. abstract) for us, rather than magnifying.