On Sun, Nov 30, 2025 at 10:30 AM ooRexx <[email protected]> wrote:

>
> Am 29.11.2025 um 13:52 schrieb Rony G. Flatscher <[email protected]
> >:
>
> Looking into this a little bit further, it seems that it would be
> sufficient to re-establish the documentation for these functions:
>
> B.2.1. RexxUtil Semaphore functions
>
> The following RexxUtil functions related to semaphore-processing have been
> deprecated.
>
> SysCloseEventSem         SysPostEventSem
> SysCloseMutexSem         SysPulseEventSem
> SysCreateEventSem         SysReleaseMutexSem
> SysCreateMutexSem         SysRequestMutexSem
> SysOpenEventSem         SysResetEventSem
> SysOpenMutexSem         SysWaitEventSem
>
> It would be necessary to obtain the documentation from ooRexx 4.2.0 and
> incorporate it into the current documentation for rexxref.pdf, adding a
> note that it is not currently available for the macOS platform.
>
> Additionally, the deprecation notices from Appendix B in rexxref.pdf
> should be removed then.
>
> We would  need to create a RFE for undeprecating it to record the
> re-establishment of the documentation against it.
>
> Would there be any takers for this task?
>
>
> I am unable to take on this task but I looked into it quickly
>
> These are found in current trunk
>
> *SysRexxUtil.cpp* (both for Win and *nix in trunk)
> *SysRexxUtilFunctions.h* (both for Win and *nix in trunk)
>
> And apparently they are built for all platforms
>
> *mig.xml* (in /docs/trunk/rexxref/en-US) This part should be changed:
> <section id="deprecated.semaphore"><title>RexxUtil Semaphore
> functions</title>
> <para>The following RexxUtil functions related to
> semaphore-processing have been deprecated.
> ...
>
>
> Present in 4.2.0 release (/docs/releases/4.2.0/trunk/rexxref/en-US/)
> *xconcur.xml*
> *rexutil.xml*
>
> So it seems only book rexxref in affected.
>
> I was baffled by Rick’s remark that it works on *nix but not on Mac. Today
> MacOS *is* based on Darwin, which in turn is based on BSD Unix. So it
> *should* work on Mac.
>

The APIs necessary to support these functions don't work on Mac/OS and
there are no suitable replacements. The code builds, it just doesn't work.

Rcik

