Possible GT.M Hacking targets discussed on Code-Convergence call

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)

Glass Wall

<<<
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
from some
set of processes is separated from any others. Much like a glass wall is
erected between
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
global variable
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,
$REFERENCE, etc
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
suddenly appear
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
to maintain
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 ?
>>>

like0

Comments

Possible GT.M Hacking targets discussed on Code-Convergence call

Maury Pepper's picture





Regarding the Glass Wall. I recall that the feature existed in
some implementation of MUMPS that I worked with about 20 years
ago. My guess is that it was DataTree. Can anyone confirm, correct
or add to that? I think it would help to look up the description
of that feature as a reference. I have manuals for DTM and MSM,
and I'm sure others have those and others that we can access for
reference.

   -maury-




cite="mid:CAH8N84zMfXPZGvaq0tTNH021si=gUZxM53+atXjVgdqqJ_nU0Q@mail.gmail.com"
type="cite">
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 <DEL>

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)

Glass Wall

<<<
 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 from
some
set of processes is
separated from any others. Much like a glass wall is erected
between
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 global
variable
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, $REFERENCE,
etc 
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
suddenly appear 
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 to maintain
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 ?
>>>






--

Full post:
https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hacking-targets-discussed-code-convergence-call

Manage my subscriptions: https://www.osehra.org/mailinglist

Stop emails for this post:
https://www.osehra.org/mailinglist/unsubscribe/4845




like0

Possible GT.M Hacking targets discussed on Code-Convergence call

DAVID Whitten's picture

I googled for "Glass Wall" and "DataTree" and found this posting by Larry
Landis
at https://sourceforge.net/p/fis-gtm/discussion/34582/thread/c29f6021/

on Forum: Open DiscussionCreator: LD Landis Created: 2002-03-20 Updated:
2002-03-20

Conceptual Specification for "The Glass Wall"
Ideas for an Extension to GT.M

Overview
--------

The term "The Glass Wall" has been coined to convey a significant
capability in the presentation, manipulation and management of data. This
document defines the concepts included in the term "The Glass Wall".

Historically, there have been implementations providing many people
experience with similar capabilities (e.g. DataTree), but differences
exist. Where these capabilities are significantly different from those
historic implementations, special note of the difference is made.

Brief Description
-----------------

A configuration using "The Glass Wall" may be thought of along the lines of
the following analogy...

- Take a "master" copy of a drawing, and overlay it with a sheet of special
glass. Initially, the view of the drawing (through the glass) is identical
to the drawing itself.

- An artist then makes any modifications to the drawing desired. The
'paint' when applied to the glass is opaque and completely covers the
drawing immediately underneath. A special 'eraser'
(masking tape) erases elements of the drawing so as to make erased features
completely hidden from view, forever (on the sheet of glass).

- New drawing (on previously unused or erased) on or erasure of areas is
retained on the glass sheet, without having any effect on the original
"master" copy underneath the glass sheet, other
than to provide a durable (permanent) masking of the underlying master copy.

- The glass sheet retains only the modifications to the underlying image,
and may be removed for separate examination, allowing the artist to see
what changes were made to the original. One may
"look through" the glass independently of having the original drawing
master behind it.

"The Glass Wall" is intended to be a separate data store that is able to
source data from alternative data stores but restricting the storing or
modification of data to the locale of the glass
wall... thereby restricting any and all attempts to change data, localizing
the effect of those changes. Two common uses of this technology are:

1. Facilitate creation of a local test environment (sourcing the data
from a source that must be treated as "read-only") without requiring
more storage than is necessary for storage of the changes.

2. Facilitate re-hosting of large data stores and aiding in the migration
of data from one data store to another without requiring a "data
conversion" event (which generally requires system or application down
time).

In analogy, there are operations that need some
interpretation relative to the concept of "The Glass Wall", and some
desired side effects as well.

1. By running an application behind the glass wall, access to all data in
the master is available to the application.
2. All changes to the data made by the application are stored in the data
space provided by the glass wall.
3. Included in the "all changes" are pervasive persistence of the effects
of KILLs on the data.
4. Optionally, explicitly generate an error if using an explicit
reference attempts to avoid the glass wall, except for "drilled holes" in
the glass wall.
5. Ability to determine $data() on or below the glass wall.

Operations Supported
--------------------

Global references, whether explicit or implicit, may be used as an argument
where ever a "gvn" (ANSI M Standard global variable name) is allowed.
Commands and functions supporting global references include:

Commands
- KILL
- LOCK
- MERGE
- SET

