Just a quick question: what is the purpose of '!' in TRACE, have not seen
documentation about it.
In the case '!' is available then this could be used as an MT toggle?
---rony
On 09.02.2023 13:40, Rick McGuire wrote:
One other thing about the trigger character. The '?' and '!' triggers act as toggles, so issuing
"Trace ?" will trigger the interactive debug setting without changing the level of tracing being
done. This should also work with whatever is chosen to turn on the multithreaded information.
Another possibility would be to automatically add the additional information when more than one
thread is active. That way, most users who only work single threaded never see this, but people
who are working with multiple threads get the extra information without needing to think about
having to change the trace settings. I think I would prefer that rather than the M suffix, which
really works quite differently from how ? and ! are handled.
Rick
On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
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
