Re: [Oorexx-devel] Working with TraceObjects, maybe adding OBJECT, removing OBJECTID, and adding STACKFRAME?

2024-04-08 Thread Rick McGuire
I’m thinking it might make sense to move the lock number to the stack frame
too.

Rick

On Mon, Apr 8, 2024 at 7:06 AM Rony G. Flatscher 
wrote:

> On 03.04.2024 09:26, Chip Davis wrote:
> > Seems more Rexx-ish, unless its specification might conflict with a
> future usage of the term in
> > that context.
> > -Chip-
> >
> > On 4/2/2024 4:19 PM, Rony wrote:
> >> Another question: offline I got the suggestion to change the NR entry
> in TraceObject to NUMBER.
> >> What do you think?
>
> The entry has been renamed from "NR" to "NUMBER".
>
> The TraceObject entries "OBJECT" and "SCOPE" have been removed as those
> values can be retrieved from
> the "STACKFRAME" entry.
>
> The documentation and the test case has been updated accordingly.
>
> ---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


Re: [Oorexx-devel] Working with TraceObjects, maybe adding OBJECT, removing OBJECTID, and adding STACKFRAME?

2024-04-08 Thread Rony G. Flatscher

On 03.04.2024 09:26, Chip Davis wrote:
Seems more Rexx-ish, unless its specification might conflict with a future usage of the term in 
that context.

-Chip-

On 4/2/2024 4:19 PM, Rony wrote:
Another question: offline I got the suggestion to change the NR entry in TraceObject to NUMBER. 
What do you think?


The entry has been renamed from "NR" to "NUMBER".

The TraceObject entries "OBJECT" and "SCOPE" have been removed as those values can be retrieved from 
the "STACKFRAME" entry.


The documentation and the test case has been updated accordingly.

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Working with TraceObjects, maybe adding OBJECT, removing OBJECTID, and adding STACKFRAME?

2024-04-03 Thread Chip Davis
Seems more Rexx-ish, unless its specification might conflict with a 
future usage of the term in that context.

-Chip-

On 4/2/2024 4:19 PM, Rony wrote:
Another question: offline I got the suggestion to change the NR 
entry in TraceObject to NUMBER. What do you think?



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Working with TraceObjects, maybe adding OBJECT, removing OBJECTID, and adding STACKFRAME?

2024-04-02 Thread Rony
As already mentoned one can get at OBJECT and SCOPE via the STACKFRAME entry. 
In the case that the TYPE is METHOD one can fetch OBJECT via the TARGET entry, 
in the case of a method one can in addition get SCOPE by sending the scope 
message to the method executable. Therefore the two current entries OBJECT and 
SCOPE in TraceObject can be removed. Would there be any objections?

Another question: offline I got the suggestion to change the NR entry in 
TraceObject to NUMBER. What do you think?

—-rony


Rony G. Flatscher (mobil/e)

> Am 29.03.2024 um 15:44 schrieb Rony G. Flatscher :
> 
> 
> While experimenting with TraceObjects for anaylsis it seems that the 
> following would be an improvement:
> 
> replace the OBJECTID entry with an OBJECT entry, storing the receiver/self 
> object: if needing the identity hash value (e.g. for externalization) one can 
> send it the identityHash message to get it; it adds the benefit of becoming 
> able to carry out further analysis on the object itself if necessary, e.g. 
> which class was used to create it, which instance methods does it have and 
> the like,
> 
> add an entry STACKFRAME (using activation->createStackFrame()): this makes 
> all of the StackFrame methods (cf. rexxref.pdf, section "5.4.20. StackFrame 
> Class") available for analization and documentation purposes like e.g. 
> arguments, executable, line, name (name used to call the executable), type (a 
> quite informative string for tracing).  Its target entry would be the 
> receiver/self object in case of a method, so possibly one could save the 
> OBJECT entry above, as it should be retrievable via the STACKFRAME entry.
> What do you think?
> 
> ---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Working with TraceObjects, maybe adding OBJECT, removing OBJECTID, and adding STACKFRAME?

2024-03-29 Thread Rony G. Flatscher
After making sure that TEST.testgroup and TEST_TestObject.testgroup work, I committed  12814 (code) 
and 12815 (doc) to see whether all tests keep on running on all platforms via Jenkins.


---rony


On 29.03.2024 15:43, Rony G. Flatscher wrote:


While experimenting with TraceObjects for anaylsis it seems that the following would be an 
improvement:


  * replace the OBJECTID entry with an OBJECT entry, storing the receiver/self 
object: if needing
the identity hash value (e.g. for externalization) one can send it the 
identityHash message to
get it; it adds the benefit of becoming able to carry out further analysis 
on the object
itself if necessary, e.g. which class was used to create it, which instance 
methods does it
have and the like,

  * add an entry STACKFRAME (using activation->createStackFrame()): this makes 
all of the
StackFrame methods (cf. rexxref.pdf, section "5.4.20. StackFrame Class") 
available for
analization and documentation purposes like e.g. arguments, executable, 
line, name (name used
to call the executable), type (a quite informative string for tracing).  
Its target entry
would be the receiver/self object in case of a method, so possibly one 
could save the OBJECT
entry above, as it should be retrievable via the STACKFRAME entry.

What do you think?

---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel