[Oorexx-devel] Announcing BSF4ooRexx 641.20220131, the "general available" (GA) release

[Rony G. Flatscher]

Today, January 31st, 2022, BSF4ooRexx 6.41 has been published as "general 
available" (GA).

BSF4ooRexx is an external ooRexx function and class library that serves as a 
bridge between ooRexx
and Java, effectively camouflaging Java as ooRexx.

BSF4ooRexx allows Rexx programmers to exploit all functionality there is in 
form of Java class
libraries directly from Rexx in a portable manner (such Rexx programs run 
unchanged on Windows,
MacOS and Linux, even GUI programs using the JavaFX libraries).

BSF4ooRexx comes with an extensive set of examples located in the "samples" 
folder which includes an
"index.html" file that briefly explains each short ("nutshell") sample. These 
samples should run
unchanged on Windows, MacOS and Linux.

BSF4ooRexx version "641.20220131" is the last one that supports ooRexx 4.1. 
Here the meaning of the
version string:

  * "6": minimum version of Java that is supported, i.e. Java 6
  * "41": minimum version of ooRexx that is supported, i.e. ooRexx 4.1
  * "20220131": release date, i.e. January 31st, 2022

Here is the download link which includes a "readmeBSF.txt" section:


<https://sourceforge.net/projects/bsf4oorexx/files/GA/BSF4ooRexx-641.20220131-GA/>

BSF4ooRexx 641.20220131, if installed from the zip-archive version
("BSF4ooRexx_install_v641-20220131-ga.zip"), has support for the following 
operating systems:

  * Apple Darwin Intel 64-bit
  * Apple Darwin M1 64-bit
  * Apple Darwin Universal 64-bit
  * Linux ARM 32-bit
  * Linux ARM 64-bit
  * Linux Intel/AMD 32-bit
  * Linux Intel/AMD 64-bit
  * Linux Mainframe s390x
  * Windows 32-bit
  * Windows 64-bit

The universal Apple installation package of BSF4ooRexx 641.20220131
("MacOS_Universal_BSF4ooRexx641GA-20220131-with-ooRexx5r12352.zip") includes 
the latest version of
ooRexx 5.0, i.e. revision 12352.

Please note: for a successful install Java needs to be present on the system. 
If you need to install
Java/OpenJDK then you could also use the links supplied in the "readmeBSF.txt" 
(azul, bellsoft), but
there are numerous Java/OpenJDK installation packages available, including from 
Amazon, IBM,
Microsoft, Oracle (make sure that you download the Java/OpenJDK package that 
includes the powerful
JavaFX GUI libraries).

All in all, making Java class libraries available to ooRexx with the help of 
BSF4ooRexx means that
there is no programming problem or challenge that could not be solved with 
ooRexx on any operating
system platform ooRexx is available!

---rony

P.S.: It is strongly suggested to use ooRexx 5.0, which gets exploited in newer 
samples. ooRexx 5.0
bugs fixed that are present in ooRexx 4.x, is faster and has many helpful and 
noticeable new feature
making programming easier and more fun! :)

P.P.S.: It is planned that the next version of BSF4ooRexx will require ooRexx 
5.0 as one of its
goals is to make a some new native ooRexx APIs available to Java programmers 
who wish to directly
interact with ooRexx objects by sending messages.


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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[Rony G. Flatscher]

Hi P.O.,

On 31.01.2022 17:04, P.O. Jonsson wrote:
>
>> Am 31.01.2022 um 16:49 schrieb Rony G. Flatscher > >:
>>
>>  One of MacPorts ports obviously caused a
>> port of ncurses to be installed on my Apple (not sure when that happened
>
> This happened to me as well, that is why I moved to Homebrew and never 
> regretted it :-)

Yes, can understand that, but it never is wrong to have also MacPorts on the 
radar to learn about
its pecularities, although it steals a lot of time and nerves ...

> Ps I noticed in the BSF thread that you mention that Apple changed „name" 
> from macOS to Darwin? In
> what context? What OS version?  Does it change anything for ooRexx builds?

Apple changed the name from MacOS to Darwin a long while ago, ooRexx (using 
"parse version") returns
the name the operating system tells.

