Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Cogito, ergo sumthin'

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                         

Bubblechamberesque Runtime Representation

Show the unfurling of a computer program as it happens.
  (+9, -3)
(+9, -3)
  [vote for,
against]

A line tracks east across the screen, suddenly, a circle emerges, expanding to the right as a series of smaller circles appear at equidistant points along its diameter, each expanding in their own turn. One of the circles spawns a radial set of spiralling logic-traps - each ending in eventual cul-de-sac, except for the final one which sets off another for-next circle...

The scene is reminiscent of the trails left by accelerated particles in a bubble chamber, but is rendered live as a program's code is interpreted by the computer.

Apart from the aesthetic niceties, such a representation might be a useful aid to debugging, or in the classroom to explain programming concepts, or in situations where visualisation of programmatic control structures might be helpful.

I'd imagine showing loops as circles with iterations dynamically marked along their diameters. From each iteration point, any code that is executed within the loop would then draw its own 'codepath'. Nested loops would show up as lollipops budding out from around a central flower.

If...Then branching statements would show as forked points, only one stub of which would continue on the grand codepath; Goto's might be represented as a jagged link to some other area altogether; the details created by Function calls could be shown in a slightly different colour.

The whole structure of a program would unfurl dynamically in realtime as it ran.

Having run a program, or perhaps having broken out into an 'interrupt' or debug mode, you'd be able to compare the pictorial representation of events - mouseovers at key points might also highlight the code responsible, and any variables that are affected.

While this is best suited to interpreted languages, I wonder if a version might be able to look at a memory location and, assuming it understood the opcodes for the chip expected to interpret the memory, pick out the conditional and structural elements in order to build up a picture of execution.

zen_tom, Jan 09 2009

animated gif of an event synchonized loop http://s1.tinypic.com/5y9t937.jpg
[beanangel, Jan 12 2009]

YouTube: Java Process Visualiser https://www.youtube...v=yUTEGepKIxY#t=650
A really interesting project - not what I'm describing here, but another approach at visually modelling code as it runs. [zen_tom, Oct 02 2013]

[link]






       Hook some D/A converters to the address lines of your processor*, switch your oscilloscope to X-Y, sit back and enjoy.   

       *OK, this works best for non-cached systems.
coprocephalous, Jan 09 2009
  

       Ok, am I getting this right for a simple example:   

       prog1
set up
loop1
run prog2
loop2
run prog3
end
  

       prog2
loop
end
  

       prog3
loop
end
  

       And this all becomes   

       line
nodes (set up)
circle (although I would prefer a spiral for a loop)
branch
circle
back along branch
circle
branch
circle
back along branch
terminus
  

       Could be nice, and would work for debugging quite well.
miasere, Jan 09 2009
  

       I think all but the simplest programs are going to fill the screen up pretty quickly. I also think the program will have to execute excruciatingly slow for humans to enjoy the visual aspect.
phoenix, Jan 09 2009
  

       I'd love to see what happens when you point this program at itself.
wagster, Jan 09 2009
  

       Erm, sort of [miasere] - but you don't have anything happening in your loops, nor do I know how many iterations they have.   

       Here's an example in a made-up language:
  

       Prog1
X = 0
FOR i = 1 to 100
..X = X + 1
..IF X = 30 THEN
....Q=FunctionA(X)
..ELSE
....Q=FunctionB(X)
..END IF
NEXT i
End Prog1
  

       FunctionA(Parameter)
FOR i = 1 to Parameter
..A=A+i
NEXT i
RETURN A
End FunctionA
  

       FunctionB(Parameter)
..B=(Parameter/2)
RETURN B
End FunctionB
  

       -END CODE-   

       So, you would start the program and (assuming you'd set it up to track from left to right) see a line emerge from the left hand-side of the screen, a small node-blob to represent the assignment of the variable X, then move on a bit more before expanding into a circle. The first iteration of the loop appears as a simple node-blob from the intersection-point of the circle and drifts around the diameter clockwise, before sprouting a small line, containing another X-assignment node, then continues outwards and sprouts into an IF branch - one half of which doesn't develop, while the other now follows the codepath specified by the code in FunctionB - perhaps rendered in a slightly different colour to show that there's a scope-change. FuncB is a simple assignment, warranting only a regular Node-blob.   

       At this point, control returns to the Prog1 represented by a line curling back to the intersection point of the original line and the current i-loop, from whence a second iteration sprouts, floating around the diameter of this loop as the previous one did (the previous codepath might shift gently along as it's displaced by the live code unfolding) - since at this point, X <> 30, the shape of the codepath will be the same, and will repeat through each iteration up to the 29th or 30th, where FunctionA is invoked (X now being = 30) taking a different path from the main loop, this path containing a loop of its own that'll have 30 iterations - since not much is happening within this loop, it should end up looking a bit like a 30-petalled flower. This is the first of our loops to run to completion (and maybe a spiral is a better representation since it has a definite end-point, though a circle's centre might work to represent the completion of an iterated loop) but either way, once complete, the codeline returns to its original progression from left to right and comes to a halt at the end of the program. The overall shape; line, circle with sprouts (one of which has another circle on the end, that circle showing 30 node-petals)with perhaps a line trailing off from the right-hand side of the circle to show program termination.   

       [phoenix] filling up the screen would indeed happen, but if we used the kind of zooming you can do in vector-based design programs (CAD, Illustrator etc) we should be able to still get an operational view of the the program's execution - and still be able to focus in on the bits we're interested in.   

       Also, yes the program would have to be slowed down in order to see all the pretty unfurlment - but maybe if this were generated as a sort of log-file, you could run the code at full-speed, and then trace through the execution using a scroll-bar, or just set the playback speed and watch it go forwards (or in reverse, if you wanted to see how something happened exactly)
zen_tom, Jan 09 2009
  

       sp: bubblechamberesque
po, Jan 11 2009
  

       Oops. Thanks po!
zen_tom, Jan 11 2009
  

       Like a pretty flow diagram then?
silverstormer, Jan 11 2009
  

       Link has a picture of a recurring loop synchronized with an event very sexy is actually a sewing machine animated gif   

       visit link to have thrill
beanangel, Jan 12 2009
  

       VDU 23;12;0;0;0
Dub, Jan 12 2009
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle