Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

'!' suppresses the issuing of commands. Generally used for
non-destructiive test runs. Not really used much but it takes up the '!'
symbol character.

Rick

On Sat, Feb 11, 2023 at 12:01 PM Rony G. Flatscher 
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 
> 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 
>> 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.
>&g

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rony G. Flatscher]

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  
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  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
   

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

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 
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  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.
>&g

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

This is one of those features where I think I need to see the complete
documentation written first before any code is checked in. In particular, I
have some reservations on how this explicitly introduces activities and
reservation counts concepts to the language without them ever appearing
elsewhere in the language reference. I'm also not willing to accept the
format with which the additional information is added without some
additional discussion. Also the concept of giving the activities a unique
identifier. Since activities are pooled and reused, it needs to be defined
how that all plays out. This feature, while useful, needs a lot more
discussion before it is put in place.

Rick

On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher 
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  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 incredi

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rony G. Flatscher]

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  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 concurrenc

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rick McGuire]

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  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

Re: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Mike Cowlishaw]

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

[Oorexx-devel] Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Rony G. Flatscher]

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.
  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