Thanks Rick, I understand now why it was done this way.
I was wondering if it would be possible to provide a method on the
Package Class that would allow the trace setting to be modified, say
setTrace(trace_option). There is already a trace method that retrieves
the current setting, either N(ormal) or whatever was specified on the
::options trace directive so providing a corresponding "setter" would
seem reasonable. If that were available, one could use RXTRACE to begin
tracing an unmodified program, use the new setTrace option on one or
more of the packages that are loaded and be able to achieve what Terry
was attempting - see the flow through a program and the packages it
::requires without modifying them to add the ::options trace directive.
Any thoughts?
Gil
On 2/6/2022 1:33 PM, Rick McGuire wrote:
It's all a matter of scope. When you use the TRACE keyword
instruction, the scope of that instruction is that executable block of
code. If you invoked a method or a routine, this is an external call
and the current trace settings are not inherited. Nothing will get
traced in those cases because the trace setting in the new block of
code reverts to the default of TRACE Normal. When ::options trace was
introduced this gave a global setting for the package that defined
what the trace setting should be on entry to a new block of code. This
made life easier because you didn't have to update each code unit to
turn things on. However, it got somewhat confusing because the context
would jump around a lot. To address this, an additional trace line was
introduced to show what code block was being entered. This would
appear with trace all, results, or intermediates. The last enhancement
was to also do this for trace labels, which gave a nice flow of
control trace for the package.
Rick
On Sun, Feb 6, 2022 at 12:17 PM Gilbert Barmwater
<gi...@bellsouth.net> wrote:
Before I open a documentation bug on this, I have a question. Is
there
a reason the enhancement to TRACE L was only done for ::OPTIONS TRACE
and not for the TRACE keyword? I think it is obvious that having
this
available for both would be extremely beneficial. Thanks!
On 2/5/2022 9:22 AM, Gilbert Barmwater wrote:
> OK, that explains it, thanks. Should I open a documentation bug?
>
> On 2/5/2022 4:09 AM, Erich Steinböck wrote:
>> Hi Gil,
>> rexxref could be clearer here.
>>
>> When specified with the TRACE keyword instruction, trace option L
>> traces internal labels only.
>> When specified with the ::OPTIONS directive, as a recent
enhancement,
>> trace option L also traces routine and method calls.
>> So you need to specify ::OPTIONS TRACE L
>>
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