Functions
- $DATA
- $GET
- $NEXT (eventhough obsolete)
- $ORDER
- $QUERY

End of $Source: /home/gtm/docs/RCS/glass_wall.txt,v $

On Thu, Apr 28, 2016 at 5:49 PM, Maury Pepper wrote:

> Regarding the Glass Wall. I recall that the feature existed in some
> implementation of MUMPS that I worked with about 20 years ago. My guess is
> that it was DataTree. Can anyone confirm, correct or add to that? I think
> it would help to look up the description of that feature as a reference. I
> have manuals for DTM and MSM, and I'm sure others have those and others
> that we can access for reference.
>
> -maury-
>
>
> 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)
>
> Glass Wall
>
> <<<
> 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
> from some
> set of processes is separated from any others. Much like a glass wall is
> erected between
> 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
> global variable
> 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,
> $REFERENCE, etc
> 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
> suddenly appear
> 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
> to maintain
> 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 ?
> >>>
>
>
> --
> Full post:
> https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hac...
> Manage my subscriptions: https://www.osehra.org/mailinglist
> Stop emails for this post:
> https://www.osehra.org/mailinglist/unsubscribe/4845
>
>
>
> --
> Full post:
> https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hac...
> Manage my subscriptions: https://www.osehra.org/mailinglist
> Stop emails for this post:
> https://www.osehra.org/mailinglist/unsubscribe/4845
>
>

like0

Possible GT.M Hacking targets discussed on Code-Convergence call

K.S. Bhaskar's picture

How are these three different? Thanks.

* Faster C-Runtime for Global Access
* C call-in code optimization
* direct C calls to access GT.M database structures

Regards
-- Bhaskar

On 04/28/2016 03:45 PM, David Whitten wrote:
> 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)
>
> Glass Wall
>
> <<<
> 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
> from some
> set of processes is separated from any others. Much like a glass wall
> is erected between
> 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 global variable
> 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,
> $REFERENCE, etc
> 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 suddenly appear
> 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 to maintain
> 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 ?
> >>>

--
|GT.M - Rock solid. Lightning fast. Secure. Pick any three.|

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

Possible GT.M Hacking targets discussed on Code-Convergence call

K.S. Bhaskar's picture

By "adding finer Debugging control. (BREAK in middle of line)" do you
mean set a breakpoint in the middle of a line? You can code a BREAK in
the middle of a line.

Regards
-- Bhaskar

On 04/28/2016 03:45 PM, David Whitten wrote:
> 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)
>
> Glass Wall
>
> <<<
> 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
> from some
> set of processes is separated from any others. Much like a glass wall
> is erected between
> 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 global variable
> 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,
> $REFERENCE, etc
> 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 suddenly appear
> 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 to maintain
> 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 ?
> >>>

--
|GT.M - Rock solid. Lightning fast. Secure. Pick any three.|

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

Possible GT.M Hacking targets discussed on Code-Convergence call

DAVID Whitten's picture

You can code a BREAK in a line, but then all processes who are running the
code will have to deal with the BREAK.
And since there is no way to tell GT.M to only act on BREAKS for people in
Programmer Mode, then anyone else
using the system (even if it isn't live, possibly being used for training)
will be affected by the BREAK commands.

the ZBREAK command sets Breakpoints only for your process. This doesn't
affect any other process but your own.
Perhaps creating a replacement line on the fly that has a BREAK command
inserted between each command
could do what is needed (that is compiled on the fly). Since Debugging
occurs at human speed, a recompile for
lines that this process is using might do what is necessary. Or maybe a
NOP instruction that gets turned into a BREAK
for the debugging user. I'm not trying to limit how something is done. It
just is useful to be able to control execution
of code to a finer-grained degree.

Dave

On Mon, May 2, 2016 at 4:42 PM, K.S. Bhaskar
wrote:

> By "adding finer Debugging control. (BREAK in middle of line)" do you mean
> set a breakpoint in the middle of a line? You can code a BREAK in the
> middle of a line.
>
> Regards
> -- Bhaskar
>
> On 04/28/2016 03:45 PM, David Whitten wrote:
>
> 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)
>
> Glass Wall
>
> <<<
> 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
> from some
> set of processes is separated from any others. Much like a glass wall is
> erected between
> 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
> global variable
> 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,
> $REFERENCE, etc
> 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
> suddenly appear
> 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
> to maintain
> 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 ?
> >>>
>
>
> --
> GT.M - Rock solid. Lightning fast. Secure. Pick any three.
> _____________
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you.
>
> --
> Full post:
> https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hac...
> Manage my subscriptions: https://www.osehra.org/mailinglist
> Stop emails for this post:
> https://www.osehra.org/mailinglist/unsubscribe/4845
>
>

