Thanks for the feedback. Probably putting M as the trailing letter after the alphabetic letter as
Mike suggests is the best option. Omitting the trailing M would switch back to the simple form.
Would that be acceptable for everyone?
---rony
On 08.02.2023 21:24, Rick McGuire wrote:
The special symbol characters "." and "_" are also available as indicators. I'm a definite -1 to
using environment variables and Erich has also voiced his displeasure about that.
Another option might be to allow a second keyword following the trace type that indicates using
the expanded form. It should also allow explicit specification of the simple form too.
Rick
On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw <m...@speleotrove.com> wrote:
I would have put the M after the other letter because it's really a
subsidiary option. If
it's first it rather 'M'asks the main option?
Mike
----------------------------------------------------------------------------------------------------
*From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
*Sent:* 08 February 2023 14:16
*To:* oorexx-devel@lists.sourceforge.net
*Subject:* [Oorexx-devel] Planning to add multithreaded (concurrent)
tracing (Re: RFC for
feature request "794 Concurrency request"
Coming back to this RFE from 17 months ago which I would like to add to
trunk. Without it
one can hardly use TRACE for debugging multithreaded programs in a
Rexx-like, i.e. easy
manner.
Currently having tried to incorporate the feedback about too many
whitespaces between the
new columns (Rexx interpreter instance number, Thread number, Activity
number, reserved
object pool).
There was another idea about making this concurrency/multihreaded trace
available without
a need to define an environment variable RXTRACE_CONCURRENCY before
starting a Rexx
program. This post is about ideas of how to activate and deactivate
concurrent tracing at
runtime (either via the TRACE keyword instruction or the TRACE()-BIF)
in a manner that is
intuitive and easy to remember.
One possibility would be to introduce new alphabetic options, this time
with two letters
by prepending the letter 'M' (for multithreaded as the letter c is
already used for
tracing commands and may therefore be irritating) to the existing
alphabetic characters,
hence defining the following semantics:
*Trace**
* *Option, turn off MT**
* *Option, turn on MT**
*
All
A
MA
Command
C
MC
Error
E
ME
Failure
F
MF
Intermediates
I
MI
Labels
L
ML
Normal
N
MN
Off
O
-
Results
R
MR
This would have the benefit that anytime it becomes possible to turn on
and to turn off
multithreaded/concurrent tracing at runtime.
What do you think?
---rony
P.S.: The "fallback" would be to just add it as is, i.e. using the
environment variable
RXTRACE_CONCURRENCY, making the multithreaded/concurrent tracing a
global option that
needs to be set before running a Rexx program.
On 05.09.2021 14:12, Rony G. Flatscher wrote:
Almost a week ago Jean Louis Faucher registered feature request "794
Concurrency request", cf.
<https://sourceforge.net/p/oorexx/feature-requests/794/>
<https://sourceforge.net/p/oorexx/feature-requests/794/> together with a patch that
implements the
feature request. So far there have been no comments, hence "requesting for
comments (RFC)" here as
it may be the case that the RFE has been overlooked.
---
IMHO this RFE is incredible helpful for debugging multi-threaded Rexx
programs and for understanding
how ooRexx dispatches multithreaded code.
The way Jean Louis devised the implementation has practically no impact
on the interpreter (unless
one defines an environment variable "RXTRACE_CONCURRENCY=on" modelled
after the existing
"RXTRACE=ON" environment variable in which case helpful information
gets generated for prefixing
each trace output statement) makes it easy even for beginners (=
students) to get insight and
understand how ooRexx executes multithreaded programs. Some problems
rooted in multithreaded Rexx
code can be quickly located, understood and resolved with this feature.
Having tested this concurrency trace feature with the most challenging
JavaFX ooRexx programs I have
been really impressed with the results. Using the ooRexx program
"samples/tracer.rex" (included in
the patch) to render the massive concurrency trace output of some
JavaFX ooRexx programs to csv and
importing the concurrency trace into a spreadsheet (e.g. Excel) makes
it possible to analyze such
massive concurrency traces in every possible detail using the
spreadsheet features (e.g. filtering
for a specific ooRexx interpreter instance or specific threads, pivots
and the like). Therefore I
uploaded one such test to this RFE such that one can directly get at
the massive concurrency trace,
the csv file created by "tracer.rex" from it and an Excel spreadsheet
which was used to import the
generated csv file. (I wished this feature had been available when
devising some of the BSF4ooRexx
JavaFX samples, which would have saved me literally weeks of debugging!)
The patch implementing RFE 794 makes it really easy for ooRexx
programmers to understand and to
debug multithreaded ooRexx programs, saving them a *lot* of time trying
to understand what happens,
how concurrent statements get executed by the interpreter(s) and
locating coding errors!
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
