Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

Hi Erico,

On 26.03.2024 19:39, Erico Mendonca via Oorexx-devel wrote:
Not entirely related, but if you guys want to automate some builds, consider using Open Build 
Service (just call the API, even from Jenkins). Here's an example: 
https://api.opensuse.org/apidocs/#/Sources%20-%20Packages/post_source__project_name___package_name__cmd_runservice 



In this case it's triggering a service to download and compile ooRexx 5.0 from the trunk on 5 
different Linux distros, and publish them to a public repository. It supports almost Linux 30 
distros and different architectures, and it's free.


Here's my package: 
https://build.opensuse.org/package/show/home:emendonca:oorexx/oorexx5

Perhaps someone could create an account for the ooRexx project. Just branch my package to it and 
should be set.


thank you for the information and your kind offer!

Maybe some Linux users among the developers could look into this?

Cheers

---rony

P.S.: I do Linux from time to time because of BSF4ooRexx850 and the DBus library for ooRexx that I 
wrote a couple of years ago, but this is quite rarely the case at the moment. Will return to Linux 
as I plan to change how BSF4ooRexx850 gets created to a more standard way and will have a need to 
test that on Linux too. Due to time constraints this will be a few months away.





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

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Erico Mendonca via Oorexx-devel]

Not entirely related, but if you guys want to automate some builds,
consider using Open Build Service (just call the API, even from Jenkins).
Here's an example:
https://api.opensuse.org/apidocs/#/Sources%20-%20Packages/post_source__project_name___package_name__cmd_runservice

In this case it's triggering a service to download and compile ooRexx 5.0
from the trunk on 5 different Linux distros, and publish them to a public
repository. It supports almost Linux 30 distros and different
architectures, and it's free.

Here's my package:
https://build.opensuse.org/package/show/home:emendonca:oorexx/oorexx5

Perhaps someone could create an account for the ooRexx project. Just branch
my package to it and should be set.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Josep Maria Blasco]

Dear P. O.,

Thanks for your reply, and for all the efforts you, and the other
developers, are putting in making of ooRexx a wonderful language. I am well
aware of the manpower problem, and I understand perfectly that time is the
main limiting factor. I just wanted to stress the fact that, seen "from
outside", things do not always look very bright. Indeed, they do not look
as bright as they really are, once you are somehow more or less "inside"
and begin to know the details. All of which is a pity, obviously. I look
forward to any improvement that makes releasing easier. If I can help in
any way, please let me know; I'd be more than happy to help.

  Josep Maria

Missatge de P.O. Jonsson  del dia dt., 26 de març 2024 a
les 22:49:

> Dear Joseph Maria,
>
> The main reason why there has been no release since 5.0.0 is lack of
> manpower. When 5.0.0 was released there was no-one with recent experience
> in releasing ooRexx and I naively volunteered, with zip experience, hence
> the many mistakes made in the process :-(.
>
> Also our build system that I maintain was less than optimal for release
> work and I ended up spending an entire week manually editing the build jobs
> several times before everything was in place. With 20+ platforms (some with
> 32/64 bit) that build and test + documentation build we have 70 jobs to
> consider whenever there is a change. Manually doing all this was a
> nightmare and before we release again we need to do some things to make
> releasing easier. I have some ideas but time is the limiting factor.
>
> I consider the „Beta“ in the name to be misleading, it is release quality
> IMO.
>
> What would be important is to hear about any „showstoppers“ that would
> prevent a release? I know of none.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 26.03.2024 um 17:39 schrieb Josep Maria Blasco <
> jose.maria.bla...@gmail.com>:
>
> Missatge de Rony G. Flatscher  del dia dt., 26
> de març 2024 a les 16:32:
>
>> Trying to reactivate this thread.
>>
>> There are ooRexx users who depend on official releases as otherwise they
>> cannot take advantage of the latest versions (bug fixes, new features,
>> etc.) as this thread shows:
>> 
>> 
>> .
>>
> I myself, before getting more involved in ooRexx, did not understand the
> long period of beta for 5.0. I was not paying much attention to RexxLA
> mail, and I saw 1) that ooRexx 5.0 was always in beta status, and 2) that
> Rony was always saying that it was "of release quality" -- a contradiction,
> in my view: if it was "of release quality", why wasn't it released? My
> conclusion was that Rony was an enthusiast, and that the product,
> nevertheless, was still not ready (I was right about the former but not
> about the latter :)).
>
> I only migrated to 5.0 when it was finally released. I can understand the
> person who initiated the "No known bugs in ooRexx 5.oo worth to fix?"
> thread perfectly.
>
> My impression is that not doing minor, fix releases can create a certain
> impression that ooRexx is abandonware. Not good!
>
>   Josep Maria
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[P.O. Jonsson]

Dear Joseph Maria,

