h a l f b a k e r yThe leaning tower of Piezo
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
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.
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. |
|
| |
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. |
|
| |
I'd love to see what happens when you point this program at itself. |
|
| |
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
|
|
| |
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) |
|
| |
Like a pretty flow diagram then? |
|
| |
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 |
|
| |