Re: [Oorexx-devel] A thought on multi-threaded tracing.
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 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
Re: [Oorexx-devel] A thought on multi-threaded tracing.
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 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
Re: [Oorexx-devel] A thought on multi-threaded tracing.
Is there any news on this? As long as these thoughts of enhancements are missing in form of real code one cannot use them to debug mulit-threaded programs with the necessary context information. Therefore the question when any such changes can be expected? Or would it be better for the moment to check in the current version (cf. patch) of multi-threaded tracing (only triggered when environment variable got set before running the program) which immediately can be used for debugging? ---rony On 25.03.2023 16:58, Rick McGuire wrote: On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater 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
Re: [Oorexx-devel] A thought on multi-threaded tracing.
So it turns out that under Windows, it is easy to obtain the thread ID of the current running code. My framework now does that so it might be of use, as is, to anyone needing to know which thread executed the line being traced. Gil On 4/1/2023 5:01 PM, Gilbert Barmwater wrote: Well, FWIW, I thought so too. Just for fun I have implemented a working framework of what I described later in this thread. Of course, even though it can modify the trace output, it does not actually put the "real" values in as that would require either the modifications to the .stackframe class that Rick describes or a native method that could obtain and return them. I haven't written either at this point. Gil On 4/1/2023 12:01 PM, Rony G Flatscher wrote: That sounds very interesting! —-rony Rony G. Flatscher (mobil/e) Am 25.03.2023 um 07:35 schrieb Rick McGuire : 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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A thought on multi-threaded tracing.
Well, FWIW, I thought so too. Just for fun I have implemented a working framework of what I described later in this thread. Of course, even though it can modify the trace output, it does not actually put the "real" values in as that would require either the modifications to the .stackframe class that Rick describes or a native method that could obtain and return them. I haven't written either at this point. Gil On 4/1/2023 12:01 PM, Rony G Flatscher wrote: That sounds very interesting! —-rony Rony G. Flatscher (mobil/e) Am 25.03.2023 um 07:35 schrieb Rick McGuire : 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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A thought on multi-threaded tracing.
That sounds very interesting! —-rony Rony G. Flatscher (mobil/e) > Am 25.03.2023 um 07:35 schrieb Rick McGuire : > > > 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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A thought on multi-threaded tracing.
On 3/25/2023 11:58 AM, Rick McGuire wrote: On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater 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. OK thanks. Some more investigation shows that Trace uses LineOut rather than Say so the class would need to implement a LINEOUT method rather than a SAY method. 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. A possible implementation would be a file that contains 1) the class definition, perhaps named "enhancedTrace", with the appropriate lineOut method and 2) some prolog code that creates an instance of the class and changes the destination of .traceoutput to that instance. The user wishing to make use of this capability would then only need to ::requires the file in his program. Gil 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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A thought on multi-threaded tracing.
On Sat, Mar 25, 2023 at 11:52 AM Gilbert Barmwater 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 > > > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A thought on multi-threaded tracing.
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? 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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] A thought on multi-threaded tracing.
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
