On Sun, Feb 12, 2023 at 9:26 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
> 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. > It's something that is part of the Mainframe classic Rexx implementations. I was dropped when Mike wrote TRL1 and was never implemented on other platforms. Rick > > 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 >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
