Looking for "ADDRESS DEBUG" concept. 
Author Message
 Looking for "ADDRESS DEBUG" concept.

>    but wouldn't it be nice to just change one line to ADDRESS DEBUG and
> have all commands simply echo to the console

> [...] send a command to a non-existent environment [...] if you have
> the default tracing on (trace f or trace n) then all these commands
> will be traced, [...]
> Alternatively, it wouldn't be that hard to write a subcommand
> environment called "DEBUG" which prints out each command.

Syntactic issues

This approach will not work with explicit address statements, as in
   /* ADDRCMDL XEDIT:  display on XEDIT's command line               */
   /*                  any Internet addresses found in the work file */
   signal on novalue /* flag particular sort of typos */
   address none      /* flag another sort of typos */
   trace o
   address xedit "COMMAND EXTRACT /LINE/CURSOR/"
   address command "PIPE xedit"     ,
                      "|" find_addr ,
                      "|" route     ,
                      "|" prune     ,
                      "| join * / /",
                      "| cmsg"
   address xedit "COMMAND LOCATE :" || line.1
   address xedit "COMMAND CURSOR SCREEN" cursor.1 cursor.2

As noted earlier (by another poster in this thread), the Trace statement
is the one line to change, to have all commands echo to the console.

Some REXX implementations support
      trace !c  /* trace, but do not execute, commands */
All REXX implementations are supposed to support
      trace ?c  /* trace commands, interactively */
      trace c   /* trace commands */

Semantic Issue

Suppressing command execution has one severe draw-back: in many cases, a
REXX program depends on the execution of a command. In the example above,
the "COMMAND EXTRACT /LINE/CURSOR/" will set the Line.1, Cursor.1, and
Cursor.2, variables that will be needed in the two pen-ultimate lines
of the program; hence, if command execution is suppressed, the REXX
interpreter will balk on undefined variables, in the latter statements.

Examples abound, where the logic of a REXX program depends on the
results gained from, or the effected by, a command; as in
   address command "ESTATE" fn ft fm
   when rc=0  then ...
   when rc=28 then ...
   when rc=32 then ...
   otherwsie       ...
These programs cannot be tested with command-execution suppressed.

The main advantage of REXX over more conventional command, or scripting,
languages is the ability to react flexibly to the results of a command
execution (return code, messages, changes in variables, or any
noticeable effect in the environment). Hence, I reckon, most REXX
programs will depend, in one place or the other, from command execution
results. Hence, a general suppression of command execution will not
help much in debugging most REXX programs.

Happy tracing, debugging, and REXXecuting,

*** Please use only my new address at uni-konstanz.de, as all Bitnet
*** addresses at DKNKURZ1 have expired, and all Internet adresses at
*** Nyx.Uni-Konstanz.de will do so some time in 1995.

Sun, 13 Jul 1997 17:49:23 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Looking for "ADDRESS DEBUG" concept.

2. Looking for "stdin", "stdout"

3. Manual describing MACRO "Concept 14"

4. Any good?: Hofstadter: "Fluid Concepts ..."

5. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

6. Debug gives an "illegal operation"

7. works in "debug" but hangs otherwise

8. "Debug Cleaner Application"

9. "Xx'Address" problem

10. "IMUL address" problem

11. "address error" during allocate()

12. debugging "Too many open files"


Powered by phpBB® Forum Software