like0

Possible GT.M Hacking targets discussed on Code-Convergence call

STEVEN MCPHELAN's picture

A ZBREAK command for a process would be nice. You do have a work around by
placing a BREAK command in a line for which only you would Break.
B:DUZ=xxxx

However, does GT.M continue processing if you enter GO at the programmer's
prompt?

Steve
The foundations of our society and our government rest so much on the
teachings of the Bible that it would be difficult to support them if faith
in these teachings would cease to be practically universal in our country.
- Calvin Coolidge

like0

Possible GT.M Hacking targets discussed on Code-Convergence call

K.S. Bhaskar's picture

GT.M doesn't have a GO command (it has G and GOTO), but it does have
ZCONTINUE and ZSTEP commands.

Regards
-- Bhaskar

On 05/02/2016 11:25 PM, STEVEN MCPHELAN wrote:
> A ZBREAK command for a process would be nice. You do have a work
> around by placing a BREAK command in a line for which only you would
> Break. B:DUZ=xxxx
>
> However, does GT.M continue processing if you enter GO at the
> programmer's prompt?
>
> Steve
> The foundations of our society and our government rest so much on the
> teachings of the Bible that it would be difficult to support them if
> faith in these teachings would cease to be practically universal in our
> country. - Calvin Coolidge
>
>
>
> --
> Full post:
> https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hac...
> Manage my subscriptions: https://www.osehra.org/mailinglist
> Stop emails for this post:
> https://www.osehra.org/mailinglist/unsubscribe/4845

--
|GT.M - Rock solid. Lightning fast. Secure. Pick any three.|

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

Possible GT.M Hacking targets discussed on Code-Convergence call

K.S. Bhaskar's picture

Thanks for the explanation.

Regards
-- Bhaskar

On 05/02/2016 11:05 PM, David Whitten wrote:
> You can code a BREAK in a line, but then all processes who are running
> the code will have to deal with the BREAK.
> And since there is no way to tell GT.M to only act on BREAKS for people
> in Programmer Mode, then anyone else
> using the system (even if it isn't live, possibly being used for
> training) will be affected by the BREAK commands.
>
> the ZBREAK command sets Breakpoints only for your process. This doesn't
> affect any other process but your own.
> Perhaps creating a replacement line on the fly that has a BREAK command
> inserted between each command
> could do what is needed (that is compiled on the fly). Since Debugging
> occurs at human speed, a recompile for
> lines that this process is using might do what is necessary. Or maybe
> a NOP instruction that gets turned into a BREAK
> for the debugging user. I'm not trying to limit how something is done.
> It just is useful to be able to control execution
> of code to a finer-grained degree.
>
> Dave
>
>
> On Mon, May 2, 2016 at 4:42 PM, K.S. Bhaskar > > wrote:
>
> By "adding finer Debugging control. (BREAK in middle of line)" do
> you mean set a breakpoint in the middle of a line? You can code a
> BREAK in the middle of a line.
>
> Regards
> -- Bhaskar
>
> On 04/28/2016 03:45 PM, David Whitten wrote:
>> 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)
>>
>> Glass Wall
>>
>> <<<
>> 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 from some
>> set of processes is separated from any others. Much like a glass
>> wall is erected between
>> 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 global variable
>> 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,
>> $REFERENCE, etc
>> 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 suddenly appear
>> 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 to maintain
>> 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 ?
>> >>>
>
> --
> |GT.M - Rock solid. Lightning fast. Secure. Pick any three.|
> _____________
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i)
> delete the message and all copies; (ii) do not disclose, distribute
> or use the message in any manner; and (iii) notify the sender
> immediately. In addition, please be aware that any message
> addressed to our domain is subject to archiving and review by
> persons other than the intended recipient. Thank you.
>
> --
> Full post:
> https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hac...
>
> Manage my subscriptions: https://www.osehra.org/mailinglist
>
> Stop emails for this post:
> https://www.osehra.org/mailinglist/unsubscribe/4845
>
>
>
>
>
> --
> Full post:
> https://www.osehra.org/post/code-convergence-work-group/possible-gtm-hac...
> Manage my subscriptions: https://www.osehra.org/mailinglist
> Stop emails for this post:
> https://www.osehra.org/mailinglist/unsubscribe/4845

--
|GT.M - Rock solid. Lightning fast. Secure. Pick any three.|

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0