On 11.02.2023 18:06, Rick McGuire wrote:
'!' suppresses the issuing of commands. Generally used for non-destructiive test runs. Not really
used much but it takes up the '!' symbol character.
It seems that this is not in the documentation.
Also trying this as a trace option prefix causes an error:
say "hi! #1"
trace ?
"dir"
trace !
say "hi! #2"
"dir"
say "hi! #3"
::options trace r
yields as output:
G:\test\orx\trace>test.rex
4 *-* trace !
Error 24 running G:\test\orx\trace\test.rex line 4: Invalid TRACE request.
Error 24.1: TRACE request letter must be one of "ACEFILNOR"; found "!".
So there seems to be no '!' trace prefix implemented.
Where and how would '!' be used as a prefix letter with the behaviour that you describe? Maybe I
have missed the related documentation in rexxref.pdf.
---rony
On Sat, Feb 11, 2023 at 12:01 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
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
