from:"Rony G. Flatscher"


Here is an example test program exercising "start" and "reply":

   t=.test~new
   t~m1
   t~m2
   t~~start(m2)~~start(m2)~~start(m2)
   say m=.message~new(t,"m2")
   m~copy~send
   m~copy~start
   m~copy~start
   m~copy~send
   say "1. ~start ..." t~start(m2)
   t~start(m1)
   call syssleep0.01 say .context~name"..." say "2. ~start ..." t~start(m1)
   t~start(m2)
   call syssleep0.01 ::class test
   ::method m1
  say .context~name"#1 (m1: before reply)" reply say .context~name"#2 (m1: after 
reply)" ::method m2
  say .context~name
  call syssleep random(0,10)/1000 say "--- m2: about to return ---"

Here is a snip from the tracelog in xml rendering (from tracetool..rex/traceutil.cls, WIP), 
representing the invocation of the method M1 from line # 17:


Among other things one can see augmented information meant to allow for analyzing a tracelog offline 
(after the traced Rexx program to analyze has run).


---rony



On 18.08.2024 18:21, Rony G. Flatscher wrote:

On 18.08.2024 15:18, Rony G. Flatscher wrote:

On 18.08.2024 14:44, Rick McGuire wrote:
One thing you've missed is that there are situations where there is no spawning activation. For 
example, from native code, I can attach a thread, create a message object and send it a START 
message. In that situation, there is no activation to create a stack frame from.


Went through the code and it seems that in this case "MessageClass::start()" gets invoked as well? 
If so, there will be an oldActivity and a newActivity as well, so I probably misunderstood your 
remark.


If there is no stack frame available, then in "Activity::setCallerStackFrameAsStringTable(...)" 
this will yield an empty StringTtable to be created as a result of invoking 
"RexxActivation::getStackFrameAsStringTable(StackFrameClass * stackFrame)". The stringtable gets a 
THREAD entry added before returning it (the existence of a THREAD entry in the TraceObject's 
callerStackFrame stringtable indicates that the caller with that thread ID spawned the activity; 
this is meant to indicate that no stackframe was available at the time of creation).


Also, the stack frame in question might be a native activation, so you need to make sure that 
these function as well.


Again not sure what the implications of a native activation are in this context.

"Activity::generateCallerStackFrame(bool skipFirst)" was modeled after 
"Activity::generateStackFrames(bool skipFirst)" assuming that it would therefore cover all 
scenarios related to dealing with stack frames.


Should the stack frame be NULL then as described above an empty StringTable gets created (meant to 
indicate that no stackframe was available at the time of creation) and a THREAD entry will be 
added to indicate the thread ID on which the spawn took place.


If this is not sufficient, then please let me know what needs to be done.

---rony

P.S.: The rexxref book needs to be updated to explain the cicrumstance when a THREAD entry gets 
added (and why it can be the case that the callerStackFrame StringTable otherwise may not contain 
stackframe related entries, e.g. when spawned from native code).


P.P.S.: As there was a left-over statement that serves no purpose anymore I removed it, hence here 
the updated diff:


Index:*interpreter/classes/MessageClass.cpp*
===
--- interpreter/classes/MessageClass.cpp(revision 12859)
+++ interpreter/classes/MessageClass.cpp(working copy)
@@ -537,6 +537,10 @@
  // spawn a new activity off of the old activity
  Activity *oldActivity = ActivityManager::currentActivity;
  Activity *newActivity = oldActivity->spawnReply();
+
+ // save current frame info in a StringTable as it has caused the creation 
of a new activity
+ Activity::setCallerStackFrameAsStringTable(oldActivity, newActivity, 
true); // create
stackframe from parent/caller
+
  // mark which activity we're running on, then dispatch the message
  // on the new activity (which is sitting waiting for work to perform)
  setField(startActivity, newActivity);
Index:*interpreter/concurrency/Activity.cpp*
===
--- interpreter/concurrency/Activity.cpp(revision 12859)
+++ interpreter/concurrency/Activity.cpp(working copy)
@@ -1159,31 +1159,53 @@
  }
  
  
+

  /**
- * Generates a StackFrame from the parent and returns it.
+ * Generate the caller's stack frame.
   *
- * @return parent's StackFrame or NULLOBJECT, if no parent exists
+ * @param skipFirst Determines if we should skip the first frame: + * 
false for reply in
RexxActivation::run(...), + * true for Message::start() and in

Re: [Oorexx-devel] RFC: suggestion a solution for getting the caller stackframe of a spawning activity


On 18.08.2024 15:18, Rony G. Flatscher wrote:

On 18.08.2024 14:44, Rick McGuire wrote:
One thing you've missed is that there are situations where there is no spawning activation. For 
example, from native code, I can attach a thread, create a message object and send it a START 
message. In that situation, there is no activation to create a stack frame from.


Went through the code and it seems that in this case "MessageClass::start()" gets invoked as well? 
If so, there will be an oldActivity and a newActivity as well, so I probably misunderstood your remark.


If there is no stack frame available, then in "Activity::setCallerStackFrameAsStringTable(...)" this 
will yield an empty StringTtable to be created as a result of invoking 
"RexxActivation::getStackFrameAsStringTable(StackFrameClass * stackFrame)". The stringtable gets a 
THREAD entry added before returning it (the existence of a THREAD entry in the TraceObject's 
callerStackFrame stringtable indicates that the caller with that thread ID spawned the activity; 
this is meant to indicate that no stackframe was available at the time of creation).


Also, the stack frame in question might be a native activation, so you need to make sure that 
these function as well.


Again not sure what the implications of a native activation are in this context.

"Activity::generateCallerStackFrame(bool skipFirst)" was modeled after 
"Activity::generateStackFrames(bool skipFirst)" assuming that it would therefore cover all scenarios 
related to dealing with stack frames.


Should the stack frame be NULL then as described above an empty StringTable gets created (meant to 
indicate that no stackframe was available at the time of creation) and a THREAD entry will be added 
to indicate the thread ID on which the spawn took place.


If this is not sufficient, then please let me know what needs to be done.

---rony

P.S.: The rexxref book needs to be updated to explain the cicrumstance when a THREAD entry gets 
added (and why it can be the case that the callerStackFrame StringTable otherwise may not contain 
stackframe related entries, e.g. when spawned from native code).


P.P.S.: As there was a left-over statement that serves no purpose anymore I removed it, hence here 
the updated diff:


   Index:*interpreter/classes/MessageClass.cpp*
   ===
   --- interpreter/classes/MessageClass.cpp (revision 12859)
   +++ interpreter/classes/MessageClass.cpp (working copy)
   @@ -537,6 +537,10 @@
 // spawn a new activity off of the old activity
 Activity *oldActivity = ActivityManager::currentActivity;
 Activity *newActivity = oldActivity->spawnReply();
   +
   + // save current frame info in a StringTable as it has caused the creation 
of a new activity +
   Activity::setCallerStackFrameAsStringTable(oldActivity, newActivity, true); 
// create stackframe
   from parent/caller
   +
 // mark which activity we're running on, then dispatch the message
 // on the new activity (which is sitting waiting for work to perform)
 setField(startActivity, newActivity);
   Index:*interpreter/concurrency/Activity.cpp*
   ===
   --- interpreter/concurrency/Activity.cpp (revision 12859)
   +++ interpreter/concurrency/Activity.cpp (working copy)
   @@ -1159,31 +1159,53 @@
 }
 
 
   +

 /**
   - * Generates a StackFrame from the parent and returns it.
   + * Generate the caller's stack frame.
  *
   - * @return parent's StackFrame or NULLOBJECT, if no parent exists
   + * @param skipFirst Determines if we should skip the first frame: + * false 
for reply in
   RexxActivation::run(...), + * true for Message::start() and in the general 
case. + * + * @return
   The stackframe of the caller which caused a spawned activity.
  */
   -StackFrameClass* Activity::generateParentStackFrame()
   +StackFrameClass* Activity::generateCallerStackFrame(bool skipFirst)
 {
   -// create lists for both the stack frames and the traceback lines
   -StackFrameClass *parentStackFrame = NULLOBJECT;
   -
 ActivationFrame *frame = activationFrames;
   + StackFrameClass *callerStackFrame = NULL;
 
   -if (frame != NULL)

   + if (frame && skipFirst)
 {
   -frame = frame->next;// get parent
   -if (frame != NULL)
   -{
   -parentStackFrame = frame->createStackFrame();
   -}
   + frame = frame->next;
 }
   -return parentStackFrame;
   + if (frame) + { + callerStackFrame = frame->createStackFrame(); + } + 
return callerStackFrame;
 }
 
 
 /**

   + * Generates and saves a StringTable to store stackFrame infos of 
oldActivity in newActivity +
   * (for TraceObject), used by MessageClass::start(). + * + */ +void

Re: [Oorexx-devel] RFC: suggestion a solution for getting the caller stackframe of a spawning activity


On 18.08.2024 14:44, Rick McGuire wrote:
One thing you've missed is that there are situations where there is no spawning activation. For 
example, from native code, I can attach a thread, create a message object and send it a START 
message. In that situation, there is no activation to create a stack frame from. Also, the stack 
frame in question might be a native activation, so you need to make sure that these function as well.


thank you very much!

Ad native code remark: changed "Activity::setCallerStackFrameAsStringTable(Activity *oldActivity, 
Activity *newActivity, bool skipFirst)" to cater for the case that there is no oldActivity. In that 
case the callerStackFrame StringTable will only contain the THREAD entry.


Ad stack frame being possibly a native activation: not sure what this implies and what should be 
done as a result in order that these function as well? Please advise.


---rony



On Sun, Aug 18, 2024 at 8:29 AM Rony G. Flatscher  
wrote:

With the introduction of TraceObject it becomes possible to create and 
store trace logs for
further analysis. In March, I started to create a little 
tracetool.rex/tracutil.cls to help
the Rexx programmers analyze their code. Testing and analyzing what can be 
inferred, it turned
out that in the case of a started message and a reply statement, no 
information about the
caller/invoker is currently available, making it very difficult, if not 
impossible, at times
to find out which instruction caused the creation of a new activity.

In the discussions on the developer list, it became clear that storing a 
StackFrame object
itself may cause crashes if the activity for which it was created has gone 
away if I
understood the problem correctly. Therefore, TraceObject would not store 
the StackFrame object
but rather create a StringTable receiving the relevant StackFrame 
information such that
accessing the StringTable later would not cause any problems.

This information gets only added to TraceObject if a 
TRACE_PREFIX_INVOCATION is active
(tracing the invocation of a routine or  method).
Looking around in the source code for ways to safely make the caller's 
stackframe information
available in the case that a new activity gets spawned as a result of a 
start message or a
reply keyword statement, the following idea would be proposed, hoping that 
it is safe and does
not impact the interpreter unduly:

 *

define a method Activity::generateCallerStackFrame(bool skipFirst)

 o

this returns the caller's StackFrame

 *

define for Activity a field "StringTable *spawnerStackFrameInfo"

 o

this is used to store a StringTable with the caller's StackFrame 
information

 *

define a method Activity::setCallerStackFrameAsStringTable(Activity 
*oldActivity, Activity
*newActivity, bool skipFirst)

 o

o    this method gets only invoked in "Method::start()" and in the 
reply section of
"RexxActivation::run(...)", which are the two cases where a new 
activity gets spawned
to execute the message in the case of "Method:start()" and the 
remaining instructions
in the case of a reply keyword instruction

 o

this method queries the caller's stackframe using
Activity::generateCallerStackFrame(skipFirst) and using
"RexxActivation::getStackFrameAsStringTable(StackFrameClass * 
stackFrame)" returning a
StringTable with the stackframe information and storing it with
"spawnerStackFrameInfo" field

 o

in addition, it will get an entry THREAD with the thread ID added, 
such that a) the
correct invocation can be located (the same location could be used 
over and over from
different threads; it is important to become able to identify which 
activity/thread
was used) and b) one can distinguish with the callerStackFrame in 
TraceObject whether
it got created

An experimental implementation seems to work, and so far, no adverse 
behavior has been observed.

Here the diff:

*Index: interpreter/classes/MessageClass.cpp*
===
--- interpreter/classes/MessageClass.cpp(revision 12859)
+++ interpreter/classes/MessageClass.cpp(working copy)
@@ -537,6 +537,10 @@
  // spawn a new activity off of the old activity
  Activity *oldActivity = ActivityManager::currentActivity;
  Activity *newActivity = oldActivity->spawnReply();
+ + // save current frame info in a StringTable as it has caused the 
creation of a new
activity + Activity::setCallerStackFrameAsStringTable(oldActivity,

[Oorexx-devel] RFC: suggestion a solution for getting the caller stackframe of a spawning activity

With the introduction of TraceObject it becomes possible to create and store trace logs for further 
analysis. In March, I started to create a little tracetool.rex/tracutil.cls to help the Rexx 
programmers analyze their code. Testing and analyzing what can be inferred, it turned out that in 
the case of a started message and a reply statement, no information about the caller/invoker is 
currently available, making it very difficult, if not impossible, at times to find out which 
instruction caused the creation of a new activity.


In the discussions on the developer list, it became clear that storing a StackFrame object itself 
may cause crashes if the activity for which it was created has gone away if I understood the problem 
correctly. Therefore, TraceObject would not store the StackFrame object but rather create a 
StringTable receiving the relevant StackFrame information such that accessing the StringTable later 
would not cause any problems.


This information gets only added to TraceObject if a TRACE_PREFIX_INVOCATION is active (tracing the 
invocation of a routine or  method).
Looking around in the source code for ways to safely make the caller's stackframe information 
available in the case that a new activity gets spawned as a result of a start message or a reply 
keyword statement, the following idea would be proposed, hoping that it is safe and does not impact 
the interpreter unduly:


 *

   define a method Activity::generateCallerStackFrame(bool skipFirst)

 o

   this returns the caller's StackFrame

 *

   define for Activity a field "StringTable *spawnerStackFrameInfo"

 o

   this is used to store a StringTable with the caller's StackFrame 
information

 *

   define a method Activity::setCallerStackFrameAsStringTable(Activity 
*oldActivity, Activity
   *newActivity, bool skipFirst)

 o

   o    this method gets only invoked in "Method::start()" and in the reply 
section of
   "RexxActivation::run(...)", which are the two cases where a new activity 
gets spawned to
   execute the message in the case of "Method:start()" and the remaining 
instructions in the
   case of a reply keyword instruction

 o

   this method queries the caller's stackframe using
   Activity::generateCallerStackFrame(skipFirst) and using
   "RexxActivation::getStackFrameAsStringTable(StackFrameClass * 
stackFrame)" returning a
   StringTable with the stackframe information and storing it with 
"spawnerStackFrameInfo" field

 o

   in addition, it will get an entry THREAD with the thread ID added, such 
that a) the correct
   invocation can be located (the same location could be used over and over 
from different
   threads; it is important to become able to identify which 
activity/thread was used) and b)
   one can distinguish with the callerStackFrame in TraceObject whether it 
got created

An experimental implementation seems to work, and so far, no adverse behavior 
has been observed.

Here the diff:

   *Index: interpreter/classes/MessageClass.cpp*
   ===
   --- interpreter/classes/MessageClass.cpp (revision 12859)
   +++ interpreter/classes/MessageClass.cpp (working copy)
   @@ -537,6 +537,10 @@
 // spawn a new activity off of the old activity
 Activity *oldActivity = ActivityManager::currentActivity;
 Activity *newActivity = oldActivity->spawnReply();
   + + // save current frame info in a StringTable as it has caused the 