>
> Just a thought: ooRexx 4.0 was released in 2009 ooRexx 4.2 in 2014. During
> that period the Mac was in a transition from PowerPC to Intel processors,
> the first Mac with Intel Processor arriving around 2009.
>
> Could it be that the notion of Mac non-function stems from testing it on
> PowerPC based Macs?
>
> Speaking of tests - I have not been able to find any test cases for these
> functions, have any been written, or could someone write some? I do not
> have the skills for doing so but would happily add them to Jenkins test
> platform.
>
> ---rony
>
>
> On 09.11.2025 00:54, Rony G. Flatscher wrote:
>
> On 08.11.2025 23:11, Rick McGuire wrote:
>
>
>
> On Sat, Nov 8, 2025 at 5:00 PM Rony G. Flatscher <[email protected]>
> wrote:
>
>> On 08.11.2025 21:25, Rick McGuire wrote:
>>
>> They got deprecated because they are impossible to implement on every
>> platform.
>>
>> It seems that in
>> <https://sourceforge.net/p/oorexx/discussion/408478/thread/4d937f7069/?limit=25#c04f>
>> <https://sourceforge.net/p/oorexx/discussion/408478/thread/4d937f7069/?limit=25#c04f>
>>  an
>> inter-process synchronization is sought on Windows. (The built-in classes
>> EventSemaphore and MutexSemaphore would work on all platforms, but within a
>> single process only.)
>>
>> As we have a few Sys-functions (rexxref.pdf, "8.2. List of Rexx Utility
>> Functions") that work only on Windows (e.g., SysBootDrive()) and a few
>> others that work only on Unix (e.g., SysCreatePipe()), we could probably
>> undeprecate these Windows-only Sys-functions as long as they can be
>> implemented on Windows. This would allow the ooRexx users exploiting these
>> Sys-functions to keep on using ooRexx.
>>
>
> The functions also work on the various *ix variants, except for the mac,
> They are still getting built for all the platforms, but are useless on the
> mac. If they get undeprecated, then the mac issue needs to be addressed,
> either by no longer including the functions on the mac build or by
> potentially raising a "Not supported" error on that platform.
>
> Thank you for the information and the hint about the Mac platform!
>
> ---rony
>
>
>
>
>> On Sat, Nov 8, 2025 at 3:21 PM Rony G. Flatscher <[email protected]>
>> wrote:
>>
>>> Here from rexxref.pdf:
>>>
>>> B.1. Incompatible ooRexx features
>>>
>>> Functions or features which have been changed in ooRexx 5.0 in a way
>>> that will lead to
>>> incompatibilities with prior versions.
>>>
>>> B.1.1. RexxUtil SysTempFileName
>>>
>>> SysTempFileName on Unix-like platforms now behaves identically to
>>> SysTempFileName on Windows.
>>> It no longer uses only the first five characters of the file name part
>>> of the template, appending a
>>> random string to make it unique. It also no more prepends an operating
>>> system-chosen writable path if
>>> no path is given in the template. Instead it now uses the same
>>> filler-based mechanism as the Windows
>>> version does.
>>>
>>> Existing ooRexx programs using SysTempFileName on Unix-like platforms
>>> will need to be amended.
>>>
>>> B.2. Deprecated Rexx features
>>>
>>> In exceptional circumstances, ooRexx may deprecate functions or
>>> features, which means the use
>>> of these functions is discouraged, documentation is no longer provided,
>>> and bug reports against
>>> deprecated functions will not be accepted. Reasons for deprecation
>>> include broken functionality,
>>> features that were never officially documented, or functions no longer
>>> required.
>>> Although existing code using deprecated functions is expected to
>>> continue to work as-is, you are
>>> strongly encouraged to migrate to the replacement functionality, as
>>> these functions may be removed
>>> from future releases of the interpreter.
>>>
>>> B.2.1. RexxUtil Semaphore functions
>>>
>>> The following RexxUtil functions related to semaphore-processing have
>>> been deprecated.
>>>
>>> SysCloseEventSem         SysPostEventSem
>>> SysCloseMutexSem         SysPulseEventSem
>>> SysCreateEventSem         SysReleaseMutexSem
>>> SysCreateMutexSem         SysRequestMutexSem
>>> SysOpenEventSem         SysResetEventSem
>>> SysOpenMutexSem         SysWaitEventSem
>>>
>>> They have been superseded by the new EventSemaphore Class and
>>> MutexSemaphore Class.
>>> ... cut ...
>>>
>>> ---rony
>>>
>>>
>>> On 08.11.2025 21:14, Rony G. Flatscher wrote:
>>>
>>> There are a couple of Sys-functions that got deprecated by removing
>>> their documentation from the installation package of ooRexx 5.1.0. Still,
>>> these functions get used and it seems that their system-wide functionality
>>> cannot be replaced by any of the new ooRexx classes.
>>>
>>> The thread in
>>> <https://sourceforge.net/p/oorexx/discussion/408478/thread/4d937f7069/?limit=25#c04f>
>>> <https://sourceforge.net/p/oorexx/discussion/408478/thread/4d937f7069/?limit=25#c04f>
>>> leads to the question:
>>>
>>> "Can't the native functions be undeprecated? It doesn't seem like there
>>> is a replacement for key features they provide, like the ability to share
>>> across processes including non-Rexx processes that can also interact with
>>> the underlying operating system objects."
>>>
>>> Would there be any downsides, if re-instatitng the documentation of
>>> these Sys-functions and formally removing the "deprecate" tag on them?
>>>
>>> ---rony
>>>
>>>
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to