That's because the activation is no longer valid, so there's no valid
information available about the activation.
Rick
On Sat, Feb 15, 2025 at 7:21 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> It is RexxActivation::termination() that will issue a
> contextObject->detach() which nullifies the activation vairable such that
> RexxContext::checkValid() will raise the execution error.
>
> ---rony
>
>
> On 16.02.2025 01:16, Rony G. Flatscher wrote:
>
> Could get the invocation id into the stackframe and callerstackframe.
>
> As your .context idea is quite intriguing :) I then attempted to add it to
> the StackFrameClass using RexxActivation::getContextObject() which at first
> sight seemed to work as well. However when fetching it from a stackframe
> and trying to interact with it the runtime error "Execution error. Target
> RexxContext is no longer active." occurs.
>
> The RexxContext methods will issue a checkValid() before proceeding, which
> is defined as:
>
> void RexxContext::checkValid()
> {
> if (activation == OREF_NULL)
> {
> reportException(Error_Execution_context_not_active);
> }
> }
>
> It seems that the backing RexxActivation gets nullified such that placing
> it into a StackFrame is of no use ATM.
>
> ---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
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
