Bret Victor and Chris Granger:
. Granger's write-up of Light Table
-- and the Victor video that inspired it --
have me wanting something new for adde:
. as it runs your code,
it opens all the files being called by main,
and also opens a simulation of the code
( some of that idea is already embodied
in the adda feature where all types
have an associated graphical image,
and you just have to start debug mode
in order to see the image of
every variable in main .
)
. once you get some working code,
it is constantly rerunning your test case
with every change to your code .
. so we get not only continuous testing,
but also continuous simulation of the testing;
and, of course,the simulation and the code are linked;
so, selecting one selects the other .
"(In light mode, Light Table lets you
see called functions not just by
highlighting their calls in your code,
but also by showing you their code to the side.
We shouldn't have to constantly
navigate back and forth to see this .
)
. this works for small files,
but for much larger ones
I would like a combination of this and
Apple's idea of being able to
open and close a file simply by
toggling the space bar .
. in my combination,
the main is opened on the left;
then for each file used by main,
it opens that file only partially,
just to show a thumbnail view of say 5 lines
to show the function's header info:
the signature and the summary string .
. when you click on the thumbnail, it opens fully,
when you arrow down, that full view is
filled with the next thumbnail's file .
. the programmability of this is important:
the layout editor should have a language for
describing not only how windows are arranged,
but also how they are behaving .
. the first time I had that idea
was wondering how to tell the editor
that we need 3 windows to be columns,
such that text being added
flows first into the first column,
with overflow going to next column, etc .
. we might have other behaviors,
so, how do we let the user design that,
and create a command for it ?
. in a composite doc' we have the choice of
whether regions overlap or not .
. when I open a thumbnail,
it covers other thumbnails,
but it doesn't cover other subwindows
like that of the simulation or the main text .
. an alternative behavior for a subwindow
is that instead of an open file
being allowed to overlap the thumbnails,
it pushes them aside,
and the region becomes scrollable,
so that I can see a stream of open files
mixed in with a stream of thumbnails .
. there are subwindows with dedicated purposes:
the project's folder system, the simulation,
the main, and the subprograms main calls .
. there are a lot of subprogram subwindows
so we can toggle them as all thumbnails,
all open, or opening only the
currently running subprogram .
. if your center of attention is not main
but something main called,
then you want main's region thumbnailed,
just like a stack of activation records:
closing your currently active file
means seeing the stack of thumbnails
that it jumped out from .
Granger's Code with a little illumination:
"( Here I find a bug where I wasn't passing x correctly.--. this is the same idea I just mentioned,
I type (greetings ["chris"]) and immediately see
all the values filled in
not just for the current function
but all the functions that it uses as well. )
that of showing the activation stack:
we're showing not just the code,
but wherever there was a
variable name in the code,
now there is a named box with a value in it
-- and of course,
every var in the code is instantiated
so there are values at
every mention of that variable .
. variables should be
toggle-able between the image and code:
an array may represent a picture,
or a list of (rgb) color vectors .
. another dimension of toggling
is the outliner feature:
all code and values are {collapsible, expandable}
and you can do this symbolically too:
there are not only commands like close all,
but such things as:
open only what names match (this pattern) .
. watching the Granger video again,
I see he does automatic filing of functions:
you can start off in one editor window,
and then when we start code for a new function,
it buds into a new editor window too;
and -- my idea here --
when you have nested functions
then you should have nested editor windows,
and of course,
they can be resized with scrolling bars,
or made so control-arrows and page{up,down}
can do the scrolling .
. the outliner menu includes
several massive window controls;
eg, we can say:
recently used windows are 25 lines high,
or say:
all windows are 10 lines long until I
focus on it for a full view .
calltree:
. a primary feature seen from the vid,
is that when the side region is showing the
files that are called by the main region,
they become part of the debugger show:
ie, when you start launching main's test program,
the files to the side turn into instantiations of
the function`bodies that main enters;
so, -- my question here --
what should it do if you have recursions,
and multiple instances of a subprogram?
the 2 obviously possible behaviors are:
# show all instantiations;
# show the current instantiations .
. in the [show current] alternative,
as the new instance is created,
you see the new instance
overwriting the previous instance .
. after the instance is done,
it is re-overwritten by the prior instance .
. in the [show all] alternative,
we need to show a call tree
perhaps expressed as dots for each node,
and then you use [birds eye view]:
drawing a box around the part you want
or using the pinch gesture
on the part of the call tree
that you want to see thumbnails of
(thumbnails are opened in the usual way).
. from the call tree's [nodes as points] view
you can also use arrow keys to
turn nodes into files or thumbnails,
one node at a time:
up= parent node, down= 1st child node;
{right,left}= nearby sibling nodes .
. we can use the finder with opener, eg:
open all the instances of subprogram x .
No comments:
Post a Comment