The main reason why there has been no release since 5.0.0 is lack of manpower. 
When 5.0.0 was released there was no-one with recent experience in releasing 
ooRexx and I naively volunteered, with zip experience, hence the many mistakes 
made in the process :-(.

Also our build system that I maintain was less than optimal for release work 
and I ended up spending an entire week manually editing the build jobs several 
times before everything was in place. With 20+ platforms (some with 32/64 bit) 
that build and test + documentation build we have 70 jobs to consider whenever 
there is a change. Manually doing all this was a nightmare and before we 
release again we need to do some things to make releasing easier. I have some 
ideas but time is the limiting factor.

I consider the „Beta“ in the name to be misleading, it is release quality IMO.

What would be important is to hear about any „showstoppers“ that would prevent 
a release? I know of none.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 26.03.2024 um 17:39 schrieb Josep Maria Blasco 
> :
> 
> Missatge de Rony G. Flatscher  > del dia dt., 26 de març 2024 a les 16:32:
> Trying to reactivate this thread. 
> 
> There are ooRexx users who depend on official releases as otherwise they 
> cannot take advantage of the latest versions (bug fixes, new features, etc.) 
> as this thread shows: 
> 
>  
> .
> 
> I myself, before getting more involved in ooRexx, did not understand the long 
> period of beta for 5.0. I was not paying much attention to RexxLA mail, and I 
> saw 1) that ooRexx 5.0 was always in beta status, and 2) that Rony was always 
> saying that it was "of release quality" -- a contradiction, in my view: if it 
> was "of release quality", why wasn't it released? My conclusion was that Rony 
> was an enthusiast, and that the product, nevertheless, was still not ready (I 
> was right about the former but not about the latter :)).
> 
> I only migrated to 5.0 when it was finally released. I can understand the 
> person who initiated the "No known bugs in ooRexx 5.oo worth to fix?" thread 
> perfectly.
> 
> My impression is that not doing minor, fix releases can create a certain 
> impression that ooRexx is abandonware. Not good!
> 
>   Josep Maria
>  
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Josep Maria Blasco]

Missatge de Rony G. Flatscher  del dia dt., 26 de
març 2024 a les 16:32:

> Trying to reactivate this thread.
>
> There are ooRexx users who depend on official releases as otherwise they
> cannot take advantage of the latest versions (bug fixes, new features,
> etc.) as this thread shows:
> 
> 
> .
>
I myself, before getting more involved in ooRexx, did not understand the
long period of beta for 5.0. I was not paying much attention to RexxLA
mail, and I saw 1) that ooRexx 5.0 was always in beta status, and 2) that
Rony was always saying that it was "of release quality" -- a contradiction,
in my view: if it was "of release quality", why wasn't it released? My
conclusion was that Rony was an enthusiast, and that the product,
nevertheless, was still not ready (I was right about the former but not
about the latter :)).

I only migrated to 5.0 when it was finally released. I can understand the
person who initiated the "No known bugs in ooRexx 5.oo worth to fix?"
thread perfectly.

My impression is that not doing minor, fix releases can create a certain
impression that ooRexx is abandonware. Not good!

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

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

Trying to reactivate this thread.

There are ooRexx users who depend on official releases as otherwise they cannot take advantage of 
the latest versions (bug fixes, new features, etc.) as this thread shows: 
.


---

Personally I would postpone my intent to get the dbus support from the sandbox into ooRexx, despite 
being convinced that this would be very helpful for the Linux users. But it can stay there for some 
time more, I guess. :)


---

Ad releasing 5.1.0: this would be an opportunity to update the scripts and documentation to allow 
for "push-button"-releases sometimes in the future which would allow for bug-fix releases to become 
possible which may be important for ooRexx deployments in professional environments.


---

What are we going to do with the open items that Gil has pointed out (see below)? Would anyone have 
any suggestions, ideas, takers?


---rony



On 30.11.2023 08:56, Rony G. Flatscher wrote:


Hi Gil,

thank you very much!

On 29.11.2023 19:10, Gilbert Barmwater wrote:


I guess I need to refresh everyone's memory on this topic. When we released 5.0.0 about a year 
ago, it contained a lot of changes!  The CHANGES file listed 361 bug fixes, 169 RFEs, 66 
documentation bug fixes and 10 patches.  Unfortunately, some of the bug fixes and RFEs were NOT 
in the "pending" state but still in the "accepted" state which indicated additional work items - 
typically doc, and/or test - were not complete. Rather than delay the release any longer(!) until 
they were all in the pending" state", it was decided to proceed, listing them as included in the 
release.  Shortly following the release, all the "pending" items were changed to "closed" as well 
as SOME of the "accepted" ones.  Since that time, additional items have been completed and their 
status changed to "pending" or "closed" but there remain a number that are still unresolved.  My 
analysis indicates that there are 11 bugs - 1447, 1624, 1625, 1656, 1742, 1762, 1763, 1786, 1827, 
1837,  and 1838 - and 11 RFEs - 353, 544, 550, 552, 569, 576, 578, 581, 603, 754, and 803 - still 
to be completed.  Whether we decide to do a bug-fix release - 5.0.1 - or a new feature release - 
5.1.0 - it is time to clean up this "unfinished business".



Indeed, we should clean up this "unfinished business" ASAP.

Would it be possible for you or for anyone else on this list to give a helping hand? The more 
shoulders carry this load the easier for each individual and the faster can the clean up go? 
(Personally, I will probably only be able to get enough free time again during the New Year 
vacation and would like to focus on the "planned additions".)


---rony



On 11/29/2023 7:11 AM, Rony G. Flatscher wrote:



On 24.11.2023 01:05, Gilbert Barmwater wrote:


If the consensus is to do this, can we make a concerted effort to get the bugs and RFEs that 
were in 5.0.0 but were not marked as "pending" - usually as "accepted" - finally to a finished 
state, namely "pending"?  There has been a good amount of work on this but I'd really want to 
see ALL of them completed.  Thanks!


Could you point them out (unfortunately, I have no idea what you mean or which bugs and RFEs are 
affected)?


---rony



On 11/23/2023 3:51 PM, Rony G Flatscher wrote:

Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards

—rony

Rony G. Flatscher (mobil/e)


Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :

 Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and 
implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a release in 
2023 would be very hard for me to cope with. What about aiming for end of January?


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se





Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher :

Given some free time I would like to add the following things to ooRexx 5.1:

  * the Windows oleinfo Rexx utilities from the sandbox
(https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  o planned for being placed as is in a new directory 
ooRexx/samples/ole/oleinfo
together with a readme.txt file
  o history: first introduced at the RexxLA symposium in 2004, cf.

  o reasoning: many times it is very difficult, if not impossible to get at 
the
published OLE interfaces of Windows COM/OLE objects including those 
returned by
invocations of methods or fetching attribute values (they may not be 
registered in
the registry, hence not discoverable); it is nice to have e.g. 
reference like
printouts of the OLE interfaces (methods, attributes, events)

  * add the DBus support from the sandbox
 to 
ooRexx if the
target platform has DBus support 

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

Hi Gil,

thank you very much!

On 29.11.2023 19:10, Gilbert Barmwater wrote:


I guess I need to refresh everyone's memory on this topic. When we released 5.0.0 about a year 
ago, it contained a lot of changes!  The CHANGES file listed 361 bug fixes, 169 RFEs, 66 
documentation bug fixes and 10 patches.  Unfortunately, some of the bug fixes and RFEs were NOT in 
the "pending" state but still in the "accepted" state which indicated additional work items - 
typically doc, and/or test - were not complete.  Rather than delay the release any longer(!) until 
they were all in the pending" state", it was decided to proceed, listing them as included in the 
release.  Shortly following the release, all the "pending" items were changed to "closed" as well 
as SOME of the "accepted" ones.  Since that time, additional items have been completed and their 
status changed to "pending" or "closed" but there remain a number that are still unresolved.  My 
analysis indicates that there are 11 bugs - 1447, 1624, 1625, 1656, 1742, 1762, 1763, 1786, 1827, 
1837,  and 1838 - and 11 RFEs - 353, 544, 550, 552, 569, 576, 578, 581, 603, 754, and 803 - still 
to be completed.  Whether we decide to do a bug-fix release - 5.0.1 - or a new feature release - 
5.1.0 - it is time to clean up this "unfinished business".



Indeed, we should clean up this "unfinished business" ASAP.

Would it be possible for you or for anyone else on this list to give a helping hand? The more 
shoulders carry this load the easier for each individual and the faster can the clean up go? 
(Personally, I will probably only be able to get enough free time again during the New Year vacation 
and would like to focus on the "planned additions".)


---rony



On 11/29/2023 7:11 AM, Rony G. Flatscher wrote:



On 24.11.2023 01:05, Gilbert Barmwater wrote:


If the consensus is to do this, can we make a concerted effort to get the bugs and RFEs that 
were in 5.0.0 but were not marked as "pending" - usually as "accepted" - finally to a finished 
state, namely "pending"?  There has been a good amount of work on this but I'd really want to 
see ALL of them completed.  Thanks!


Could you point them out (unfortunately, I have no idea what you mean or which bugs and RFEs are 
affected)?


---rony



On 11/23/2023 3:51 PM, Rony G Flatscher wrote:

Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards

—rony

Rony G. Flatscher (mobil/e)


Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :

 Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and 
implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a release in 
2023 would be very hard for me to cope with. What about aiming for end of January?


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se





Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher :

Given some free time I would like to add the following things to ooRexx 5.1:

  * the Windows oleinfo Rexx utilities from the sandbox
(https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  o planned for being placed as is in a new directory 
ooRexx/samples/ole/oleinfo together
with a readme.txt file
  o history: first introduced at the RexxLA symposium in 2004, cf.

  o reasoning: many times it is very difficult, if not impossible to get at 
the published
OLE interfaces of Windows COM/OLE objects including those returned by 
invocations of
methods or fetching attribute values (they may not be registered in the 
registry,
hence not discoverable); it is nice to have e.g. reference like 
printouts of the OLE
interfaces (methods, attributes, events)

  * add the DBus support from the sandbox
 to 
ooRexx if the
target platform has DBus support available (originally a message system on 
Linux
exploited by many distributions)
  o history:
  + Flatscher R.G., "D-Bus Language Bindings for ooRexx", International 
Rexx
Symposium 2011: 

  + Margiol S., "DBusooRexx", International Rexx Symposium 2015:


  + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the 
Power of D-Bus to
Your Fingertips"
  + Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and 
Windows",
International Rexx Symposium 2016:


  * multithreading trace ("MT trace")
  o history: Jean-Louis has offered a very helpful and interesting means in 
form of a
patch, that has not yet been applied; due to some discussions I had 
expected that an
alternative 

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Gilbert Barmwater]

I guess I need to refresh everyone's memory on this topic.  When we 
released 5.0.0 about a year ago, it contained a lot of changes!  The 
CHANGES file listed 361 bug fixes, 169 RFEs, 66 documentation bug fixes 
and 10 patches.  Unfortunately, some of the bug fixes and RFEs were NOT 
in the "pending" state but still in the "accepted" state which indicated 
additional work items - typically doc, and/or test - were not complete.  
Rather than delay the release any longer(!) until they were all in the 
pending" state", it was decided to proceed, listing them as included in 
the release.  Shortly following the release, all the "pending" items 
were changed to "closed" as well as SOME of the "accepted" ones. Since 
that time, additional items have been completed and their status changed 
to "pending" or "closed" but there remain a number that are still 
unresolved.  My analysis indicates that there are 11 bugs - 1447, 1624, 
1625, 1656, 1742, 1762, 1763, 1786, 1827, 1837,  and 1838 - and 11 RFEs 
- 353, 544, 550, 552, 569, 576, 578, 581, 603, 754, and 803 - still to 
be completed.  Whether we decide to do a bug-fix release - 5.0.1 - or a 
new feature release - 5.1.0 - it is time to clean up this "unfinished 
business".


On 11/29/2023 7:11 AM, Rony G. Flatscher wrote:



On 24.11.2023 01:05, Gilbert Barmwater wrote:


If the consensus is to do this, can we make a concerted effort to get 
the bugs and RFEs that were in 5.0.0 but were not marked as "pending" 
- usually as "accepted" - finally to a finished state, namely 
"pending"?  There has been a good amount of work on this but I'd 
really want to see ALL of them completed.  Thanks!


Could you point them out (unfortunately, I have no idea what you mean 
or which bugs and RFEs are affected)?


---rony



On 11/23/2023 3:51 PM, Rony G Flatscher wrote:

Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards

—rony

Rony G. Flatscher (mobil/e)


Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :

 Dear Rony,

I have no preferences regarding your proposals, for me you can go 
ahead and implement them.


Regarding a 5.1.0 release I have a tight schedule from now until 
Christmas so a release in 2023 would be very hard for me to cope 
with. What about aiming for end of January?


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher 
:


Given some free time I would like to add the following things to 
ooRexx 5.1:


  * the Windows oleinfo Rexx utilities from the sandbox
(https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  o planned for being placed as is in a new directory
ooRexx/samples/ole/oleinfo together with a readme.txt file
  o history: first introduced at the RexxLA symposium in 2004,
cf. 
  o reasoning: many times it is very difficult, if not
impossible to get at the published OLE interfaces of
Windows COM/OLE objects including those returned by
invocations of methods or fetching attribute values (they
may not be registered in the registry, hence not
discoverable); it is nice to have e.g. reference like
printouts of the OLE interfaces (methods, attributes, events)

  * add the DBus support from the sandbox

to ooRexx if the target platform has DBus support available
(originally a message system on Linux exploited by many
distributions)
  o history:
  + Flatscher R.G., "D-Bus Language Bindings for ooRexx",
International Rexx Symposium 2011:

  + Margiol S., "DBusooRexx", International Rexx Symposium
2015:


  + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx
Bringing the Power of D-Bus to Your Fingertips"
  + Flatscher R.G., "The ooRexx DBus Bindings for Linux,
MacOSX and Windows", International Rexx Symposium
2016:


  * multithreading trace ("MT trace")
  o history: Jean-Louis has offered a very helpful and
interesting means in form of a patch, that has not yet
been applied; due to some discussions I had expected that
an alternative means becomes available, but this has not
materialized; after a couple of years it is time to give
the ooRexx developers sound means into their hands; as
designed Jean-Louis' version will have to be activated by
setting an environment variable before starting the MT
program, hence it is meant for explicitly debugging (no
new MT-related trace options would have to be defined at all)
  

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Michael Lueck]

Greetings Rony,

No, I do not have the necessary skills to take on the task. The task seemed 
pretty important, and thus it stuck in my mind.

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/



Rony G. Flatscher wrote:

Hi Michael,

AFAIK nothing has happened since then. Would you be interested in taking this 
on?

Cheers

---rony


On 24.11.2023 01:43, Michael Lueck wrote:

Greetings ooRexx team,


Reminder of Rick's prior email...

 Begin Forwarded Message 
Subject: [Oorexx-devel] I think I've seen the future...
Date: Sun, 22 Jan 2023 17:10:10 -0500
From: Rick McGuire 
Reply-To: Open Object Rexx Developer Mailing List 

To: Open Object Rexx Developer Mailing List 




Today in a FaceBook group I'm a member of, someone made a post about a remarkable result obtained from ChatGPT. I decided I would check it out, using a problem that I struggled with for two months, 
then gave up an implemented a less than optimal solution that fixed the problem but was not exactly secure.


The problem in question was the problem caused when the rexxapi daemon gpt created by a process with elevated privileges, which prevented processes with non-elevated privledges from connecting to 
the rexxapi daemon via the named pipe. I struggled for several months trying figure out the Windows documentation for the security APIs and a lot of time in StackOverflow trying to find some 
examples I could adapt. I came up empty and ended up creating the pipe with no security restrictions.


So, today I asked ChatGPT how to create a named pipe that only users of the same process could connect to. It immediately gave me a program that created the named pipe using the same code we were 
using at first that had the elevated permissions issues. Not what I was looking for, but impressive nonetheless.


I told ChatGPT has issues communicating between processes with elevated permissions. It agreed with me and produced a new program that I *think* might be exactly what is needed to close the security 
hole. I was truly amazed!


I don't know if I'm interested in fixing this myself, nor if I'll have the 
time. However, I want to post the code suggested by ChatGPT in case anyone else 
wants to adapt it to rexxapi communications.

Rick
 End Forwarded Message 



Did that suggested code prototype ever make it into the ooRexx RexxAPI 
communications code base?

I am thankful,



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

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

Hi Michael,

AFAIK nothing has happened since then. Would you be interested in taking this 
on?

Cheers

---rony


On 24.11.2023 01:43, Michael Lueck wrote:

Greetings ooRexx team,


Reminder of Rick's prior email...

 Begin Forwarded Message 
Subject: [Oorexx-devel] I think I've seen the future...
Date: Sun, 22 Jan 2023 17:10:10 -0500
From: Rick McGuire 
Reply-To: Open Object Rexx Developer Mailing List 

To: Open Object Rexx Developer Mailing List 




Today in a FaceBook group I'm a member of, someone made a post about a remarkable result obtained 
from ChatGPT. I decided I would check it out, using a problem that I struggled with for two 
months, then gave up an implemented a less than optimal solution that fixed the problem but was 
not exactly secure.


The problem in question was the problem caused when the rexxapi daemon gpt created by a process 
with elevated privileges, which prevented processes with non-elevated privledges from connecting 
to the rexxapi daemon via the named pipe. I struggled for several months trying figure out the 
Windows documentation for the security APIs and a lot of time in StackOverflow trying to find some 
examples I could adapt. I came up empty and ended up creating the pipe with no security restrictions.


So, today I asked ChatGPT how to create a named pipe that only users of the same process could 
connect to. It immediately gave me a program that created the named pipe using the same code we 
were using at first that had the elevated permissions issues. Not what I was looking for, but 
impressive nonetheless.


I told ChatGPT has issues communicating between processes with elevated permissions. It agreed 
with me and produced a new program that I *think* might be exactly what is needed to close the 
security hole. I was truly amazed!


I don't know if I'm interested in fixing this myself, nor if I'll have the time. However, I want 
to post the code suggested by ChatGPT in case anyone else wants to adapt it to rexxapi 
communications.


Rick
 End Forwarded Message 



Did that suggested code prototype ever make it into the ooRexx RexxAPI 
communications code base?

I am thankful,




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

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

On 24.11.2023 01:05, Gilbert Barmwater wrote:


If the consensus is to do this, can we make a concerted effort to get the bugs and RFEs that were 
in 5.0.0 but were not marked as "pending" - usually as "accepted" - finally to a finished state, 
namely "pending"?  There has been a good amount of work on this but I'd really want to see ALL of 
them completed. Thanks!


Could you point them out (unfortunately, I have no idea what you mean or which bugs and RFEs are 
affected)?


---rony



On 11/23/2023 3:51 PM, Rony G Flatscher wrote:

Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards

—rony

Rony G. Flatscher (mobil/e)


Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :

 Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and 
implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a release in 2023 
would be very hard for me to cope with. What about aiming for end of January?


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se





Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher :

Given some free time I would like to add the following things to ooRexx 5.1:

  * the Windows oleinfo Rexx utilities from the sandbox
(https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  o planned for being placed as is in a new directory 
ooRexx/samples/ole/oleinfo together
with a readme.txt file
  o history: first introduced at the RexxLA symposium in 2004, cf.

  o reasoning: many times it is very difficult, if not impossible to get at 
the published
OLE interfaces of Windows COM/OLE objects including those returned by 
invocations of
methods or fetching attribute values (they may not be registered in the 
registry, hence
not discoverable); it is nice to have e.g. reference like printouts of 
the OLE
interfaces (methods, attributes, events)

  * add the DBus support from the sandbox
 to 
ooRexx if the
target platform has DBus support available (originally a message system on 
Linux exploited
by many distributions)
  o history:
  + Flatscher R.G., "D-Bus Language Bindings for ooRexx", International 
Rexx Symposium
2011: 

  + Margiol S., "DBusooRexx", International Rexx Symposium 2015:


  + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the 
Power of D-Bus to
Your Fingertips"
  + Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and 
Windows",
International Rexx Symposium 2016:


  * multithreading trace ("MT trace")
  o history: Jean-Louis has offered a very helpful and interesting means in 
form of a
patch, that has not yet been applied; due to some discussions I had 
expected that an
alternative means becomes available, but this has not materialized; 
after a couple of
years it is time to give the ooRexx developers sound means into their 
hands; as
designed Jean-Louis' version will have to be activated by setting an 
environment
variable before starting the MT program, hence it is meant for 
explicitly debugging (no
new MT-related trace options would have to be defined at all)
  + one aim when doing so is to come up with a BIF (suggestions?) that 
allows for
retrieving the thread number, the activation number, the variable 
pool number and
lock status, which the documentation of that BIF would explain: 
this should allow
e.g. Gil to use this information to experiment with Rick's idea in
non-explicit-debugging runs
  # this will cause these counters/this information to be always 
maintained,
irrespectively whether  MT trace is active or not
  o reasoning: for debugging multithreaded programs it is necessary to get 
at the
respective context invocation information, without it certain 
multithreaded problems
cannot be analyzed/debugged

  * allow invoking the garbage collector for debugging purposes
  o history and reasoning: for debugging purposes in the context of the 
Java bridge it
became necessary to make sure that the Rexx garbage collector ran 
(background: Java
changed the finalization logics and to debug the new Java 
implementations for releasing
cached Rexx objects and to test correct execution of their uninit 
methods); without a
means to invoke the ooRexx garbage collector this is simply not 
possible; it is very
likely that such debugging needs occur in 

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Michael Lueck]

Greetings ooRexx team,


Reminder of Rick's prior email...

 Begin Forwarded Message 
Subject:[Oorexx-devel] I think I've seen the future...
Date:   Sun, 22 Jan 2023 17:10:10 -0500
From:   Rick McGuire 
Reply-To:   Open Object Rexx Developer Mailing List 

To: Open Object Rexx Developer Mailing List 




Today in a FaceBook group I'm a member of, someone made a post about a remarkable result obtained from ChatGPT. I decided I would check it out, using a problem that I struggled with for two months, 
then gave up an implemented a less than optimal solution that fixed the problem but was not exactly secure.


The problem in question was the problem caused when the rexxapi daemon gpt created by a process with elevated privileges, which prevented processes with non-elevated privledges from connecting to the 
rexxapi daemon via the named pipe. I struggled for several months trying figure out the Windows documentation for the security APIs and a lot of time in StackOverflow trying to find some examples I 
could adapt. I came up empty and ended up creating the pipe with no security restrictions.


So, today I asked ChatGPT how to create a named pipe that only users of the same process could connect to. It immediately gave me a program that created the named pipe using the same code we were 
using at first that had the elevated permissions issues. Not what I was looking for, but impressive nonetheless.


I told ChatGPT has issues communicating between processes with elevated permissions. It agreed with me and produced a new program that I *think* might be exactly what is needed to close the security 
hole. I was truly amazed!


I don't know if I'm interested in fixing this myself, nor if I'll have the 
time. However, I want to post the code suggested by ChatGPT in case anyone else 
wants to adapt it to rexxapi communications.

Rick
 End Forwarded Message 



Did that suggested code prototype ever make it into the ooRexx RexxAPI 
communications code base?

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


Gilbert Barmwater wrote:
If the consensus is to do this, can we make a concerted effort to get the bugs and RFEs that were in 5.0.0 but were not marked as "pending" - usually as "accepted" - finally to a finished state, 
namely "pending"?  There has been a good amount of work on this but I'd really want to see ALL of them completed.  Thanks!


On 11/23/2023 3:51 PM, Rony G Flatscher wrote:

Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards

—rony

Rony G. Flatscher (mobil/e)


Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :

 Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and 
implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a 
release in 2023 would be very hard for me to cope with. What about aiming for 
end of January?

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se





Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher :

Given some free time I would like to add the following things to ooRexx 5.1:

  * the Windows oleinfo Rexx utilities from the sandbox 
(https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  o planned for being placed as is in a new directory 
ooRexx/samples/ole/oleinfo together with a readme.txt file
  o history: first introduced at the RexxLA symposium in 2004, cf. 

  o reasoning: many times it is very difficult, if not impossible to get at 
the published OLE interfaces of Windows COM/OLE objects including those 
returned by invocations of methods or
fetching attribute values (they may not be registered in the registry, 
hence not discoverable); it is nice to have e.g. reference like printouts of 
the OLE interfaces (methods, attributes,
events)

  * add the DBus support from the sandbox 
 to 
ooRexx if the target platform has DBus support available (originally a message
system on Linux exploited by many distributions)
  o history:
  + Flatscher R.G., "D-Bus Language Bindings for ooRexx", International Rexx 
Symposium 2011: 
  + Margiol S., "DBusooRexx", International Rexx Symposium 2015: 

  + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the Power of 
D-Bus to Your Fingertips"
  + Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and Windows", 
International Rexx Symposium 2016: 


  * multithreading trace ("MT trace")
  o history: Jean-Louis has offered a very helpful and interesting means in 
form of a patch, that has not yet 

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Gilbert Barmwater]

If the consensus is to do this, can we make a concerted effort to get 
the bugs and RFEs that were in 5.0.0 but were not marked as "pending" - 
usually as "accepted" - finally to a finished state, namely "pending"?  
There has been a good amount of work on this but I'd really want to see 
ALL of them completed.  Thanks!


On 11/23/2023 3:51 PM, Rony G Flatscher wrote:

Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards

—rony

Rony G. Flatscher (mobil/e)


Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :

 Dear Rony,

I have no preferences regarding your proposals, for me you can go 
ahead and implement them.


Regarding a 5.1.0 release I have a tight schedule from now until 
Christmas so a release in 2023 would be very hard for me to cope 
with. What about aiming for end of January?


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher 
:


Given some free time I would like to add the following things to 
ooRexx 5.1:


  * the Windows oleinfo Rexx utilities from the sandbox
(https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  o planned for being placed as is in a new directory
ooRexx/samples/ole/oleinfo together with a readme.txt file
  o history: first introduced at the RexxLA symposium in 2004,
cf. 
  o reasoning: many times it is very difficult, if not
impossible to get at the published OLE interfaces of Windows
COM/OLE objects including those returned by invocations of
methods or fetching attribute values (they may not be
registered in the registry, hence not discoverable); it is
nice to have e.g. reference like printouts of the OLE
interfaces (methods, attributes, events)

  * add the DBus support from the sandbox

to ooRexx if the target platform has DBus support available
(originally a message system on Linux exploited by many
distributions)
  o history:
  + Flatscher R.G., "D-Bus Language Bindings for ooRexx",
International Rexx Symposium 2011:

  + Margiol S., "DBusooRexx", International Rexx Symposium
2015:


  + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx
Bringing the Power of D-Bus to Your Fingertips"
  + Flatscher R.G., "The ooRexx DBus Bindings for Linux,
MacOSX and Windows", International Rexx Symposium 2016:


  * multithreading trace ("MT trace")
  o history: Jean-Louis has offered a very helpful and
interesting means in form of a patch, that has not yet been
applied; due to some discussions I had expected that an
alternative means becomes available, but this has not
materialized; after a couple of years it is time to give the
ooRexx developers sound means into their hands; as designed
Jean-Louis' version will have to be activated by setting an
environment variable before starting the MT program, hence
it is meant for explicitly debugging (no new MT-related
trace options would have to be defined at all)
  + one aim when doing so is to come up with a BIF
(suggestions?) that allows for retrieving the thread
number, the activation number, the variable pool number
and lock status, which the documentation of that BIF
would explain: this should allow e.g. Gil to use this
information to experiment with Rick's idea in
non-explicit-debugging runs
  # this will cause these counters/this information to
be always maintained, irrespectively whether  MT
trace is active or not
  o reasoning: for debugging multithreaded programs it is
necessary to get at the respective context invocation
information, without it certain multithreaded problems
cannot be analyzed/debugged

  * allow invoking the garbage collector for debugging purposes
  o history and reasoning: for debugging purposes in the context
of the Java bridge it became necessary to make sure that the
Rexx garbage collector ran (background: Java changed the
finalization logics and to debug the new Java
implementations for releasing cached Rexx objects and to
test correct execution of their uninit methods); without a
means to invoke the ooRexx garbage collector this is simply
not possible; it is very likely that such debugging needs
occur in other contexts where native information systems
   

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G Flatscher]

Dear P.O.,fine, around end of January for planning a release of 5.1 would be fine!Best regards —ronyRony G. Flatscher (mobil/e)Am 23.11.2023 um 10:28 schrieb P.O. Jonsson :Dear Rony,I have no preferences regarding your proposals, for me you can go ahead and implement them.Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a release in 2023 would be very hard for me to cope with. What about aiming for end of January?
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se

Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher :

  

  
  Given some free time I would like to add the following things to
  ooRexx 5.1:

  the Windows oleinfo Rexx utilities from the sandbox (https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
  
planned for being placed as is in a new directory
  ooRexx/samples/ole/oleinfo together with a readme.txt file
history: first introduced at the RexxLA symposium in 2004,
  cf. 

reasoning: many times it is very difficult, if not
  impossible to get at the published OLE interfaces of Windows
  COM/OLE objects including those returned by invocations of
  methods or fetching attribute values (they may not be
  registered in the registry, hence not discoverable); it is
  nice to have e.g. reference like printouts of the OLE
  interfaces (methods, attributes, events)

  


  add the DBus support from the sandbox

to ooRexx if the target platform has DBus support available
(originally a message system on Linux exploited by many
distributions)
  
history: 


  Flatscher R.G., "D-Bus Language Bindings for ooRexx",
International Rexx Symposium 2011: 
  
  Margiol S., "DBusooRexx", International Rexx Symposium
2015:

  Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing
the Power of D-Bus to Your Fingertips"
  
  Flatscher R.G., "The ooRexx DBus Bindings for Linux,
MacOSX and Windows", International Rexx Symposium 2016: 

  


  multithreading trace ("MT trace")
  
  
history: Jean-Louis has offered a very helpful and
  interesting means in form of a patch, that has not yet been
  applied; due to some discussions I had expected that an
  alternative means becomes available, but this has not
  materialized; after a couple of years it is time to give the
  ooRexx developers sound means into their hands; as designed
  Jean-Louis' version will have to be activated by setting an
  environment variable before starting the MT program, hence it
  is meant for explicitly debugging (no new MT-related trace
  options would have to be defined at all) 


  one aim when doing so is to come up with a BIF
(suggestions?) that allows for retrieving the thread number,
the activation number, the variable pool number and lock
status, which the documentation of that BIF would explain:
this should allow e.g. Gil to use this information to
experiment with Rick's idea in non-explicit-debugging runs
  
  
this will cause these counters/this information to be
  always maintained, irrespectively whether  MT trace is
  active or not

  

reasoning: for debugging multithreaded programs it is
  necessary to get at the respective context invocation
  information, without it certain multithreaded problems cannot
  be analyzed/debugged 
  

  
  allow invoking the garbage collector for debugging purposes
  
  
history and reasoning: for debugging purposes in the context
  of the Java bridge it became necessary to make sure that the
  Rexx garbage collector ran (background: Java changed the
  finalization logics and to debug the new Java implementations
  for releasing cached Rexx objects and to test correct
  execution of their uninit methods); without a means to invoke
  the ooRexx garbage collector this is simply not possible; it
  is very likely that such debugging needs occur in other
  contexts where native information systems interacting with
  ooRexx (e.g. using ooRexx for scripts) need to be able to
  check/analyze/debug correct releases of cached ooRexx objects
  for debugging purposes; without such a function this simply
  cannot be achieved; as running the garbage collector (in every
  programming language) is a very expensive operation this needs
  appropriate documentation; invoking 

Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[P.O. Jonsson]

Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and 
implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a 
release in 2023 would be very hard for me to cope with. What about aiming for 
end of January?

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher :
> 
> Given some free time I would like to add the following things to ooRexx 5.1:
> 
> the Windows oleinfo Rexx utilities from the sandbox 
> (https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/ 
> )
> planned for being placed as is in a new directory ooRexx/samples/ole/oleinfo 
> together with a readme.txt file
> history: first introduced at the RexxLA symposium in 2004, cf. 
>  
> 
> reasoning: many times it is very difficult, if not impossible to get at the 
> published OLE interfaces of Windows COM/OLE objects including those returned 
> by invocations of methods or fetching attribute values (they may not be 
> registered in the registry, hence not discoverable); it is nice to have e.g. 
> reference like printouts of the OLE interfaces (methods, attributes, events)
> add the DBus support from the sandbox 
>  
>  to 
> ooRexx if the target platform has DBus support available (originally a 
> message system on Linux exploited by many distributions)
> history: 
> Flatscher R.G., "D-Bus Language Bindings for ooRexx", International Rexx 
> Symposium 2011: 
>  
> 
> Margiol S., "DBusooRexx", International Rexx Symposium 2015: 
>  
> 
> Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the Power of D-Bus 
> to Your Fingertips"
> Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and Windows", 
> International Rexx Symposium 2016: 
>  
> 
> multithreading trace ("MT trace")
> history: Jean-Louis has offered a very helpful and interesting means in form 
> of a patch, that has not yet been applied; due to some discussions I had 
> expected that an alternative means becomes available, but this has not 
> materialized; after a couple of years it is time to give the ooRexx 
> developers sound means into their hands; as designed Jean-Louis' version will 
> have to be activated by setting an environment variable before starting the 
> MT program, hence it is meant for explicitly debugging (no new MT-related 
> trace options would have to be defined at all) 
> one aim when doing so is to come up with a BIF (suggestions?) that allows for 
> retrieving the thread number, the activation number, the variable pool number 
> and lock status, which the documentation of that BIF would explain: this 
> should allow e.g. Gil to use this information to experiment with Rick's idea 
> in non-explicit-debugging runs
> this will cause these counters/this information to be always maintained, 
> irrespectively whether  MT trace is active or not
> reasoning: for debugging multithreaded programs it is necessary to get at the 
> respective context invocation information, without it certain multithreaded 
> problems cannot be analyzed/debugged 
> 
> allow invoking the garbage collector for debugging purposes
> history and reasoning: for debugging purposes in the context of the Java 
> bridge it became necessary to make sure that the Rexx garbage collector ran 
> (background: Java changed the finalization logics and to debug the new Java 
> implementations for releasing cached Rexx objects and to test correct 
> execution of their uninit methods); without a means to invoke the ooRexx 
> garbage collector this is simply not possible; it is very likely that such 
> debugging needs occur in other contexts where native information systems 
> interacting with ooRexx (e.g. using ooRexx for scripts) need to be able to 
> check/analyze/debug correct releases of cached ooRexx objects for debugging 
> purposes; without such a function this simply cannot be achieved; as running 
> the garbage collector (in every programming language) is a very expensive 
> operation this needs appropriate documentation; invoking existing garbage 
> collectors is possible in popular programming languages such as Java's 
> java.lang.System.gc() (cf. 
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#gc 
> 

[Oorexx-devel] Planned additions, release of ooRexx 5.1 ?

[Rony G. Flatscher]

Given some free time I would like to add the following things to ooRexx 5.1:

 * the Windows oleinfo Rexx utilities from the sandbox
   (https://sourceforge.net/p/oorexx/code-0/HEAD/tree/sandbox/rony/oleinfo/)
 o planned for being placed as is in a new directory 
ooRexx/samples/ole/oleinfo together with a
   readme.txt file
 o history: first introduced at the RexxLA symposium in 2004, cf.
   
 o reasoning: many times it is very difficult, if not impossible to get at 
the published OLE
   interfaces of Windows COM/OLE objects including those returned by 
invocations of methods or
   fetching attribute values (they may not be registered in the registry, 
hence not
   discoverable); it is nice to have e.g. reference like printouts of the 
OLE interfaces
   (methods, attributes, events)

 * add the DBus support from the sandbox
    to 
ooRexx if the target
   platform has DBus support available (originally a message system on Linux 
exploited by many
   distributions)
 o history:
 + Flatscher R.G., "D-Bus Language Bindings for ooRexx", International 
Rexx Symposium 2011:
   
 + Margiol S., "DBusooRexx", International Rexx Symposium 2015:
   

 + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the Power 
of D-Bus to Your
   Fingertips"
 + Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and 
Windows", International
   Rexx Symposium 2016: 


 * multithreading trace ("MT trace")
 o history: Jean-Louis has offered a very helpful and interesting means in 
form of a patch,
   that has not yet been applied; due to some discussions I had expected 
that an alternative
   means becomes available, but this has not materialized; after a couple 
of years it is time
   to give the ooRexx developers sound means into their hands; as designed 
Jean-Louis' version
   will have to be activated by setting an environment variable before 
starting the MT program,
   hence it is meant for explicitly debugging (no new MT-related trace 
options would have to be
   defined at all)
 + one aim when doing so is to come up with a BIF (suggestions?) that 
allows for retrieving
   the thread number, the activation number, the variable pool number 
and lock status,
   which the documentation of that BIF would explain: this should allow 
e.g. Gil to use
   this information to experiment with Rick's idea in 
non-explicit-debugging runs
 # this will cause these counters/this information to be always 
maintained,
   irrespectively whether  MT trace is active or not
 o reasoning: for debugging multithreaded programs it is necessary to get 
at the respective
   context invocation information, without it certain multithreaded 
problems cannot be
   analyzed/debugged

 * allow invoking the garbage collector for debugging purposes
 o history and reasoning: for debugging purposes in the context of the Java 
bridge it became
   necessary to make sure that the Rexx garbage collector ran (background: 
Java changed the
   finalization logics and to debug the new Java implementations for 
releasing cached Rexx
   objects and to test correct execution of their uninit methods); without 
a means to invoke
   the ooRexx garbage collector this is simply not possible; it is very 
likely that such
   debugging needs occur in other contexts where native information systems 
interacting with
   ooRexx (e.g. using ooRexx for scripts) need to be able to 
check/analyze/debug correct
   releases of cached ooRexx objects for debugging purposes; without such a 
function this
   simply cannot be achieved; as running the garbage collector (in every 
programming language)
   is a very expensive operation this needs appropriate documentation; 
invoking existing
   garbage collectors is possible in popular programming languages such as 
Java's
   java.lang.System.gc() (cf.
   https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#gc--) or 
.Net/CLR's
   System.GC.collect() (cf.
   
https://learn.microsoft.com/en-us/dotnet/api/system.gc.collect#System_GC_Collect,
   
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals)

Any comments?

---

Also we should plan to release the current 5.1 version of ooRexx as soon as possible for at least 
the following reasons:


 * make the current bug fixes available in the form of an officially released 
package: many
   companies do not allow beta software to be installed, used, hence the need 
for a