Thank you Rick!
Just one thing: the idea would be to add a uint32_t field to the StackFrameClass such that when a
stackframe gets created in RexxActivation::createStackFrame() the RexxActivation::getIdntfr() could
be used there to supply that uint32_t value. This way no Rexx object would be used for that
information and no internal Rexx object would need to be exposed to user code. Would that be an
acceptable approach then?
---rony
On 12.02.2025 16:04, Rick McGuire wrote:
First of all, RexxActivaion is an RexxInternalObject. Those must NEVER be returned as an instance
by Rexx code. They are not fully functional objects that can be seen by Rexx code. There are also
issues with NativeActivation which is part of the same hierarchy with RexxActivation and also must
never be returned to Rexx code. If you really feed the need to do this, a better choice would be
to return the .Context object associated with the activation. Buy you need to make this adjustment
in every place an StackFrame object is created, because only RexxActivation ones will have a
backing context.
Rick
On Wed, Feb 12, 2025 at 9:51 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
Currently, the stackframes do not contain the information to which
RexxActivation
(“invocation”) they relate to. As a result, a caller stack frame cannot be
consulted to learn
which invocation created the called invocation. This is vital information
in case one creates
a tracelog and wishes to analyze exactly the flow of control post-mortem
using a tracelog.
Therefore, I would like to add that information to stackframes using the
name “invocation”
storing the value of RexxActivation::getIdntfr() and adjust
RexxActivation::createStackFrame()
and the StackFrameClass accordingly. Would there be something else that one
needs to pay
attention to?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