What you saw was a fix to an ooRexx program (a portable ooRexxTry GUI) written 
by two different
students long ago, when ooRexx reported "MacOS" because MacOS reported that. As 
I am preparing the
GA version of BSF4ooRexx I tested the GUI on the Mac where an error caused by 
Java all of a sudden
(Java 8 in this case, font related) would uncover a bug in ooRexxTry.rxj that 
had to do with still
using "M" where now "D" was returned. The fix in this case was to change the 
version letter from "D"
to "M" in case "D" got returned from ooRexx. This will add Mac specific font 
names that are to be
used by ooRexxTry.rxj and fixed the bug.

---rony

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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[Rony G. Flatscher]

On 31.01.2022 17:03, CV Bruce wrote:
> If I remember correctly, there is a port command or option to cause the port 
> to be built from source, I would think that would be a work around.
Yes, I tried that, but to no avail so far.
> I have had trouble in the past mixing “Apple programs” with non-Apple 
> programs, which is why I avoid it. I’ve had problems with old versions, 
> unsupported options, and in one case different functionality. All of this may 
> have been resolved, but once burned…

:)

Can not blame you!

---

My current workaround for creating a universal version of ooRexx is, to do this 
sequence:

sudo port uninstall ncurses

cmake ...

sudo port install ncurses

This seems to work.

---rony

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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[P.O. Jonsson]

Hi Rony,

> Am 31.01.2022 um 16:49 schrieb Rony G. Flatscher :
> 
>  One of MacPorts ports obviously caused a
> port of ncurses to be installed on my Apple (not sure when that happened

This happened to me as well, that is why I moved to Homebrew and never 
regretted it :-)

Ps I noticed in the BSF thread that you mention that Apple changed „name" from 
macOS to Darwin? In what context? What OS version?  Does it change anything for 
ooRexx builds?___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[CV Bruce]

If I remember correctly, there is a port command or option to cause the port to 
be built from source, I would think that would be a work around.

I have had trouble in the past mixing “Apple programs” with non-Apple programs, 
which is why I avoid it. I’ve had problems with old versions, unsupported 
options, and in one case different functionality. All of this may have been 
resolved, but once burned…

Sent by Magic!

> On Jan 31, 2022, at 7:50 AM, Rony G. Flatscher  
> wrote:
> 
> Dear P.O.,
> 
> On 31.01.2022 15:14, P.O. Jonsson wrote:
> ... cut ...
>> Why the urgency to push another ncurses library than the default on macOS?
> 
> There is no "urgency to push another ncurses library" here. One of MacPorts 
> ports obviously caused a
> port of ncurses to be installed on my Apple (not sure when that happened, but 
> I noticed it yesterday
> for the first time after updating the Apple operating systems and in that 
> context had to update my
> MacPorts installation). Not sure why they did if there was one from Apple 
> available anyway.
> 
> It took me a while yesterday to figure out why compiling a universal ooRexx 
> (from a pristine version
> of ooRexx from trunk) did not fail because unlike all other linking only the 
> ncurses one failed.
> After finding the cause I tried to report this and ask for information, hints 
> what to do about it
> such that XCode's SDKs ncurses would be used for linking, not the MacPort one 
> (being installed in
> /opt/local/lib). Maybe there is a possibility in CMake to tell it to use a 
> certain sequence to
> locate the libraries that would allow the SDKs libraries to be found before 
> those
> 
> ---rony
> 
> P.S.: MacPort on my x86_64 is x86_64 only, trying to install all ports with 
> "+universal" did not
> have the effect of getting universal versions of the MacPort ports. There are 
> no links in the /usr
> branch to /opt/local/lib files.
> 
> 
> 
> 
> ___
> 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] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[Rony G. Flatscher]

Dear P.O.,

On 31.01.2022 15:14, P.O. Jonsson wrote:
... cut ...
> Why the urgency to push another ncurses library than the default on macOS?

There is no "urgency to push another ncurses library" here. One of MacPorts 
ports obviously caused a
port of ncurses to be installed on my Apple (not sure when that happened, but I 
noticed it yesterday
for the first time after updating the Apple operating systems and in that 
context had to update my
MacPorts installation). Not sure why they did if there was one from Apple 
available anyway.

