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 >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