creation of a new activity
   + Activity::setCallerStackFrameAsStringTable(oldActivity, newActivity, 
true); // create
   stackframe from parent/caller +
 // mark which activity we're running on, then dispatch the message
 // on the new activity (which is sitting waiting for work to perform)
 setField(startActivity, newActivity);
   *Index: interpreter/concurrency/Activity.cpp*
   ===
   --- interpreter/concurrency/Activity.cpp (revision 12859)
   +++ interpreter/concurrency/Activity.cpp (working copy)
   @@ -1159,31 +1159,54 @@
 }
 
 
   +

 /**
   - * Generates a StackFrame from the parent and returns it.
   + * Generate the caller's stack frame.
  *
   - * @return parent's StackFrame or NULLOBJECT, if no parent exists
   + * @param skipFirst Determines if we should skip the first frame: + * false 
for reply in
   RexxActivation::run(...), + * true for Message::start() and in the general 
case. + * + * @return
   The stackframe of the caller which caused a spawned activity.
  */
   -StackFrameClass* Activity::generateParentStackFrame()
   +StackFrameClass* Activity::generateCallerStackFrame(bool skipFirst)
 {
   -// create lists for both the stack frames and the traceback lines
   -StackFrameClass *parentStackFrame = NULLOBJECT;
   -
 ActivationFrame *frame = activationFrames;

Re: [Oorexx-devel] net-oo-rexx updated with latest oorexxdebugger, here is a howto! (Re: [rexxla-members] A real Rexx user's treasure grove: introducing "net-oo-rexx", ready for download and use withi

2024-08-16 Thread Rony G. Flatscher

There was a typo: to run the debugger on your own Rexx program you should use the proper name for 
the debugger, namely "rexxdebugger"! So this is the command:


   run rexxdebugger myOwnRexxProgram

---rony


On 16.08.2024 16:41, Rony Flatscher wrote:


An updated version with Dom's GUI-Rexx and ooRexx debugger was just uploaded to: 
.


It takes two (sic!) minutes to download, de-quarantine and run it. So if you ever wanted your Rexx 
or ooRexx program to be debugged with a GUI debugger, with break points, watch window of your 
variables at runtime and much more, this is the opportuntiy to check it out on Windows, Apple and 
Linux!


To do so you run "setup.cmd" (Windows) or "setup.sh" (Unix) which create "run.cmd"/"run" and 
"setenv.cmd"/"setenv".


E.g. you could use the following command to debug your own Rexx program 
'myOwnRexxProgram.rex' with:

run oorexxdebug myOwnRexxProgram.rex

You immediately get your Rexx program into the debugger, can set breakpoints, use watch windows 
and much more!


It cannot get easier for you or your Rexx friends!

---rony

P.S.: This package allows for using ooRexx, all ooRexx packages - includes Dom's great 
ooRexxDebugger for Windows and Unix systems - and NetRexx in parallel to your installed Rexx.



On 25.07.2024 13:21, Rony Flatscher wrote:


This is the follow-up to the "oorexx-packages" bundle that got introduced to the community about 
a month ago.


This time the latest ooRexx, oorexxshell, oorexx-debugger, and - as a bit of surprise and favor 
to the community - NetRexx is on board!


Needed steps: you download it, de-quarantine (see note # 1 below) the zip archive, unzip, and run 
"setup," and off you go!


It cannot get easier for interested programmers, so there is no excuse for anyone not to check it 
out as soon as possible!


Currently, the following 64-bit net-oo-rexx bundles are readily available for the most important 
operating systems (in alphabetic order):


 *
net-oo-rexx.macos.arm64-portable-release-20240724.zip
 *
net-oo-rexx.macos.x86_64-portable-release-20240724.zip
 *
net-oo-rexx.ubuntu2004.x86_64-portable-release-20240724.zip
 *
net-oo-rexx.windows.x86_64-portable-release-20240724.zip

Here the temporary download link: 


Here the content of the readme_net--oo-rexx.txt file:

"net-oo-rexx packages"
==

This is the readme file for "net-oo-rexx", a bundling ready to use that
gives immediate access to a number of Rexx packages, like:

- bsf4oorexx (ooRexx-Java bridge for all operating systems) - dbus4oorexx 
(ooRexx-DBus bridge
for Linux) - executor packages (see oorexxshell) - log4rexx (logging for 
ooRexx) - netrexx
(Java in the clothes of Rexx) - nrws (NetRexx Workspace, a NetRexx shell) - 
oorexx (open
object Rexx) - oorexxshell (a rexxtry.rex kind of shell for ooRexx) - regex 
(powerful regular
expression implementation in ooRexx) - rexxdebugger (an ooRexx debugger, 
exploits the Java
bindings on Unix)


Directions in a nutshell


- download the latest "NetRexx, ooRexx with packages with oorexxshell"
   (net-oo-rexx-packages) zip archive from
   https://wi.wu.ac.at/rgf/rexx/tmp/net-oo-rexx-packages/

- de-quarantine the zip archive (see NOTE # 1 below)

- unzip the archive

- change into the unzipped directory and enter in the system shell

   Windows  UnixComment
   ---  +--
   setup.cmd./setup.sh  | creates two scripts

   This will create the two scripts:

   run.cmd  run | allows to run 
net-oo-rexx programs
   setenv.cmd   setenv  | allows to set 
environment to net-oo-rexx in Terminal

   


   ---> use the generated 'run.cmd/run' script

   Windows  Unix  Comment
   ---    +--
   run oorexxshell  ./run oorexxshell | runs oorexxshell (a 
script)

   run rexx testoorexx.rex  ./run rexx testoorexx.rex | use ooRexx to run 
testoorexx.rex
   run rexx which_rexx.rex| use ooRexx to run 
which_rexx.rex

   run nrc -exec which_rexx.rex   | use NetRexx to run 
which_rexx.rex


   

   ---> use the generated 'setenv.cmd/setenv' script

   Windows  UnixComment
   ---  +--
setenv.cmd  source ./setenv

[Oorexx-devel] net-oo-rexx updated with latest oorexxdebugger, here is a howto! (Re: [rexxla-members] A real Rexx user's treasure grove: introducing "net-oo-rexx", ready for download and use within on

2024-08-16 Thread Rony G. Flatscher

An updated version with Dom's GUI-Rexx and ooRexx debugger was just uploaded to: 
.


It takes two (sic!) minutes to download, de-quarantine and run it. So if you ever wanted your Rexx 
or ooRexx program to be debugged with a GUI debugger, with break points, watch window of your 
variables at runtime and much more, this is the opportuntiy to check it out on Windows, Apple and Linux!


To do so you run "setup.cmd" (Windows) or "setup.sh" (Unix) which create "run.cmd"/"run" and 
"setenv.cmd"/"setenv".


E.g. you could use the following command to debug your own Rexx program 
'myOwnRexxProgram.rex' with:

   run oorexxdebug myOwnRexxProgram.rex

You immediately get your Rexx program into the debugger, can set breakpoints, use watch windows and 
much more!


It cannot get easier for you or your Rexx friends!

---rony

P.S.: This package allows for using ooRexx, all ooRexx packages - includes Dom's great 
ooRexxDebugger for Windows and Unix systems - and NetRexx in parallel to your installed Rexx.



On 25.07.2024 13:21, Rony Flatscher wrote:


This is the follow-up to the "oorexx-packages" bundle that got introduced to the community about a 
month ago.


This time the latest ooRexx, oorexxshell, oorexx-debugger, and - as a bit of surprise and favor to 
the community - NetRexx is on board!


Needed steps: you download it, de-quarantine (see note # 1 below) the zip archive, unzip, and run 
"setup," and off you go!


It cannot get easier for interested programmers, so there is no excuse for anyone not to check it 
out as soon as possible!


Currently, the following 64-bit net-oo-rexx bundles are readily available for the most important 
operating systems (in alphabetic order):


 *
net-oo-rexx.macos.arm64-portable-release-20240724.zip
 *
net-oo-rexx.macos.x86_64-portable-release-20240724.zip
 *
net-oo-rexx.ubuntu2004.x86_64-portable-release-20240724.zip
 *
net-oo-rexx.windows.x86_64-portable-release-20240724.zip

Here the temporary download link: 


Here the content of the readme_net--oo-rexx.txt file:

"net-oo-rexx packages"
==

This is the readme file for "net-oo-rexx", a bundling ready to use that
gives immediate access to a number of Rexx packages, like:

- bsf4oorexx (ooRexx-Java bridge for all operating systems) - dbus4oorexx 
(ooRexx-DBus bridge
for Linux) - executor packages (see oorexxshell) - log4rexx (logging for 
ooRexx) - netrexx
(Java in the clothes of Rexx) - nrws (NetRexx Workspace, a NetRexx shell) - 
oorexx (open
object Rexx) - oorexxshell (a rexxtry.rex kind of shell for ooRexx) - regex 
(powerful regular
expression implementation in ooRexx) - rexxdebugger (an ooRexx debugger, 
exploits the Java
bindings on Unix)


Directions in a nutshell


- download the latest "NetRexx, ooRexx with packages with oorexxshell"
   (net-oo-rexx-packages) zip archive from
   https://wi.wu.ac.at/rgf/rexx/tmp/net-oo-rexx-packages/

- de-quarantine the zip archive (see NOTE # 1 below)

- unzip the archive

- change into the unzipped directory and enter in the system shell

   Windows  UnixComment
   ---  +--
   setup.cmd./setup.sh  | creates two scripts

   This will create the two scripts:

   run.cmd  run | allows to run 
net-oo-rexx programs
   setenv.cmd   setenv  | allows to set 
environment to net-oo-rexx in Terminal

   


   ---> use the generated 'run.cmd/run' script

   Windows  Unix  Comment
   ---    +--
   run oorexxshell  ./run oorexxshell | runs oorexxshell (a 
script)

   run rexx testoorexx.rex  ./run rexx testoorexx.rex | use ooRexx to run 
testoorexx.rex
   run rexx which_rexx.rex| use ooRexx to run 
which_rexx.rex

   run nrc -exec which_rexx.rex   | use NetRexx to run 
which_rexx.rex


   

   ---> use the generated 'setenv.cmd/setenv' script

   Windows  UnixComment
   ---  +--
setenv.cmd  source ./setenv | sets the environment 
in the Terminal to net-oo-rexx

the following commands will work on Windows as well as on Unix:

oorexxshell | runs oorexxshell

rexx testoorexx.rex

[Oorexx-devel] RFC for sample for .Object's "5.1.4.12. instanceMethods"

2024-08-16 Thread Rony G. Flatscher

The sample going with "5.1.4.12. instanceMethods" is meant to be updated as follows in the context 
of applying Josep Maria's respective patch:


Any comments?

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

Re: [Oorexx-devel] Looking further into instanceMethods for class and non-class objects, not all class methods reported?

2024-08-15 Thread Rony G. Flatscher


On 15.08.2024 15:38, Rick McGuire wrote:


On Thu, Aug 15, 2024 at 8:05 AM Rony G. Flatscher  
wrote:



... cut ...

I'm not seeing anything that appears to be missing from .String~instancemethods, so I'm not seeing 
any problem here.


Oops, you are right, there was a coding error (corrected code below)!


There is certainly one error in your assumptions. You are assuming that any class object will 
automatically have all of the methods of .Class, but other class objects do not directly inherit 
from  .Class, but are instances created by .Class (or rather the metaclass, which is .Class in 
most cases).


Yes, indeed, metcalasses, would need to be taken into account for a general test (and if so, their 
superclasses up to and including .class would need to be processed)!



That new class object does not automatically get all of the methods of the metaclass, for example, 
the NEW methods.


This is an important information, as NEW is treated then as a special case at class object 
construction time. Would that also mean that it is not possible to invoke "self~new:super"?



In that state, it is barely usable. The full scope of the instance methods is then built up by 
adding in the inheritance hierarchy. So, if you are manually trying to construct things yourself, 
you would do this by adding the instance methods from each superclass, ending with adding in 
.Object~instancemethods(.Class).


Thank you for all of your explanations!

---rony


P.S.: Just for the record the corrected code:

   call testInstanceMethods.string say "="~copies(79)
   say call testInstanceMethods"hello world"

   ::routine testInstanceMethods
  use arg obj
  bIsClassObject=obj~isA(.class)
  if bIsClassObjectthen clz=obj
else clz=obj~class

  say "instanceMethods of" pp(obj)":" superclasses=clz~superClasses-- get array of superclasses 
say "=" say "superclasses:" ppDoOver(superclasses)~makeString(,', ')
  say "=" say "clz~metclass:" clz~metaclass
  say sum=0 arrMeths=.array~new
  classes2ask= .array~of(clz)~~appendAll(superclasses)
  if bIsClassObjectthen classes2ask~append(.class)-- we have also the 
methods of .class available do oover classes2ask
 tmpObj=bIsClassObject~?(o,obj)
 
arrOMeths=ppDoOver(.array~new~appendall(tmpObj~instanceMethods(o)~allIndexes~sort))
 arrMeths~appendAll(arrOMeths)
 sum+=arrOMeths~items
 say "---> " pp(tmpObj)"~instanceMethods("pp(o)"), arrOMeths~items:" 
pp(arrOMeths~items)", methods:" if arrOMeths~items>0 then say " " arrOMeths~makeString(,', ')
 say end say say "arrMeths~items:" arrMeths~items"sum:" sum
  say "-"~copies(79)
  say tmpObj=bIsClassObject~?(clz,obj)
  say "allMeths, result of:" pp(tmpObj)"~instanceMethods:" 
allMeths=ppDoOver(tmpObj~instanceMethods~allIndexes~sort)
  say "allMeths~items:" allMeths~items
  say "===> allMeths:"allMeths~makeString(,', ')
  say "allMeths~items:" allMeths~items
  say

   ::routine pp
  return "["arg(1)"]" ::routine ppDoOver
  use arg o
  arrOut=.array~new
  do valover o
 arrOut~append(pp(val))
  end return arrOut
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Looking further into instanceMethods for class and non-class objects, not all class methods reported?

2024-08-15 Thread Rony G. Flatscher

It seems that "instanceMethods", without a class_object argument, does not return all the class 
methods that are available to the receiving class object (whereas it returns correctly all the 
instance methods in the case of instances).


The following code will invoke the routine "testInstanceMethods" with the class object .String, and 
then once more with a string instance with the value "hello world" in this case.


The routine "testInstanceMethods" checks whether the argument is a class object and if so uses it as 
the starting class to send the instanceMethods message, and if not gets the class object of an 
instance of a class. If a class object, then also the instance methods of .Class get queried in 
addition as these methods will be available as instance methods to any class object.


Next the superclasses of that clz get queried and as a result a loop over the classes .String, 
.Object, and .Comparable will be executed to get first the instance methods for each class, which 
get counted and collected, followed by querying all instanceMethods without a class_object argument.


Here the respective code:

   call testInstanceMethods.string say "="~copies(79)
   say call testInstanceMethods"hello world"

   ::routine testInstanceMethods
  use arg obj
  bIsClassObject=obj~isA(.class)
  if bIsClassObjectthen clz=obj
else clz=obj~class

  say "instanceMethods of" pp(obj)":" superclasses=clz~superClasses-- get array of superclasses 
say "=" say "superclasses:" ppDoOver(superclasses)~makeString(,', ')
  say "=" say sum=0 arrMeths=.array~new
  classes2ask= .array~of(clz)~~appendAll(superclasses)
  if bIsClassObjectthen classes2ask~append(.class)-- we have also the 
methods of .class available -- do o over
   .array~of(clz)~~appendAll(superclasses) do oover classes2ask
 tmpObj=bIsClassObject~?(o,obj)
 
arrOMeths=ppDoOver(.array~new~appendall(tmpObj~instanceMethods(o)~allIndexes~sort))
 arrMeths~appendAll(arrOMeths)
 sum+=arrOMeths~items
 say "---> " pp(tmpObj)"~instanceMethods("pp(o)"), arrOMeths~items:" 
pp(arrOMeths~items)", methods:" if arrOMeths~items>0 then say " " arrOMeths~makeString(,', ')
 say end say say "arrMeths~items:" arrMeths~items"sum:" sum
  say "-"~copies(79)
  say tmpObj=bIsClassObject~?(clz,obj)
  say "allMeths, result of:" pp(tmpObj)"~instanceMethods:" 
allMeths=ppDoOver((bIsClassObject~?(o,obj))~instanceMethods~allIndexes~sort)
  say "allMeths~items:" allMeths~items
  say "===> allMeths:"allMeths~makeString(,', ')
  say "allMeths~items:" allMeths~items
  say

   ::routine pp
  return "["arg(1)"]" ::routine ppDoOver
  use arg o
  arrOut=.array~new
  do valover o
 arrOut~append(pp(val))
  end return arrOut

Running this program will yield the following output:

   instanceMethods of [The String class]:
   =
   superclasses: [The Object class], [The Comparable class]
   =

   --->  [The String class]~instanceMethods([The String class]), 
arrOMeths~items: [17], methods:
  [ALNUM], [ALPHA], [BLANK], [CNTRL], [CR], [DIGIT], [GRAPH], [LOWER], 
[NEW], [NL], [NULL], [PRINT], [PUNCT], [SPACE], [TAB], [UPPER], [XDIGIT]

   --->  [The Object class]~instanceMethods([The Object class]), 
arrOMeths~items: [33], methods:
  [], [ ], [<>], [=], [==], [><], [CLASS], [COPY], [DEFAULTNAME], 
[HASHCODE], [HASMETHOD], [IDENTITYHASH], [INIT], [INSTANCEMETHOD], [INSTANCEMETHODS], 
[ISA], [ISINSTANCEOF], [ISNIL], [NEW], [OBJECTNAME], [OBJECTNAME=], [REQUEST], [RUN], 
[SEND], [SENDWITH], [SETMETHOD], [START], [STARTWITH], [STRING], [UNSETMETHOD], [\=], 
[\==], [||]

   --->  [The Comparable class]~instanceMethods([The Comparable class]), 
arrOMeths~items: [0], methods:

   --->  [The Class class]~instanceMethods([The Class class]), arrOMeths~items: 
[34], methods:
  [<>], [=], [==], [><], [ACTIVATE], [ANNOTATION], [ANNOTATIONS], 
[BASECLASS], [COPY], [DEFAULTNAME], [DEFINE], [DEFINEMETHODS], [DELETE], [ENHANCED], 
[HASHCODE], [ID], [INHERIT], [ISABSTRACT], [ISMETACLASS], [ISSUBCLASSOF], [METACLASS], 
[METHOD], [METHODS], [MIXINCLASS], [NEW], [PACKAGE], [QUERYMIXINCLASS], [SUBCLASS], 
[SUBCLASSES], [SUPERCLASS], [SUPERCLASSES], [UNINHERIT], [\=], [\==]


   *arrMeths~items: **84**sum: 84*
   
---

   allMeths, result of: [The String class]~instanceMethods:
   *allMeths~items: **66*
   ===> allMeths:[], [ ], [<>], [<>], [=], [=], [==], [==], [><], [><], 
[ACTIVATE], [ANNOTATION], [ANNOTATIONS], [BASECLASS], [CLASS], [COPY], [COPY], [DEFAULTNAME], 
[DEFAULTNAME], [DEFINE], [DEFINEMETHODS], [DELETE], [ENHANCED], [HASHCODE], [HASHCODE], [HASMETHOD], [ID], 
[IDENTITYHASH], [INHERIT], [INIT], [INSTANCEMETHOD], [INSTANCEMETHODS], [ISA], [ISABSTRACT], 
[ISINSTANCEOF], [ISMETACLASS], [ISNIL], [ISSUBCLASSOF], [METACLASS], [M

Re: [Oorexx-devel] Question ad instanceMethods if fetching class methods

2024-08-14 Thread Rony G Flatscher

Thank you!—-ronyRony G. Flatscher (mobil/e)Am 14.08.2024 um 18:53 schrieb Rick McGuire :On Wed, Aug 14, 2024 at 12:45 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:

  


  
  
The documentation of rexxref.pdf chapter "5.1.4.12.
  instanceMethods" has a documentation bug that Josep Maria referred
  to (# 317, https://sourceforge.net/p/oorexx/documentation/317/)
  and supplied a patch for it.
Looking into the patch and then into the example that should be
  working correctly (ooRexx 5.1.0 in this case), it seems that the
  method "instanceMethods" without an argument does not return the
  complete list of class methods for the String class.
Here using instanceMethods on the .class objects involved for the
  .string class (.object, .class, .string):

  
say .context~name "(".context~executable~class~id")"
say

sum=0
allMethods1=.bag~new
do clz over .Class, .Object, .String
   clzMethods=ppIndexes(clz~instanceMethods(clz))
   items=clzMethods~items
   sum+=items
   say clz~id":" items "class methods"
   say clzMethods~makeString(,', ')
   allMethods1=allMethods1~union(clzMethods)
   say "---"
   say
end
say "total of:" sum
say "allMethods1~items:" allMethods1~items
say "allMethods1:" allMethods1~allIndexes~sort~makeString(, ', ')
say
say "-"~copies(79)

clzMethods=ppIndexes(.string~instanceMethods)
allMethods2=.bag~new~union(clzMethods)
say .string~id":" clzMethods~items
say "allMethods2~items:" allMethods2~items
say clzMethods~makeString(,', ')
say
say "-"~copies(79)
say
say "allMethods2:" allMethods2~allIndexes~sort~makeString(, ', ')
say
say "allMethods1~difference(allMethods2):" allMethods1~difference(allMethods2)~makearray~sort~makeString(, ',')
say "allMethods2~difference(allMethods1):" allMethods2~difference(allMethods1)~makearray~sort~makeString(, ',')


  ::routine pp
  return "["arg(1)"]"

::routine ppIndexes
  use arg o
  arrOut=.array~new
  do val over o~allindexes~sort
 arrOut~append(pp(val))
  end
  return arrOut

  
  

Running this program shows at the end the following output:

  allMethods1~difference(allMethods2): [NEW]
allMethods2~difference(allMethods1): 


Indeed there is a NEW method in .Object, one in .Class, and one
  in .String, if querying .Object~instanceMethods(.Object),
  .Class~instanceMethods(.Class), and
  .String~instanceMethods(.String), totalling three NEW methods
  (they are included in "allMethods1").
However .String~instanceMethods only returns two NEW methods (see
  "allMethods2") instead of three, hence the discrepancy.
Why would that be?The Class NEW method is the method used for new instances of Class objects. The hierarchy is Class~New, Object~New. The String~New method is used for creating new instances of String objects, and like class, the hierarchy is two levels deep (String, Object). You would see the same hierarchy for all classes that are subclasses of Object. The Claas New method would not make any sense in that hierarchy, since Class objects are not getting constructed in that context. Rick 
---rony


  

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

___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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] Question ad instanceMethods if fetching class methods

2024-08-14 Thread Rony G. Flatscher

The documentation of rexxref.pdf chapter "5.1.4.12. instanceMethods" has a documentation bug that 
Josep Maria referred to (# 317, https://sourceforge.net/p/oorexx/documentation/317/) and supplied a 
patch for it.


Looking into the patch and then into the example that should be working correctly (ooRexx 5.1.0 in 
this case), it seems that the method "instanceMethods" without an argument does not return the 
complete list of class methods for the String class.


Here using instanceMethods on the .class objects involved for the .string class (.object, .class, 
.string):


   say .context~name"(".context~executable~class~id")" say sum=0 
allMethods1=.bag~new
   do clzover .Class,.Object,.String 
clzMethods=ppIndexes(clz~instanceMethods(clz))
   items=clzMethods~items
   sum+=items
   say clz~id":" items"class methods" say clzMethods~makeString(,', ')
   allMethods1=allMethods1~union(clzMethods)
   say "---" say end say "total of:" sum
   say "allMethods1~items:" allMethods1~items
   say "allMethods1:" allMethods1~allIndexes~sort~makeString(,', ')
   say say "-"~copies(79)

   clzMethods=ppIndexes(.string~instanceMethods)
   allMethods2=.bag~new~union(clzMethods)
   say .string~id":" clzMethods~items
   say "allMethods2~items:" allMethods2~items
   say clzMethods~makeString(,', ')
   say say "-"~copies(79)
   say say "allMethods2:" allMethods2~allIndexes~sort~makeString(,', ')
   say say "allMethods1~difference(allMethods2):" 
allMethods1~difference(allMethods2)~makearray~sort~makeString(,',')
   say "allMethods2~difference(allMethods1):" 
allMethods2~difference(allMethods1)~makearray~sort~makeString(,',')

   ::routine pp
  return "["arg(1)"]" ::routine ppIndexes
  use arg o
  arrOut=.array~new
  do valover o~allindexes~sort
 arrOut~append(pp(val))
  end return arrOut

Running this program shows at the end the following output:

   allMethods1~difference(allMethods2): [NEW]
   allMethods2~difference(allMethods1):

Indeed there is a NEW method in .Object, one in .Class, and one in .String, if querying 
.Object~instanceMethods(.Object), .Class~instanceMethods(.Class), and 
.String~instanceMethods(.String), totalling three NEW methods (they are included in "allMethods1").


However .String~instanceMethods only returns two NEW methods (see "allMethods2") instead of three, 
hence the discrepancy.


Why would that be?

---rony

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

[Oorexx-devel] Ad documentation patches, any documentation committer volunteers?

2024-08-03 Thread Rony G. Flatscher

Josep Maria has filed a few documentation bugs in the past months. Yesterday Josep Maria even took 
the time to create patches attached to the following bugs:


 * https://sourceforge.net/p/oorexx/documentation/321/
 * https://sourceforge.net/p/oorexx/documentation/308/
 * https://sourceforge.net/p/oorexx/documentation/318/
 * https://sourceforge.net/p/oorexx/documentation/316/

In the interest of distributing the "committing load" :) on as many shoulders as possible, who would 
volunteer to check and commit these patches?


Any correction to the documentation should be reflected ASAP in the 
downloadable PDF books.

---rony

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

[Oorexx-devel] Links (Re: [rexxla-members] Food for thoughts ...

2024-08-03 Thread Rony G. Flatscher


Forgot the links:

   Elif Dager's "JDOR: Java 2D Drawing for ooRexx" entry:
   

   Cookbook "JDOR: Java 2D Drawing for ooRexx" (PDF-seminar paper) with full 
documentation
   including screenshots:
   


   zip-archive containing all "JDOR: Java 2D Drawing for ooRexx" examples, 
ready to run on your
   computer:
   


The "net-oo-rexx" package can be unzipped and used in parallel to any installed software, including 
parallel to an installed ooRexx (this way you could check out the latest ooRexx version without 
uninstalling your installed Rexx). One could copy all its files to an USB-stick and carry around 
computers and after running "setup" will allow for running the above ooRexx scripts, here the link:


   net-oo-rexx (cf. readme.txt): 


If you have any questions (including "dumb" questions), please do not hesitate 
and ask them!

---rony


On 02.08.2024 17:39, Rony Flatscher wrote:
Since it is possible for everyone on this list to install or use the "net-oo-rexx" packages to run 
the latest versions of ooRexx, NetRexx, BSF4ooRexx850, et.al. it might be interesting for peeking 
around what some of my students have created in the past twenty+ (!) years. Some of my student's 
work gets published on , if I think that they write about 
or demonstrate something helpful. As you will see there are quite a few works related to Rexx, 
ooRexx, BSF4ooRexx and the like.


The productivity gains for professionals in this list can be quite impressive, *if* these 
professionals would only be aware of the potential, that is easy to realize if they know Rexx 
already, hence pointing out student's work. Also, professionals who are aware that that (many 
times impressive) work was created by business adminstration students should infer that then it 
would be possible for themselves to take advantage of that infrastructure, especially if it gets 
demonstrated and explained in form of short nutshell examples.


One example is the seminar paper entitled "BSF4ooRexx850 JDOR: Java 2D Drawing for ooRexx" by Elif 
Deger which explores and demonstrates in form of nutshell examples how easy it has become to 
create 2D graphics with Rexx commands. Anyone who reads this e-mail would be immediately available 
to create such 2D graphics. The examples in the seminar paper (a PDF file) can be downloaded from 
that very website, from the entry to "Deger, Elif".


As the "net-oo-rexx" packages contains JDOR, anyone who downloads net-oo-rexx can run these 
samples right on their own PC, no matter whether it runs Windows, Apple or Linux. Just try it out!


As the weekend is in front of many, maybe you take some time and look around?

---rony

P.S.: If you look through those works you will find out that there is a current work where a 
student has created the core of 3D commands exploiting JavaFX, such that JDOR commands can be 
processed by JDORFX as well and add the ability to create and manipulate 3D graphics (the 
zip-archive contains the jar-file and the samples, including one where 3D objects get animated). 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad Activity::activationFrames and asynchronous message

2024-08-02 Thread Rony G. Flatscher

On 14.07.2024 11:31, Rick McGuire wrote:

On Sun, Jul 14, 2024 at 5:28 AM Rony G. Flatscher
wrote:

On 13.07.2024 17:31, Rick McGuire wrote:

That makes absolutely no sense. Once the new activity is started, there is
no guarantee that
the stackframe or even the activity from which it was spawned even exists
any more. The
original activity has continued on doing its own stuff.

A question here: I thought that if storing Rexx objects in a Rexx
collection they are pinned
and do not get garbage collected.

The stack frame object would not be garbage collected, but the stack frame itself and the things
that it referred to would no longer exist or be valid.

As you have seen, I tried to remove that dependency to the stack frame itself by creating a
StringTable that receives the stack frame-related entries in RexxActivation.hpp's "static
StringTable *getStackFrameAsStringTable(StackFrameClass *)" and which gets used to store the stack
frame information.

If analyzing the trace objects, the asynchronously dispatched messages will cause invocation entries
with no caller stack frame currently. So I was wondering, now that a StringTable representation is
possible, whether it would be o.k. to do something like the following without jeopardizing the
running system: define some StringTable field ("spawner") which is set to NULLOBJECT, but if a
message gets spawned the static method getStackFrameAsStringTable() would get invoked with the
spawner's stack frame and the resulting StringTable would be used to assign this new "spawner"
field, such that no reference to the stack frame would be needed. This way, when creating a
TraceObject and the caller's stack frame is null, one could use the activity's spawner field instead
such that the caller can be located/identified from it.

What do you think? Would that be a safe solution for tracing asynchronous
invocations?

---rony

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

[Oorexx-devel] Food for thoughts ...

2024-08-02 Thread Rony G. Flatscher

Since it is possible for everyone on this list to install or use the "net-oo-rexx" packages to run 
the latest versions of ooRexx, NetRexx, BSF4ooRexx850, et.al. it might be interesting for peeking 
around what some of my students have created in the past twenty+ (!) years. Some of my student's 
work gets published on , if I think that they write about 
or demonstrate something helpful. As you will see there are quite a few works related to Rexx, 
ooRexx, BSF4ooRexx and the like.


The productivity gains for professionals in this list can be quite impressive, *if* these 
professionals would only be aware of the potential, that is easy to realize if they know Rexx 
already, hence pointing out student's work. Also, professionals who are aware that that (many times 
impressive) work was created by business adminstration students should infer that then it would be 
possible for themselves to take advantage of that infrastructure, especially if it gets demonstrated 
and explained in form of short nutshell examples.


One example is the seminar paper entitled "BSF4ooRexx850 JDOR: Java 2D Drawing for ooRexx" by Elif 
Deger which explores and demonstrates in form of nutshell examples how easy it has become to create 
2D graphics with Rexx commands. Anyone who reads this e-mail would be immediately available to 
create such 2D graphics. The examples in the seminar paper (a PDF file) can be downloaded from that 
very website, from the entry to "Deger, Elif".


As the "net-oo-rexx" packages contains JDOR, anyone who downloads net-oo-rexx can run these samples 
right on their own PC, no matter whether it runs Windows, Apple or Linux. Just try it out!


As the weekend is in front of many, maybe you take some time and look around?

---rony

P.S.: If you look through those works you will find out that there is a current work where a student 
has created the core of 3D commands exploiting JavaFX, such that JDOR commands can be processed by 
JDORFX as well and add the ability to create and manipulate 3D graphics (the zip-archive contains 
the jar-file and the samples, including one where 3D objects get animated).






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

[Oorexx-devel] A real Rexx user's treasure grove: introducing "net-oo-rexx", ready for download and use within one minute!

2024-07-25 Thread Rony G. Flatscher

This is the follow-up to the "oorexx-packages" bundle that got introduced to the community about a 
month ago.


This time the latest ooRexx, oorexxshell, oorexx-debugger, and - as a bit of surprise and favor to 
the community - NetRexx is on board!


Needed steps: you download it, de-quarantine (see note # 1 below) the zip archive, unzip, and run 
"setup," and off you go!


It cannot get easier for interested programmers, so there is no excuse for anyone not to check it 
out as soon as possible!


Currently, the following 64-bit net-oo-rexx bundles are readily available for the most important 
operating systems (in alphabetic order):


 *

   net-oo-rexx.macos.arm64-portable-release-20240724.zip

 *

   net-oo-rexx.macos.x86_64-portable-release-20240724.zip

 *

   net-oo-rexx.ubuntu2004.x86_64-portable-release-20240724.zip

 *

   net-oo-rexx.windows.x86_64-portable-release-20240724.zip

Here the temporary download link: 


Here the content of the readme_net--oo-rexx.txt file:

   "net-oo-rexx packages"
   ==

   This is the readme file for "net-oo-rexx", a bundling ready to use that
   gives immediate access to a number of Rexx packages, like:

   - bsf4oorexx (ooRexx-Java bridge for all operating systems) - dbus4oorexx 
(ooRexx-DBus bridge
   for Linux) - executor packages (see oorexxshell) - log4rexx (logging for 
ooRexx) - netrexx (Java
   in the clothes of Rexx) - nrws (NetRexx Workspace, a NetRexx shell) - oorexx 
(open object Rexx)
   - oorexxshell (a rexxtry.rex kind of shell for ooRexx) - regex (powerful 
regular expression
   implementation in ooRexx) - rexxdebugger (an ooRexx debugger, exploits the 
Java bindings on Unix)

   
   Directions in a nutshell
   

   - download the latest "NetRexx, ooRexx with packages with oorexxshell"
  (net-oo-rexx-packages) zip archive from
  https://wi.wu.ac.at/rgf/rexx/tmp/net-oo-rexx-packages/

   - de-quarantine the zip archive (see NOTE # 1 below)

   - unzip the archive

   - change into the unzipped directory and enter in the system shell

  Windows  UnixComment
  ---  +--
  setup.cmd./setup.sh  | creates two scripts

  This will create the two scripts:

  run.cmd  run | allows to run 
net-oo-rexx programs
  setenv.cmd   setenv  | allows to set 
environment to net-oo-rexx in Terminal

  


  ---> use the generated 'run.cmd/run' script

  Windows  Unix  Comment
  ---    +--
  run oorexxshell  ./run oorexxshell | runs oorexxshell (a 
script)

  run rexx testoorexx.rex  ./run rexx testoorexx.rex | use ooRexx to run 
testoorexx.rex
  run rexx which_rexx.rex| use ooRexx to run 
which_rexx.rex

  run nrc -exec which_rexx.rex   | use NetRexx to run 
which_rexx.rex


  

  ---> use the generated 'setenv.cmd/setenv' script

  Windows  UnixComment
  ---  +--
   setenv.cmd  source ./setenv | sets the environment 
in the Terminal to net-oo-rexx

   the following commands will work on Windows as well as on Unix:

   oorexxshell | runs oorexxshell

   rexx testoorexx.rex | use ooRexx to run 
testoorexx.rex
   rexx which_rexx.rex | use ooRexx to run 
which_rexx.rex

   rexxdebugger packages/rexxdebugger/tutorial.rex | use ooRexx to run the 
rexxdebugger with its tutorial.rex

   nrc -exec which_rexx.rex| use NetRexx to run 
which_rexx.rex

   nrc which_rexx.rex  | use NetRexx to compile 
which_rexx.rex to which_rexx.class
   java which_rexx | use Java to run which_rexx.class 
(note: no ".class" extension!)



   ==
   Additional information
   ==

   To learn about the functionality of oorexxshell, take a few minutes and see 
the
   asciinema demos at [4].

   First feedback
   --

 - "install this bundle, you run a small, trivial setup program, and, poof,
   you have immediate access to a real trove of packages -- no additional
   installation needed"
   (JMB)

 - "I even was able to load the JDOR handler, then "address JDOR", and then
   construct one of the JDOR samples step-by-step, by manu

[Oorexx-devel] Done (Re: Version 2 (Re: Ad rules for running guarded methods (Re: A question about the blocking of a particular method

2024-07-19 Thread Rony G. Flatscher

Added to "15.4. Debugging Multithreaded Programs" under a new section "15.4.1. About Debugging
Guarded and Unguarded Methods". It fits better there and enables the reader to better understand the
remainder of that section.

Committed with [r12858], cf. <https://sourceforge.net/p/oorexx/code-0/12858/>.

---rony

On 13.07.2024 12:54, Rony G. Flatscher wrote:

Planning on adding the documentation at the end of section "12.4.3. Guarded
Methods" in rexxref.pdf.

---

Planning on the following improvements for TraceObject:

* add an entry ISWAITING for "GUARD ON|OFF WHEN condition" statements,
reflecting the state of
the evaluated condition; if condition is false, then ISWAITING will be set
to .true as the
method has to wait for the re-evaluation of the condition, it is set to
.false else (the
method continues to run),

* add an entry CALLERSTACKFRAME for each invocation entry: this should allow
to find out the
caller for that particular invocation when analyzing trace logs,

* change the format of "Standard" to include the attribute pool ID, add next
to the guarded
(G)/unguarded(U) indicator in lowercase "u" if a guarded method is
currently executing
unguarded and "g" if an unguarded method is currently executing guarded a
blank otherwise, a
"W" as the last column if waiting on a guard condition to succeed a blank
otherwise. To not
increase the space for the extended trace prefix the widths for the ID
values will be reduced
from the minimum of currently three to two digits which should cater for
tracing small to
medium sized ooRexx programs,

* change the format of "Full" to include next to the guarded (G)/unguarded(U)
indicator in
lowercase "u" if a guarded method is currently executing unguarded and "g"
if an unguarded
method is currently executing guarded a blank otherwise, a "W" as the last
column if waiting
on a guard condition to succeed a blank otherwise.

---rony

On 12.07.2024 16:28, Rony G. Flatscher wrote:

Here an attempt to improve the text for the rules:

*Rules for running guarded methods*

ooRexx ensures that guarded methods of the same scope (defined for the
same class) cannot
execute concurrently to protect access to its attribute pool (object
variable pool). To
do so, a counter-based guard lock is maintained for each scope, which
gets increased by
one if a guarded method gets invoked and decreased by one upon return.
If a guarded
method for the same scope gets invoked from another thread and the
scope's guard lock
counter is not zero, it gets blocked because another guarded method
holding the guard
lock is currently running in the same scope. Once the scope's guard
lock counter drops to
0 (no other guarded method runs currently), the blocked guarded method
can acquire the
guard lock, thereby increasing the guard lock counter to one and
starting to run.

1. Invoking a guarded method from the same thread, then it will
increase the guard lock
counter by one and, upon return, will decrease it by one. Invoking
an unguarded
method from the same thread will not change the guard lock counter.

2. Invoking a guarded method from another thread for a scope in which
a guarded method
is currently running will block the invocation until the scope's
guard lock counter
drops to 0 (no other guarded method for the same scope is running
anymore) and the
guard lock becomes free. In this situation, the blocked guarded
method will succeed
in acquiring the guard lock, increasing the guard lock counter to
one, and starting
running.

3. If a REPLY keyword statement is processed in a currently guarded
method, the
remaining instructions of the guarded method will remain guarded.

4. A GUARD ON keyword statement has no effect.

5. A GUARD OFF keyword statement changes the guarded method to an
unguarded method from
that point on, in the process reducing the guard lock counter by
one and removing the
guard lock.

*Rules for running unguarded methods*

1. Unguarded methods can always run concurrently with any other method
of the same scope.

2. If a REPLY keyword statement is processed in a currently unguarded
method, the
remainder of the invocation will continue on a different thread,
also unguarded.

3. A GUARD ON keyword statement changes the unguarded method to a
guarded method from
that point on, in the process increasing the guard lock counter by
one and acquiring
the guard lock.

4. A GUARD OFF keyword statement has no effect.

---

[Oorexx-devel] Changes committed (#841 Add entries to TraceObject, store stackframe values in StringTable)

2024-07-17 Thread Rony G. Flatscher


RFE #841:

   Add information about the caller's stack frame (CALLERSTACKFRAME) to 
TraceObject for an
   invocation entry to find out exactly where the call or message came from, an 
entry ISWAITING
   whenever a “guard on when condition” gets evaluated. Change the extended 
trace prefix for
   options “S” and “F” to reflect the current guard state if it differs from 
the guard state
   defined for the running method. Also, indicate if a “guard on when 
condition” is evaluated as
   false by the capital letter W next to the asterisk.

   Save the stack frame values for ARGUMENTS, EXECUTABLE, LINE, NAME, TARGET, 
TRACELINE, and TYPE
   in a StringTable with the same index names when storing the stack frame 
information in the
   TraceObject (entries STACKFRAME and CALLERSTACKFRAME).

Implemented with [r12855], adapted unit tests with [r12856].

ToDo: documentation.

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

Re: [Oorexx-devel] Question ad Activity::activationFrames and asynchronous message

2024-07-16 Thread Rony G. Flatscher

On 14.07.2024 11:31, Rick McGuire wrote:

On Sun, Jul 14, 2024 at 5:28 AM Rony G. Flatscher
wrote:

On 13.07.2024 17:31, Rick McGuire wrote:

A question here: I thought that if storing Rexx objects in a Rexx
collection they are pinned
and do not get garbage collected.

The stack frame object would not be garbage collected, but the stack frame itself and the things
that it referred to would no longer exist or be valid.

Thank you!

A last question in this context: as a StackFrame object allows access to strings and the executable
(a routine or a method) and target (in case of a method) object, would it be safe to just create a
StringTable and copy all accessible values of the StackFrame to the StringTable using the same names
as index?

I.e. the stack frame values for: arguments (an array), executable (a routine or a method), line (a
string), name (a string), target (an object), traceLine (a string), type (a string). The idea being
that the executable and the target object would get pinned by the StringTable (and there would be no
stack frame related context left that could be erroneously referred to later by a Rexx programmer).

---rony

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

[Oorexx-devel] StackFrame entry and stack frame (Re: Question ad Activity::activationFrames and asynchronous message

2024-07-14 Thread Rony G. Flatscher

On 14.07.2024 11:31, Rick McGuire wrote:

On Sun, Jul 14, 2024 at 5:28 AM Rony G. Flatscher
wrote:

On 13.07.2024 17:31, Rick McGuire wrote:

A question here: I thought that if storing Rexx objects in a Rexx
collection they are pinned
and do not get garbage collected.

The stack frame object would not be garbage collected, but the stack frame itself and the things
that it referred to would no longer exist or be valid.

Thank you!

Will make the TraceObject StackFrame entry pointing to a StringTable entry instead that contains
.nil or string values only for the stack frame entries at the point the traceObject gets created.
This way no unexpected crashes can occur if accessing the entries at a later time when the activity
and the stackframe are not available anymore.

Still the trace related information which package, line, traceline, type etc. will remain available.
The referrals to executable or object will get replaced by their identity hash values such that post
anaylsis of trace log objects allows to determine the identity later which may be interesting e.g.
for analyzing message communication patterns and the like.

---rony

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

Re: [Oorexx-devel] Question ad Activity::activationFrames and asynchronous message

2024-07-14 Thread Rony G. Flatscher

On 13.07.2024 17:31, Rick McGuire wrote:
That makes absolutely no sense. Once the new activity is started, there is no guarantee that the
stackframe or even the activity from which it was spawned even exists any more. The original
activity has continued on doing its own stuff.

A question here: I thought that if storing Rexx objects in a Rexx collection they are pinned and do
not get garbage collected.

Your statement about the possibility of a stackframe to not exist anymore seems to indicate that a
StackFrame object could be garbage collected while being referred to in a Rexx collection?

The reason for this question is the following scenario: running Rexx programs for tracing, creating
trace logs that will get analyzed way after the traced program has finished running. In that
scenario the traceObjects that are collected in an array need to be processed and at that time will
analyze the stackframe entry to learn about the package name, line numbers and the like. What would
happen then if accessing the stackframe entries at that point in time?

---rony

On Sat, Jul 13, 2024 at 11:09 AM Rony G. Flatscher
wrote:

On 13.07.2024 16:27, Rick McGuire wrote:

the stackframes are a representation of the activations active on an
activity. When a method
is started asynchronously, it is the base of the activity stack and does
not have a parent
stack frame. So many other things would get messed up by trying to add one
to that stack. And
you're on your own with fixing any problems created by trying to add one.

Hmm, o.k., thanks.

Would there be another source from where one could learn at runtime where
an activity got
created from that could be used instead? Or would it be possible to add
"just" a field to
Activity that would allow to refer to an Activity's creator's stack frame,
if available?

---rony

On Sat, Jul 13, 2024 at 9:15 AM Rony G. Flatscher
wrote:

While analyzing various invocation types and the caller's stack frame
(for invocation
entries to allow identifying the caller from a trace log later),
everything seems to work
out nicely.

There is one case where the caller's stack frame cannot be generated,
it seems to have to
do with methods that get run asynchroneously, e.g.:

...
o=.clz~new
o~m1 -- caller's stack frame can be built for ">I> Method "M1" with
scope ..."

o~start("m1") -- caller's stack frame can NOT be built for ">I> Method
"M1" with scope ..."
...

The activity for the asynchronous message has
Activity::activationFrames as NULL, such
that it cannot be used for creating a parent stack frame.

Would it possible to supply an Activity::activationFrames for
asynchronous dispatch?

---rony

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

Re: [Oorexx-devel] Question ad Activity::activationFrames and asynchronous message

2024-07-13 Thread Rony G. Flatscher

On 13.07.2024 16:27, Rick McGuire wrote:
the stackframes are a representation of the activations active on an activity. When a method is
started asynchronously, it is the base of the activity stack and does not have a parent stack
frame. So many other things would get messed up by trying to add one to that stack. And you're on
your own with fixing any problems created by trying to add one.

Hmm, o.k., thanks.

Would there be another source from where one could learn at runtime where an activity got created
from that could be used instead? Or would it be possible to add "just" a field to Activity that
would allow to refer to an Activity's creator's stack frame, if available?

---rony

On Sat, Jul 13, 2024 at 9:15 AM Rony G. Flatscher
wrote:

While analyzing various invocation types and the caller's stack frame (for
invocation entries
to allow identifying the caller from a trace log later), everything seems
to work out nicely.

There is one case where the caller's stack frame cannot be generated, it
seems to have to do
with methods that get run asynchroneously, e.g.:

...
o=.clz~new
o~m1 -- caller's stack frame can be built for ">I> Method "M1" with scope
..."

o~start("m1") -- caller's stack frame can NOT be built for ">I> Method
"M1" with scope ..."
...

The activity for the asynchronous message has Activity::activationFrames as
NULL, such that it
cannot be used for creating a parent stack frame.

Would it possible to supply an Activity::activationFrames for asynchronous
dispatch?

---rony

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

[Oorexx-devel] Question ad Activity::activationFrames and asynchronous message

2024-07-13 Thread Rony G. Flatscher

While analyzing various invocation types and the caller's stack frame (for invocation entries to 
allow identifying the caller from a trace log later), everything seems to work out nicely.


There is one case where the caller's stack frame cannot be generated, it seems to have to do with 
methods that get run asynchroneously, e.g.:


   ...
   o=.clz~new
   o~m1 -- caller's stack frame can be built for ">I> Method "M1" with scope 
..."

   o~start("m1") -- caller's stack frame can NOT be built for ">I> Method "M1" 
with scope ..."
   ...

The activity for the asynchronous message has Activity::activationFrames as NULL, such that it 
cannot be used for creating a parent stack frame.


Would it possible to supply an Activity::activationFrames for asynchronous 
dispatch?

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

Re: [Oorexx-devel] Version 2 (Re: Ad rules for running guarded methods (Re: A question about the blocking of a particular method

2024-07-13 Thread Rony G. Flatscher


Planning on adding the documentation at the end of section "12.4.3. Guarded 
Methods" in rexxref.pdf.

---

Planning on the following improvements for TraceObject:

 * add an entry ISWAITING for "GUARD ON|OFF WHEN condition" statements, 
reflecting the state of the
   evaluated condition; if condition is false, then ISWAITING will be set to 
.true as the method
   has to wait for the re-evaluation of the condition, it is set to .false else 
(the method
   continues to run),

 * add an entry CALLERSTACKFRAME for each invocation entry: this should allow 
to find out the
   caller for that particular invocation when analyzing trace logs,

 * change the format of "Standard" to include the attribute pool ID, add next 
to the guarded
   (G)/unguarded(U) indicator in lowercase "u" if a guarded method is currently 
executing unguarded
   and "g" if an unguarded method is currently executing guarded a blank otherwise,  a 
"W" as the
   last column if waiting on a guard condition to succeed a blank otherwise. To 
not increase the
   space for the extended trace prefix the widths for the ID values will be 
reduced from the
   minimum of currently three to two digits which should cater for tracing 
small to medium sized
   ooRexx programs,

 * change the format of "Full" to include next to the guarded (G)/unguarded(U) 
indicator in
   lowercase "u" if a guarded method is currently executing unguarded and "g" 
if an unguarded
   method is currently executing guarded a blank otherwise,  a "W" as the last 
column if waiting on
   a guard condition to succeed a blank otherwise.

---rony


On 12.07.2024 16:28, Rony G. Flatscher wrote:


Here an attempt to improve the text for the rules:

*Rules for running guarded methods*

ooRexx ensures that guarded methods of the same scope (defined for the 
same class) cannot
execute concurrently to protect access to its attribute pool (object 
variable pool). To do
so, a counter-based guard lock is maintained for each scope, which gets 
increased by one
if a guarded method gets invoked and decreased by one upon return. If a 
guarded method for
the same scope gets invoked from another thread and the scope's guard 
lock counter is not
zero, it gets blocked because another guarded method holding the guard 
lock is currently
running in the same scope. Once the scope's guard lock counter drops to 
0 (no other
guarded method runs currently), the blocked guarded method can acquire 
the guard lock,
thereby increasing the guard lock counter to one and starting to run.

 1. Invoking a guarded method from the same thread, then it will 
increase the guard lock
counter by one and, upon return, will decrease it by one. Invoking 
an unguarded method
from the same thread will not change the guard lock counter.

 2. Invoking a guarded method from another thread for a scope in which 
a guarded method is
currently running will block the invocation until the scope's guard 
lock counter drops
to 0 (no other guarded method for the same scope is running 
anymore) and the guard
lock becomes free. In this situation, the blocked guarded method 
will succeed in
acquiring the guard lock, increasing the guard lock counter to one, 
and starting running.

 3. If a REPLY keyword statement is processed in a currently guarded 
method, the remaining
instructions of the guarded method will remain guarded.

 4. A GUARD ON keyword statement has no effect.

 5. A GUARD OFF keyword statement changes the guarded method to an 
unguarded method from
that point on, in the process reducing the guard lock counter by 
one and removing the
guard lock.

*Rules for running unguarded methods*

 1. Unguarded methods can always run concurrently with any other method 
of the same scope.

 2. If a REPLY keyword statement is processed in a currently unguarded 
method, the
remainder of the invocation will continue on a different thread, 
also unguarded.

 3. A GUARD ON keyword statement changes the unguarded method to a 
guarded method from
that point on, in the process increasing the guard lock counter by 
one and acquiring
the guard lock.

 4. A GUARD OFF keyword statement has no effect.


-

Some notes and maybe some planned improvements to TraceObject:

  * the extended trace log includes the attribute pool (object variable pool) 
ID which allows for
distinguishing different instances for which the methods run; it is planned 
to change the
"Standard" format of TraceObject to include the attribute pool ID,

  *

[Oorexx-devel] Version 2 (Re: Ad rules for running guarded methods (Re: A question about the blocking of a particular method


Here an attempt to improve the text for the rules:

   *Rules for running guarded methods*

   ooRexx ensures that guarded methods of the same scope (defined for the 
same class) cannot
   execute concurrently to protect access to its attribute pool (object 
variable pool). To do
   so, a counter-based guard lock is maintained for each scope, which gets 
increased by one if
   a guarded method gets invoked and decreased by one upon return. If a 
guarded method for the
   same scope gets invoked from another thread and the scope's guard lock 
counter is not zero,
   it gets blocked because another guarded method holding the guard lock is 
currently running
   in the same scope. Once the scope's guard lock counter drops to 0 (no 
other guarded method
   runs currently), the blocked guarded method can acquire the guard lock, 
thereby increasing
   the guard lock counter to one and starting to run.

1. Invoking a guarded method from the same thread, then it will 
increase the guard lock
   counter by one and, upon return, will decrease it by one. Invoking 
an unguarded method
   from the same thread will not change the guard lock counter.

2. Invoking a guarded method from another thread for a scope in which a 
guarded method is
   currently running will block the invocation until the scope's guard 
lock counter drops
   to 0 (no other guarded method for the same scope is running anymore) 
and the guard lock
   becomes free. In this situation, the blocked guarded method will 
succeed in acquiring
   the guard lock, increasing the guard lock counter to one, and 
starting running.

3. If a REPLY keyword statement is processed in a currently guarded 
method, the remaining
   instructions of the guarded method will remain guarded.

4. A GUARD ON keyword statement has no effect.

5. A GUARD OFF keyword statement changes the guarded method to an 
unguarded method from
   that point on, in the process reducing the guard lock counter by one 
and removing the
   guard lock.

   *Rules for running unguarded methods*

1. Unguarded methods can always run concurrently with any other method 
of the same scope.

2. If a REPLY keyword statement is processed in a currently unguarded 
method, the remainder
   of the invocation will continue on a different thread, also 
unguarded.

3. A GUARD ON keyword statement changes the unguarded method to a 
guarded method from that
   point on, in the process increasing the guard lock counter by one 
and acquiring the
   guard lock.

4. A GUARD OFF keyword statement has no effect.

   
-

Some notes and maybe some planned improvements to TraceObject:

 * the extended trace log includes the attribute pool (object variable pool) ID 
which allows for
   distinguishing different instances for which the methods run; it is planned 
to change the
   "Standard" format of TraceObject to include the attribute pool ID,

 * the extended trace log includes a hint in the case that a method is not 
executing in the defined
   state due to the use of GUARD OFF|ON. In the trace log above a guarded 
method that runs
   unguarded is marked with a small 'u' right next to the method's defined 
state 'G'; it is planned
   to add this information at runtime, if possible (and not to a trace log as 
is the case here),

 * the extended trace log includes a hint 'W' (for waiting) for trace output 
where a wait for the
   guard lock takes place; ; it is planned to add this information at runtime, 
if possible (and not
   to a trace log as is the case here).

Any comments, suggestions?

---rony

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

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp


On 12.07.2024 15:25, Rick McGuire wrote:
Looking at your CreateTraceObject code, it appears there were several conditional tests where it 
appears it was possible to not have an available RexxActivation. My suggestion be to make the code 
that creates the TraceObject into a static method and have add the activity and the activation as 
arguments, restoring the conditional tests from the original.


+1

Committed [r12851].

---rony



On Fri, Jul 12, 2024 at 9:05 AM Rick McGuire  wrote:



On Fri, Jul 12, 2024 at 8:49 AM Rony G. Flatscher  
wrote:

Unfortunately, when doing a global trace (e.g. "::options trace i") 
there are crashes with
the refactored version, hence I uncommitted the changes.

The problem is in RexxActivation.cpp where in global trace "this" is 
NULL.

Even if checking for NULL and supplying defaults for that situation 
there is problem in
trying to invoke Activity::traceOutput(...) as there is no activity 
available if in
RexxActivation "this" is NULL.

What would be the proper solution for this situation?

Figure out why the RexxActivation is NULL, it's called debugging. The first 
step would be to
figure out how you got to that point by examining the stack trace.

Ignoring any invocation of processing the trace in such a situation?

---rony


    On 12.07.2024 13:54, Rony G. Flatscher wrote:


Commit [r12849] implements the refactoring (changes got successfully 
tested using the
ooRexx testing framework's TRACE related testgroups).

---rony


On 12.07.2024 11:55, Rick McGuire wrote:



    On Fri, Jul 12, 2024 at 5:52 AM Rony G. Flatscher 
 wrote:

On 12.07.2024 01:16, Rick McGuire wrote:

I still think the code refactoring I suggested is a good idea, 
which will make
things a bit cleaner.


+1



However, I just realized that the original problem could have been 
fixed by just
adding

enum TracePrefix;

where the class definitions at the top of Activity.cpp are located.


As the first error occurs with compiling the ArrayClass.cpp 
Activity.hpp also got
that definition added and it makes it compile.

However, later when RexxActivation.cpp gets compiled the following 
error gets raised:

[ 17%] Building CXX object
CMakeFiles/rexx.dir/interpreter/execution/RexxActivation.cpp.obj
RexxActivation.cpp

D:\orx.work202312\main_trunk_20240312\trunk\interpreter\execution\RexxActivation.cpp(3674):
error C2664: 'void Activity::traceOutput(RexxActivation 
*,RexxString
*,TracePrefix,RexxObject *,RexxObject *)': cannot convert 
argument 3 from
'RexxActivation::TracePrefix' to 'TracePrefix'

Ah, that's because they are different types because of the 
RexxActivation qualification.

Rick

    ---rony




On Thu, Jul 11, 2024 at 12:29 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 18:26, Rick McGuire wrote:



On Thu, Jul 11, 2024 at 12:20 PM Rony G. Flatscher 

wrote:

On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to 
answer the last
question first.


Thank you!



The problem with the compile error results in how 
RexxActivation is
defined in Activity.hpp. It's declaration is just "class 
RexxActivation",
which tells the compiler that RexxActivation is a 
class...and nothing
else. This allows RexxActivation * to be used in prototypes 
since there
is enough information available for that purpose. To get 
the full
definition of RexxActivation, you would need to replace 
"class
RexxActivation" with "#include "RexxActivation.hpp". 
However, I suspect
doing that will result in some circular dependencies 
between the two
header files.


Indeed.



Any you would probably need to define Activity as friend to 
the
RexxActivation class to make that enum visible.

Given the relationship between RexxActivation and Activity, 
and that both
classes need the information, having the enum defined in 
RexxActivation
feels like the wrong place to for that to be located. It 
feels like it
should belong in Activity. However, those values are really 
only used for
things created for RexxActivatio

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp


On 12.07.2024 15:05, Rick McGuire wrote:



On Fri, Jul 12, 2024 at 8:49 AM Rony G. Flatscher  
wrote:

Unfortunately, when doing a global trace (e.g. "::options trace i") there 
are crashes with the
refactored version, hence I uncommitted the changes.

The problem is in RexxActivation.cpp where in global trace "this" is NULL.

Even if checking for NULL and supplying defaults for that situation there 
is problem in trying
to invoke Activity::traceOutput(...) as there is no activity available if 
in RexxActivation
"this" is NULL.

What would be the proper solution for this situation?

Figure out why the RexxActivation is NULL, it's called debugging. The first step would be to 
figure out how you got to that point by examining the stack trace.


OK, here the call stack:

rexx.dll!RexxActivation::createTraceObject(RexxString * 
traceline=0x02129b4987e0, RexxActivation::TracePrefix 
tracePrefix=TRACE_OUTPUT, RexxString * tag=0x, RexxObject * 
value=0x) Line 5134   C++
rexx.dll!RexxActivation::processTraceInfo(RexxString * 
traceLine=0x02129b4987e0, RexxActivation::TracePrefix 
tracePrefix=TRACE_OUTPUT, RexxString * tag=0x, RexxObject * 
value=0x) Line 5175C++
rexx.dll!RexxActivation::displayUsingTraceOutput(RexxString * 
traceLine=0x02129b4987e0) Line 5187   C++
rexx.dll!Activity::display(DirectoryClass * exobj=0x02129b497870) 
Line 1384 C++
rexx.dll!Activity::displayCondition(DirectoryClass * 
errorInfo=0x02129b497870) Line 549 C++
   > rexx.dll!DisplayCondition(RexxThreadContext_ * c=0x02129b47fed8) Line 
1943  C++
rexx.exe!RexxThreadContext_::DisplayCondition() Line 1624   C++
rexx.exe!main(int argc=2, char * * argv=0x0212993a52b0) Line 231
C++
rexx.exe!invoke_main() Line 65  C++
rexx.exe!__scrt_common_main_seh() Line 253  C++
rexx.exe!__scrt_common_main() Line 296  C++
rexx.exe!mainCRTStartup() Line 17   C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown

Here the Locals:

   -c   0x02129b47fed8 {instance=0x02129b480470 
{functions=0x7ff9b5c699a0 {rexx.dll!RexxInstanceInterface 
InterpreterInstance::interfaceVector} {...} ...} ...} RexxThreadContext_ *
   -instance0x02129b480470 
{functions=0x7ff9b5c699a0 {rexx.dll!RexxInstanceInterface 
InterpreterInstance::interfaceVector} {...} ...}   RexxInstance_ *
   +functions   0x7ff9b5c699a0 
{rexx.dll!RexxInstanceInterface InterpreterInstance::interfaceVector} 
{interfaceVersion=...} RexxInstanceInterface *
applicationData 0x  void *
   +functions   0x7ff9b5c69b00 
{rexx.dll!RexxThreadInterface Activity::threadContextFunctions} 
{interfaceVersion=...}   RexxThreadInterface *
   -context {activity=0x02129b47feb0 
{instance=0x02129b480450 
{context={instanceContext={functions=0x7ff9b5c699a0 
{rexx.dll!RexxInstanceInterface InterpreterInstance::interfaceVector} {...} 
...} ...} ...} ...} ...}  ApiContext
   +activity0x02129b47feb0 {instance=0x02129b480450 
{context={instanceContext={functions=0x7ff9b5c699a0 
{rexx.dll!RexxInstanceInterface InterpreterInstance::interfaceVector} {...} 
...} ...} ...} ...} Activity *
   +context 0x02129b480cf0 {activity=0x02129b47feb0 
{instance=0x02129b480450 {context={instanceContext=...} ...} ...} ...}  
NativeActivation *
releaseLock truebool
clearConditions false   bool

The call comes from "RexxActivation::displayUsingTraceOutput(RexxString * 
traceLine=0x02129b4987e0)" which uses


     currentRexxFrame->displayUsingTraceOutput(text);

Activity.hpp defines currentRexxFrame as (with the preceeding hint):

// the following two fields represent the current top of the activation 
stack
// and the top Rexx frame in the stack.  Generally, if executing Rexx 
code,
// then currentRexxFrame == topStackFrame.  If we're at the base of the 
stack
// topStackFrame will be the root stack element (a NativeActivation 
instance)
// and the currentRexxFrame will be OREF_NULL.  If we've made a callout 
from a
// Rexx context, then the topStackFrame will be the NativeActivation 
that
// made the callout and the currentRexxFrame will be the predecessor 
frame.
RexxActivation *currentRexxFrame;
ActivationBase *topStackFrame;  // top-most activation frame (can 
be either native or Rexx).

So ATM at the end of my Latin.

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

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp


This gets invoked with "this" being NULL:

   void RexxActivation::processTraceInfo(RexxString *traceLine, TracePrefix 
tracePrefix, RexxString *tag, RexxObject *value)
   {
   // make sure this is a real string value (likely, since we constructed 
it in the first place)
   Protected pline = traceLine->stringTrace();
   Protected traceObject=createTraceObject(pline, tracePrefix, 
tag, value);
   activity->traceOutput(this, pline, traceObject);
   }

"activity" is a local variable of "this".

The test Rexx program which causes the crash:

   .clz~~nw~~m1

   ::class clz
   ::method m1 guarded
  k=1
  self~m2
  k=2

   ::method m2 unguarded
  k=3
  self~m3
  k=4

   ::method m3 guarded
  k=5

---rony


On 12.07.2024 14:48, Rony G. Flatscher wrote:


Unfortunately, when doing a global trace (e.g. "::options trace i") there are crashes with the 
refactored version, hence I uncommitted the changes.


The problem is in RexxActivation.cpp where in global trace "this" is NULL.

Even if checking for NULL and supplying defaults for that situation there is problem in trying to 
invoke Activity::traceOutput(...) as there is no activity available if in RexxActivation "this" is 
NULL.


What would be the proper solution for this situation?

Ignoring any invocation of processing the trace in such a situation?

---rony


On 12.07.2024 13:54, Rony G. Flatscher wrote:


Commit [r12849] implements the refactoring (changes got successfully tested using the ooRexx 
testing framework's TRACE related testgroups).


---rony


On 12.07.2024 11:55, Rick McGuire wrote:



On Fri, Jul 12, 2024 at 5:52 AM Rony G. Flatscher  
wrote:

On 12.07.2024 01:16, Rick McGuire wrote:

I still think the code refactoring I suggested is a good idea, which will 
make things a bit
cleaner.


+1



However, I just realized that the original problem could have been fixed by 
just adding

enum TracePrefix;

where the class definitions at the top of Activity.cpp are located.


As the first error occurs with compiling the ArrayClass.cpp Activity.hpp 
also got that
definition added and it makes it compile.

However, later when RexxActivation.cpp gets compiled the following error 
gets raised:

[ 17%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/execution/RexxActivation.cpp.obj
RexxActivation.cpp

D:\orx.work202312\main_trunk_20240312\trunk\interpreter\execution\RexxActivation.cpp(3674):
error C2664: 'void Activity::traceOutput(RexxActivation *,RexxString
*,TracePrefix,RexxObject *,RexxObject *)': cannot convert argument 3 
from
'RexxActivation::TracePrefix' to 'TracePrefix'

Ah, that's because they are different types because of the RexxActivation 
qualification.

Rick

---rony




On Thu, Jul 11, 2024 at 12:29 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 18:26, Rick McGuire wrote:



On Thu, Jul 11, 2024 at 12:20 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to answer the 
last question
first.


Thank you!



The problem with the compile error results in how RexxActivation is 
defined in
Activity.hpp. It's declaration is just "class RexxActivation", 
which tells the
compiler that RexxActivation is a class...and nothing else. This 
allows
RexxActivation * to be used in prototypes since there is enough 
information
available for that purpose. To get the full definition of 
RexxActivation, you
would need to replace "class RexxActivation" with "#include 
"RexxActivation.hpp".
However, I suspect doing that will result in some circular 
dependencies between
the two header files.


Indeed.



Any you would probably need to define Activity as friend to the
RexxActivation class to make that enum visible.

Given the relationship between RexxActivation and Activity, and 
that both classes
need the information, having the enum defined in RexxActivation 
feels like the
wrong place to for that to be located. It feels like it should 
belong in
Activity. However, those values are really only used for things 
created for
RexxActivation.

A better solution would be to refactor the code a bit. 
Activity::traceOutput() .
The first two lines of TraceOutput deal with the creation of the 
TraceObject,
which really should be something that the RexxActivation is 
responsible for. Move
the stuff involved with that to RexxActivation and then only pass 
the constructed
TraceObject to the

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp

Unfortunately, when doing a global trace (e.g. "::options trace i") there are crashes with the 
refactored version, hence I uncommitted the changes.


The problem is in RexxActivation.cpp where in global trace "this" is NULL.

Even if checking for NULL and supplying defaults for that situation there is problem in trying to 
invoke Activity::traceOutput(...) as there is no activity available if in RexxActivation "this" is 
NULL.


What would be the proper solution for this situation?

Ignoring any invocation of processing the trace in such a situation?

---rony


On 12.07.2024 13:54, Rony G. Flatscher wrote:


Commit [r12849] implements the refactoring (changes got successfully tested using the ooRexx 
testing framework's TRACE related testgroups).


---rony


On 12.07.2024 11:55, Rick McGuire wrote:



On Fri, Jul 12, 2024 at 5:52 AM Rony G. Flatscher  
wrote:

On 12.07.2024 01:16, Rick McGuire wrote:

I still think the code refactoring I suggested is a good idea, which will 
make things a bit
cleaner.


+1



However, I just realized that the original problem could have been fixed by 
just adding

enum TracePrefix;

where the class definitions at the top of Activity.cpp are located.


As the first error occurs with compiling the ArrayClass.cpp Activity.hpp 
also got that
definition added and it makes it compile.

However, later when RexxActivation.cpp gets compiled the following error 
gets raised:

[ 17%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/execution/RexxActivation.cpp.obj
RexxActivation.cpp

D:\orx.work202312\main_trunk_20240312\trunk\interpreter\execution\RexxActivation.cpp(3674):
error C2664: 'void Activity::traceOutput(RexxActivation *,RexxString
*,TracePrefix,RexxObject *,RexxObject *)': cannot convert argument 3 
from
'RexxActivation::TracePrefix' to 'TracePrefix'

Ah, that's because they are different types because of the RexxActivation 
qualification.

Rick

---rony




On Thu, Jul 11, 2024 at 12:29 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 18:26, Rick McGuire wrote:



On Thu, Jul 11, 2024 at 12:20 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to answer the 
last question
first.


Thank you!



The problem with the compile error results in how RexxActivation is 
defined in
Activity.hpp. It's declaration is just "class RexxActivation", 
which tells the
compiler that RexxActivation is a class...and nothing else. This 
allows
RexxActivation * to be used in prototypes since there is enough 
information
available for that purpose. To get the full definition of 
RexxActivation, you
would need to replace "class RexxActivation" with "#include 
"RexxActivation.hpp".
However, I suspect doing that will result in some circular 
dependencies between
the two header files.


Indeed.



Any you would probably need to define Activity as friend to the
RexxActivation class to make that enum visible.

Given the relationship between RexxActivation and Activity, and 
that both classes
need the information, having the enum defined in RexxActivation 
feels like the
wrong place to for that to be located. It feels like it should 
belong in Activity.
However, those values are really only used for things created for 
RexxActivation.

A better solution would be to refactor the code a bit. 
Activity::traceOutput() .
The first two lines of TraceOutput deal with the creation of the 
TraceObject,
which really should be something that the RexxActivation is 
responsible for. Move
the stuff involved with that to RexxActivation and then only pass 
the constructed
TraceObject to the traceOutput() method which is now just 
responsible for handling
the output. Now there's no need for TracePrefix to be visible 
outside of
RexxActivation.


There are the following places in Activity that cause the use of 
traceOutput()
directly and indirectly:

 *

wholenumber_t Activity::error()

/** Force error termination on an activity, returning the 
resulting REXX error code.
* @return The resulting Rexx error code. */

 *

wholenumber_t Activity::error(ActivationBase *activation, 
DirectoryClass *errorInfo)

/** Force error termination on an activity, returning the 
resulting REXX error code.
  * @param activation The activation raising the error.
  * @par

Re: [Oorexx-devel] Ad rules for running guarded methods (Re: A question about the blocking of a particular method


Bonjour Jean Louis,

On 11.07.2024 08:37, Jean Louis Faucher wrote:

Guten Tag Rony

+1 globally


:-)



I still continue to think that the point 1 for guarded methods could be 
reworded.
Your description makes reference to 2 guarded methods:

  * the “caller”: A guarded method can invoke...
  * the “called”: If that other method is guarded...

In the point 2, it’s clear that the focus is on the “called”:  Invoking a guarded method from 
another thread


The purpose of the point 1 is to explain when the counter is incremented.
That doesn’t depend on the “caller” being guarded, but it depends on the thread 
of the caller.
Maybe the point 1 should start like that:
Invoking a guarded method from the same thread …


Point 1 would express that, however the information about the same thread is at the end of the 
sentence (probably due to my German speaking background) and not at the beginning which may be 
irritating.


As it seems to make it clearer, I will change that point as you suggest.

While doing so, I would add another point on both variants that explain guard on|off in their 
context and link to the explanation where "guard on|off when condition" gets explained in the 
documentation.


The question would be also where to place this information in the ooRexx 
reference?

Best regards

---rony

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

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp

Commit [r12849] implements the refactoring (changes got successfully tested using the ooRexx testing 
framework's TRACE related testgroups).


---rony


On 12.07.2024 11:55, Rick McGuire wrote:



On Fri, Jul 12, 2024 at 5:52 AM Rony G. Flatscher  
wrote:

On 12.07.2024 01:16, Rick McGuire wrote:

I still think the code refactoring I suggested is a good idea, which will 
make things a bit
cleaner.


+1



However, I just realized that the original problem could have been fixed by 
just adding

enum TracePrefix;

where the class definitions at the top of Activity.cpp are located.


As the first error occurs with compiling the ArrayClass.cpp Activity.hpp 
also got that
definition added and it makes it compile.

However, later when RexxActivation.cpp gets compiled the following error 
gets raised:

[ 17%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/execution/RexxActivation.cpp.obj
RexxActivation.cpp

D:\orx.work202312\main_trunk_20240312\trunk\interpreter\execution\RexxActivation.cpp(3674):
error C2664: 'void Activity::traceOutput(RexxActivation *,RexxString
*,TracePrefix,RexxObject *,RexxObject *)': cannot convert argument 3 
from
'RexxActivation::TracePrefix' to 'TracePrefix'

Ah, that's because they are different types because of the RexxActivation 
qualification.

Rick

---rony




    On Thu, Jul 11, 2024 at 12:29 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 18:26, Rick McGuire wrote:



    On Thu, Jul 11, 2024 at 12:20 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to answer the 
last question first.


Thank you!



The problem with the compile error results in how RexxActivation is 
defined in
Activity.hpp. It's declaration is just "class RexxActivation", 
which tells the
compiler that RexxActivation is a class...and nothing else. This 
allows
RexxActivation * to be used in prototypes since there is enough 
information
available for that purpose. To get the full definition of 
RexxActivation, you would
need to replace "class RexxActivation" with "#include 
"RexxActivation.hpp".
However, I suspect doing that will result in some circular 
dependencies between the
two header files.


Indeed.



Any you would probably need to define Activity as friend to the
RexxActivation class to make that enum visible.

Given the relationship between RexxActivation and Activity, and 
that both classes
need the information, having the enum defined in RexxActivation 
feels like the
wrong place to for that to be located. It feels like it should 
belong in Activity.
However, those values are really only used for things created for 
RexxActivation.

A better solution would be to refactor the code a bit. 
Activity::traceOutput() .
The first two lines of TraceOutput deal with the creation of the 
TraceObject, which
really should be something that the RexxActivation is responsible 
for. Move the
stuff involved with that to RexxActivation and then only pass the 
constructed
TraceObject to the traceOutput() method which is now just 
responsible for handling
the output. Now there's no need for TracePrefix to be visible 
outside of
RexxActivation.


There are the following places in Activity that cause the use of 
traceOutput()
directly and indirectly:

 *

wholenumber_t Activity::error()

/** Force error termination on an activity, returning the 
resulting REXX error code.
* @return The resulting Rexx error code. */

 *

wholenumber_t Activity::error(ActivationBase *activation, 
DirectoryClass *errorInfo)

/** Force error termination on an activity, returning the 
resulting REXX error code.
  * @param activation The activation raising the error.
  * @param errorInfo  The directory containing the error 
condition information.
  * @return The Rexx error code.  */

 *

wholenumber_t Activity::displayCondition(DirectoryClass 
*errorInfo)

/** Display error information and traceback lines for a Syntax 
condition.
  * @param errorInfo The condition object with the error 
information
  * @return The major error code for the syntax error, if this 
is  indeed a syntax conditon. */

 *

void Activity::display(DirectoryClass *exobj) ...

/** Display information from an exceptio

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp


On 12.07.2024 01:16, Rick McGuire wrote:

I still think the code refactoring I suggested is a good idea, which will make 
things a bit cleaner.


+1



However, I just realized that the original problem could have been fixed by 
just adding

enum TracePrefix;

where the class definitions at the top of Activity.cpp are located.


As the first error occurs with compiling the ArrayClass.cpp Activity.hpp also got that definition 
added and it makes it compile.


However, later when RexxActivation.cpp gets compiled the following error gets 
raised:

   [ 17%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/execution/RexxActivation.cpp.obj
   RexxActivation.cpp
   
D:\orx.work202312\main_trunk_20240312\trunk\interpreter\execution\RexxActivation.cpp(3674):
   error C2664: 'void Activity::traceOutput(RexxActivation *,RexxString 
*,TracePrefix,RexxObject
   *,RexxObject *)': cannot convert argument 3 from 
'RexxActivation::TracePrefix' to 'TracePrefix'

---rony




On Thu, Jul 11, 2024 at 12:29 PM Rony G. Flatscher  
wrote:

On 11.07.2024 18:26, Rick McGuire wrote:



On Thu, Jul 11, 2024 at 12:20 PM Rony G. Flatscher 
 wrote:

On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to answer the last 
question first.


Thank you!



The problem with the compile error results in how RexxActivation is 
defined in
Activity.hpp. It's declaration is just "class RexxActivation", which 
tells the compiler
that RexxActivation is a class...and nothing else. This allows 
RexxActivation * to be
used in prototypes since there is enough information available for that 
purpose. To get
the full definition of RexxActivation, you would need to replace "class 
RexxActivation"
with "#include "RexxActivation.hpp". However, I suspect doing that will 
result in some
circular dependencies between the two header files.


Indeed.



Any you would probably need to define Activity as friend to the 
RexxActivation class to
make that enum visible.

Given the relationship between RexxActivation and Activity, and that 
both classes need
the information, having the enum defined in RexxActivation feels like 
the wrong place to
for that to be located. It feels like it should belong in Activity. 
However, those
values are really only used for things created for RexxActivation.

A better solution would be to refactor the code a bit. 
Activity::traceOutput() . The
first two lines of TraceOutput deal with the creation of the 
TraceObject, which really
should be something that the RexxActivation is responsible for. Move 
the stuff involved
with that to RexxActivation and then only pass the constructed 
TraceObject to the
traceOutput() method which is now just responsible for handling the 
output. Now there's
no need for TracePrefix to be visible outside of RexxActivation.


There are the following places in Activity that cause the use of 
traceOutput() directly
and indirectly:

 *

wholenumber_t Activity::error()

/** Force error termination on an activity, returning the resulting 
REXX error code.
* @return The resulting Rexx error code. */

 *

wholenumber_t Activity::error(ActivationBase *activation, 
DirectoryClass *errorInfo)

/** Force error termination on an activity, returning the resulting 
REXX error code.
  * @param activation The activation raising the error.
  * @param errorInfo  The directory containing the error condition 
information.
  * @return The Rexx error code.  */

 *

wholenumber_t Activity::displayCondition(DirectoryClass *errorInfo)

/** Display error information and traceback lines for a Syntax 
condition.
  * @param errorInfo The condition object with the error information
  * @return The major error code for the syntax error, if this is  
indeed a syntax conditon. */

 *

void Activity::display(DirectoryClass *exobj) ...

/** Display information from an exception object.  *@param exobj  
The exception object.  */

 *

void Activity::displayDebug(DirectoryClass *exobj)

/** Display information about an error in interactive debug. @param 
exobj  The exception  */+


Only the last two of these are relevant, since the others just call those. 
If the creation of
the trace object is a method of RexxActivation(), that method is just 
called to get the
information needed by traceOutput().


ah, ok, thank you!

---rony

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

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp

2024-07-11 Thread Rony G. Flatscher


On 11.07.2024 18:26, Rick McGuire wrote:



On Thu, Jul 11, 2024 at 12:20 PM Rony G. Flatscher  
wrote:

On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to answer the last 
question first.


Thank you!



The problem with the compile error results in how RexxActivation is defined 
in Activity.hpp.
It's declaration is just "class RexxActivation", which tells the compiler 
that
RexxActivation is a class...and nothing else. This allows RexxActivation * 
to be used in
prototypes since there is enough information available for that purpose. To 
get the full
definition of RexxActivation, you would need to replace "class RexxActivation" 
with "#include
"RexxActivation.hpp". However, I suspect doing that will result in some 
circular dependencies
between the two header files.


Indeed.



Any you would probably need to define Activity as friend to the 
RexxActivation class to make
that enum visible.

Given the relationship between RexxActivation and Activity, and that both 
classes need the
information, having the enum defined in RexxActivation feels like the wrong 
place to for that
to be located. It feels like it should belong in Activity. However, those 
values are really
only used for things created for RexxActivation.

A better solution would be to refactor the code a bit. 
Activity::traceOutput() . The first
two lines of TraceOutput deal with the creation of the TraceObject, which 
really should be
something that the RexxActivation is responsible for. Move the stuff 
involved with that to
RexxActivation and then only pass the constructed TraceObject to the 
traceOutput() method
which is now just responsible for handling the output. Now there's no need 
for TracePrefix to
be visible outside of RexxActivation.


There are the following places in Activity that cause the use of 
traceOutput() directly and
indirectly:

 *

wholenumber_t Activity::error()

/** Force error termination on an activity, returning the resulting 
REXX error code.
* @return The resulting Rexx error code. */

 *

wholenumber_t Activity::error(ActivationBase *activation, 
DirectoryClass *errorInfo)

/** Force error termination on an activity, returning the resulting 
REXX error code.
  * @param activation The activation raising the error.
  * @param errorInfo  The directory containing the error condition 
information.
  * @return The Rexx error code.  */

 *

wholenumber_t Activity::displayCondition(DirectoryClass *errorInfo)

/** Display error information and traceback lines for a Syntax 
condition.
  * @param errorInfo The condition object with the error information
  * @return The major error code for the syntax error, if this is  
indeed a syntax conditon. */

 *

void Activity::display(DirectoryClass *exobj) ...

/** Display information from an exception object.  *@param exobj  The 
exception object.  */

 *

void Activity::displayDebug(DirectoryClass *exobj)

/** Display information about an error in interactive debug. @param 
exobj  The exception  */+


Only the last two of these are relevant, since the others just call those. If the creation of the 
trace object is a method of RexxActivation(), that method is just called to get the information 
needed by traceOutput().


ah, ok, thank you!

---rony

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

Re: [Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp

2024-07-11 Thread Rony G. Flatscher


On 11.07.2024 17:52, Rick McGuire wrote:

I'm going to answer this out of line because I want to answer the last question 
first.


Thank you!


The problem with the compile error results in how RexxActivation is defined in Activity.hpp. It's 
declaration is just "class RexxActivation", which tells the compiler that RexxActivation is a 
class...and nothing else. This allows RexxActivation * to be used in prototypes since there is 
enough information available for that purpose. To get the full definition of RexxActivation, you 
would need to replace "class RexxActivation" with "#include "RexxActivation.hpp". However, I 
suspect doing that will result in some circular dependencies between the two header files.


Indeed.


Any you would probably need to define Activity as friend to the RexxActivation class to make that 
enum visible.


Given the relationship between RexxActivation and Activity, and that both classes need the 
information, having the enum defined in RexxActivation feels like the wrong place to for that to 
be located. It feels like it should belong in Activity. However, those values are really only used 
for things created for RexxActivation.


A better solution would be to refactor the code a bit. Activity::traceOutput() . The first two 
lines of TraceOutput deal with the creation of the TraceObject, which really should be something 
that the RexxActivation is responsible for. Move the stuff involved with that to 
RexxActivation and then only pass the constructed TraceObject to the traceOutput() method which is 
now just responsible for handling the output. Now there's no need for TracePrefix to be visible 
outside of RexxActivation.


There are the following places in Activity that cause the use of traceOutput() 
directly and indirectly:

 *

   wholenumber_t Activity::error()

   /** Force error termination on an activity, returning the resulting REXX 
error code.
   * @return The resulting Rexx error code. */

 *

   wholenumber_t Activity::error(ActivationBase *activation, DirectoryClass 
*errorInfo)

   /** Force error termination on an activity, returning the resulting REXX 
error code.
 * @param activation The activation raising the error.
 * @param errorInfo  The directory containing the error condition 
information.
 * @return The Rexx error code.  */

 *

   wholenumber_t Activity::displayCondition(DirectoryClass *errorInfo)

   /** Display error information and traceback lines for a Syntax condition.
 * @param errorInfo The condition object with the error information
 * @return The major error code for the syntax error, if this is  indeed a 
syntax conditon. */

 *

   void Activity::display(DirectoryClass *exobj) ...

   /** Display information from an exception object.  *@param exobj  The 
exception object.  */

 *

   void Activity::displayDebug(DirectoryClass *exobj)

   /** Display information about an error in interactive debug. @param exobj  
The exception  */

What should be done with these?

Oh, and in the process, could you please make CreateTraceObject() into a method of RexxActivation? 
Doing things via functions really doesn't belong in this code base.


+1

---rony





On Thu, Jul 11, 2024 at 11:24 AM Rony G. Flatscher  
wrote:

The enum TracePrefix type gets defined RexxActivation.hpp and is public 
(needs to be used from
RexxActivation.cpp and Activit.cpp).

What is the proper way to become able to refer to the enum TracePrefix in 
Activity.hpp and
Activity.cpp?

Currently "Activity.hpp" defines the prototype for traceOutput(...) as

void traceOutput(RexxActivation *, RexxString *, RexxString *, 
RexxObject *, RexxObject *);

and should be changed to allow for a TracePrefix argument as the third 
argument, hence trying to:

void traceOutput(RexxActivation *, RexxString *, TracePrefix, 
RexxString *, RexxObject *, RexxObject *);

If doing so the compiler yields an error "error C2664: ... cannot convert 
argument 3 from
'RexxActivation::TracePrefix' to 'TracePrefix'".

Therefore changing the prototype to

  void traceOutput(RexxActivation *, RexxString *, 
RexxActivation::TracePrefix, RexxObject *, RexxObject *, RexxObject *);

yields the compiler error messages:

...\Activity.hpp(210): error C2027: use of undefined type 
'RexxActivation'
...\Activity.hpp(73): note: see declaration of 'RexxActivation'

The type "RexxActivation" can be used in Activity.hpp (defines at the top 
"class
RexxActivation;") do define prototypes.

---

The question: what needs to be defined where in order to become able to 
reference the enum
TracePrefix from Activity.hpp and Activity.cpp without an error?

---rony

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

[Oorexx-devel] Question ad how to use TracePrefix in Activity.cpp

2024-07-11 Thread Rony G. Flatscher

The enum TracePrefix type gets defined RexxActivation.hpp and is public (needs to be used from 
RexxActivation.cpp and Activit.cpp).


What is the proper way to become able to refer to the enum TracePrefix in 
Activity.hpp and Activity.cpp?

Currently "Activity.hpp" defines the prototype for traceOutput(...) as

   void traceOutput(RexxActivation *, RexxString *, RexxString *, RexxObject *, 
RexxObject *);

and should be changed to allow for a TracePrefix argument as the third 
argument, hence trying to:

   void traceOutput(RexxActivation *, RexxString *, TracePrefix, RexxString *, 
RexxObject *, RexxObject *);

If doing so the compiler yields an error "error C2664: ... cannot convert argument 3 from 
'RexxActivation::TracePrefix' to 'TracePrefix'".


Therefore changing the prototype to

 void traceOutput(RexxActivation *, RexxString *, 
RexxActivation::TracePrefix, RexxObject *, RexxObject *, RexxObject *);

yields the compiler error messages:

   ...\Activity.hpp(210): error C2027: use of undefined type 'RexxActivation'
   ...\Activity.hpp(73): note: see declaration of 'RexxActivation'

The type "RexxActivation" can be used in Activity.hpp (defines at the top "class RexxActivation;") 
do define prototypes.


---

The question: what needs to be defined where in order to become able to reference the enum 
TracePrefix from Activity.hpp and Activity.cpp without an error?


---rony

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

[Oorexx-devel] Ad adding new TracePrefix values ...

2024-07-10 Thread Rony G. Flatscher

In preparation of adding a new entry to TraceObject it is clear that deciding whether an entry 
should be added or not needs to be done as quickly as possible in CreateTraceObject(). To facilate 
this decision it would be good to supply the TracePrefix value for which a trace line gets output. 
This would incur an additional TracePrefix argument to traceOutput() and to CreateTraceObject() in 
which the TracePrefix value could then be tested.


While going through the invocations of traceOutput(...) all but the following two routines have 
proper TracePrefix values defined for them:


 *

   void RexxActivation::traceSourceString()

 *

   bool RexxActivation::doDebugPause()

Therefore the idea is to define two new TracePrefix enum values that allow to identify the reason of 
the call to traceOutput():


 * TRACE_SOURCE_STRING ... intended for use in --> void 
RexxActivation::traceSourceString()
 * TRACE_DEBUG_PROMPT ... intended for use in the initial debug prompt --> bool
   RexxActivation::doDebugPause()

Alternatively, one could add an enum value TRACE_UNDEFINED for use in traceSourceString() and 
doDebugPause() when invoking traceOutput(). Personally I would prefer to communicate the exact 
reason for the trace line output.


Any comments?

---rony

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

[Oorexx-devel] Ad rules for running guarded methods (Re: A question about the blocking of a particular method

2024-07-10 Thread Rony G. Flatscher


O.K. after quite some research and inspection time these seem to be the rules:

   *Rules for running guarded methods*

   ooRexx ensures that guarded methods of the same scope (defined for the same 
class) cannot
   execute concurrently to protect access to its attribute pool (object 
variable pool). To do so, a
   counter-based guard lock is maintained for each scope, which gets increased 
by one if a guarded
   method gets invoked and decreased by one upon return. If a guarded method 
for the same scope
   gets invoked from another thread and the scope's guard lock counter is not 
zero, it gets blocked
   because another guarded method holding the guard lock is currently running 
in the same scope.
   Once the scope's guard lock counter drops to 0 (no other guarded method runs 
currently), the
   blocked guarded method can acquire the guard lock, thereby increasing the 
guard lock counter to
   one and starting to run.

1. A guarded method can invoke any other method belonging to the same scope 
on its thread, be
   it guarded or unguarded. If that other method is guarded, then it will 
increase the guard
   lock counter by one and, upon return, will decrease it by one.

2. Invoking a guarded method from another thread for a scope in which a 
guarded method is
   currently running will block the invocation until the scope's guard lock 
counter drops to 0
   (no other guarded method for the same scope is running anymore) and the 
guard lock becomes
   free. In this situation, the blocked guarded method will succeed in 
acquiring the guard
   lock, increasing the guard lock counter to one, and starting running.

3. If a REPLY keyword statement is processed in a currently guarded method, 
the remaining
   instructions of the guarded method will remain guarded.

   *Rules for running unguarded methods*

1. Unguarded methods can always run concurrently with any other method of 
the same scope.

2. If a REPLY keyword statement is processed in a currently unguarded 
method, the remainder of
   the invocation will continue on a different thread, also unguarded.

-

Here analyzing the "deadlock.rex" example according to these rules:

   Code:

 1 o = .Clz ~new
 2 call syssleep 0.5
 3 o~m2 −− wake −up m1
 4 say " done . "
 5
 6 ::class Clz
 7 ::method init −− guarded method
 8expose a −− exclusive access
 9a = 0
   10reply
   11
   12self~m1 −− still guarded
   13
   14 ::method m1 −− guarded method
   15expose a −− exclusive access
   16a = 1
   17guard off −− unguard m1 method
   18say "m1 method : unguarded "
   19guard on when a <> 1
   20say "m1 method : guarded "
   21
   22 ::method m2 −− guarded method
   23expose a −− exclusive access
   24a = 2 −− change attribute

   Extended trace output:

   [T2 I2]   >I> Routine "deadlock.rex"
   [T2 I2] 1 *-* o = .Clz~new
   [T2 I3 G   A1 L0] >I> Method "INIT" with scope "CLZ"
   [T2 I3 G   A1 L1 *  ]   8 *-* expose a   -- exclusive access
   [T2 I3 G   A1 L1 *  ]   9 *-* a = 0
   [T2 I3 G   A1 L1 *  ] >>>   "0"
   [T2 I3 G   A1 L1 *  ]  10 *-* reply
   [T2 I3 G   A1 L1 *  ] >>   "a CLZ"
   [T2 I2] 2 *-* call syssleep 0.5
   [T3 I3 G   A1 L1 *  ] >I> Method "INIT" with scope "CLZ"
   [T3 I3 G   A1 L1 *  ]  12 *-* self~m1-- still guarded
   [T3 I4 G   A1 L1] >I> Method "M1" with scope "CLZ"
   [T3 I4 G   A1 L2 *  ]  15 *-* expose a   -- exclusive access
   [T3 I4 G   A1 L2 *  ]  16 *-* a = 1
   [T3 I4 G   A1 L2 *  ] >>>   "1"
   [T3 I4 G   A1 L2 *  ]  17 *-* guard off  -- unguard m1 method
   [T3 I4 G u A1 L1]  18 *-* say "m1 method: unguarded"
   [T3 I4 G u A1 L1] >>>   "m1 method: unguarded"
   *[T3 I4 G u A1 L1 ] 19 *-* guard on when a <> 1*
   [T3 I4 G u A1 L2 * W] >K>   "WHEN" => "0"
   [T2 I2]   >>>   "0"
   *[T2 I2] 3 *-* o~m2 -- wake-up m1 [T2 I5 G A1 L1 W] >I> Method "M2" with scope 
"CLZ"*

The message "o~m2" will cause a wait (block) as upon entry to "M2" from a different thread (T2) the 
lock count is not 0, but 1 (L1) such that it needs to wait until the guard lock counter drops to 0.


-

Here analyzing the "solved.rex" example according to these rules:

   Code:

 1 o = .Clz ~new
 2 call syssleep 0.5
 3 o~m2 −− wake −up m1
 4 say " done . "
 5
 6 ::class Clz
 7 ::method init −− guarded method
 8expose a −− exclusive access
 9a = 0
   10reply
   11guard off -- free guard lock
   12self~m1 −− still guarded
   13
   14 ::method m1 −− guarded method
   15expose a −− exclusive access
   16a = 1
   17guard off −− unguard m1 method
   18say "m1 method : unguarded "
   19

Re: [Oorexx-devel] A question about the blocking of a particular method

2024-07-06 Thread Rony G. Flatscher

In case it helps here the version that does not deadlock (line # 11 does a "guard off") with the 
annotated trace log.


Here "solved.rex":

 1 o = .Clz ~new
 2 call syssleep 0.5
 3 o~m2 −− wake −up m1
 4 say " done . "
 5
 6 ::class Clz
 7 ::method init −− guarded method
 8expose a −− exclusive access
 9a = 0
   10reply
   11guard off -- now no deadlock anymore !?!
   12self~m1 −− still guarded
   13
   14 ::method m1 −− guarded method
   15expose a −− exclusive access
   16a = 1
   17guard off −− unguard m1 method
   18say "m1 method : unguarded "
   19guard on when a <> 1
   20say "m1 method : guarded "
   21
   22 ::method m2 −− guarded method
   23expose a −− exclusive access
   24a = 2 −− change attribute

Here the trace log:

   [T2 I2]   >I> Routine "solved.rex"
   [T2 I2] 1 *-* o = .Clz~new
   [T2 I3 G   A1 L0] >I> Method "INIT" with scope "CLZ"
   [T2 I3 G   A1 L1 *  ]   8 *-* expose a   -- exclusive access
   [T2 I3 G   A1 L1 *  ]   9 *-* a = 0
   [T2 I3 G   A1 L1 *  ] >>>   "0"
   [T2 I3 G   A1 L1 *  ]  10 *-* reply
   [T2 I3 G   A1 L1 *  ] >>   "a CLZ"
   [T2 I2] 2 *-* call syssleep 0.5
   [T3 I3 G   A1 L1 *  ] >I> Method "INIT" with scope "CLZ"
   [T3 I3 G   A1 L1 *  ]  11 *-*guard off -- now no deadlock anymore !?!
   [T3 I3 G u A1 L0]  12 *-* self~m1-- now unguarded
   [T3 I4 G   A1 L0] >I> Method "M1" with scope "CLZ"
   [T3 I4 G   A1 L1 *  ]  15 *-* expose a   -- exclusive access
   [T3 I4 G   A1 L1 *  ]  16 *-* a = 1
   [T3 I4 G   A1 L1 *  ] >>>   "1"
   [T3 I4 G   A1 L1 *  ]  17 *-*guard off   -- unguard m1 method
   [T3 I4 G u A1 L0]  18 *-* say "m1 method: unguarded"
   [T3 I4 G u A1 L0] >>>   "m1 method: unguarded"
   [T3 I4 G u A1 L0]  19 *-* guard on when a <> 1
   [T3 I4 G u A1 L1 * W] >K>   "WHEN" => "0"
   [T2 I2]   >>>   "0"
   [T2 I2] 3 *-* o~m2 -- wake-up m1
   [T2 I5 G   A1 L0] >I> Method "M2" with scope "CLZ"
   [T2 I5 G   A1 L1 *  ]  23 *-* expose a   -- exclusive access
   [T2 I5 G   A1 L1 *  ]  24 *-* a = 2  -- change attribute
   [T2 I5 G   A1 L1 *  ] >>>   "2"
   [T2 I5 G   A1 L0] >>   "done."
   [T3 I4 G u A1 L1 *  ] >K>   "WHEN" => "1"
   [T3 I4 G   A1 L1 *  ]  20 *-* say "m1 method: guarded"
   [T3 I4 G   A1 L1 *  ] >>>   "m1 method: guarded"
   [T2 I2]   Again, the question whether this behaviour is due to a bug in ooRexx or whether there is a rule that 
explains this behaviour?


Why should releasing the guard lock before invoking method M1 solve the deadlock when entering later 
method M2 from a routine context?


Or with yet other words: releasing the guard lock in method M1 using "guard off" should allow method 
M2 later to acquire it no matter from where it gets invoked?


---rony


On 05.07.2024 16:38, Rony G. Flatscher wrote:


A question related to the following simple program which Jean Louis has come up with (cf. 
<https://github.com/jlfaucher/executor/blob/master/sandbox/jlf/samples/concurrency/deadlock1.rex>) 
some time ago and which I edited a little bit to ease reading the trace lines:


  1 o = .Clz ~new
  2 call syssleep 0.5
  3 o~m2 −− wake −up m1
  4 say " done . "
  5
  6 ::class Clz
  7 ::method init −− guarded method
  8expose a −− exclusive access
  9a = 0
10reply
11
12self~m1 −− still guarded
13
14 ::method m1 −− guarded method
15expose a −− exclusive access
16a = 1
17guard off −− unguard m1 method
18say "m1 method : unguarded "
19guard on when a <> 1
20say "m1 method : guarded "
21
22 ::method m2 −− guarded method
23expose a −− exclusive access
24a = 2 −− change attribute

Running the above program will end in a deadlock.

Using another program that collects the trace objects employing "::options trace results" while 
running the above program on a different thread (thereby not getting deadlocked itself) and 
afterwords annotating the trace log objects created while running the above program in the 
following manner: if the current guard state differs from the defined one the effective guard 
state is shown in lowercase letters ('u') in the extended bracketed prefix, if an instruction is 
waiting (e.g. on the gaurd lock) then it gets marked with a "W"

[Oorexx-devel] A question about the blocking of a particular method

2024-07-05 Thread Rony G. Flatscher

A question related to the following simple program which Jean Louis has come up with (cf. 
) 
some time ago and which I edited a little bit to ease reading the trace lines:


 1 o = .Clz ~new
 2 call syssleep 0.5
 3 o~m2 −− wake −up m1
 4 say " done . "
 5
 6 ::class Clz
 7 ::method init −− guarded method
 8expose a −− exclusive access
 9a = 0
   10reply
   11
   12self~m1 −− still guarded
   13
   14 ::method m1 −− guarded method
   15expose a −− exclusive access
   16a = 1
   17guard off −− unguard m1 method
   18say "m1 method : unguarded "
   19guard on when a <> 1
   20say "m1 method : guarded "
   21
   22 ::method m2 −− guarded method
   23expose a −− exclusive access
   24a = 2 −− change attribute

Running the above program will end in a deadlock.

Using another program that collects the trace objects employing "::options trace results" while 
running the above program on a different thread (thereby not getting deadlocked itself) and 
afterwords annotating the trace log objects created while running the above program in the following 
manner: if the current guard state differs from the defined one the effective guard state is shown 
in lowercase letters ('u') in the extended bracketed prefix, if an instruction is waiting (e.g. on 
the gaurd lock) then it gets marked with a "W" right before the closing bracket; then the following 
trace lines using a customized makeString method reflect all this information:


   [T2 I2]   >I> Routine "deadlock.rex"
   [T2 I2] 1 *-* o = .Clz~new
   [T2 I3 G   A1 L0] >I> Method "INIT" with scope "CLZ"
   [T2 I3 G   A1 L1 *  ]   8 *-* expose a   -- exclusive access
   [T2 I3 G   A1 L1 *  ]   9 *-* a = 0
   [T2 I3 G   A1 L1 *  ] >>>   "0"
   [T2 I3 G   A1 L1 *  ]  10 *-* reply
   [T2 I3 G   A1 L1 *  ] >>   "a CLZ"
   [T2 I2] 2 *-* call syssleep 0.5
   [T3 I3 G   A1 L1 *  ] >I> Method "INIT" with scope "CLZ"
   [T3 I3 G   A1 L1 *  ]  12 *-* self~m1-- still guarded
   [T3 I4 G   A1 L1] >I> Method "M1" with scope "CLZ"
   [T3 I4 G   A1 L2 *  ]  15 *-* expose a   -- exclusive access
   [T3 I4 G   A1 L2 *  ]  16 *-* a = 1
   [T3 I4 G   A1 L2 *  ] >>>   "1"
   [T3 I4 G   A1 L2 *  ]  17 *-* guard off  -- unguard m1 method
   [T3 I4 G u A1 L1]  18 *-* say "m1 method: unguarded"
   [T3 I4 G u A1 L1] >>>   "m1 method: unguarded"
   [T3 I4 G u A1 L1]  19 *-* guard on when a <> 1
   [T3 I4 G u A1 L2 * W] >K>   "WHEN" => "0"
   [T2 I2]   >>>   "0"
   [T2 I2] 3 *-* o~m2 -- wake-up m1
   [T2 I5 G   A1 L1   W] >I> Method "M2" with scope "CLZ"

The prolog code in I2 on T2 creates an instance of CLZ (line # 1) which causes an invocation I3 on 
T2 entering the INIT method which acquires the guard lock. The reply keyword statement in line # 10 
causes the return from that invocation and the remaining INIT instructions of invocation I3 get 
dispatched on a new thread T3. Sending the M1 message to the newly created object is carried out in 
I4, the method M1 gets successfully the guard lock, releasing it thereafter in line # 17 with the 
"guard off" keyword statement.


At that point I3 is waiting on the "self~m1" message to return, I4 is continuing unguarded. The 
"guard on when a <> 1" statement in line # 19 causes the condition "a <> 1" to be evaluated after 
gaining the guard lock (see the trace with the prefix >K>) but does not turn .true in this case. So 
the guard lock for I4 should be released again (does this happen?).


As long as the attribute "a" in the condition is not changed by a method running on another thread, 
the WHEN condition does not get re-evaluated.


In order to change the attribute "a" in I2 on T2 (line # 3) the message M2 gets sent to the newly 
created object causing a new invocation I5 in which method M2 (line # 22) gets entered. It seems 
that M2 is not able to acquire the guard lock as it gets blocked at that point in time and the 
program gets deadlocked.


Is this to be expected? If so, why, what is the rule for this?

---

Adding a "guard off" in line # 11 in I3 on T3 right *before* the statement "self~m1" makes it 
possible for method M2 way later in I5 on T2 to acquire the guard lock! This then enables I5 on T2 
to execute "a = 2", hence changing the value of attribute "a" such that the next time the WHEN 
condition in line # 19 gets re-evaluated in I4 on T3 will turn .true allowing method M1 in I4 on T3 
to conclude. As a result all threads conclude and the program can end without a deadlock.


Why is it, that that change makes this program run successfully to the end?

---rony

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

[Oorexx-devel] A question ad trace settings, turning more specific traces on and off at runtime

2024-06-25 Thread Rony G. Flatscher

For debugging especially with debuggers it would helpful (and maybe sometimes even important 
especially with respect to performance, system load) to become able to, e.g.


 * trace only variables (maybe being able to distinguish between 
using/referring to variables and
   variable assignments)
 * turn off and turn on package wide tracing (currently only ::options trace x 
possible) at runtime

Would that be possible? If so, what would be necessary to do and what problems 
need to be tackled?

---rony

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

[Oorexx-devel] Done (Re: A suggestion for enhancing the trace object.

2024-06-25 Thread Rony G. Flatscher


On 25.06.2024 10:45, Rony G. Flatscher wrote:

On 24.06.2024 20:08, Rony G Flatscher wrote:

OK, this is what I would come up with:

- entry RECEIVER if tracing a method
- entrie VARNAME, VARVALUE and VARASSIGNMENT (.true or .false) if tracing variable access 
including attribute access


the variable related entry should probably be a single entry in TraceObject using VARIABLE as a 
name, and the information about its name, value and whether it is an assignment should be in a 
StringTable.


Just for the record, in RexxActivation::traceTaggedValue(...): TRACE_PREFIX_VARIABLE is supplied 
when referring to variables (i.e. fetching their value). In order to get changes to variables one 
needs to process TRACE_PREFIX_ASSIGNMENT in addition.


---

Implemented with [r12845] (code), [r12846] (tests), [r12847] (documentation).

---rony



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

[Oorexx-devel] New "oorexx-packages" available for download

2024-06-21 Thread Rony G. Flatscher

In the past days, weeks further work was invested into "oorexx-packages" (thanks to Jean Louis and 
Josep Maria) and today a new version has been made available which got another ooRexx package added 
to it (the log4rexx package modeled after Apache's log4j).


The "oorexx-packages" zip archives at  include 
the 64-bit portable versions of ooRexx for Windows, MacOS (ARM and x86_64) and Linux, each enhanced 
with Jean Louis' "oorexxshell" and additional ooRexx related packages like bsf4oorexx (Java bindings 
for ooRexx, so you need to have Java in order to take advantage of it).


This allows anyone interested in ooRexx and oorexxshell to download it, unzip it, run setupoorexx 
and then immediately check it out without a need to deinstall any existing Rexx interpreter.


Here the content of readme_oorexx-packages.txt 
:


   "ooRexx packages with oorexxshell" (oorexx-packages)
    This is the readme file for 
"oorexxshell",
   an enhanced ooRexx shell that gives immediate access to a number of Rexx 
packages, like:    
   - bsf4oorexx (ooRexx-Java bridge), which includes a powerful Java2D  
 command handler
   named JDOR (Java2D for ooRexx), see samples and   synopsis of the 
JDOR Rexx commands in
  packages\bsf4oorexx\doc\jdor\jdor_doc.html     - dbus4oorexx 
(ooRexx-DBus bridge
   for Linux)     - log4rexx (logging for ooRexx)     - pipelines (a 
CMS-like pipeline
   implementation)     - procedural (implementation of some of Executor's 
extended methods)
    - profiling (profile Rexx programs)     - regex (powerful 
regular expression
   implementation)     - rgf_util2 (utilities for ooRexx, e.g. caseless 
BIFs, easy sorting)
    - utilities (indentable stream) Directions in a nutshell 

    - download the latest "ooRexx packages with oorexxshell"   
(oorexx-packages)
   zip archive from https://wi.wu.ac.at/rgf/rexx/tmp/oorexx-packages/     - 
UNBLOCK it before
   unzipping (see notes below)     - unzip the archive     - change 
into the unzipped
   directory and enter   Windows   Unix 
  Comment  
   ---      +--   
setupoorexx.cmd  
   ./setupoorexx.sh   | create tailored scripts   
setenv2rxenv.cmd  source
   ./setenv2rxenv.sh   | set environment   oorexxshell   
oorexxshell   
   | run oorexxshell Additional information -- To learn 
about the functionality
   of oorexxshell, take a few minutes and see the asciinema demos at [4]. First 
feedback
   --  - "install this bundle, you run a small, trivial setup 
program, and, poof,   
   you have immediate access to a real trove of packages -- no additional    
installation needed"
   (JMB)  - "I even was able to load the JDOR handler, then "address JDOR", 
and then   
   construct one of the JDOR samples step-by-step, by manually writing the    
(quoted) JDOR
   commands.  This is very impressive, and very useful too,    from a 
pedagogical point of view,
   since it provides immediate incremental    visual feedback for the JDOR 
commands.  You just have
   to move the Java    window besides the command window and you have a fantastic 
experience."   
   (JMB) 
--- 
NOTES
   - --- NOTE # 1: Microsoft and Apple 
do not allow
   programs from the Internet to run   if they are not signed using 
their fee-based service
   citing "security   reasons".   Therefore, before installing or 
unzipping open source
   projects you need   to remove the respective attributes.   Windows: 
after downloading,
   open with a right-mouse click the property    menu, mark the 
"unblock" check mark
   and click "apply".    Thereafter you can install or unzip the 
file. Or open a
   command line window and run (change 'filename' to the name 
of    the
   downloaded file):     powershell Unblock-File filename   
   e.g.,
    powershell Unblock-File 
oorexx-5.1.0-12838.windows.x86_64-portable-release.zip
  macOS: after downloading, open a Terminal window and run "xattr 
filename"  to
   see the extended attributes of the downloaded file (replace  
'filename' with the
   name of the zip archive), then issue  (again,  change 'filename' 
to the name of the
   downloaded file):     xattr -d com.apple.quarantine filename 
 e.g.,
    xattr -d com.apple.quarantine
   oorexx-5.1.0-12838.macos.arm

Re: [Oorexx-devel] A suggestion for enhancing the trace object.

2024-06-18 Thread Rony G. Flatscher

On 18.06.2024 11:35, Rick McGuire wrote:
All of the trace entries that format a value into the message pass through 
RexxActivation::traceTaggedValue(), which then calls RexxActivation::traceOutput(), where the 
trace object is created. Just pass the name and value along to traceOutput() as arguments and set 
them as properties in the TraceObject if they're non-null.

Thank you for this information! Will take a little while for me to turn to it (unfortunately, I have 
a couple of urgent work related duties that I need to address in the next days, only thing possible 
at the moment is to check and briefly communicate via e-mail).

---rony

On Tue, Jun 18, 2024 at 5:30 AM Rony G. Flatscher  
wrote:

On 18.06.2024 02:09, Rick McGuire wrote:
> Dom's debugger has me thinking there should be some additional 
information added to the trace
> object. One thing that would be quite useful for a debugger would be a 
property that
provides the
> raw object that is included in the trace message.
Do you mean the receiver/target object in case of a traced message?
> Another thing that would be useful would be the name of the variable 
being assigned or
referenced.
> This would make it easy, for example, to implement variable modification 
breakpoints in the
debugger.

How would one go about implementing this efficiently (would not be able to 
implement this by
myself,
hence the question)? If you could supply such an implementation or a sketch 
thereof that would be
really very helpful!

---rony

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

Re: [Oorexx-devel] Crash with ooRexx debugger in r12844 (latest trunk)

2024-06-18 Thread Rony G. Flatscher


On 17.06.2024 15:30, Rony G. Flatscher wrote:


As reported on the RexxLA mailing list, running the ooRexx debugger crashes ooRexx. It does not 
matter whether the ooDialog or the BSF4ooRexx850 version gets used:



... cut ...

Dom Wise reported on the RexxLA.org mailing list that he found the reason and fixed it in 
<https://github.com/DomJWise/ooRexxDebugger/releases/tag/v1.250>.


---rony



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

Re: [Oorexx-devel] A suggestion for enhancing the trace object.

2024-06-18 Thread Rony G. Flatscher


On 18.06.2024 02:09, Rick McGuire wrote:
Dom's debugger has me thinking there should be some additional information added to the trace 
object. One thing that would be quite useful for a debugger would be a property that provides the 
raw object that is included in the trace message.

Do you mean the receiver/target object in case of a traced message?
Another thing that would be useful would be the name of the variable being assigned or referenced. 
This would make it easy, for example, to implement variable modification breakpoints in the debugger.


How would one go about implementing this efficiently (would not be able to implement this by myself, 
hence the question)? If you could supply such an implementation or a sketch thereof that would be 
really very helpful!


---rony




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

[Oorexx-devel] Crash with ooRexx debugger in r12844 (latest trunk)

2024-06-17 Thread Rony G. Flatscher

As reported on the RexxLA mailing list, running the ooRexx debugger crashes ooRexx. It does not 
matter whether the ooDialog or the BSF4ooRexx850 version gets used:


 * Locals shows "this" to be NULL
 * the exception occurs in StringClass.hpp, inline HashCode getStringHash(), 
line # 318
 * Threads (in the ooDialog case):

   Not Flagged  15436   0   Worker Thread   
ntdll.dll!TppWorkerThread   ntdll.dll!NtWaitForWorkViaWorkerFactory Normal
   Not Flagged  >52840   Main Thread Main Thread 
rexx.dll!RexxString::getStringHash  Normal
   Not Flagged  28300   0   Worker Thread   
ntdll.dll!TppWorkerThread   ntdll.dll!NtWaitForWorkViaWorkerFactory Normal
   Not Flagged  29216   0   Worker Thread   
ntdll.dll!TppWorkerThread   ntdll.dll!NtWaitForWorkViaWorkerFactory Normal
   Not Flagged  28036   0   Worker Thread   
ntdll.dll!TppWorkerThread   ntdll.dll!NtWaitForWorkViaWorkerFactory Normal
   Not Flagged  25236   0   Worker Thread   
rexx.dll!dispatch_activity_function()  
win32u.dll!NtUserMsgWaitForMultipleObjectsExNormal
   Not Flagged  40400   Worker Thread   
rexx.dll!dispatch_activity_function()  
win32u.dll!NtUserMsgWaitForMultipleObjectsExNormal
   Not Flagged  15088   0   Worker Thread   
oodialog.dll!WindowUsrLoopThread() win32u.dll!NtUserGetMessage Above 
Normal
   Not Flagged  24984   0   Worker Thread   
combase.dll!CRpcThreadCache::RpcWorkerThreadEntry   
combase.dll!WaitCoalesced   Normal
   Not Flagged  86760   Worker Thread   
ntdll.dll!TppWorkerThread   ntdll.dll!NtWaitForWorkViaWorkerFactory Normal
   Not Flagged  27912   0   Worker Thread   ANSI64.dll thread   
ANSI64.dll!5e3f2390 Normal

 * Call Stack (same in both cases):

   > rexx.dll!RexxString::getStringHash() Line 318   C++
rexx.dll!StringHashContents::hashIndex(RexxInternalObject * 
index=0x) Line 496  C++
rexx.dll!HashContents::put(RexxInternalObject * 
value=0x021e975486d0, RexxInternalObject * index=0x) Line 
232   C++
rexx.dll!VariableDictionary::addVariable(RexxString * 
name=0x, RexxVariable * variable=0x021e975486d0) Line 463   
  C++
rexx.dll!RexxLocalVariables::createDictionary() Line 601C++
rexx.dll!RexxLocalVariables::getDictionary() Line 114   C++
rexx.dll!RexxActivation::getLocalVariables() Line 465   C++
rexx.dll!RexxActivation::getAllLocalVariables() Line 469C++
rexx.dll!RexxContext::getVariables() Line 213   C++
rexx.dll!CPPCode::run(Activity * activity=0x021e97507eb0, MethodClass * 
method=0x021e9740b740, RexxObject * receiver=0x021e97cfd2a0, RexxString * 
messageName=0x021e97d65c60, RexxObject * * argPtr=0x021e98110238, unsigned 
__int64 count=0, ProtectedObject & result={...}) Line 170  C++
rexx.dll!MethodClass::run(Activity * activity=0x021e97507eb0, 
RexxObject * receiver=0x021e97cfd2a0, RexxString * msgname=0x021e97d65c60, 
RexxObject * * argPtr=0x021e98110238, unsigned __int64 count=0, ProtectedObject 
& result={...}) Line 172   C++
rexx.dll!RexxObject::messageSend(RexxString * msgname=0x021e97d65c60, 
RexxObject * * arguments=0x021e98110238, unsigned __int64 count=0, 
ProtectedObject & result={...}) Line 901   C++
rexx.dll!ExpressionStack::send(RexxString * message=0x021e97d65c60, 
unsigned __int64 count=0, ProtectedObject & result={...}) Line 80   C++
rexx.dll!RexxExpressionMessage::evaluate(RexxActivation * 
context=0x021e980f5920, ExpressionStack * stack=0x021e980f5a88) Line 
191  C++
rexx.dll!RexxInstruction::evaluateArguments(RexxActivation * 
context=0x021e980f5920, ExpressionStack * stack=0x021e980f5a88, 
RexxInternalObject * * argArray=0x021e97daf1b0, unsigned __int64 
argCount=1) Line 154  C++
rexx.dll!RexxInstructionMessage::execute(RexxActivation * 
context=0x021e980f5920, ExpressionStack * stack=0x021e980f5a88) Line 
183  C++
rexx.dll!RexxActivation::run(RexxObject * _receiver=0x, 
RexxString * name=0x021e9750e030, RexxObject * * _arglist=0x, 
unsigned __int64 _argcount=0, RexxInstruction * start=0x, 
ProtectedObject & resultObj={...}) Line 611 C++
rexx.dll!RexxActivation::debugInterpret(RexxString * 
codestring=0x021e975486d0) Line 2758   C++
rexx.dll!RexxActivation::doDebugPause() Line 4231   C++
rexx.dll!RexxActivation::pauseInstruction() Line 377C++
rexx.dll!RexxInstructionCall::execute(RexxActivation * 
context=0x021e97df08e0, ExpressionStack * stack=0x021e97df0a48) Line 
212 C++
rexx.dll!RexxActivation::run(RexxObject * _receiver=0x, 
RexxString * name=0x021e9750e03

[Oorexx-devel] A question ad reported bug "#1951 Additional condition filtering too restrictive"

2024-06-17 Thread Rony G. Flatscher

 demonstrates the replacement of non-printable 
characters with question marks when displaying in an error message distorting the message.


A question in this context: if inhibiting the replacement operation when reporting errors, could 
there be any serious problems to be expected? If so, what could they be?


If there are no real problems to be expected I would be in favor of removing the replacement 
process, if possible. It makes the BSF4ooRexx error messages legible (that is the purpose of using 
line feeds in the error text) and it will allow displaying UTF-8 characters in the terminal if set 
to Unicode as gets stressed in #1951.


---rony






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

Re: [Oorexx-devel] How about adding class methods arrayIn and arrayOut on the Stream class ?

2024-06-16 Thread Rony G. Flatscher


On 16.06.2024 02:02, Rick McGuire wrote:

Um,

a = .stream~new(filename)~arrayin

is a one liner that reads into an array.


Yes, that is the beauty of cascading messages! However, the file needs to be closed (e.g. if one 
wishes to replace it later) which is not possible in the same line, rather another statement needs 
to be issued to close the stream, actually for closing the stream one needs a variable to store the 
stream temporarily, hence two more statements:


    s=.stream~new(filename)
a=s~arrayin
s~close

... some other code in between ...

.stream~new(filename)~~open("replace")~~arrayout(a)~close

With the suggested class methods it would become possible to do instead:

   a=.stream~arrayin(filename)

   ... some other code in between ...

   .stream~arrayout(filename,a)

which is much simpler, shorter, hence easier to code, easier to comprehend and as a result less 
error prone.


---rony




On Sat, Jun 15, 2024 at 7:50 PM Gilbert Barmwater  wrote:

First let me offer the following way to write the contents of an array to a 
stream that only
requires a single  line:

.stream~new(streamFileName)~~arrayOut(arr [,Lines|Chars])~close

Unfortunately, there is no corresponding "one-liner" for reading the 
contents of a stream into
an array.  This lack of "symmetry" has always bothered me and I have 
experimented over the
years with possible solutions.  Not too long ago I was able to devise a way 
to finally
accomplish it.

Before I reveal it, let me note that the above comments are equally 
applicable to
charOut/charIn and lineOut/lineIn should one wish to deal with character(s) 
or a single line
of output/input.

My solution is to add additional instance methods to the .stream class 
named arrayInto,
charInto and lineInto.  The difference between them and the similar *In 
methods is that the
first argument is a variable reference followed by the "standard" *In 
arguments.  These
methods perform the operation of the related *In method and then assign the 
data - array,
character(s) or line - to the value of the variable reference.  So the 
corresponding
"one-liner" for reading the contents of a stream into an array is:

.stream~new(streamFileName)~~arrayInto(>arr, [Lines|Chars] )~close

But, you might say, ooRexx doesn't allow you to "add" methods to the 
pre-defined classes like
.stream.  That is not strictly true and there are several ways around that. 
I had planned to
talk about that as part of a planned presentation at the Vienna Symposium 
next May but, since
the subject has come up now, it looks like I will need to reveal it ahead 
of time.

On a more general, philosophical note, I prefer to find solutions that do 
NOT require adding
classes, methods, or functions to the base ooRexx but that can be included 
with a ::requires
statement, similar to the way that, e.g. RxMath functions are handled.  I 
guess that goes back
to the original Rexx idea of keeping the language small but is also 
consistent with how other
languages provide "libraries" of added functionality.

If anyone is interested in the implementation of the arryInto method, I 
will post it here and,
if not, will discuss it during the Symposium.

Gil

On 6/15/2024 2:38 PM, Rony G. Flatscher wrote:


The Stream class has the handy instance methods arrayIn and arrayOut.

To read the content of a stream into an array the following statements are 
necessary:

s=.stream~new(streamFileName)
s~open( [read|both] )
arr=s~arrayIn( [Lines|Chars] )
s~close

To write the content of an array into a  stream the following statements 
are necessary:

s=.stream~new(streamFileName)
s~open( [write | both  [append|replace]] )
s~arrayOut(arr [,Lines|Chars])
s~close

---

It would be very handy, if the Stream class also offered as class methods 
arrayIn and
arrayOut that would allow one single statement to read from any stream 
(file) into an array
or to write an array to any stream (file).

class method arrayIn:

arr=.stream~arrayIn( streamFileName [,Lines|Chars] ) -- default: Lines

and

class method arrayOut:

.stream~arrayOut(streamFileName , arr [,append|replace] [,Lines|Chars] 
)  -- default: append, Lines

What do you think?

Would you see any problems and if so which ones?

---rony

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

Re: [Oorexx-devel] How about adding class methods arrayIn and arrayOut on the Stream class ?

2024-06-16 Thread Rony G. Flatscher


On 16.06.2024 01:49, Gilbert Barmwater wrote:


First let me offer the following way to write the contents of an array to a stream that only 
requires a single  line:


.stream~new(streamFileName)~~arrayOut(arr [,Lines|Chars])~close

Unfortunately, there is no corresponding "one-liner" for reading the contents of a stream into an 
array.  This lack of "symmetry" has always bothered me and I have experimented over the years with 
possible solutions.  Not too long ago I was able to devise a way to finally accomplish it.


Before I reveal it, let me note that the above comments are equally applicable to charOut/charIn 
and lineOut/lineIn should one wish to deal with character(s) or a single line of output/input.


My solution is to add additional instance methods to the .stream class named arrayInto, charInto 
and lineInto.  The difference between them and the similar *In methods is that the first argument 
is a variable reference followed by the "standard" *In arguments.  These methods perform the 
operation of the related *In method and then assign the data - array, character(s) or line - to 
the value of the variable reference. So the corresponding "one-liner" for reading the contents of 
a stream into an array is:


.stream~new(streamFileName)~~arrayInto(>arr, [Lines|Chars] )~close

But, you might say, ooRexx doesn't allow you to "add" methods to the pre-defined classes like 
.stream.  That is not strictly true and there are several ways around that.  I had planned to talk 
about that as part of a planned presentation at the Vienna Symposium next May but, since the 
subject has come up now, it looks like I will need to reveal it ahead of time.


That may be helpful for other situations as well! How about revealing it here and talking about it 
on wider audience and forum at the symposium? The symposium slides (and articles) are being made 
public via the RexxLA symposium page and thereby making your work (world-)widely available.


On a more general, philosophical note, I prefer to find solutions that do NOT require adding 
classes, methods, or functions to the base ooRexx but that can be included with a ::requires 
statement, similar to the way that, e.g. RxMath functions are handled.  I guess that goes back to 
the original Rexx idea of keeping the language small but is also consistent with how other 
languages provide "libraries" of added functionality.



In principle I agree of "keeping the language small and easy".

Over the course of time it has turned out that reading the content from a file into an array and 
writing a file from an array has become more and more helpful.


Hence the motivation of allowing for using a single statement to read into an array from and to 
write from an array to a file. It is about folding four statements into a single one.


If anyone is interested in the implementation of the arryInto method, I will post it here and, if 
not, will discuss it during the Symposium.



Just to be sure: *yes*, please! :)

---rony



On 6/15/2024 2:38 PM, Rony G. Flatscher wrote:


The Stream class has the handy instance methods arrayIn and arrayOut.

To read the content of a stream into an array the following statements are 
necessary:

s=.stream~new(streamFileName)
s~open( [read|both] )
arr=s~arrayIn( [Lines|Chars] )
s~close

To write the content of an array into a  stream the following statements are 
necessary:

s=.stream~new(streamFileName)
s~open( [write | both  [append|replace]] )
s~arrayOut(arr [,Lines|Chars])
s~close

---

It would be very handy, if the Stream class also offered as class methods arrayIn and arrayOut 
that would allow one single statement to read from any stream (file) into an array or to write an 
array to any stream (file).


class method arrayIn:

arr=.stream~arrayIn( streamFileName [,Lines|Chars] ) -- default: Lines

and

class method arrayOut:

.stream~arrayOut(streamFileName , arr [,append|replace] [,Lines|Chars] )  
-- default: append, Lines

What do you think?

Would you see any problems and if so which ones?

---rony

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

[Oorexx-devel] How about adding class methods arrayIn and arrayOut on the Stream class ?

2024-06-15 Thread Rony G. Flatscher


The Stream class has the handy instance methods arrayIn and arrayOut.

To read the content of a stream into an array the following statements are 
necessary:

   s=.stream~new(streamFileName)
   s~open( [read|both] )
   arr=s~arrayIn( [Lines|Chars] )
   s~close

To write the content of an array into a  stream the following statements are 
necessary:

   s=.stream~new(streamFileName)
   s~open( [write | both  [append|replace]] )
   s~arrayOut(arr [,Lines|Chars])
   s~close

---

It would be very handy, if the Stream class also offered as class methods arrayIn and arrayOut that 
would allow one single statement to read from any stream (file) into an array or to write an array 
to any stream (file).


   class method arrayIn:

   arr=.stream~arrayIn( streamFileName [,Lines|Chars] ) -- default: Lines

and

   class method arrayOut:

   .stream~arrayOut(streamFileName , arr [,append|replace] [,Lines|Chars] )  -- 
default: append, Lines

What do you think?

Would you see any problems and if so which ones?

---rony

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

[Oorexx-devel] macOS ARM version not creating ?

2024-06-01 Thread Rony G. Flatscher


Hi P.O.,

just noticed that ooRexx for macOS ARM has not been created.

It seems that Mark's box has been hanging/waiting since a few days for downloading jar files. Not 
knowing how to get over that point requesting your help for getting it going again! :)


Best regards

---rony




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

Re: [Oorexx-devel] Clarification on .package~new

2024-06-01 Thread Rony G. Flatscher


On 31.05.2024 20:29, Gilbert Barmwater wrote:
I've been experimenting with the .package class and have run into somewhat puzzling behavior.  I 
am trying to create a .package object from a file which, according to the documentation, should 
look like this:


thePkg=.package~new(fileName)

When I do this I DO get a package in thePkg, BUT the package also gets loaded(executed) as if I 
had issued a

.context~package~loadPackage(fileName).

The docs do not indicate that this is to be expected.  Help!


If you do not want the prolog to be executed you can use "::options noprolog". Then later, whenever 
you want it to be executed you could issue "thePkg~prolog~call" or "thePkg~prolog~callWith(...)".


---rony




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

[Oorexx-devel] Foregoing the "runtime" portable zip archive ?

2024-05-30 Thread Rony G. Flatscher

A while ago, I think P.O. suggested to not produce the "runtime" versions of the portable zip 
archives as having two zip archives per system may be confusing potential users (which version to 
download)?


Indeed, having a single zip-archive per system would simplify things and if someone wanted, he or 
she could create the "runtime" version by simply removing the contained "samples" and "doc" 
directories.


Is there anyone who would object to not produce the "runtime" portable zip 
archives anymore?

---rony




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

Re: [Oorexx-devel] Trace ?a and "

2024-05-30 Thread Rony G. Flatscher


Hi Jeremy,

a few minutes ago I committed Jean Louis' patch #5 ("retro-trace") to trunk such that the next 
ooRexx installation and portable packages will include RFE 835 for testing such that you can get 
your hands on it.


The test script I used to test it:

   .context~package~local~traceOption="A"

   call he
   call ho
   say

   t=.test~new
   t~~he~~ho~~ha~~hi


   ::routine he
  say .context~name", line #" .line
  say

   ::routine ho
  trace (.traceOption) -- trace l
  say .context~name", line #" .line  "(trace l)"
  say


   ::class test
   ::method he
  say .context~name", line #" .line
  say

   ::method ho
  trace (.traceOption) -- trace l
  say .context~name", line #" .line  "(trace l)"
  say

   ::method ha
  expose abc
  say .context~name", line #" .line
  say

   ::method hi
  expose abc
  trace (.traceOption) -- trace l
  say .context~name", line #" .line  "(trace l after expose)"
  say

ooRexx being a dynamic and a very versatile language allows for many variations. In this case the 
package's (= program's) local directory gets the trace option assigned with the index name 
traceOption such that using the environment symbol .traceOption will retrieve that value which then 
gets used to define the trace type. Just changing "A" at the top to "N" would turn off tracing.


Such a solution would allow one to pick the routines and methods individually that get traced and 
the trace option to use can be defined centrally, in this case only affecting the routines and 
methods of the little test program.


---

The location to download the new version [r12839] for testing is eventually at 
.


HTH,

---rony


On 30.05.2024 10:58, Jeremy Nicoll wrote:

IIUC the idea is that a "trace" statement that turns on label-tracing
could be the first executable instruction in a method/routine, & could
generate that routine's invocation trace (even though strictly speaking
the invocation has already happened).

If the method/routine doesn't use "expose" then we might have eg

::method ...
if something_or_other then trace i

and if it does use expose then eg:

::method ...
expose this that other
if something_or_other then trace i


Jean Louis Faucher suggested that, to allow a passed parameter to turn
on such tracing one could use something like

::method ...
trace value (arg(3) == .true)~?("i", "o”)

use strict arg arg1, arg2, trace=.false
...

or:

::method ...
expose this that other
trace value (arg(3) == .true)~?("i", "o”)

use strict arg arg1, arg2, trace=.false
...


Somthing like that seems to me to be "un-REXX-ish" - far from intuitive,
and also quite likely accidentally not to be updated if/when someone
changes the way parameters are passed & suddenly it's no longer arg 3
that is significant.

It's a pity to have a named argument in the "use" statement and then
not be able to use that name, to get the invocation trace to occur.


Also, would a "trace o" turn off whatever package-wide tracing options
the user might have set up (& want) via "::options trace"?



Would it be so terrible not to have this convoluted approach and simply
have the logic that responds to "trace i" etc test whether invocation
was already traced, and if not, generate a line like

"   >I> Method .myClass~myMethod (implied)"


OK, it wouldn't be in /precisely/ the right place in the trace output,
but since probably most people would still have their trace logic very
close to the start of a method/routine, it wouldn't be far off.

Documentation could explain why this was an /implied/ invocation.


And then people COULD refer to their named arguments.  So eg

::method ...
use strict arg arg1, arg2, traceint=.false, tracecmd=.false
if traceint then trace i
if tracecmd then trace c
...

or:

::method ...
expose this that other
use strict arg arg1, arg2, traceint=.false, tracecmd=.false
if traceint then trace i
if tracecmd then trace c
...
   
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad RFE 835 ("retro-trace")

2024-05-30 Thread Rony G. Flatscher


Committed with [r12839].

---rony


On 29.05.2024 18:21, Jean Louis Faucher wrote:



On 29 May 2024, at 18:00, Rony G. Flatscher  wrote:


Planning on committing the latest patch (v4) to trunk such that others (like Dom) become 
able to further test this "retro-trace" feature.


The patch v4 is still a debug patch.
I will attach a v5 which will not contain the debug code.
In particular, Token.cpp and Token.hpp will not be impacted.

This patch doesn’t address the RFE 836 opened by Dom.
A possible solution could be to detect the presence of
TRACE ?
using an ahead scan, as it’s done for:
- the detection of a procedure at the start of the code section (already in 
ooRexx5 code)
- the detection of an early trace entry (done in the patch)

The goal being to stop the debug mode before execution the EXPOSE instruction.
TRACE ? is a non dynamic instruction, so it’s easy to check if the debug switch 
is used.

The problem of this solution is that the TRACE instructions are ignored when in 
debug mode.
So this ahead scan would not respect this rule.
Just sharing my thoughts, not planning to put this in the patch for RFE 835.


Regards
Jean Louis






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

[Oorexx-devel] Ad RFE 835 ("retro-trace")

2024-05-29 Thread Rony G. Flatscher

Thanks to Jean Louis patch in RFE 835 (https://sourceforge.net/p/oorexx/feature-requests/835/) it 
has become possible to also get the invocation entry traceline if a programmer wishes.


Planning on committing the latest patch (v4) to trunk such that others (like Dom) become able to 
further test this "retro-trace" feature.


Any comments?

---rony




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

[Oorexx-devel] Test

2024-05-28 Thread Rony G Flatscher



Rony G. Flatscher (mobil/e)


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

Re: [Oorexx-devel] Trace ?a and "

2024-05-21 Thread Rony G. Flatscher

As TRACE is an important keyword statement it would be great if the people in this group would share
their thoughts!

---rony

On 18.05.2024 16:57, Josep Maria Blasco wrote:
The new multitasking tracing features introduce a new form of trace output with a "The documentation for this particular form of output (rexxref 2.29.5. /*CHG* The Format of Trace
Output/, pp. 84--5) says

/**A) As an interpreter bug*, "no "::OPTIONS TRACE" is in effect.

*B) As a documentation bug*, the documentation should be amended to indicate that "Trace a" does
also trigger this form of tracing.

I can see reasons to defend both A and B.

*In favour of A*, I would argue that the new features introduce unwanted and uncalled for forms of
tracing in contexts where the old behaviour of the Trace instruction would not produce them. I
would also argue that being able to trace "I>" for a particular routine introduces
an ugly assymmetry (I do understand why this assymetry does happen, but it is an assymetry anyway,
and avoidable assymetries are Bad Things). On the other hand, if one uses the ::OPTIONS TRACE
directive, then one gets both ">I>" and "">I>" before the new features were introduced, getting "the language, which only makes it more complete.

*In favour of B*, one could argue that the user can disable such output anyway (by inserting a
"Trace Off" before every exit point, for example), and that, since she has full control over the
feature, it does not make any sense to remove it.

Philosophically, the question amounts to the following: "Where does this form of "belong to?". If the answer to that question is "to the caller", then we should chose A. If the
answer is "to the callee", then we should chose B.

My personal impression is that A is the right choice, but I can not be completely sure. I have had
some private interchanges with Rony and we can't seem to reach a complete agreement.

What do you think?

Josep Maria

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

Re: [Oorexx-devel] Converting from old to new oorexx API

2024-05-12 Thread Rony G. Flatscher


On 12.05.2024 20:17, taf wrote:
Does anyone have documentation / advice / sample on how to convert from the 'old' rexx API set to 
the 'new' one?


the SAA-interface is totally different to the ooRexx C++ interface such that I do not know of such a 
documentation other than the ooRexx "rexxapi.pdf" book in the ooRexx documentation folder which you 
probably know anyway.


There are API samples coming with ooRexx that you are probably aware of, cf. 
"oorexx/samples/api/classic" and "oorexx/samples/api/c++" and the readme.txt-files there.


The same is probably true for  with the links 
 with its source and Makefile in 
 (note that on Windows AFAIK the 
def files like extsimple.def, extfunc.def or extmethod.def are not necessary anymore as ooRexx can 
locate RexxGetPackage without them). Also "rexxpg.pdf" has been renamed to "rexxapi.pdf" starting 
with ooRexx 5.0.0.


Not sure whether any of this is new or helps, but once you have a recipe it would be great if you 
could share it! :)


---rony







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

Re: [Oorexx-devel] StackFrame of INTERNALLCALL within a method missing target ?

2024-04-25 Thread Rony G. Flatscher


On 25.04.2024 12:46, Rick McGuire wrote:

That is correct. The stackframe is for an internal call, so it does not have a 
target object.


Would it be possible to make the method's context available in special cases like this? (In these 
cases the the StackFrame EXECUTABLE entry is a method object, but the important context information 
like the method's name used to invoke it and the target object of that method unfortunately is 
currently not available.)


Would it be possible to make e.g. the method's traceentry stackframe (in which the internal label is 
defined and gets called) in such an INTERNALCALL stackframe available? Maybe with a name like 
METHODCONTEXT in case it is an INTERNALCALL with an EXECUTABLE being a method, .nil else?


---rony




On Thu, Apr 25, 2024 at 6:27 AM Rony G. Flatscher  
wrote:

While experimenting and analyzing various traces I stumbled over the 
following: if calling a
label within a method the stackframes for the called internal routine miss 
the reference to
the method's TARGET object (and therefore to the method and scope), rather 
the TARGET entry is
set to .nil (which is fine for PROGRAM and ROUTINE).

Here an example program calling a label in the main program (prolog) and 
calling a label from
within a method:

-- test INTERNALCALL's stackframes trace off arr=.array~new 
.traceObject~collector=arr
.traceObject~option='F' say .context~name trace all sf1=hey() trace off 
say say
"stackframes:" say sf1 line="-"~copies(79) say line sf2=.test~new~oha 
say say
"stackframes:" say sf2 say line exit hey: return 
dumpStackFrames(.context~stackframes)
::class test ::method oha trace all return hey() trace off exit hey: 
return
dumpStackFrames(.context~stackframes) ::routine dumpStackFrames trace 
off use arg
stackframes mb=.MutableBuffer~new do counter c sf over stackFrames call 
dumpSF mb, c, sf
end return mb~string ::routine dumpSF trace off use strict arg mb, c, SF 
crlf="0d0a"x
tab="09"x target=sf~target mb~append("... stackFrame # ", c, ": ", - "line=", 
"[",sf~line,
"]", " name=", "[",sf~name, "]", crlf, - tab, "type=", "[",sf~type, "]", " 
target=",
"[",target~string, "] ", crlf, - tab, "executable~package~name=",
"[",sf~executable~package~name, "]", crlf, - tab, "traceline=", "[", 
sf~traceline, "]",
crlf, crlf) return ::routine pp trace off return "["arg(1)"]"

Running it yields the following output:

[R1   T1   I1   ] 9 *-* sf1=hey()
[R1   T1   I2   ]23 *-*   hey:
[R1   T1   I2   ]24 *-*   return 
dumpStackFrames(.context~stackframes)
[R1   T1   I1   ]10 *-* trace off

stackframes:
... stackFrame # 1: line=[24] name=[HEY]
 type=[INTERNALCALL] target=[The NIL object]
 
executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
 traceline=[24 *-*   return 
dumpStackFrames(.context~stackframes)]

... stackFrame # 2: line=[9] 
name=[G:\test\orx\trace\bug\test_stackframe.rex]
 type=[PROGRAM] target=[The NIL object]
 
executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
 traceline=[ 9 *-* sf1=hey()]



---
[R1   T1   I3G A1L1   *] 29 *-* return hey()
*[R1 T1 I4 G A2 L0 ] 33 *-* hey: [R1 T1 I4 G A2 L0 ] 34 *-* return
dumpStackFrames(.context~stackframes)*
[R1   T1   I3G A1L0]___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] StackFrame of INTERNALLCALL within a method missing target ?

2024-04-25 Thread Rony G. Flatscher

While experimenting and analyzing various traces I stumbled over the following: if calling a label 
within a method the stackframes for the called internal routine miss the reference to the method's 
TARGET object (and therefore to the method and scope), rather the TARGET entry is set to .nil (which 
is fine for PROGRAM and ROUTINE).


Here an example program calling a label in the main program (prolog) and calling a label from within 
a method:


   -- test INTERNALCALL's stackframes trace off arr=.array~new 
.traceObject~collector=arr
   .traceObject~option='F' say .context~name trace all sf1=hey() trace off say say 
"stackframes:"
   say sf1 line="-"~copies(79) say line sf2=.test~new~oha say say 
"stackframes:" say sf2 say line
   exit hey: return dumpStackFrames(.context~stackframes) ::class test ::method 
oha trace all
   return hey() trace off exit hey: return 
dumpStackFrames(.context~stackframes) ::routine
   dumpStackFrames trace off use arg stackframes mb=.MutableBuffer~new do 
counter c sf over
   stackFrames call dumpSF mb, c, sf end return mb~string ::routine dumpSF 
trace off use strict arg
   mb, c, SF crlf="0d0a"x tab="09"x target=sf~target mb~append("... stackFrame # ", c, 
": ", -
   "line=", "[",sf~line, "]", " name=", "[",sf~name, "]", crlf, - tab, "type=", "[",sf~type, 
"]", "
   target=", "[",target~string, "] ", crlf, - tab, "executable~package~name=",
   "[",sf~executable~package~name, "]", crlf, - tab, "traceline=", "[", sf~traceline, 
"]", crlf,
   crlf) return ::routine pp trace off return "["arg(1)"]"

Running it yields the following output:

   [R1   T1   I1   ] 9 *-* sf1=hey()
   [R1   T1   I2   ]23 *-*   hey:
   [R1   T1   I2   ]24 *-*   return 
dumpStackFrames(.context~stackframes)
   [R1   T1   I1   ]10 *-* trace off

   stackframes:
   ... stackFrame # 1: line=[24] name=[HEY]
type=[INTERNALCALL] target=[The NIL object]
executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
traceline=[24 *-*   return 
dumpStackFrames(.context~stackframes)]

   ... stackFrame # 2: line=[9] name=[G:\test\orx\trace\bug\test_stackframe.rex]
type=[PROGRAM] target=[The NIL object]
executable~package~name=[G:\test\orx\trace\bug\test_stackframe.rex]
traceline=[ 9 *-* sf1=hey()]


   
---
   [R1   T1   I3G A1L1   *] 29 *-* return hey()
   *[R1 T1 I4 G A2 L0 ] 33 *-* hey: [R1 T1 I4 G A2 L0 ] 34 *-* return
   dumpStackFrames(.context~stackframes)*
   [R1   T1   I3G A1L0]The call to the label "hey" within the method reveals in full format that the attributepool id gets 
changed from "A1" ("a TEST" target) to "A2" ("The NIL object").


Shouldn't the TARGET entry of called labels/internal routines within a method supply the reference 
to the context object ("a TEST") rather than .nil ("The NIL object")?


---rony

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

Re: [Oorexx-devel] Sandbox

On 22.04.2024 18:02, ooRexx wrote:

On 22. Apr 2024, at 16:54, Rony G. Flatscher wrote:

On 22.04.2024 15:24, ooRexx wrote:

... cut ...

AFAICT these are meant to initially match the release versions. In the case that minor changes
are applied to a released version and a minor release is intended, then the changes should go to
branches. Once a release gets created from branches the new release would carry the version 4.2.1
in your example.

Indeed. As I understand the release process in the past /branches/4,2/trunk is where working copy
for 4.2.0 resided. Once that was copied to /releases/4.2.0/trunk it was changed to be the working
copy for 4.2.1 and so on. This is not how it was done for 5.0.0, leading to all kinds of
complications.

AFAIR there were no complications because of that, there was a request/demand to create a branch for
5.0.0.

Compare to / branches/4.1 that served as the working copy for the release of
4.1.0 4.1.1 4.1.2 4.1.3

What I am asking is if we should not do it this way for 5.1.0, i.e. create a /branches/5.1/trunk
with the release candidate (when there is a release candidate...) and

Maybe a branch 5.1.0 should get created once the release process starts, representing the release
candidate. All the code, docs and tests from trunk should be there as well.

do the necessary documentation updates there and THEN move it to releases?

It depends what kind of documentation: the normal documentation for ooRexx should be already at the
state of the release (candidate).

Maybe creating the documentation without any beta in the release version should be created off it
there and maybe the release documentation like changes.txt and the like should be done there as
well. Is that would you mean?

... cut ...

But before creating the branch please consult the developer list a few days before that step, such
that work in progress for the release can be finalized and added to trunk, if necessary.

HTH

---rony

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

Re: [Oorexx-devel] Sandbox

On 22.04.2024 17:06, ooRexx wrote:

On 22. Apr 2024, at 16:54, Rony G. Flatscher wrote:

On 22.04.2024 15:24, ooRexx wrote:
is it ok to branch off and create folders in the Sandbox branch?

A "sandbox" is an area where experiments can be carried out. In the ooRexx project there are
subdirectories by the name of the developers, committers, such that one can use one own's
temporary subdirectories there to carry out the experiments.

Ok so I can set up something in /sandbox/PO for testing the Jenkins build modification automation
(switching from 5.1.0beta to 5.1.0 for ALL tasks in one go)

Yes, that would be possible.

Can they be deleted after a test? I wanted to make a 2nd short test for the next release.

There is quite a lot to add so I would prefer to delete it afterwords, using
SVN rm, is that possible?

That should be possible. Also, there is a shell interface to SourceForge which details escaped me,
where you would have secure shell access (ssh) and would be able to issue a "rm ...", however, I am
not sure whether one would be able to get to the sandbox directory.

Maybe Rick or Erich know that.

Also, in this context a question: When I look at what was done for 4.2 it appears that first two
workfolders were created:

.../docs/branches/4.2/trunk/
.../main/branches/4.2/trunk/

If you look at the folders it seems .../main/branches/4.2 was used as the working area before
4.2.0 was put in /releases. It could then also serve as working area for 4.2.1 and so on. I want
to avoid we had earlier where we discovered errors in CMakeList.txt when 5.0.0 was already in
/releases.

This is maybe a little bit hypothetical looking back at 4.2.0 which never was followed by a 4.2.1,
rather a lot of work and focus went into 5.0.0beta for years.

But once a release is made a branch with its version number should be made as well such that minor
fixes can ba easily applied to it in case an interim release would be regarded to be valuable.

and then, only at the end, the results were moved to

.../docs/releases/4.2.0/trunk/
.../main/releases/4.2.0/trunk/

Se my remark above, I am talking about the situation where we have a release candidate that we
need to do documentation work on BEFORE it goes into the /releases branch.

Why not?
:)

HTH

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

Re: [Oorexx-devel] Sandbox

On 22.04.2024 15:24, ooRexx wrote:
is it ok to branch off and create folders in the Sandbox branch?

A "sandbox" is an area where experiments can be carried out. In the ooRexx project there are
subdirectories by the name of the developers, committers, such that one can use one own's temporary
subdirectories there to carry out the experiments.

Can they be deleted after a test? I wanted to make a 2nd short test for the
next release.

Also, in this context a question: When I look at what was done for 4.2 it appears that first two
workfolders were created:

.../docs/branches/4.2/trunk/
.../main/branches/4.2/trunk/

AFAICT these are meant to initially match the release versions. In the case that minor changes are
applied to a released version and a minor release is intended, then the changes should go to
branches. Once a release gets created from branches the new release would carry the version 4.2.1 in
your example.

and then, only at the end, the results were moved to

.../docs/releases/4.2.0/trunk/
.../main/releases/4.2.0/trunk/

Does it make sense to do the same for 5.1->5.1.0?
The release version number should always consist of three digits even if the third digits remains to
be 0. The reason being that ooRexx supplies all three digits and the name should reflect the full
version digits.
Will it have an impact on the revision? I understand that the release should show no revision,
something controlled from CMakeLists.txt (according to where the build is taking place I think)?#

If you do a "svn cp" to create a branch or a release this does not change the svn revision number.
Deleting a branch with "svn rm" would not change the svn revision number either AFAIK. The svn
revision number only changes if committing changes/additions to/deletions of files.

HTH,

---rony

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

Re: [Oorexx-devel] Question ad tracing the invocation of a method containing a reply statement

Committed with [r12834] <https://sourceforge.net/p/oorexx/code-0/12834/> (code) and [r12835] 
<https://sourceforge.net/p/oorexx/code-0/12835/> (unit tests) after running the entire test suite.


---rony

On 21.04.2024 20:47, Rony G. Flatscher wrote:


Thinking about this problem, the best understandable solution would probably be to insert an 
invocation exit traceline in the thread right before starting to spawn in RexxActivation.


A test implementation would show the following output:

  1 *-* .traceObject~option="T" -- from now on display thread id in 
prefix
  2 *-1* t=.test~new
  3 *-1* t~test_reply
*>I1>*  Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
  7 *-1* say "before reply ..."
before reply ...
  8 *-1* reply
   *I2> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
  9 *-2* say "after reply ..."
after reply ...
*As can be seen the invocation enter and exit tracelines now match, also with respect to the 
respective thread ids.


---rony


On 20.04.2024 13:59, Rony G. Flatscher wrote:


Given the following program:

.traceObject~option="T" -- from now on display thread id in prefix
t=.test~new
t~test_reply

::class test
::method test_reply
   say "before reply ..."
   reply
   say "after reply ..."

::options trace all

Running it will yield:

  1 *-* .traceObject~option="T" -- from now on display thread id
  2 *-1* t=.test~new
  3 *-1* t~test_reply
>I1> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
  7 *-1* say "before reply ..."
before reply ...
  8 *-1* reply
   *>I2> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".*
  9 *-2* say "after reply ..."
after reply ...
The ">I2>" traceline after line # 8 is probably caused by spawning a new activity to process the 
remainder of the method's code.


However, this is a little bit misleading for the Rexx programmer as there is /no /new invocation 
taking place, rather it is a continuation of the remainder on a new thread/activity. (In the 
current form there is also no matching "

How about either removing ">I2>" or inserting an "I2>" to 
">T2>" (">T>") a new prefix indicating that the remainder gets executed on a new 
thread/activity), if possible?


What do you think?

---rony





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


--
--
__

Prof. Dr. Rony G. Flatscher
Department Wirtschaftsinformatik und Operations Management
Institut für Wirtschaftsinformatik und Gesellschaft
D2c 2.086
WU Wien
Welthandelsplatz 1
A-1020  Wien/Vienna, Austria/Europe

http://www.wu.ac.at
__




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

Re: [Oorexx-devel] Question ad tracing the invocation of a method containing a reply statement

2024-04-21 Thread Rony G. Flatscher

Thinking about this problem, the best understandable solution would probably be to insert an 
invocation exit traceline in the thread right before starting to spawn in RexxActivation.


A test implementation would show the following output:

 1 *-* .traceObject~option="T" -- from now on display thread id in 
prefix
 2 *-1* t=.test~new
 3 *-1* t~test_reply
   *>I1>*  Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
 7 *-1* say "before reply ..."
   before reply ...
 8 *-1* reply
  *I2> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
 9 *-2* say "after reply ..."
   after reply ...
   *As can be seen the invocation enter and exit tracelines now match, also with respect to the 
respective thread ids.


---rony


On 20.04.2024 13:59, Rony G. Flatscher wrote:


Given the following program:

.traceObject~option="T" -- from now on display thread id in prefix
t=.test~new
t~test_reply

::class test
::method test_reply
   say "before reply ..."
   reply
   say "after reply ..."

::options trace all

Running it will yield:

  1 *-* .traceObject~option="T" -- from now on display thread id
  2 *-1* t=.test~new
  3 *-1* t~test_reply
>I1> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
  7 *-1* say "before reply ..."
before reply ...
  8 *-1* reply
   *>I2> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".*
  9 *-2* say "after reply ..."
after reply ...
The ">I2>" traceline after line # 8 is probably caused by spawning a new activity to process the 
remainder of the method's code.


However, this is a little bit misleading for the Rexx programmer as there is /no /new invocation 
taking place, rather it is a continuation of the remainder on a new thread/activity. (In the 
current form there is also no matching "

How about either removing ">I2>" or inserting an "I2>" to 
">T2>" (">T>") a new prefix indicating that the remainder gets executed on a new thread/activity), 
if possible?


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] ooRexx website

2024-04-20 Thread Rony G. Flatscher


Terry, that is *great* that you have been able to overhaul it, thank you very 
much!

---rony

On 20.04.2024 02:05, taf wrote:


Well, nevermind🙂 Just found svn info and I think I've got what I need.

On 2024.04.19 09.04, taf wrote:

Hello all,

I've finally gotten started on the website.  I'm still living in the punch card 
days tho' 😳

I fixed some of the more outdated bits, but eventually saw a .svn subdirectory in the website 
directory and realized that I probably shouldn't be editing the live website files directly 😳


Does anyone know the procedures/software that was being used on the ooRexx site?  Failing that 
does anyone have pointers on how to figure out what subversion repository I should use? 




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

[Oorexx-devel] Question ad tracing the invocation of a method containing a reply statement

2024-04-20 Thread Rony G. Flatscher


Given the following program:

   .traceObject~option="T" -- from now on display thread id in prefix
   t=.test~new
   t~test_reply

   ::class test
   ::method test_reply
  say "before reply ..."
  reply
  say "after reply ..."

   ::options trace all

Running it will yield:

 1 *-* .traceObject~option="T" -- from now on display thread id
 2 *-1* t=.test~new
 3 *-1* t~test_reply
   >I1> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".
 7 *-1* say "before reply ..."
   before reply ...
 8 *-1* reply
  *>I2> Method "TEST_REPLY" with scope "TEST" in package 
"G:\test\orx\trace\test_reply.rex".*
 9 *-2* say "after reply ..."
   after reply ...
   The ">I2>" traceline after line # 8 is probably caused by spawning a new activity to process the 
remainder of the method's code.


However, this is a little bit misleading for the Rexx programmer as there is /no /new invocation 
taking place, rather it is a continuation of the remainder on a new thread/activity. (In the current 
form there is also no matching "

How about either removing ">I2>" or inserting an "I2>" to ">T2>" 
(">T>") a new prefix indicating that the remainder gets executed on a new thread/activity), if possible?


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] Preparing for the next release

2024-04-20 Thread Rony G. Flatscher

Hi P.O.,

thank you for your information and efforts!

How about targeting an initiative to create a new release (5.1.0) at the
beginning of June then?

Cheers

---rony

On 19.04.2024 19:01, ooRexx wrote:

A progress report on my activites today.

The test was partially successful, if you look at Sourceforge you will find two folders 5.0.0test
under /files/oorexx and /files/oorexx-doc. They are staged so only visible if you are logged on to
sourceforge.

For the understanding of how Jenkins works: Each job is defined in an xml file and each setting in
the GUI correspond to a line in the xml.

The test showed that it is possible to parse and modify all those xml files and thereby modify all
build jobs in one go, replacing "needles" with "newneedles", i.e. switching from 5.1.0beta to
5.0.0test or whatever.

I have also modified the uploading script so that it can be redirected by an input parameter. This
worked with the sideeffect that all the 5.1.0 files were uploaded as well. They can be removed
manually or deleted in the work folder so not a big problem

The zip uploader did not work as expected, not yet sure why.

The documentation build should also accept input parameters to redirect the builds, unfortunately
this did not work as expected, I will look into that later.

Finally, since I reproduced the 5.0.0 I got all the mistakes coming back (referring to a missing
document; wrong case for the built entities etc)

Have a look on sourceforge and on Jenkins, I will restore everything tomorrow 20.4. to 5.1.0beta
again.

In my view this will be a doable way to save manual work during the next release, unfortunately I
will be away from home for the most of April and May and can only help at the beginning of june.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se

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

Re: [Oorexx-devel] Test in environmentEntries.testGroup in error (Re: Planning to commit the enclosed diff for the trace invocation exit traceline

Changed the test to expect the NOMETHOD condition, cf. [r12830] 
(https://sourceforge.net/p/oorexx/code-0/12830/).


---rony


On 11.04.2024 13:33, Rony G. Flatscher wrote:


Hmm, there is one unexpected error in the test suite:

[error] 20240411 11:35:15.207000
   Test:   TEST_ZZZ_TRACEOUTPUT_INVALID
   Class:  ENVIRONMENTENTRIES.TESTGROUP
   File:   
...\oorexx\test\trunk\ooRexx\base\runtime.objects\environmentEntries.testGroup
   Event:  NOMETHOD raised unexpectedly.
 Program: REXX
 Line:103
   1454 *-* Method UNKNOWN with scope "Monitor" in package "REXX" (no 
source available).
   1454 *-* Method UNKNOWN with scope "Monitor" in package "REXX" (no 
source available).
103 *-* trace n
*-* Compiled method "SEND" with scope "Message".
   1585 *-* .message~new(self, methodName)~send
   1548 *-* self~doTheTest(fName, aTestResult)  -- carry out the testmethod
552 *-*   test~execute(testResult, verbose)
552 *-*   test~execute(testResult, verbose)
110 *-* suite~execute(testResult)
 79 *-* retCode = 'worker.rex'(arguments)

Here the code of the test:

::method test_zzz_error_invalid
   self~expectSyntax(97.1) -- Object .. does not understand message 
"LINEOUT"
   .error~destination("") -- has no LINEOUT method
   .error~lineOut

::method test_zzz_traceoutput_invalid
   self~expectSyntax(97.1) -- Object .. does not understand message 
"LINEOUT"
   .traceOutput~destination("") -- has no LINEOUT method
   trace r*trace n -- <-- this line # 103*

Not sure whyt it does not trigger 97.1 as the other tests in this test unit do.

Will be able to adjust this test to not bring up an error, but before doing so the question, why 
that would be the case? Why would the changes for the trace invocation exit change this particular 
test (in the context of trace results)?


---rony


On 11.04.2024 11:53, Rony G. Flatscher wrote:
Enclosed please find the diff for adding the trace invocation exit traceline to complement the 
trace invocation (>I>) traceline.


The reason is mainly to make sure that the changes are sensible and acceptable.

While working on this I noticed that in RexxActivation.cpp there is a superfluous call to 
RexxActivation::termination() in case an explicitly given EXIT statement gets processed. After 
commenting it out running the entire test suite only the expected failures (e.g. in 
TRACE.testGroup) occur and those test cases need to be adjusted, which I would also do before 
committing the enclosed diff. The same goes for updating the rexxref docbook.


Before committing I would open an RFE tracker item to record all commits related to this RFE such 
that one can research the changes also at a later time and to not overlook it to be included it 
in the changes log of the next release of ooRexx.


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

Re: [Oorexx-devel] Planning to commit the enclosed diff for the trace invocation exit traceline


Created RFE # 833: https://sourceforge.net/p/oorexx/feature-requests/833/

Committed with [r12828] <https://sourceforge.net/p/oorexx/code-0/12828/> (docs), [r12829] 
<https://sourceforge.net/p/oorexx/code-0/12829/> (code) and [r12830] 
<https://sourceforge.net/p/oorexx/code-0/12830/> (test units).


---rony

On 11.04.2024 11:53, Rony G. Flatscher wrote:
Enclosed please find the diff for adding the trace invocation exit traceline to complement the 
trace invocation (>I>) traceline.


The reason is mainly to make sure that the changes are sensible and acceptable.

While working on this I noticed that in RexxActivation.cpp there is a superfluous call to 
RexxActivation::termination() in case an explicitly given EXIT statement gets processed. After 
commenting it out running the entire test suite only the expected failures (e.g. in 
TRACE.testGroup) occur and those test cases need to be adjusted, which I would also do before 
committing the enclosed diff. The same goes for updating the rexxref docbook.


Before committing I would open an RFE tracker item to record all commits related to this RFE such 
that one can research the changes also at a later time and to not overlook it to be included it in 
the changes log of the next release of ooRexx.


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

[Oorexx-devel] Test in environmentEntries.testGroup in error (Re: Planning to commit the enclosed diff for the trace invocation exit traceline


Hmm, there is one unexpected error in the test suite:

   [error] 20240411 11:35:15.207000
  Test:   TEST_ZZZ_TRACEOUTPUT_INVALID
  Class:  ENVIRONMENTENTRIES.TESTGROUP
  File:   
...\oorexx\test\trunk\ooRexx\base\runtime.objects\environmentEntries.testGroup
  Event:  NOMETHOD raised unexpectedly.
Program: REXX
Line:103
  1454 *-* Method UNKNOWN with scope "Monitor" in package "REXX" (no source 
available).
  1454 *-* Method UNKNOWN with scope "Monitor" in package "REXX" (no source 
available).
   103 *-* trace n
   *-* Compiled method "SEND" with scope "Message".
  1585 *-* .message~new(self, methodName)~send
  1548 *-* self~doTheTest(fName, aTestResult)  -- carry out the testmethod
   552 *-*   test~execute(testResult, verbose)
   552 *-*   test~execute(testResult, verbose)
   110 *-* suite~execute(testResult)
79 *-* retCode = 'worker.rex'(arguments)

Here the code of the test:

   ::method test_zzz_error_invalid
  self~expectSyntax(97.1) -- Object .. does not understand message 
"LINEOUT"
  .error~destination("") -- has no LINEOUT method
  .error~lineOut

   ::method test_zzz_traceoutput_invalid
  self~expectSyntax(97.1) -- Object .. does not understand message 
"LINEOUT"
  .traceOutput~destination("") -- has no LINEOUT method
  trace r*trace n -- <-- this line # 103*

Not sure whyt it does not trigger 97.1 as the other tests in this test unit do.

Will be able to adjust this test to not bring up an error, but before doing so the question, why 
that would be the case? Why would the changes for the trace invocation exit change this particular 
test (in the context of trace results)?


---rony


On 11.04.2024 11:53, Rony G. Flatscher wrote:
Enclosed please find the diff for adding the trace invocation exit traceline to complement the 
trace invocation (>I>) traceline.


The reason is mainly to make sure that the changes are sensible and acceptable.

While working on this I noticed that in RexxActivation.cpp there is a superfluous call to 
RexxActivation::termination() in case an explicitly given EXIT statement gets processed. After 
commenting it out running the entire test suite only the expected failures (e.g. in 
TRACE.testGroup) occur and those test cases need to be adjusted, which I would also do before 
committing the enclosed diff. The same goes for updating the rexxref docbook.


Before committing I would open an RFE tracker item to record all commits related to this RFE such 
that one can research the changes also at a later time and to not overlook it to be included it in 
the changes log of the next release of ooRexx.


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

[Oorexx-devel] Planning to commit the enclosed diff for the trace invocation exit traceline