It took me a while yesterday to figure out why compiling a universal ooRexx 
(from a pristine version
of ooRexx from trunk) did not fail because unlike all other linking only the 
ncurses one failed.
After finding the cause I tried to report this and ask for information, hints 
what to do about it
such that XCode's SDKs ncurses would be used for linking, not the MacPort one 
(being installed in
/opt/local/lib). Maybe there is a possibility in CMake to tell it to use a 
certain sequence to
locate the libraries that would allow the SDKs libraries to be found before 
those

---rony

P.S.: MacPort on my x86_64 is x86_64 only, trying to install all ports with 
"+universal" did not
have the effect of getting universal versions of the MacPort ports. There are 
no links in the /usr
branch to /opt/local/lib files.




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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[P.O. Jonsson]

Dear Rony,

On the Jenkins macOS agents I have added fileicon, subversion and cmake using 
Homebrew but I have NOT installed ncures, I use what is on the machine per 
default.

Here is what I see on macOS Big Sur 11.3, Darwin 20.3 (on an Intel based 
machine):
-- Looking for wsyncup in 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libcurses.tbd
-- Looking for wsyncup in 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libcurses.tbd - 
found
-- Looking for cbreak in 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libncurses.tbd
-- Looking for cbreak in 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libncurses.tbd 
- found
-- Looking for nodelay in 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libncurses.tbd
-- Looking for nodelay in 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libncurses.tbd 
- found
-- Found Curses: 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/lib/libncurses.tbd  
-- CURSES_HAVE_NCURSES_H is 
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include/ncurses.h
-- CURSES_HAVE_NCURSES_NCURSES_H is CURSES_HAVE_NCURSES_NCURSES_H-NOTFOUND
-- CPACK_PACKAGE_FILE_NAME ooRexx-5.0.0-12352.macOS.arm64.x86_64
-- Configuring done

Here on macOS Monterey 12.2, Darwin 21-3:
-- Looking for wsyncup in 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libcurses.tbd
-- Looking for wsyncup in 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libcurses.tbd - 
found
-- Looking for cbreak in 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libncurses.tbd
-- Looking for cbreak in 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libncurses.tbd 
- found
-- Looking for nodelay in 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libncurses.tbd
-- Looking for nodelay in 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libncurses.tbd 
- found
-- Found Curses: 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libncurses.tbd  
-- CURSES_HAVE_NCURSES_H is 
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/ncurses.h
-- CURSES_HAVE_NCURSES_NCURSES_H is CURSES_HAVE_NCURSES_NCURSES_H-NOTFOUND
-- CPACK_PACKAGE_FILE_NAME ooRexx-5.0.0-12352.macOS.arm64.x86_64
-- Configuring done

Please not the .tbd ending (not dylib) They both pass all tests, including the 
ncurses.testGroup

Why the urgency to push another ncurses library than the default on macOS?

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



> Am 30.01.2022 um 20:17 schrieb Rony G Flatscher :
> 
> Where does brew stuff its binaries?
> 
> It looks as if CMske resorts to XCode‘s SDK if it does not find the needed 
> resources. There might be some cmake definition that may influence the search 
> order bit I did not find one.
> 
> —-rony
> 
> Rony G. Flatscher (mobil/e)
> 
>> Am 30.01.2022 um 19:33 schrieb René Jansen :
>> 
>> Tried this on M1, no problem.
>> Tried this on X86_64, no problem
>> 
>> Both on 12.2, I use ninja for building the CMake-generated stuff, only 
>> difference is that I use brew and not ports.
>> There is always some movement needed when upgrading macOS, I mostly do that 
>> by starting the Xcode GUI once and doing a
>> 
>> xcode-select —install
>> 
>> From the command line. Sometimes that tells me to sudo, which I then do.
>> 
>> Best regards,
>> 
>> René.
>> 
>> 
>>> On 30 Jan 2022, at 18:46, Rony G. Flatscher >> > wrote:
>>> 
>>> Upgraded my Intel Apple to macOS Monterey, version 12.2. 
>>> Using MacPort which got updated as well. MacPort will install its libraries 
>>> to /opt/local/lib which includes ncurses.
>>> Downloaded a fresh, pristine version of ooRexx from trunk and started to 
>>> create a universal build with: 
>>> cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_OSX_UNIVERSAL_BINARIES=1  
>>> ~/dev/oorexx_allura/main/trunk
>>> -- CMake version is 3.22.2
>>> -- The C compiler identification is AppleClang 12.0.5.12050022
>>> -- The CXX compiler identification is AppleClang 12.0.5.12050022
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working C compiler: 
>>> /Library/Developer/CommandLineTools/usr/bin/cc - skipped
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Check for working CXX compiler: 
>>> /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Building for a 64-bit architecture
>>> -- OOREXX_SHEBANG_PROGRAM: "/usr/bin/env rexx" (default)
>>> -- Found Subversion: /opt/local/bin/svn (found version "1.14.1") 
>>> -- SVN Revision Number is 12352
>>> -- CMAKE_INSTALL_PREFIX is /Users/rony/Applications/ooRexx5
>>> -- INSTALL_LIB_DIR is lib
>>> -- Looking for xlocale.h
>>> -- 

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[René Jansen]

