The motivation for doing this involves analyzing tracelogs created using the information of
collected TraceObjects after a Rexx program got executed (or a section of it when tracing that).
Currently, it is not possible to identify exactly which executable got invoked by which invocation,
which would be needed to become able to analyze all the exact paths through the traced program
(part). This would become possible if the ‘callerStackFrame’ entry in TraceObjects would convey this
information by adding the invocation (activation) id with an "invocation” attribute to a stackframe.
So, it would not be a new concept per se as it is already available in the TraceObject ‘invocation’
entry (which then could be removed as its ‘stackframe’ entry would maintain that information).
---rony
On 12.02.2025 16:24, Rick McGuire wrote:
It would work, but it would be meaningless information to anybody other than someone familiar with
the internal code. You are introducing a totally new concept at the language level, which is not a
good idea.
Rick
On Wed, Feb 12, 2025 at 10:19 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
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
