O.K. so picking up this idea of an external function that would return the multithreaded trace
information that then could be used for insertion in one own's trace enhancement in the context of
adding multithreaded trace.
The question would be what should be the name of such a function, which should just return the
interpreter instance, activation/invocation, thread and object's variable pool information as a
blank delimited string?
After thinking a while about this, we should probably not create a new function to follow the
principle of keeping the language small if possible at all.
Therefore it may make sense to use the existing trace() built-in function for querying that
information (returning the current interpreter instance, activation/invocation, thread, variable
pool and lock as a blank delimited string).
As trace() so far reflects as arguments the arguments of the trace keyword instruction we would need
to come up with a new argument name where the starting letter is not used yet but that should be
intuitive such that users (Rexx programmers) can infer intuitively its meaning.
As this information is meant for helping tracing the multithreaded execution of a Rexx program I
would suggest to use "Multithreading" as the argument name. "M" has not been used as an option in
the trace keyword statement nor in the trace()-BIF.
What do you think?
---rony
P.S.: Alternative names which seem to be less ideal would be "DebugInfo", "Supplemental", "Glimpse".
The latter two are not intuitive, but their first letter are not in use. "DebugInfo" would not hint
at the purpose of helping to trace multithreaded execution of programs.
On 30.09.2023 14:18, Rony G. Flatscher wrote:
Time passes too quickly.
@Rick: do you have any intentions to implement the ideas you have communicated?
---rony
On 25.03.2023 16:58, Rick McGuire wrote:
On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater <gi...@bellsouth.net> wrote:
Let me see if I've got this. If there was a class, perhaps a subclass
of outputStream, that implemented a SAY method which would "collect" the
additional multi-threading information and add it to the argument that
it receives, then one would only need to create an instance of that
class associated with (presumably) STDERR and then change the
destination of .traceOutput to be that instance. The "enhanced" trace
lines would appear instead of the standard trace lines. Is that
somewhat correct?
Pretty much spot on. It would require a couple of enhancements in other places to allow the
additional information to be gathered, but those would be fairly trivial to implement and also
useful for situations other than TRACE. This solution requires no new TRACE command syntax, and
the arguments about how much information is appropriate to add goes away because any user can
choose to modify the information as they see fit.
Rick
Gil
On 3/25/2023 8:34 AM, Rick McGuire wrote:
> I had one of those AHA moments this morning. The whole question about
> multithreaded tracing can be quite cleanly resolved by removing the
> question from the TRACE command entirely.
>
> Currently, the trace output is written to the .TRACEOUTPUT monitor.
> With a few small enhancements to already existing classes, it would be
> possible for any additional information to be added by the
> TRACEOUPUT target. To enable it, one would only need to push a new
> output destination to the monitor. The new destination would add any
> additional debug information to the trace lines. This is not only
> pretty simple, but it also means any user can customize the trace
> information to their own requirements, though it would be nice to
> supply a couple of builtin alternatives.
>
> The enhancements necessary to do this are pretty simple. The
> StackFrame class already has most of the information you need for
> debugging, but it could use methods to expose a threadid, instance id,
> and also the current GUARD status in the case of method calls. This
> can be quite easily done, and would provide useful debug information
> for more than just the trace output. It might be desirable to add the
> same methods to .Context. I can go either way with that one.
>
> Rick
>
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