One comment on homebrew - don’t choose your own location, but always take the 
default. Some packages do not treat the deviation well, but will not tell you, 
and will, e.g. always build from source and disregard things that are already 
there, so you’ll see gcc and openssl built from source every time, which will 
only heat up your laptop and is not very useful, especially when the package 
build fails anyway.

And always have a large scroll back buffer, because indeed homebrew is very 
talkative, but you need to go over it in detail after an install, yo make sure 
you can find includes or link to libraries later. I still prefer it over 
MacPorts.

Best regards,

René.

> On 31 Jan 2022, at 12:48, Rony G. Flatscher  wrote:
> 
> Hi Mark,
> 
> On 31.01.2022 01:27, Mark Hessling wrote:
>> As P.O. says, Homebrew installs its binaries in /Cellar and 
>> symbolically links those
>> binaries to /usr/local/bin. However, if the package you are installing is 
>> already supplied by
>> Apple in macOS, it DOES NOT do the symbolic link.  In your case ncurses is 
>> supplied by Apple so
>> the symbolic link is not done by HomeBrew.  It does tell you this when you 
>> are installing. So to
>> get the Homebrew version of ncurses, you may have to manually link the 
>> files, or set environment
>> variables so the HomeBrew version is loaded first. 
> 
> thank you very much!
> 
> Cheers
> 
> ---rony
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[Rony G. Flatscher]

On 31.01.2022 00:32, CV Bruce wrote:
> It really sounded like the MacPorts library was X86_64 only, Did you check 
> it’s architecture with
> ‘file’?

yes, they are x86_64.

---rony


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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[Rony G. Flatscher]

Dear P.O.,

On 31.01.2022 08:33, P.O. Jonsson wrote:
>
>> Am 31.01.2022 um 00:29 schrieb Rony G Flatscher > >:
>>
>> with a ncurses bittle
>
> Rony, what do you mean with bittle?
It should have read "bottle".
> ncurses is built by ooRexx build in the normal case
>
> I have tried it on macOS (you have my results I think) but on a High Sierra 
> or Mojave machine,
> both migrated a number of times, so not „clean“ installs.
>
> I can have a go at testing your baby this afternoon on Big Sur/Monterey in a 
> clean build, if you
> send me your files + instructions
> /P.O.

thank you for your kind offer, you would have to install macports and use a 
pristine oorexx from
trunk. But it is not necessary to duplicate this problem.

I am just curious whether it would be possible to add some definition to 
CMakeLists.txt that causes
searching for libraries in the XCode/SDK libraries first.

Cheers

---rony

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

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[Rony G. Flatscher]

Hi Mark,

On 31.01.2022 01:27, Mark Hessling wrote:
> As P.O. says, Homebrew installs its binaries in /Cellar and 
> symbolically links those
> binaries to /usr/local/bin. However, if the package you are installing is 
> already supplied by
> Apple in macOS, it DOES NOT do the symbolic link.  In your case ncurses is 
> supplied by Apple so
> the symbolic link is not done by HomeBrew.  It does tell you this when you 
> are installing. So to
> get the Homebrew version of ncurses, you may have to manually link the files, 
> or set environment
> variables so the HomeBrew version is loaded first. 

thank you very much!

Cheers

---rony




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