While experimenting with the trace infos I think we should choose the names for the entries in the
TraceObject in a self-documentary manner, such that Rexx users can intuitively understand their
meaning (saving looking up the documentation once accustomed).
Suggesting to use the following letters and names (in alphabetical order) and in parentheses the
names in the source:
* A ... attributePool: "object variable dictionary", the Rexx users will know
about the attribute
directive and know that all attributes constitute the object variables
* * ... hasObjectLock: "isObjectLockScoped"
* R ... interpreter: "instance"
* I ... invocation: "activation"
* G|U ... isGuarded: how the method got defined (not its current guard state)
* L ... objectLockCount: "reserveCount"
* T ... thread: "activity"
* timeStamp: a DateTime object that documents when the TraceObject got created
(if Rexx users
collect the TraceObject, they can take advantage of this information)
* traceLine: the trace line that gets displayed
The TraceObject should have two class attributes:
* "option" (instead of mtPrefix which sounds awkward): one of "N" (normal), "S"
(standard) or "F"
(full), default: "N"
o 'N' ... returns the traceline only
'S' ... returns prefix [T1 I1 ] ... thread, invocation
for a method statement:
[T1 I1 G L1 *] ... thread, invocation,
guarded/unguarded,
lockcount, hasObjectLock
'F' ... returns prefix [R1 T1 I1 ]... interpreter, thread,
invocation
for a method statement:
[R1 T1 I1 G A1 L1 *] ...
interpreter, thread,
invocation, guarded/unguarded, attribute pool, lockcount, hasObjectLock
* "collector": any object that understands the APPEND message with a single
argument (e.g. ordered
collections), default: .nil
o the Rexx user can supply any object which from that moment on will get
any new TraceObject
appended, changing it to .nil stops that; however a Rexx user can switch
the collector to
different collections at runtime
This information and features of TraceObject should allow for maximum flexibility. The standard
cases normal, standard and full might be more than sufficient for normal debugging, even of
multithreaded programs.
However, if special needs arise like profiling, analyzing repeated execution of (multithreaded)
programs, identifying patterns or whatever this infrastructure should allow for any Rexx user to
intercept the TraceObjects sent to .traceOutput, inspect them and do with the information whatever
is needed to satisfy any special need.
Once the implementation is done and some scripts can be shared, I would make a portable build and
the scripts available for download to research, test this infrastructure. Also I will supply an
update to the suggested documentation (to cater for the suggested name changes and the new features,
i.e. the timestamp entry and the collector class attribute).
The exploitation of the extended trace capabilities, including having the TraceObjects collected for
later analysis, should really have a low threshold such that it is easy to use. If a Rexx user does
not need the new features, he would not have to do anything special. A Rexx user wishing to exploit
the new features can do so hopefully without any cumbersome preparations.
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
