Reverse $QUERY (string V glvn , -1 )
2 argument $QUERY (string V glvn , 1)
Command line "more linuxy" to give gnu readline commands, external library
already: ^E ^A ^U
pipe from command line into operating system commands
Ignore BREAK in "Application Mode"
CR LF in ROUTINE.m lines
Global variables search list
Faster C-Runtime for Global Access
SSVNs recognized and call User Code
C call-in code optimization
direct C calls to access GT.M database structures
adding finer Debugging control. (BREAK in middle of line)
would like to run an idea past you that I would like to implement.
I would like to implement a Glass Wall debugging module for GT.M
A glass wall is a method of running the system so the changes that come
set of processes is separated from any others. Much like a glass wall is
the process and the data that is seen "through" the glass wall to see the
data written on
the "untouchable" wall.
If there is nothing written on the glass wall then any globals that are
written on the "untouchable"
wall are visible as if they are are written on the glass wall. This would
allow the back wall
to be the production database, and the glass wall can be a database that
records all the
changes that have happened while running the currently tested program.or
set of programs.
GT.M currently has a single variable $ZGBLDIR which references a list of
names, much like a translation table in other MUMPS implementations.
I propose to add two more translation tables to the GT.M database. The
first would record any
data that had been SET by the programs using this glass wall. Effectively
writing on the front
of the glass wall. Any functions like $DATA, $GET, $ORDER, $NEXT,
that reference globals will first look in the "front of the glass" database
to see if there
is a global value with that reference there.
If there is, the data about that node will be returned.
If there is nothing in the front of the glass database, then it will look
in the "back of the glass
wall" database. This database is intended to record any global nodes that
have been KILLed.
Since the normal global code does not record any data about what is not
there, we have
to explicitly record these on the "back of the glass wall" database because
if we didn't,
we could have the paradoxical action of KILLing a global node, and then
after the node is
removed from the front of the glass wall, its entire global subtree will
because it is defined in the "untouchable" wall behind the glass wall.
So we need to record KILLs as positive data that is interpreted negatively
the official MUMPS semantics of globals.
Finally if there is nothing recorded on the front or the back of the glass
wall, the data from
the untouchable wall will be returned.
Do you think this will work ?
How would you implement a glass wall ?