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