Re: [Oorexx-devel] Please help: how can i configure Open Object Rexx 5.1 in OpenSuse Leap 15.4

[CV Bruce]

On Linux and Unix, your Rexx program needs to start with a line like#!/path/to/rexxWhere path/to/Rexx is the path to where the Rexx executable is installed.And the Rexx program must have its permissions set to executable, I.e. “chmod 755 myRexxProgram.rex”BruceSent by Magic!On May 12, 2023, at 5:22 AM, Franz Marx  wrote:Hi,i have to learn still a lot for OpenSuse, but I have time."It's a rainy day, hallelujah ..."珞Grüsse aus ÖsterreichFranzAm Fr., 12. Mai 2023 um 14:08 Uhr schrieb ooRexx :Hi,I am not sure I understand the question. Once you have installed ooRexx it should work out of the box, there is nothing to configure on the ooRexx side, you just call it with rexx myprogram.rex, you can leave out the extension so rexx myprogram suffices. Similar to how you call a Python program. Be aware that there are no GUI features for any other implementation than Windows (ooDialog), it is all done on the command line for all the Linuxes and in macOS.If you mean that you want to be able to “click” the program to start it from a Graphical interface you could try to change the rules for how a certain extension is handled in OpenSuse as explained here, but I am no expert in how this works out you will have to figure that out yourself. Hope it helps.
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se

On 12. May 2023, at 13:39, Franz Marx  wrote:Hi, Mr. Jonson!First of all: the Installation worked with your detailed advice, of course!But One thing I still miss:how can I configure the Open Rexx Version 5.1.0 within OpenSuse Leap 15.4 ?Like in Windows, my *.rex program should be executed immediately.i am sorry to be such inexperienced to bore you with this question 蘿I only find Rexxtry within the App-Listing  (that works, of course)regardsFranzAm Mi., 10. Mai 2023 um 15:25 Uhr schrieb ooRexx :Hi,Suse is one of the most unproblematic/stable platforms for ooRexx, I have hardly ever seen a problem in the testing so go ahead and do not hesitate to report back any problem you find (I bet one bottle of beer that you won’t find any :-) )Try to ignore the “Beta” in the name of the rolling release, it is solid as a rock in my experience. Since 5.0.0 was so long in the coming, a number of minor things were missed out in the release, mostly in the documentation area. All those things are ironed out in 5.1.0. Installation procedure is exactly the same. Good luck.
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se

On 10. May 2023, at 14:21, Franz Marx  wrote:Hi P.O. Jonsson!Thank you very much for your detailed description, I will now try to install release 5.1.0 Beta,as you suggest.One explanation from me, why i like to use SuSE:it`s because i had already experience making SuSE SLES Installations productiveon PC's in the 2010's and also on IBM zSeries (and it comes from Europe!)  before I retired.Yours sincerelyFranz MarxooRexx  schrieb am Mi., 10. Mai 2023, 12:04:Hi Franz,Nice to hear that you want to try out ooRexx!Indeed the package for OpenSuse (and all other packages I think) is unsigned so you would need to ignore the warning when it arrives. The steps would be (assuming the installer is in Downloads):noob:~/Downloads> sudo zypper install ooRexx-5.0.0-12583.opensuse15.x86_64.rpm[sudo] password for root: Loading repository data...Warning: Repository 'Update repository of openSUSE Backports' appears to be outdated. Consider using a different mirror or server.Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. Consider using a different mirror or server.Reading installed packages...Resolving package dependencies...The following NEW package is going to be installed:  ooRexx1 new package to install.Overall download size: 1.0 MiB. Already cached: 0 B. After the operation,additional 6.6 MiB will be used.Continue? [y/n/v/...? shows all options] (y): yRetrieving package ooRexx-5.0.0-12583.x86_64                                           (1/1),   1.0 MiB (  6.6 MiB unpacked)ooRexx-5.0.0-12583.opensuse15.x86_64.rpm:    Package header is not signed!ooRexx-5.0.0-12583.x86_64 (Plain RPM files cache): Signature verification failed [6-File is unsigned]Abort, retry, ignore? [a/r/i] (a): iAfter that it should work.To uninstall it usesudo zypper remove ooRexx(Note: there is a minor bug here, the name of the installed package should be oorexx to follow convention this is fixed in the running release 5.1.0Beta)Good luck.
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se

On 10. May 2023, at 11:05, Franz Marx  wrote:To the team of oorexx-devel@lists.sourceforge.net>I already installed the new Open Rexx Version 5.0 on my Windows 10 Acer-Laptop.I am very pleased and satisfied with the performance of this version.I have an older HP-Laptop with dual boot Windows 10 and OpenSuse Leap 15.4.Calculating 4 Million Primes with my Rexx-Program using Windows 10 it tookson the ACER-Laptop: 5639 secs. 

Re: [Oorexx-devel] Package name casing

[CV Bruce]

I’ve kept quiet on this issue, but I’d like to point out that for those of us 
that have issues reading, such as dyslexia, mixed case allows easier parsing of 
the text. Where possible I agree with supporting the “brand name” of the 
software, such as CentOS over centos. 
My 2¢.
Bruce

Sent by Magic!

> On Apr 19, 2023, at 7:32 AM, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> 
> Dear all
> 
> Unfortunately too much has been said about the subject issue
> And more unfortunately it was just a … I think,   I heard somewhere, somebody 
> else said …
> Without having done the due diligence
> 
> I researched a bit and what I found is that …
> 
> The casing rules are mandatory for the names of packages distrbuted 
> automagically from the system repositories handled by the system package 
> manager
> Generally  they are all lower case,  
> Fedora  makes an exception for that, recognising the right for the owners(s) 
> of SELECTED  packages to use a name of their choice
> 
> An example close to us 
> Mike Cowlishaw’ s General Decimal Arithmetic package is distributed as 
> decNumber-icu-368.zip
> 
> Another example from my real life experience
> John Hauser’s Berkeley SoftFloat library conforming to IEEE Standard for 
> Floating-Point Arithmetic is distributed as SoftFloat-3e.zip
> 
> IMO - with the due respect - Mark Hessing request was due to a 
> misunderstanding of the home-brew rules
> What has to be LOWER CASE is the the home-brew formula name … not the real 
> package source name ( hidden inside the rb formula )
> They suffer from OCD  about the naming, they remarked quite a few times that 
> the proper name is formula/( plural formulae) , not package
> 
> For macports mixed case package names are accepted
> 
> Anyway I feel that we should respect the brand/trademark  name casing 
> 
> For Apple it should be macOS, NOT macos/macOSX/macosx , the distributables 
> are mixed case also for the extra packages 
> (They made a public announcement about changing the system name)
> Since I am an Apple user I had no need to research 
> 
> A quick and dirty research  for other environments gave back
> 
> For Debian the name should be Debian,  the distributable are lower case ==> 
> debian-11.6.0-arm64-netinst.iso
> 
> For Fedora the name should be Fedora,  the distributable are mixed case  ==> 
> Fedora-Workstation-38-1.6.aarch64.raw.xz 
> And also found the manual  
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/
> 
> For CentOS  the names are … CentOS and CentOS-Stream , the distributable are 
> mixed case ==> CentOS-Stream-9-latest-aarch64-dvd1.iso
> For the standards CentOS refers to the Fedora manuals
> 
> For FreeBSD the name is, guess what … FreeBSD, and the distributable are 
> mixed case ==> FreeBSD-13.1-RELEASE-amd64-dvd1.iso.xz
>  
> 
> My best regards 
> 
> Enrico 
> 
> PS
> 
> A quick and dirty search gave back that 
> 
> Fedora 36 provides an oorexx-4.2.0-3.x86_64.rpm  in third party repository 
> https://fedora.pkgs.org/36/rpm-sphere-x86_64
> And they even provide an aarch64 rpm 
> 
> Since the repository contains mixed case file names , maybe somebody from the 
> RexxLA might want to ask them to use a proper name casing  ( ooRexx )
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> ___
> 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] I think I've seen the future...

[CV Bruce]

I’ve played with ChatGPT, nothing as complex as your example, and it is amazing.But don’t underestimate that Rick had the expertise to recognize that the first solution presented had the same problems as the current code. Rick was also able to criticize the solution, which enabled the AI to generate a better solution. Again, Rick had the expertise to evaluate the second solution as to its suitability.It kind of seems like the days when people checked the assembler created by the compiler to make sure the compiler was “doing it right”. I think we are crossing a bridge from one technology to the next, and until full faith can be give to the new technology, check and check again.BruceSent by Magic!On Jan 23, 2023, at 6:42 AM, Rick McGuire  wrote:On Mon, Jan 23, 2023 at 9:34 AM Sahananda Sahananda  wrote:Rick,Fascinating!I'm really impressed and grateful for the time that you put into trying to solve this question.  Did ChatGPT provide the comments and variable names as well?  That was a direct cut and paste from the chat session. It provided anything. Do you think it 'created' that code or merely 'found it' already solved by human brains?I actually think it created the code. As a result of the chat, it needed to make adjustments to the orginal code. Also, I spent a LOT of time looking for an example like this one, in any form. If a clear one like this had existed, I believe I would have found it.Rick JonOn Mon, 23 Jan 2023 at 14:21, Rony G. Flatscher  wrote:
On 23.01.2023 14:17, Mike Cowlishaw wrote:
>   
>> "but still humans need to be able to
>> understand and assess/control them otherwise humanity becomes
>> helpless and dependent over time"
> So it just happens earlier in life ...?  :-))
Indeed! 


___
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 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

Re: [Oorexx-devel] Suggestions, notes, and "yep, ooRexx V5 works"...

[CV Bruce]

Good points Bill. Many Linux(s) have more than one “current” version. One is the most current and the other is the LTS current version. Sometimes they are one and the same. What is our strategy for dealing with this environment?BruceSent by Magic!On Jan 3, 2023, at 7:13 AM, Bill Turner, WB4ALM  wrote:
  


  
  


I would also like to suggest, that starting with Release 5, that a
version be pre-compiled for LINUX MINT 21. 
I have found a number of folks who are not happy with some of the
recent versions of UBUNTU, and many of them are switching to LINUX
MINT 17 or LINUX MINT 21.

Even though the Linux Mint 21 operating system is based upon UBUNTU
22.04;  
UBUNTU 22.04 or 22.04.1  will not run reliably on my desktop, but
LINUX MINT 21 and 21.1 run without any problems.

I downloaded the UBUNTU version of ooRexx 5.0, and it runs on my
Linux Mint 21 system with no problems.


Other notes:


1) Sourceforge: If I tell folks to go to sourceforge.net and enter
"ooRexx" in the search box, what they get is confusing:
   ( apparently our description of "Open Oject Rexx" does not
include the "keyword "ooRexx" so we do not get listed.)
    
   if you do enter "ooRexx", a pop-box is displayed that says
===
   "open Source Projects"
        OS2-OORexx
        OORexxDoc
  and a second search box that says "search Open Source for
"ooRexx"...
===

 If they click on that second level suggested search, they get a new
popup windows that identifies "open Object Rexx" as the third or
fourth item making it appear that ooRexx is not a "primary" product.


So I have to tell folks to go to  
https://sourceforge.net/projects/oorexx/files/   
  and select "oorexx", 
      and then select "5.0.0" 
 and then based upon their operating system
    (for windows)        select "ooRexx-5.0.0-12583.windows.x86_64.exe"
      (for ubuntu 22.04)    select "ooRexx-5.0.0-12583.ubuntu2204.x86_64.deb"
      (for Linux Mint 21)    select "ooRexx-5.0.0-12583.ubuntu2204.x86_64.deb"  
or  "ooRexx-5.0.0-12583.linuxmint20.x86_64.deb"

Non-programmers find this very confusing and so they won't always
try it



2) The ooRexx SQLite package works under Version 5 with no problems.



3) Don't know about the RexxGTK, it does not seem to work on my
system.



4) It would be nice if RexxMods could be brought "up to date" with
better documentation.
    I would like to use it, but can't figure out how to install it
correctly.


/s/ Bill Turner, wb4alm



  

___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

Re: [Oorexx-devel] MacOS zip problems (Re: Ad state of docs/branches/5.0.0

[CV Bruce]

I’ve read the referenced material, and I don’t think it applies to this 
problem. The references mention archives with greater than 64k files or greater 
than 4Gb in size. 
When the archive exceeds these parameters, zip64 is invoked.

It appears that the incompatibility problems are created by the zip64.

It sounds to me that the limits were in response to the FAT16 file system.

I’m glad a work around was found.

Sent by Magic!

> On Dec 22, 2022, at 3:23 AM, Rony G. Flatscher  
> wrote:
> 
> 
>> On 22.12.2022 08:30, ooRexx wrote:
>> Re
>> 
>> 
>>> On 22. Dec 2022, at 01:15, Gilbert Barmwater  wrote:
>>> 
>>> And thanks for all the work I know this took!
>>> 
>>> Gil
> +1
>> It is a bit depressing to spend half a day hunting for the problem and in 
>> the end all you do is replacing zip -r -q with 7zz a
>> 
>> In the end it was a good thing; I went through my HowTo and amended a couple 
>> of things. fop is now 2.8 on macOS for instance, it used to be 2.4 when I 
>> used it first time. Will commit it today but will check the Linux version 
>> first.
> It seems that this as an intentional incompatibility by MacOS judging from 
> 
>  from six years ago. And also from 
>  from 2018. 
> 
> Great that you could find a working solution!
> 
> ---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] tools/bldoc_orx/setup.rex error, non existing server?

[CV Bruce]

I agree with P.O. regarding building documents. The most I’d expect is a build 
(plain text) document that would list dependencies, including minimum version, 
as well as their home.

Personally, I’ve always built oorexx from source, but I’ve never found it 
necessary to build the docs.

Bruce

Sent by Magic!

> On Dec 21, 2022, at 8:54 AM, P.O. Jonsson  wrote:
> 
> Dear Gil,
> 
> In my experience every URL is invalid the next time you try to use it :-) so 
> my approach is another one. For macOS and Linux I included zipped folders 
> with a set of tools that DID work when I zipped them, as well as a list of 
> requirements that the user must take care of him/herself. In that way it 
> should be possible to get going, also if some of the tools are out of date. I 
> cannot imagine that too many people besides the two of us actually build the 
> documentation for ooRexx voluntarily :-)
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
> 
> 
> 
> 
>> Am 21.12.2022 um 17:37 schrieb Gilbert Barmwater :
>> 
>> When I first wrote setup.rex the goal was to make it easy for the new 
>> (Windows) user to get all the pieces needed to build the ooRexx 
>> documentation.  Most of those pieces were pretty straight forward as they 
>> were fairly static so coding web addresses and file names was not a problem. 
>>  FOP however was a different story.  There is active work ongoing for this 
>> project so the version, and hence the file name, changes from time to time.  
>> This was reported first by Jean_Louis and it resulted in an update to 
>> dynamically determine the most recent version from the Apache web site and 
>> download it as opposed to trying to download an older version which might 
>> have been archived and hence not where the current version was located.  Now 
>> it appears that the mirror sites which is where one must go to download the 
>> files also changes from time to time.   I will work on automating the 
>> determination of the mirror site and update the script once I do.  In the 
>> meantime, around line 191 is the URL of the mirror site which has apparently 
>> gone away.  If you replace it with 
>> "https://dlcdn.apache.org/xmlgraphics/fop/binaries/;, the now suggested 
>> mirror for downloads, it should run successfully.  NB. I have NOT actually 
>> confirmed that at this time.
>> 
>> Gil
>> 
>> On 12/20/2022 9:14 AM, Rony G. Flatscher wrote:
>>> Just used "tools\bldoc_orx\setup.rex" and get the following error:
>>> 
>>> Downloading fop-2.8-bin.zip
>>> Start-BitsTransfer : HTTP-Status 404: Die angeforderte URL ist auf diesem 
>>> Server nicht vorhanden.
>>> At line:1 char:1
>>> + Start-BitsTransfer https://mirror.nodesdirect.com/apache/xmlgraphics/ ...
>>> + ~
>>> + CategoryInfo  : InvalidOperation: (:) [Start-BitsTransfer], 
>>> Exception
>>> + FullyQualifiedErrorId : 
>>> StartBitsTransferCOMException,Microsoft.BackgroundIntelligentTransfer.Management.NewBitsTransferCommand
>>> 
>>> Error retrieving fop-2.8-bin.zip; RC was 1.
>>> 
>>> It is at: . 
>>> 
>>> The script uses 
>>> "https://mirror.nodesdirect.com/apache/xmlgraphics/fop/binaries/; which 
>>> returns a 404.
>>> 
>>> ---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
> 
> ___
> 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] Wrong Apple version of ooRexx serviced by the Sourceforge website

[CV Bruce]

+1. What’s the old saying about perfection being the enemy of good enough?

Sent by Magic!

> On Dec 14, 2022, at 5:34 AM, Mike Cowlishaw  wrote:
> 
> I fear that if we just keep discussing things that need to be done another
> 10 years will pass.
> 
> Surely the priority here is to get 5.0 out there for most platforms, and
> worry about loose ends afterwards?
> 
> Mike
> 
> 
>> -Original Message-
>> From: Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at] 
>> Sent: 14 December 2022 13:24
>> To: oorexx-devel@lists.sourceforge.net
>> Subject: Re: [Oorexx-devel] Wrong Apple version of ooRexx 
>> serviced by the Sourceforge website
>> 
>> On 13.12.2022 16:59, P.O. Jonsson wrote:
 This was my point: currently all Apple users get outdated not 
 workable ooRexx by the official ooRexx site. ALLl official 
>> versions 
 of ooRexx for macOS are broken and do not install, not the 
>> 32 bit and 
 not the 64 bit version of ooRexx 4. We do not currently have ANY 
 official version of ooRexx that install with ANY Mac (Intel or 
 M1/ARM) running OS X El Capitan (2015) (OS X 10.11) or newer. This 
 problem is 7 years old :-(
>>> Dear Rony, I take that back, actually the official 64 bit 
>> version DOES work, and installs to /opt. I think this was my 
>> tinkering way back then. But /opt is a hidden folder on macOS 
>> so not so easy to find back once installed.
>>> 
>>> You still need to set PATH=/opt/ooRexx/bin:$PATH (and 
>> DYLD_LIBRARY_PATH=/opt/ooRexx/lib/ooRexx) to make it run and 
>> there is no uninstaller. But changing the pointer to 64 bit 
>> instead of 32 bit would be a good thing, also if the 4.1.2 is 
>> now 10 years old (September 2012).
>> 
>> Just tried it from my Mac and got as download offered a "4.0 
>> all" zip, which is also neither helpful nor useful for Apple 
>> users. So it is really time to get a nice, working and 
>> up-to-date version of ooRexx to the Apple table ...
>> 
>> ---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] OORexx beta - Unable to load library "RXMATH

[CV Bruce]

Is case O/S dependent?

Sent by Magic!

> On Nov 30, 2022, at 1:46 AM, Erich Steinböck  
> wrote:
> 
> 
> Hi Cyril,
> the library is called rxmath (all lowercase), not RXMATH.
> To load it, use ::requires "rxmath" library
> 
> (CLASSPATH isn't used with ooRexx)
> ___
> 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] Add fish to the list of Unix ADDRESS environments

[CV Bruce]

In my small education in UNIX/Linux shells, I believe that I read that some 
shells will change their behavior depending on the name that they are invoked 
with. /bin/sh has behaviors defined in POSIX standards, and on many Linux 
systems is linked to bash. When invoked by /bin/sh it takes on the POSIX 
behaviors. I would assume that dash would do the same, but I don’t know that 
for sure.

What that means is that certain language features that are available when 
invoked by the true name cease to work when invoked by the alias name. 

I believe this is documented on the shell man page.

Bruce 

Sent by Magic!

> On Sep 12, 2022, at 2:44 AM, Erich Steinböck  
> wrote:
> 
> 
> Hi Leslie,
> I think when this was last discussed it was agreed that nowadays typically sh 
> would be a link to the preferred shell.
> Like on my old Ubuntu it is /bin/sh -> dash
> 
> With this ooRexx won't have to create new environments dedicated to a 
> specific shell and users could consistently code address sh or address ""
> ___
> 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 ...

[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 ...

[CV Bruce]

It really sounded like the MacPorts library was X86_64 only, Did you check it’s 
architecture with ‘file’? 


Sent by Magic!

> On Jan 30, 2022, at 10:33 AM, René Jansen  wrote:
> 
> 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
>> -- Looking for xlocale.h - found
>> -- Looking for malloc.h
>> -- Looking for malloc.h - not found
>> -- Looking for alloca.h
>> -- Looking for alloca.h - found
>> -- Looking for signal.h
>> -- Looking for signal.h - found
>> -- Looking for time.h
>> -- Looking for time.h - found
>> -- Looking for inttypes.h
>> -- Looking for inttypes.h - found
>> -- Looking for stdint.h
>> -- Looking for stdint.h - found
>> -- Looking for nsleep
>> -- Looking for nsleep - not found
>> -- Looking for nanosleep
>> -- Looking for nanosleep - found
>> -- Looking for crypt in crypt
>> -- Looking for crypt in crypt - not found
>> -- Looking for crypt
>> -- Looking for crypt - found
>> -- Looking for wordexp
>> -- Looking for wordexp - found
>> -- Looking for wordexp.h
>> -- Looking for wordexp.h - found
>> -- Looking for sys/xattr.h
>> -- Looking for sys/xattr.h - found
>> -- Looking for catopen
>> -- Looking for catopen - found
>> -- Looking for dlfcn.h
>> -- Looking for dlfcn.h - found
>> -- Looking for features.h
>> -- Looking for features.h - not found
>> -- Looking for filehdr.h
>> -- Looking for filehdr.h - not found
>> -- Looking for euidaccess
>> -- Looking for euidaccess - not found
>> -- Looking for nl_types.h
>> -- Looking for nl_types.h - found
>> -- Looking for pthread.h
>> -- Looking for pthread.h - found
>> -- Looking for pthread_mutex_timedlock
>> -- Looking for pthread_mutex_timedlock - not found
>> -- Performing Test HAVE_DLADDR
>> -- Performing Test HAVE_DLADDR - Success
>> -- Looking for _PC_CASE_SENSITIVE
>> -- Looking for _PC_CASE_SENSITIVE - found
>> -- Looking for FNM_CASEFOLD
>> -- Looking for FNM_CASEFOLD - found
>> -- Looking for KDMKTONE
>> -- Looking for KDMKTONE - not found
>> -- Looking for FS_CASEFOLD_FL
>> -- Looking for FS_CASEFOLD_FL - not found
>> -- Looking for _NSGetExecutablePath
>> -- Looking for _NSGetExecutablePath - found
>> -- Looking for getexecname
>> -- Looking for getexecname - not found
>> -- Looking for KERN_PROC_PATHNAME
>> -- Looking for KERN_PROC_PATHNAME - not found
>> -- Looking for KERN_PROC_ARGV
>> -- Looking for KERN_PROC_ARGV - not found
>> -- Performing Test HAVE_STAT_ST_MTIM
>> -- Performing Test HAVE_STAT_ST_MTIM - Failed
>> -- Performing Test HAVE_STAT_ST_MTIMESPEC
>> -- Performing Test HAVE_STAT_ST_MTIMESPEC - Success
>> -- Looking for pwd.h
>> -- Looking for pwd.h - found
>> -- Looking for sched.h
>> -- Looking for sched.h - found
>> -- Looking for strings.h
>> -- Looking for strings.h - found
>> -- Looking for sys/filio.h
>> -- Looking for sys/filio.h - found
>> -- Looking for sys/ldr.h
>> -- Looking for sys/ldr.h - not found
>> -- Looking for sys/resource.h
>> -- Looking for sys/resource.h - found
>> -- Looking for sys/select.h
>> -- Looking for sys/select.h - found
>> -- Looking for sys/sem.h
>> -- Looking for sys/sem.h - found
>> -- Looking for sys/signal.h
>> -- Looking for 

Re: [Oorexx-devel] Official Apple advice howto allow apps to run despite Gatekeeper

[CV Bruce]

I’m sorry I didn’t speak up, but it has been this way for years. I thought that 
there was something new in Big Sur.

Sent from my iPad

> On Jul 18, 2021, at 8:51 AM, Rony G. Flatscher  
> wrote:
> 
> As I have encountered this with Apache OpenOffice as well (and could solve 
> the issue with removing the extended quarantine attribute) I was curious how 
> the AOO project addresses this problem. 
> 
> AOO points to  which documents the 
> situation by Apple, but around the bottom Apple shows an official way how to 
> solve it (while the popup is there go to "Tools" -> "Security & Privacy" -> 
> "General" and at the bottom right-hand side click "Open Anyway").
> 
> ---rony
> 
> 
> 
>> On 16.07.2021 16:15, Rony G. Flatscher wrote:
>> Just tested the new version of the BSF4ooRexx command line installer and it 
>> works with the official ooRexx 5 installation. To test:
>> 
>> download 
>> "https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/BSF4ooRexx_install_v641-20210715-beta.zip;
>>  
>> run "xattrs -d com.apple.quarantine 
>> BSF4ooRexx_install_v641-20210715-beta.zip"
>> unzip
>> change into "bsf4oorexx/install/macosx", issue "sh install.sh"
>> BSF4ooRexx gets copied to "/opt/BSF4ooRexx"
>> to uninstall use "sh /opt/BSF4ooRexx/install/macosx/uninstall.sh"
>> ---rony
>> 
>> P.S.: The alternative would be to use the GUI-package for MacOSX which 
>> includes ooRexx 5:
>> 
>> download 
>> "https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/b4r_641_500_64Bit_macosx-universal-20210627-r12266.zip;
>> run "xattrs -d com.apple.quarantine 
>> b4r_641_500_64Bit_macosx-universal-20210627-r12266.zip"
>> unzip and open the package for installation
>> to uninstall: use the menu by opening "/Applications/ooRexx.app", choose 
>> "Installation -> Uninstall"
>> 
>> 
>>> On 16.07.2021 15:41, Rony G. Flatscher wrote:
>>> While testing a little bit, here is maybe another helpful insight: after 
>>> downloading the ooRexx installation package it is possible without 
>>> super-user power to remove the quarantine attribute using Renés example:
>>> 
>>> xattr -d com.apple.quarantine ooRexx-5.0.0-12280.macOS.x86_64.dmg
>>> 
>>> Then installing ooRexx by opening the dmg-file and following the 
>>> installation directions yields a working installation in 
>>> /Applications/ooRexx5!
>>> 
>>> ---rony
>>> 
>>> 
 On 16.07.2021 14:27, René Jansen wrote:
 Running 
 
 sudo xattr -r -d com.apple.quarantine $YOUR_DIRECTORY 
 
 mostly helps.
 
 René
 
> On 16 Jul 2021, at 14:10, P.O. Jonsson  wrote:
> 
> What version of MacOS are we talking about? In the past extracting the 
> .dmg caused a warning that could be overwritten but I never experienced 
> that rexx would not launch? Is this a M1 thing only? Or „Fat Binary“ 
> problem? Does it help to install to ~/Applications (a local install) 
> rather than to /Applications (Install for all users)? 
> 
> I run High Sierra (10.13) and the build machine runs Mojave (10.14). In 
> view of the age of the build machine (~ late 2014) I would not go beyond 
> Catalina (10.15) and I see no gain in changing, just risk of running into 
> problems with outdated hardware.
> 
> We do not have at our disposal any machine with macOS Big Sur (11.1) that 
> can run on either Intel or M1 hardware.
> 
> What I can try to do is to see if I can get some Virtual Machines set up 
> with Catalina/Big Sur. But it will not be on M1 hardware.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
> 
> 
> 
>> Am 16.07.2021 um 13:47 schrieb Rony G. Flatscher 
>> :
>> 
>> Downloaded the latest MacOS version of ooRexx 5.0 from the ooRexx 
>> project page at sourceforge. 
>> 
>> It turns out that Apple inhibits using anything from that dmg as it was 
>> downloaded from the Internet and not from Apple's store! :(
>> 
>> This is due to Apple's "security policy" that they put in effect, which 
>> simply deprive the owners of those Apple computers. 
>> 
>> Here are two use cases, each demonstrated with an attached screenshot:
>> 
>> Scenario 1: installing ooRexx according to the readme will create 
>> "/Application/ooRexx5" with the "bin", "lib" etc directories. Trying to 
>> run "/Application/ooRexx5/bin/rexx -v" causes "Screenshot 2021-07-16 at 
>> 12.46.04.png" to pop up. Apple suggests to move the program to the bin! 
>> :-(
>> 
>> Scenario 2: using Finder to "open" (run) "/Application/ooRexx5/bin/rexx" 
>> yields at first a pop up that seems to indicate, that further opening 
>> would allow the program to run from now on, cf. "Screenshot 2021-07-16 
>> at 12.53.17.png". However when "rexx" loads the "librexx.4.dylib" the 
>> "Move to Bin" popup as above gets displayed!
>> Probably turning off SIP 
>> 

Re: [Oorexx-devel] MacOSX: Rexx-script to link ooRexx5

[CV Bruce]

I believe oorexx-config is a Linux-ism that you can include in a make file to 
populate variables with information about where various parts of oorexx can be 
found.
Bruce

Sent by Magic!

> On Jul 16, 2021, at 9:02 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Fri, Jul 16, 2021 at 11:41 AM P.O. Jonsson  wrote:
>> Dear Rony, just some thoughts.
>> 
>> I did not run the script (yet) but is the intention to create symlinks to 
>> /usr/local so as to avoid the need to modify the path?
>> 
>> If the 2nd part is creating the steps necessary to „unlink" why do you not 
>> create a shell script of those lines? After all the user will not realize at 
>> the time of installation (linking) that he might need them (much) later 
>> during an uninstall? (unlinking). It would appear possible to create a 
>> static unlink script for the default (/Applications/ooRexx5/bin,lib <-> 
>> /usr/local/bin,lib
>> 
>> Can we hear from the developers what the skipped files ( callrexx1, 
>> callrexx2, libwpipe1.dylib, libwpipe2.dylib, libwpipe3.dylib and 
>> oorexx-config.) are for? Can they be safely removed from the installation on 
>> macOS? How does one go about it?
> 
> I'm not sure what oorexx-config is, but the others are the compiled sample 
> files. 
> 
> Rick 
>> 
>> It is possible to delete these files from the (auto-generated) script 
>> building the dmg in a post-process but that would be the ugly way. IMO we 
>> should locate the places in CMakelists.txt where those files are copied and 
>> fix the problem there.
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>>> Am 16.07.2021 um 17:09 schrieb Rony G. Flatscher :
>>> 
>>> Those who use ooRexx5 from Sourceforge on a Mac and who have followed the 
>>> instructions will have
>>> ooRexx in "/Applications/ooRexx5".
>>> 
>>> The enclosed Rexx script will create the link and remove commands that will 
>>> make ooRexx5 available
>>> systemwide. Run it and copy & paste the output to create the links or 
>>> remove them.
>>> 
>>> If you have ooRexx5 installed somewhere else, adjust the script accordingly.
>>> 
>>> ---rony
>>> 
>>> 
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> ___
> 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] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

It appears that both intel and arm (by default) are little endians. arm V8 can 
be configured to be both.

Sent by Magic!

> On Jun 7, 2021, at 8:34 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:
>> Now that I think about it rexx.img was the primary problem. It contains 
>> executable code, but is not in a library format. You can’t even combine x86 
>> and amd64 into one binary.
> I contains no native code, only core classes and and methods that are written 
> in Rexx in a pre-compiled format. However, all values are stored in the .img 
> file using the native architecture endian-ness. Intel is little-endian and 
> I'm pretty sure ARM is big-endian, do the images would not be compatible. 
>  
>> 
>> There was probably a good reason why rexx.img was implemented (speed or 
>> space?).
> It was a huge savings in startup time, particularly back when a really fast 
> machine ran at about 100Mhz and memory was still very expensive. It might be 
> that things have gotten fast enough now that removing this might not be a 
> huge impact, and there might even be some advantages to no longer having 
> this, but it would not be a simple experiment to perform. 
> 
>  
>> 
>> Perhaps it’s time to talk about eliminating or replacing it with something 
>> more standard.
> The replacement would be to reparse and translate all of the core classes 
> from source each time the interpreter is started. 
> 
> Rick
>  
>> 
>> Bruce
>> 
>> Sent by Magic!
>> 
>> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> > 
>> > The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> > because Rexx is   invoked during the build. There are tools to combine 
>> > single binaries into “universal” binaries, but what your are really asking 
>> > is can OORexx be cross compiled for a non-native architecture.  Even then 
>> > there were, if I remember correctly, problems with the Rexx.img file.
>> > Bruce
>> > 
>> > Sent by Magic!
>> > 
>> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> >> wrote:
>> >> 
>> >> As Apple has been selling new hardware with a proper processor, it would 
>> >> be important to support
>> >> that hardware platform.
>> >> 
>> >> In the past Apple allowed for "fat binaries" which included binaries for 
>> >> different hardware
>> >> architectures in the same file. Would it be possible with CMake to have 
>> >> such ooRexx "fat binaries"
>> >> created for the MacOS platform? If so, how would one be able to achieve 
>> >> that?
>> >> 
>> >> ---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
> ___
> 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] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

>   File:   .../ooRexx/testSuite/ooRexx/base/class/File.testGroup
>   Line:   674
>   Failed: assertEquals
> Expected: /Applications/ooRexx5/bin/rexx
> Actual:   /applications/ooRexx5/bin/rexx
> Message:  this may fail if rexx is run directly from a build tree
> 
> [failure] 20210607 17:10:10.527207
>   svn:r12195   Change date: 2021-03-15 17:46:10 +0100
>   Test:   TEST_SEARCHPATH_REXX
>   Class:  SYSSEARCHPATH.TESTGROUP
>   File:   .../ooRexx/testSuite/ooRexx/base/rexxutil/SysSearchPath.testGroup
>   Line:   122
>   Failed: assertSame
> Expected: /Applications/ooRexx5/bin/rexx
> Actual:   /applications/ooRexx5/bin/rexx
> Message:  this may fail if rexx is run directly from a build tree
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
> OS Name:DARWIN
> SysVersion: Darwin 20.5.0
> 
> Tests ran:  23288
> Assertions: 385289
> Failures:   2
> Errors:         0
> 
> File search:00:00:01.421314
> Suite construction: 00:00:01.240871
> Test execution: 00:05:01.552165
> Total time: 00:05:04.304650
> 
> 
> the error was triggered by purpose 
> when adding the path I used /applications instead of /Application
> 
> I hope to have demonstrated that the universl build is possible and it works 
> 
> 
> so it would be wiser for the esteemed participant in  forum to refrain from 
> wild guessing
> and stick to verified facts
> 
> my best regards
> 
> Enrico Sorichetti 
> 
> 
>> On 7 Jun 2021, at 16:22, CV Bruce  wrote:
>> 
>> The last time I looked at this, probably ppc/x86, it wasn’t possible because 
>> Rexx is   invoked during the build. There are tools to combine single 
>> binaries into “universal” binaries, but what your are really asking is can 
>> OORexx be cross compiled for a non-native architecture.  Even then there 
>> were, if I remember correctly, problems with the Rexx.img file.
>> Bruce
>> 
>> Sent by Magic!
>> 
>>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>>> wrote:
>>> 
>>> As Apple has been selling new hardware with a proper processor, it would 
>>> be important to support
>>> that hardware platform.
>>> 
>>> In the past Apple allowed for "fat binaries" which included binaries for 
>>> different hardware
>>> architectures in the same file. Would it be possible with CMake to have 
>>> such ooRexx "fat binaries"
>>> created for the MacOS platform? If so, how would one be able to achieve 
>>> that?
>>> 
>>> ---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
> 
> ___
> 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] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Rick, thanks for keeping me honest.

Sent by Magic!

> On Jun 7, 2021, at 8:34 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:
>> Now that I think about it rexx.img was the primary problem. It contains 
>> executable code, but is not in a library format. You can’t even combine x86 
>> and amd64 into one binary.
> I contains no native code, only core classes and and methods that are written 
> in Rexx in a pre-compiled format. However, all values are stored in the .img 
> file using the native architecture endian-ness. Intel is little-endian and 
> I'm pretty sure ARM is big-endian, do the images would not be compatible. 
>  
>> 
>> There was probably a good reason why rexx.img was implemented (speed or 
>> space?).
> It was a huge savings in startup time, particularly back when a really fast 
> machine ran at about 100Mhz and memory was still very expensive. It might be 
> that things have gotten fast enough now that removing this might not be a 
> huge impact, and there might even be some advantages to no longer having 
> this, but it would not be a simple experiment to perform. 
> 
>  
>> 
>> Perhaps it’s time to talk about eliminating or replacing it with something 
>> more standard.
> The replacement would be to reparse and translate all of the core classes 
> from source each time the interpreter is started. 
> 
> Rick
>  
>> 
>> Bruce
>> 
>> Sent by Magic!
>> 
>> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> > 
>> > The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> > because Rexx is   invoked during the build. There are tools to combine 
>> > single binaries into “universal” binaries, but what your are really asking 
>> > is can OORexx be cross compiled for a non-native architecture.  Even then 
>> > there were, if I remember correctly, problems with the Rexx.img file.
>> > Bruce
>> > 
>> > Sent by Magic!
>> > 
>> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> >> wrote:
>> >> 
>> >> As Apple has been selling new hardware with a proper processor, it would 
>> >> be important to support
>> >> that hardware platform.
>> >> 
>> >> In the past Apple allowed for "fat binaries" which included binaries for 
>> >> different hardware
>> >> architectures in the same file. Would it be possible with CMake to have 
>> >> such ooRexx "fat binaries"
>> >> created for the MacOS platform? If so, how would one be able to achieve 
>> >> that?
>> >> 
>> >> ---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
> ___
> 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] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

One could put multiple copies of oorexx into the .dmg file, and then let the 
installer select the correct/best binary to install.

Sent by Magic!

> On Jun 7, 2021, at 7:37 AM, CV Bruce  wrote:
> 
> Now that I think about it rexx.img was the primary problem. It contains 
> executable code, but is not in a library format. You can’t even combine x86 
> and amd64 into one binary.
> 
> There was probably a good reason why rexx.img was implemented (speed or 
> space?).
> 
> Perhaps it’s time to talk about eliminating or replacing it with something 
> more standard.
> 
> Bruce
> 
> Sent by Magic!
> 
>> On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> 
>> The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> because Rexx is   invoked during the build. There are tools to combine 
>> single binaries into “universal” binaries, but what your are really asking 
>> is can OORexx be cross compiled for a non-native architecture.  Even then 
>> there were, if I remember correctly, problems with the Rexx.img file.
>> Bruce
>> 
>> Sent by Magic!
>> 
>>>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>>>> wrote:
>>> 
>>> As Apple has been selling new hardware with a proper processor, it would 
>>> be important to support
>>> that hardware platform.
>>> 
>>> In the past Apple allowed for "fat binaries" which included binaries for 
>>> different hardware
>>> architectures in the same file. Would it be possible with CMake to have 
>>> such ooRexx "fat binaries"
>>> created for the MacOS platform? If so, how would one be able to achieve 
>>> that?
>>> 
>>> ---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] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Now that I think about it rexx.img was the primary problem. It contains 
executable code, but is not in a library format. You can’t even combine x86 and 
amd64 into one binary.

There was probably a good reason why rexx.img was implemented (speed or space?).

Perhaps it’s time to talk about eliminating or replacing it with something more 
standard.

Bruce

Sent by Magic!

> On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
> 
> The last time I looked at this, probably ppc/x86, it wasn’t possible because 
> Rexx is   invoked during the build. There are tools to combine single 
> binaries into “universal” binaries, but what your are really asking is can 
> OORexx be cross compiled for a non-native architecture.  Even then there 
> were, if I remember correctly, problems with the Rexx.img file.
> Bruce
> 
> Sent by Magic!
> 
>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> wrote:
>> 
>> As Apple has been selling new hardware with a proper processor, it would be 
>> important to support
>> that hardware platform.
>> 
>> In the past Apple allowed for "fat binaries" which included binaries for 
>> different hardware
>> architectures in the same file. Would it be possible with CMake to have such 
>> ooRexx "fat binaries"
>> created for the MacOS platform? If so, how would one be able to achieve that?
>> 
>> ---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] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

The last time I looked at this, probably ppc/x86, it wasn’t possible because 
Rexx is   invoked during the build. There are tools to combine single binaries 
into “universal” binaries, but what your are really asking is can OORexx be 
cross compiled for a non-native architecture.  Even then there were, if I 
remember correctly, problems with the Rexx.img file.
Bruce

Sent by Magic!

> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  wrote:
> 
> As Apple has been selling new hardware with a proper processor, it would be 
> important to support
> that hardware platform.
> 
> In the past Apple allowed for "fat binaries" which included binaries for 
> different hardware
> architectures in the same file. Would it be possible with CMake to have such 
> ooRexx "fat binaries"
> created for the MacOS platform? If so, how would one be able to achieve that?
> 
> ---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] need help on eliminating an error on a ::REQUIRES statement

[CV Bruce]

Me, I’d probably just create the winsystm.cls on the Linux system perhaps with 
a return statement in it to satisfy the requires.



Sent from my iPhone

> On Apr 4, 2021, at 9:57 AM, Bill Turner, WB4ALM  wrote:
> 
> I have a routine that functions under LINUX or under WINDOWS.
> 
> It has additional functionality under WINDOWS, that needs a
>  ::REQUIRES "winsystm.cls"
> statement.
> 
> Obviously, that is not installed on a LINUX based system so it causes an error
> that the ".cls" can not be found.
> 
> I do not want to maintain two different copies of the same ooRexx script and
> I use the PARSE SOURCE instruction to determine the current operating system
> and save this value for testing later in the program.
> 
> Is there a way to
> (1) conditionally control the execution of the ::REQUIRES statement or
> (2) Trap that specific error so that t can be ignored?
> 
> /s/ Bill Turner, wb4alm
> 
> 
> ___
> 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] CMake

[CV Bruce]

Whatever. My point was the ready availability of Cmake recent versions for Mac. 
When I first built ooRexx V5, Rick told me I needed Version 3 of Cmake, which 
was readily available.

Sent by Magic!

> On Mar 7, 2021, at 7:16 AM, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> IMO the best way to install cmake on APPLE is to use the drag and drop dmg
> Available in the download section at cmake.org
> 
> You get a first hand build , it allows to keep updated with minimal effort 
> 
> It installs into /Applications and it can create a symlink into /usr/local
> Tested on high sierra , catalina, big sur  
> 
> Now I am using 3.20-rc3
> 
> I built the APPLE  ooRexx universal binaries  and the test suite runs well 
> down to El Capitan
> ( both the x86_64 and the apple silicon  builds) 
> 
> Greetings
> 
> enrico
> 
> 
> 
>> On 7 Mar 2021, at 15:57, CV Bruce  wrote:
>> 
>> Apple is notorious for updating packages based on their own needs, which is 
>> why I use MacPorts. The current MacPorts version of CMake is 3.19.6. Fink is 
>> 3.19.1, and Homebrew is also 3.19.6.
>> I would be in favor of raising the required Cmake level.
>> 
>> Sent by Magic!
>> 
>>>> On Mar 7, 2021, at 5:50 AM, Michael Lueck  
>>>> wrote:
>>>> 
>>>> Greetings P.O.
>>>> 
>>>> P.O. Jonsson wrote:
>>>> This will also require 2.8 rather than 2.6 for other platforms, which 
>>>> seems to make sense from the warnings received. Any objections?
>>> 
>>> 
>>> Ubuntu Xeniel, which is just rolling off of LTS support shortly has version:
>>> 
>>> [ Source: cmake  ]
>>> Package: cmake (3.5.1-1ubuntu1)
>>> 
>>> I see no issue in the Ubuntu world making the minimum version 2.8 rather 
>>> than 2.6.
>>> 
>>> I am thankful,
>>> 
>>> -- 
>>> Michael Lueck
>>> Lueck Data Systems
>>> http://www.lueckdatasystems.com/
>>> 
>>> 
>>> ___
>>> 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
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] CMake

[CV Bruce]

Apple is notorious for updating packages based on their own needs, which is why 
I use MacPorts. The current MacPorts version of CMake is 3.19.6. Fink is 
3.19.1, and Homebrew is also 3.19.6.
I would be in favor of raising the required Cmake level.

Sent by Magic!

> On Mar 7, 2021, at 5:50 AM, Michael Lueck  wrote:
> 
> Greetings P.O.
> 
> P.O. Jonsson wrote:
>> This will also require 2.8 rather than 2.6 for other platforms, which seems 
>> to make sense from the warnings received. Any objections?
> 
> 
> Ubuntu Xeniel, which is just rolling off of LTS support shortly has version:
> 
> [ Source: cmake  ]
> Package: cmake (3.5.1-1ubuntu1)
> 
> I see no issue in the Ubuntu world making the minimum version 2.8 rather than 
> 2.6.
> 
> I am thankful,
> 
> -- 
> Michael Lueck
> Lueck Data Systems
> http://www.lueckdatasystems.com/
> 
> 
> ___
> 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] Releasing ooRexx 5.0? Building on Debian Linux Shared Web Hosting as non-root

[CV Bruce]

Thanks.  I just thought I’d ask since you seem to be the guru for the -D 
option.  This was in no way an enhancement request.

Yours,

Bruce
> On Jan 27, 2019, at 10:36 AM, Erich Steinböck  
> wrote:
> 
> Is there a build option that would allow me to rename the rexx executable to, 
> perhaps orexx?
> Tthat's not a supported scenario.
> You'd have to rename the binary manually. On Unix at least you could build 
> with -DORX_SHEBANG=/-your-install-path-/bin/orexx so that built rexx programs 
> have their shebangs modified accordingly.
> On Windows, you'd have to modify the file type association with ftype 
> RexxScript="d:\-your-install-path-\ooRexx\orexx.exe" "%1" %*
> I never tested anything like this, so you might experience other issues.
> ___
> 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] Releasing ooRexx 5.0? Building on Debian Linux Shared Web Hosting as non-root

[CV Bruce]

Hi Eric,

Is there a build option that would allow me to rename the rexx executable to, 
perhaps orexx?

Thanks,

Bruce
> On Jan 22, 2019, at 8:53 AM, Erich Steinböck  
> wrote:
> 
> Hi Michael,
> if you do not want to build to the default ooRexx install location /usr/bin, 
> set CMAKE_INSTALL_PREFIX to the desired path on the cmake command. To build 
> for an install to your home directory, you would use
> 
> cmake -DBUILD_DEB=1 -DOS_DIST=ubuntu1604 -DCMAKE_BUILD_TYPE=RELEASE 
> -DCMAKE_INSTALL_PREFIX=~/oorexx ../../oorexxsvn/main/trunk
> 
> To install without building a package, use make install
> 
> No APIService.cpp patching, ./configure, mkdir ~/opt/oorexx/var should be 
> necessary for 5.0.  The latest 5.0 trunk will no longer require rxapi to run 
> as root.
> 
> 
> I have just updated our How-to-build-ooRexx wiki at 
> https://sourceforge.net/p/oorexx/wiki/how-to-build-oorexx/ 
> I'll also update 
> CMake-build-readme.txt 
> 
> Please let us know of any issues you encounter.
> ___
> 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] Question ad RPATH and MacOSX

[CV Bruce]

Thank you Tony and Enrico, this was something I was never able to get across.

Bruce
> On Jan 8, 2019, at 8:17 AM, Rony G. Flatscher  wrote:
> 
> Dear P.O.,
> 
> On 08.01.2019 16:24, P.O. Jonsson wrote:
>> I am not taking about the future, it is working NOW, without any 
>> modification besides the /bin
>> being in the path. NO NADA NIX modifications it works out of the box. Try it.
> 
> I believe you. :)
> 
>> A relocatable installation is desirable for other reasons, such as for 
>> creating an automated build
>> to ~/Applications, this is NOT possible today.
> 
> With Enricos definitions this has become possible. Just tested it a few 
> minutes ago successfully on
> MacOSX: moved the directories in ~/Applications/ooRexx.5.0.0 to ~/oha2/test 
> and successfully ran
> ooRexx from ~/oha2/test/bin and all of the sample programs there as well.
> 
> Cheers,
> 
> ---royn
> 
> 
> 
> 
> ___
> 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] rxqueue, the program not the function.

[CV Bruce]

Eric,

I’ve been playing with rxqueue from the current repository.  It doesn’t work.  
I notice that there are already open tickets for rxqueue(), and the root cause 
for both is probably the same.  Do you want me to open a new ticket or to add 
info to the existing tickets.

Yours,

Bruce

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

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

[CV Bruce]

I may not have been entirely accurate. I believe that two rxapi process can run 
at the same time as long as they have different PID files.  The problem is that 
only one of them can bind the socket.  Do we know if rxapi issues an error 
message if it can not bind the socket?  If so where does it send the error 
message?

Bruce
> On Nov 21, 2018, at 8:21 AM, CV Bruce  wrote:
> 
> Enrico, 
> 
> I’m a little concerned that installing anything in ~/… will make it user 
> specific, and not system wide.  Since only one copy of rxapi can run at a 
> time, then only one user can use ooRexx.  In your explorations can you test 
> for this?  
> 
> "The main difference [on Mac OS] is that an agent is run on behalf of the 
> logged in user while a daemon runs on behalf of the root user or any user you 
> specify with the UserName key.”
> 
> This may imply that if you log off the daemon may stop running, or the daemon 
> may not start until the user logs on.
> 
> Yours,
> 
> Bruce
> 
>> On Nov 21, 2018, at 8:03 AM, Enrico Sorichetti via Oorexx-devel 
>> > <mailto:oorexx-devel@lists.sourceforge.net>> wrote:
>> 
>> 
>> 
>>> On 21 Nov 2018, at 15:23, Rick McGuire >> <mailto:object.r...@gmail.com>> wrote:
>>> 
>>>  I believe writing the pid file at that location is part of the 
>>> requirements for running as a daemon on other unix-based systems.
>> 
>> 
>> Does not seem true for Mac OS
>> 
>> I have been running and ooRexx-ing  for a while with /tmp/ooRexx.pid
>> and everything seems too work 
>> 
>> Anyway I will keep experimenting with the different setups 
>> 
>> also, on Mac OS there are the Agents and the Daemons 
>> 
>> And the plist for starting an agent can be in ~/Library/LaunchAgents 
>> 
>> So again  no need to sudo anything,
>> But I will have to check what happens when alternating logins with different 
>> users
>> Without logging off 
>> 
>> I just looked and home-brew  does not need sudo because it assumes that 
>> /usr/local is not protected
>> 
>> And brew will …. ( from brew service help )
>>  If sudo is passed, operate on /Library/LaunchDaemons (started at boot).
>>  Otherwise, operate on ~/Library/LaunchAgents (started at login).
>> 
>> 
>> 
>> 
>> Cheers
>> 
>> Enrico
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> <mailto: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] Ad MacOSX and daemons (for rxapi)

[CV Bruce]

I agree with this.  What I’ve seen before is at install time the user is asked 
whether they want to install for just the user or for all users.  Selecting all 
users then requests authentication for the install.

Bruce


> On Nov 21, 2018, at 8:39 AM, René Jansen  wrote:
> 
> User specific is fine and is what will suffice for most users. It will be the 
> default for a portable install. Multiuser installs should be an option and 
> there is no issue in requiring admin for those, I’d rather they do.
> 
> René.
> 
> 
> 
>> On 21 Nov 2018, at 12:21, CV Bruce > <mailto:cvbr...@gmail.com>> wrote:
>> 
>> Enrico, 
>> 
>> I’m a little concerned that installing anything in ~/… will make it user 
>> specific, and not system wide.  Since only one copy of rxapi can run at a 
>> time, then only one user can use ooRexx.  In your explorations can you test 
>> for this?  
>> 
>> "The main difference [on Mac OS] is that an agent is run on behalf of the 
>> logged in user while a daemon runs on behalf of the root user or any user 
>> you specify with the UserName key.”
>> 
>> This may imply that if you log off the daemon may stop running, or the 
>> daemon may not start until the user logs on.
>> 
>> Yours,
>> 
>> Bruce
>> 
>>> On Nov 21, 2018, at 8:03 AM, Enrico Sorichetti via Oorexx-devel 
>>> >> <mailto:oorexx-devel@lists.sourceforge.net>> wrote:
>>> 
>>> 
>>> 
>>>> On 21 Nov 2018, at 15:23, Rick McGuire >>> <mailto:object.r...@gmail.com>> wrote:
>>>> 
>>>>  I believe writing the pid file at that location is part of the 
>>>> requirements for running as a daemon on other unix-based systems.
>>> 
>>> 
>>> Does not seem true for Mac OS
> 
> ___
> 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] Ad MacOSX and daemons (for rxapi)

[CV Bruce]

Enrico, 

I’m a little concerned that installing anything in ~/… will make it user 
specific, and not system wide.  Since only one copy of rxapi can run at a time, 
then only one user can use ooRexx.  In your explorations can you test for this? 
 

"The main difference [on Mac OS] is that an agent is run on behalf of the 
logged in user while a daemon runs on behalf of the root user or any user you 
specify with the UserName key.”

This may imply that if you log off the daemon may stop running, or the daemon 
may not start until the user logs on.

Yours,

Bruce

> On Nov 21, 2018, at 8:03 AM, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> 
> 
>> On 21 Nov 2018, at 15:23, Rick McGuire > > wrote:
>> 
>>  I believe writing the pid file at that location is part of the requirements 
>> for running as a daemon on other unix-based systems.
> 
> 
> Does not seem true for Mac OS
> 
> I have been running and ooRexx-ing  for a while with /tmp/ooRexx.pid
> and everything seems too work 
> 
> Anyway I will keep experimenting with the different setups 
> 
> also, on Mac OS there are the Agents and the Daemons 
> 
> And the plist for starting an agent can be in ~/Library/LaunchAgents 
> 
> So again  no need to sudo anything,
> But I will have to check what happens when alternating logins with different 
> users
> Without logging off 
> 
> I just looked and home-brew  does not need sudo because it assumes that 
> /usr/local is not protected
> 
> And brew will …. ( from brew service help )
>  If sudo is passed, operate on /Library/LaunchDaemons (started at boot).
>  Otherwise, operate on ~/Library/LaunchAgents (started at login).
> 
> 
> 
> 
> Cheers
> 
> Enrico
> 
> 
> 
> 
> 
> 
> ___
> 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] Ad MacOSX and daemons (for rxapi)

[CV Bruce]

I’m more of a MacPorts kind of guy, and I’ve used fink in the past.  It would 
be nice if we could support more of the Mac OS specific package managers. 

> On Nov 21, 2018, at 7:07 AM, René Jansen  wrote:
> 
> I agree.
> 
> Want to add to the discussion: homebrew (brew) has a ‘brew services’ command 
> that can install a service on macOS without requiring sudo.

I imagine that it installs a user owned service. It just needs to point to the 
plist file, and place the PID file in a writeable position. I don’t know if 
this would make it fully multi user compatible. Or it could be using a setuid 
on ‘brew’ to accomplish the same thing as sudo.

> A portable ‘installer’ (drag an application icon from a .dmg to 
> ~/Applications) would be a good thing. A ‘brew install oorexx’ would be a 
> good thing - brew manages dependencies (we don’t have a lot but Curses comes 
> to mind) and enables one to choose the location brew installs everything to 
> on a user base - and enables build-from-source installs. At least it already 
> offers sudo-less integration with launchctl.

Dragging it from a disk image, and allowing it to execute from anywhere is a 
very Mac kind of thing to do.  Of course it would be nice if RexxLA would sign 
up for Apple Developer so that we could digitally sign the installs.

Bruce

> 
> Now I am going to try Per’s .dmg image.
> 
> René
> 
> 
> 
>> On 21 Nov 2018, at 10:41, CV Bruce  wrote:
>> 
>> Well….
>> 
>> I agree with Enrico, mostly.  
>> 
>> Installation: Yes you need sudo privileges to write to 
>> /Library/LaunchDaemons. You also need sudo to write to /usr/local/… which is 
>> as far as I know, the current place to put system wide user programs.  I 
>> could be wrong as I haven’t been keeping up.
>> 
>> Execution: Yes, as far as I know you only need sudo for writing to 
>> /var/run/ooRexx.pid.  The port bound by rxapi ( 10010? ) is out of the range 
>> requiring sudo authority to bin.
>> 
>> Bruce
>>> On Nov 21, 2018, at 5:12 AM, Enrico Sorichetti via Oorexx-devel 
>>>  wrote:
>>> 
>>> 
>>> The only reason for having sudo privileges is to install the plist into 
>>> /Library/LaunchDaemons
>>> 
>>> The only reason for having sudo privileges when starting by hand the rxapi 
>>> thing is to write /var/run/ooRexx.pid
>>> 
> 
> 
> 
> ___
> 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] Ad MacOSX and daemons (for rxapi)

[CV Bruce]

Well….

I agree with Enrico, mostly.  

Installation: Yes you need sudo privileges to write to /Library/LaunchDaemons. 
You also need sudo to write to /usr/local/… which is as far as I know, the 
current place to put system wide user programs.  I could be wrong as I haven’t 
been keeping up.

Execution: Yes, as far as I know you only need sudo for writing to 
/var/run/ooRexx.pid.  The port bound by rxapi ( 10010? ) is out of the range 
requiring sudo authority to bin.

Bruce
> On Nov 21, 2018, at 5:12 AM, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> 
> The only reason for having sudo privileges is to install the plist into 
> /Library/LaunchDaemons
> 
> The only reason for having sudo privileges when starting by hand the rxapi 
> thing is to write /var/run/ooRexx.pid
> 
> I just run a VERY quick and dirty test changing 
> rexxapi/server/platform/unix/linux/APIService.cpp to write to /tmp/ooRexx.pid 
> 
> And at first glance everything seems to run smoothly 
> Naturally more research and test is needed but …
> it looks possible to install and use rexx without sudo privileges,
> I will research a bit more and let You know 
> 
> Cheers
> 
> Enrico
> 
> PS
> 
> The change is really simple 
> 
> In /opt/ooRexx.alt/rexxapi/server/platform/unix/linux/APIService.cpp
> 
> Just change the first 
> #define OOREXX_PIDFILE "/var/run/ooRexx.pid”
> To
> #define OOREXX_PIDFILE "/tmp/ooRexx.pid"
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] portable (usb) ooRexx 5.00

[CV Bruce]

There are some minor changes to the code that would allow ooRexx to run, on Mac 
OS, from any folder it is copied to without recompiling.  There are some 
special library load paths that inform Mac OS of the relative location of 
shared libraries.  Because Mac OS by default searches some libraries that are 
specifically in the code for linux (like /usr/lib), a Mac OS version could 
replace that section of the code that searches those library load paths with 
the special relative paths.
This would also eliminate having to code any environmental variable pointing to 
the library path.

I forget which source file the code is in, but it is the one that performs the 
library loads.  I would have to look up the form of the relative path that you 
code, but it would be something that would be relative to the executable.

If you’re interested in making those changes, I would be happy to look it up 
again.

Bruce
> On Mar 30, 2018, at 11:24 AM, P.O. Jonsson  wrote:
> 
> Dear developers,
> 
> I think the discussion have gone off in another direction than the title 
> proposes (I have no opinion on that matter) but for what it is worth I just 
> now created an ooRexx installation that runs of a USB stick, with no use of 
> superuser powers whatsoever.
> 
> It is only for MAC but the idea is extremely simple and should be possible to 
> take to other platforms: During the CMake I redirected the installation to 
> /volumes/. After that the only thing I needed to do was to 
> amend the path.
> 
> Can be found here, instructions for use in the dmg image, just mount it and 
> read howto.txt. 
> 
> https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0 
> 
> 
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
>> Am 30.03.2018 um 17:02 schrieb René Jansen > >:
>> 
>> Moritz,
>> 
>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that it 
>> has been taken up by Rick) so we might hold off the freeze for some time 
>> until we have all infrastructure and installers ready (and maybe have 
>> ADDRESS WITH). Maybe this gives us also time to look into the portable 
>> version again. I personally think this would be a great boost for takeup.
>> 
>> I remember you had a set of patches to turn the sockets of rxapi into pipes. 
>> I do not remember if this was windows-only or also included linux/macos.
>> 
>> The issues with rxapi:
>> 
>> - you must be authorized to run it on its port
>> - the firewall must allow access (cost me great headaches on Z, where the 
>> standard image for a Linux VM was very restrictive, and you got a timeout 
>> and no message)
>> - you must be authorized to start it, so that means a service on windows or 
>> some systemd / startup item
>> - it writes a PID file so whoever starts it, must be authorized to write 
>> there
>> 
>> Thing is, solutions must work for the three main platforms, that is the 
>> reason of my question.
>> 
>> best regards,
>> 
>> 
>> René
>> 
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org ! 
>> http://sdm.link/slashdot 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> 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] Running Testcases

[CV Bruce]

I also see in my notes (emails) that some tests will fail if your try to 
redirect the output of ooTest to a file.  If I remember correctly, I would just 
let all the output go to the screen, and then cut and paste the screen buffer 
into a text document.

Bruce
> On Nov 19, 2018, at 11:24 AM, P.O. Jonsson  wrote:
> 
> "Boing-Boing" means that the machine produces a noise „boing!“ five times in 
> a row at exactly the time I see a space instead of a dot in the execution 
> output. I cannot describe it better than that, it must be an error raised. I 
> will try to pinpoint each error.
> 
> Von meinen Macbook gesendet
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 19.11.2018 um 20:13 schrieb P.O. Jonsson > <mailto:oor...@jonases.se>>:
>> 
>> Dear Eric, thanks for responding, answer below inline.
>> 
>> Von meinen Macbook gesendet
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se <mailto:oor...@jonases.se>
>> 
>> 
>> 
>>> Am 19.11.2018 um 19:09 schrieb Erich Steinböck >> <mailto:erich.steinbo...@gmail.com>>:
>>> 
>>> Hi P.O.,
>>> good practice is to run tests with `testOORexx -s -X native_API`
>>> If in addition if you suppress long-running tests with e. g. `-x CHAROUT 
>>> TIME Alarm Message ticker WindowsEventLog`  tests will finish in a minute 
>>> or less.
>>> 
>> 
>> I will try with -X native_API
>> 
>>> When something goes wrong, the last test group printed should be the 
>>> offender, in your case Macrospace.testGroup.  What happens when you run it 
>>> stand-alone?
>>> 
>> 
>> I have enclosed a run with that test, it aborts without a result.
>> 
>>> the machine goes boing-boing five times 
>>> Please explain what "boing-boing" means
>>> 
>>> REX121: Storage for data queues is exhausted
>>> Which test group raises this error?  This may point to an issue with rxap
>>> 
>> There are more than one place, I will look further
>> 
>>> cat: stdout: Broken pipe
>>> Which test group raises this error?
>>> 
>> Same here, I need to pinpoint it
>> 
>>> 
>>> On Mon, Nov 19, 2018 at 5:18 PM P.O. Jonsson >> <mailto:oor...@jonases.se>> wrote:
>>> I also just found out what Rony just wrote, here are some options
>>> 
>>>  Output control:
>>>   -l  -DlogFile=FILEPut test results in log file FILE
>>>   -L  -DlogFileAppend=bool  Append test results to log file
>>>   -s  -DshowProgress=bool   Show test group progress
>>>   -S  -DshowTestcases=bool  Show test case progress
>>>   -u  -DsuppressTestcaseTicks=bool  Do not show ticks during test execution
>>>   -U  -DsuppressAllTicks=bool   Do not show any ticks
>>>   -V, -Dverbosity=NUM   Set vebosity to NUM
>>>   -w, -DwaitAtCompletion=bool   At test end, wait for user to hit enter
>>> 
>>> with this information I could get a bit further,  a potential problem (I 
>>> think) is the need to use ./ to refer to the testcases on Mac (deprecated)?
>>> 
>>> This works now:
>>> 
>>> testOORexx.rex -R ./ooRexx/base/expressions -s -S
>>> 
>>> -s and -S was enough to see that is was running and in the end I got a 
>>> result
>>> 
>>> ooTest Framework - Automated Test of the ooRexx Interpreter
>>> 
>>> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 18 Nov 2018
>>> OS Name:DARWIN
>>> SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 
>>> 23:06:14 PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0
>>> 
>>> Tests ran:  2913
>>> Assertions: 5387
>>> Failures:   0
>>> Errors: 0
>>> 
>>> File search:00:00:00.066862
>>> Suite construction: 00:00:00.103980
>>> Test execution: 00:00:00.860958
>>> Total time: 00:00:01.468976
>>> 
>>> However, and this is weird, If I broaden the test
>>> 
>>> testOORexx.rex -R ./ooRexx/base -s -S
>>> 
>>> The tests start to run and I get some 100 test classes run, but somewhere 
>>> along the line the machine goes boing-boing five times (and I see five 
>>> spaces instead of dots, like this (. …..) and 
>>> then I need to break out of

Re: [Oorexx-devel] Running Testcases

[CV Bruce]

Does anyone know if there is a “verbose” option that would print out test 
results as each test is performed? That way we can at least see where we are 
dying.

Bruce
> On Nov 18, 2018, at 3:45 PM, P.O. Jonsson  wrote:
> 
> dear Bruce,
> 
> I have updated using svn to todays built r11519, created an installer and 
> installed a working installation of ooRexx. I have also downloaded the 
> corresponding test folder structure: 
> 
> oorexx-code-0-r11519-test-trunk/
> 
> Then I move into oorexx-code-0-r11519-test-trunk/
> 
> and set up the environment
> 
> bash setTestEnv.sh
> 
> After that I can run a single test (the example in readme.first uses a 
> partial path, this is not something I invented so don’t shoot me ok?)
> 
> rexx testOORexx.rex -R ./ooRexx/base/expressions -f Addition
> 
> This produces the desired output
> 
> POs-MacBook-Pro:oorexx-code-0-r11519-test-trunk po$ rexx testOORexx.rex -R 
> ./ooRexx/base/expressions -f Addition
> Searching for test containers..
> Executing automated test suite..
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 18 Nov 2018
> OS Name:DARWIN
> SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 
> PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0
> 
> Tests ran:  200
> Assertions: 304
> Failures:   0
> Errors: 0
> 
> File search:00:00:00.010274
> Suite construction: 00:00:00.005753
> Test execution: 00:00:00.016902
> Total time: 00:00:01.013693
> 
> I can then do the same for a whole set of tests
> 
> rexx testOORexx.rex -R ./ooRexx/base/expressions
> 
> BUT, when I try to run the whole suite like this:
> 
> rexx testOORexx
> 
> I get stuttering dots every second and after some time things like this
> 
> oorexx-code-0-r11519-test-trunk po$ rexx testOORexx.rex
> Searching for test containers
> Executing automated test suite.
> REX121: Storage for data queues is exhausted.
> .
> REX121: Storage for data queues is exhausted.
> 
> REX121: Storage for data queues is exhausted.
> cat: stdout: Broken pipe
> .
> 
> And I have to kill a rexx process manually to get it stopped.
> 
> It seems to me that when I do not find the test the program gets out of 
> control,
> 
> Please advice how to refer to the whole set of test cases, I tried some 
> variants, but failed.
> 
> 
> 
> 
> Von meinen Macbook gesendet
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 18.11.2018 um 21:05 schrieb CV Bruce > <mailto:cvbr...@gmail.com>>:
>> 
>> That depends. you need to pull ooTest from the same build level, I believe.
>> 
>> Bruce
>>> On Nov 18, 2018, at 11:50 AM, P. O. Jonsson >> <mailto:oor...@jonases.se>> wrote:
>>> 
>>> Thanks for the info, I have done it the way you proposed including the 
>>> shell script but I have an older build of ooRexx, can that be the problem?
>>> 
>>> I will try further tomorrow, thanks for all the feedback.  
>>> Hälsningar/Regards/Grüsse,
>>> P. O. Jonsson
>>> Von meinem iPhone gesendet
>>> 
>>> Am 18.11.2018 um 20:07 schrieb CV Bruce >> <mailto:cvbr...@gmail.com>>:
>>> 
>>>> I looked at some of my runs from many years ago, and the run time was less 
>>>> then three minutes.  Also, after a test run be sure that all of the files 
>>>> created during the test run are deleted.  They should be, but double 
>>>> check.  Also my prior comment (off line) regarding RXAPI.  It is probably 
>>>> best to kill it and restart it manually so that you can be sure that you 
>>>> are getting the version that was from the current build. 
>>>> 
>>>> Bruce
>>>>> On Nov 18, 2018, at 10:48 AM, CV Bruce >>>> <mailto:cvbr...@gmail.com>> wrote:
>>>>> 
>>>>> It’s been a while since I’ve run the test suite, but it shouldn’t take 
>>>>> more than 15 minutes or so.
>>>>> 
>>>>> In the past, I’ve run into the situation that you have, and it generally 
>>>>> means that either your invocation or your environment isn’t set up 
>>>>> correctly.
>>>>> 
>>>>> Bruce
>>>>>> On Nov 18, 2018, at 10:41 AM, P.O. Jonsson >>>>> <mailto:oor...@jonases.se>> wrote:
>>>>>> 
>>>>>> De

Re: [Oorexx-devel] Running Testcases

[CV Bruce]

That depends. you need to pull ooTest from the same build level, I believe.

Bruce
> On Nov 18, 2018, at 11:50 AM, P. O. Jonsson  wrote:
> 
> Thanks for the info, I have done it the way you proposed including the shell 
> script but I have an older build of ooRexx, can that be the problem?
> 
> I will try further tomorrow, thanks for all the feedback.  
> Hälsningar/Regards/Grüsse,
> P. O. Jonsson
> Von meinem iPhone gesendet
> 
> Am 18.11.2018 um 20:07 schrieb CV Bruce  <mailto:cvbr...@gmail.com>>:
> 
>> I looked at some of my runs from many years ago, and the run time was less 
>> then three minutes.  Also, after a test run be sure that all of the files 
>> created during the test run are deleted.  They should be, but double check.  
>> Also my prior comment (off line) regarding RXAPI.  It is probably best to 
>> kill it and restart it manually so that you can be sure that you are getting 
>> the version that was from the current build. 
>> 
>> Bruce
>>> On Nov 18, 2018, at 10:48 AM, CV Bruce >> <mailto:cvbr...@gmail.com>> wrote:
>>> 
>>> It’s been a while since I’ve run the test suite, but it shouldn’t take more 
>>> than 15 minutes or so.
>>> 
>>> In the past, I’ve run into the situation that you have, and it generally 
>>> means that either your invocation or your environment isn’t set up 
>>> correctly.
>>> 
>>> Bruce
>>>> On Nov 18, 2018, at 10:41 AM, P.O. Jonsson >>> <mailto:oor...@jonases.se>> wrote:
>>>> 
>>>> Dear Developers,
>>>> 
>>>> I have downloaded the test environment from : 
>>>> https://svn.code.sf.net/p/oorexx/code-0/test/trunk 
>>>> <https://svn.code.sf.net/p/oorexx/code-0/test/trunk> as suggested by Rick 
>>>> and have started to run the available test cases (on a Mac). It has now 
>>>> been running for four hours and I wonder what the expected completion time 
>>>> is on a decent i5 machine? There is no lack of memory (11 from 16 GB still 
>>>> available) and the machine is in average 95% idling. Should I abort and 
>>>> try a subset first or is it normal to have these runtimes? I have seen 
>>>> that there are many many tests. The „dots“ go on for another page or so. I 
>>>> will do the same on a Win machine to see if there is a difference but some 
>>>> input is welcome on what to expect. I have run the shell script to set up 
>>>> the test environment and I have done what is set out in readme.first.
>>>> 
>>>> Os-MacBook-Pro:oorexx-code-0-r11517-test-trunk po$ rexx testOORexx.rex -X 
>>>> native_API
>>>> Searching for test containers...
>>>> Executing automated test 
>>>> suite..
>>>> . 
>>>> ..
>>>> ...
>>>> 
>>>> As a side remark: all rexx files (including the test case files in 
>>>> /test/trunk have the shebang #!/usr/bin/rexx rather than #! /usr/bin/env 
>>>> rexx
>>>> 
>>>> PS the exercise with test cases for the samples is for me also a test to 
>>>> benchmark the installer I am working on, so please bear with my qs
>>>> 
>>>> Von meinen Macbook gesendet
>>>> 
>>>> Hälsningar/Regards/Grüsse,
>>>> P.O. Jonsson
>>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Oorexx-devel mailing list
>>>> Oorexx-devel@lists.sourceforge.net 
>>>> <mailto:Oorexx-devel@lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
>>>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> <mailto:Oorexx-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
>> <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] Running Testcases

[CV Bruce]

I looked at some of my runs from many years ago, and the run time was less then 
three minutes.  Also, after a test run be sure that all of the files created 
during the test run are deleted.  They should be, but double check.  Also my 
prior comment (off line) regarding RXAPI.  It is probably best to kill it and 
restart it manually so that you can be sure that you are getting the version 
that was from the current build. 

Bruce
> On Nov 18, 2018, at 10:48 AM, CV Bruce  wrote:
> 
> It’s been a while since I’ve run the test suite, but it shouldn’t take more 
> than 15 minutes or so.
> 
> In the past, I’ve run into the situation that you have, and it generally 
> means that either your invocation or your environment isn’t set up correctly.
> 
> Bruce
>> On Nov 18, 2018, at 10:41 AM, P.O. Jonsson > <mailto:oor...@jonases.se>> wrote:
>> 
>> Dear Developers,
>> 
>> I have downloaded the test environment from : 
>> https://svn.code.sf.net/p/oorexx/code-0/test/trunk 
>> <https://svn.code.sf.net/p/oorexx/code-0/test/trunk> as suggested by Rick 
>> and have started to run the available test cases (on a Mac). It has now been 
>> running for four hours and I wonder what the expected completion time is on 
>> a decent i5 machine? There is no lack of memory (11 from 16 GB still 
>> available) and the machine is in average 95% idling. Should I abort and try 
>> a subset first or is it normal to have these runtimes? I have seen that 
>> there are many many tests. The „dots“ go on for another page or so. I will 
>> do the same on a Win machine to see if there is a difference but some input 
>> is welcome on what to expect. I have run the shell script to set up the test 
>> environment and I have done what is set out in readme.first.
>> 
>> Os-MacBook-Pro:oorexx-code-0-r11517-test-trunk po$ rexx testOORexx.rex -X 
>> native_API
>> Searching for test containers...
>> Executing automated test suite..
>> . 
>> ..
>> ...
>> 
>> As a side remark: all rexx files (including the test case files in 
>> /test/trunk have the shebang #!/usr/bin/rexx rather than #! /usr/bin/env rexx
>> 
>> PS the exercise with test cases for the samples is for me also a test to 
>> benchmark the installer I am working on, so please bear with my qs
>> 
>> Von meinen Macbook gesendet
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se <mailto:oor...@jonases.se>
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> <mailto: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] Running Testcases

[CV Bruce]

It’s been a while since I’ve run the test suite, but it shouldn’t take more 
than 15 minutes or so.

In the past, I’ve run into the situation that you have, and it generally means 
that either your invocation or your environment isn’t set up correctly.

Bruce
> On Nov 18, 2018, at 10:41 AM, P.O. Jonsson  wrote:
> 
> Dear Developers,
> 
> I have downloaded the test environment from : 
> https://svn.code.sf.net/p/oorexx/code-0/test/trunk 
>  as suggested by Rick and 
> have started to run the available test cases (on a Mac). It has now been 
> running for four hours and I wonder what the expected completion time is on a 
> decent i5 machine? There is no lack of memory (11 from 16 GB still available) 
> and the machine is in average 95% idling. Should I abort and try a subset 
> first or is it normal to have these runtimes? I have seen that there are many 
> many tests. The „dots“ go on for another page or so. I will do the same on a 
> Win machine to see if there is a difference but some input is welcome on what 
> to expect. I have run the shell script to set up the test environment and I 
> have done what is set out in readme.first.
> 
> Os-MacBook-Pro:oorexx-code-0-r11517-test-trunk po$ rexx testOORexx.rex -X 
> native_API
> Searching for test containers...
> Executing automated test suite..
> . 
> ..
> ...
> 
> As a side remark: all rexx files (including the test case files in 
> /test/trunk have the shebang #!/usr/bin/rexx rather than #! /usr/bin/env rexx
> 
> PS the exercise with test cases for the samples is for me also a test to 
> benchmark the installer I am working on, so please bear with my qs
> 
> Von meinen Macbook gesendet
> 
> 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

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

Re: [Oorexx-devel] Sort doesn't work properly with signed numbers.

[CV Bruce]

It’s pretty clear that in all your test cases, the data is being treated as 
text.

If the cases where the data is in the format of “testxx” it will always be 
treated as a text string. Specifying just that portion of the variable that is 
numeric doesn’t override that.

In the case where you array contains just numbers, when you created the array 
you quoted all the numbers you assigned to the array thereby telling Rexx that 
you wanted those values treated as text strings.

Bottom line, just because something looks like a number doesn’t mean that Rexx 
has the context to treat it as a number.  For example if a variable looks like 
a number and then has an arithmetic operation performed on it, Rexx has enough 
context to treat the variable as a number.  
X='-2' <— text string
X=X+0 <— Ok, it’s now a number.
X=-2 <— Number
X=X||” ” <— Ok, you want a text string

As to:
> For all the other comparison operators, if both terms are numeric, the String 
> class does a numeric comparison (ignoring, for example, leading zeros

Rexx doesn’t know that it is a number until you tell it, it is a number.  You 
loaded the array with text strings, and didn’t tell it otherwise so it compared 
them as text strings.

Bruce

> On May 14, 2018, at 9:59 AM, Leslie Turriff  wrote:
> 
>   I need to sort an array of strings by their signed numeric suffixes, 
> but I'm 
> getting some strange results from sort and sortWith.  I have attached my V4.2 
> test program; together with its output.
> 
>   Section 5.1.3.8 of the Language Reference says,
> 'The strict comparison operators do not attempt to perform a numeric 
> comparison on the two operands.
> For all the other comparison operators, if both terms are numeric, the String 
> class does a numeric comparison (ignoring, for example, leading zeros— see 
> Section 10.4, “Numeric Comparisons”).'
> 
>   Section 10.4 says,
> 'Numeric values are compared by subtracting the two numbers (calculating the 
> difference) and then comparing the result with 0. That is, the operation:
>   A ? Z
> where ? is any numeric comparison operator, is identical with:
>   (A - Z) ? "0"
> It is, therefore, the difference between two numbers, when subtracted under 
> Rexx subtraction rules, that determines their equality.'
> 
>   Further, Section 10 says,
> 'Numbers can be expressed flexibly. Leading and trailing whitespace 
> characters 
> are permitted, and
> exponential notation can be used. Valid numbers are, for example:
> 
>  Example 10.1. Numbers
> 
>   12   /* a whole number */
>   "-76"/* a signed whole number  */
> 12.76 /* decimal places  */
> " + 0.003 "   /* blanks around the sign and so forth */
> 17.   /* same as 17  */
> .5/* same as 0.5 */
> 4E9   /* exponential notation*/
> 0.73e-7   /* exponential notation*/
> 
> A number in Rexx is defined as follows:
> 
>>> -++--+--+--+-digits+-->
>  +-whitespace-+ +-sign--++-+ +-digits.digits-+
> +-whitespace-++-.digits---+
>   +-digits.---+
>> --++--><
>  +-whitespace-+
> 
> whitespace
> are one or more blanks or horizontal tab characters.
> sign
> is either + or -.
> digits
> are one or more of the decimal digits 0-9.'
> 
>   However, in section 5.3.18, Sorting Arrays, we see that
> 'The sort method orders the strings by using the compareTo method of the 
> String class. The compareTo method knows how to compare one string to 
> another, and returns the values -1 (less than), 0 (equal), or 1 (greater 
> than) to indicate the relative ordering of the two strings.'
> 
> and
> 'Performs a sort comparison of the target string to the string argument. If 
> the two strings are equal, 0 is returned. If the target string is larger, 1 
> is returned. -1 if the string argument is the larger string.
> The comparison is performed starting at character n for length characters in 
> both strings. n must be a positive whole number. If n is omitted, the 
> comparison starts at the first character. length must be a non-negative whole 
> number. If omitted, the comparison will take place to the end of the target 
> string.'
> 
> which seems to imply a character comparison; and the examples for compareTo 
> include no numeric strings.
> 
>   Looking at the output from the test program, ooRexx seems to be sorting 
> signed numeric strings non-numerically (+ < - < 0), contrary to what would be 
> expected from section 10.  This seems to me to be a bug?  I would not expect 
> to have to write a custom comparator to re-implement a built-in mechanism.

Re: [Oorexx-devel] oorexx-config

[CV Bruce]

Ok, so the answer is that ooRexx-config is being dropped. Thanks.

Sent by Magic!

> On May 22, 2017, at 4:12 AM, Rick McGuire  wrote:
> 
> probably. David and I largely left the old files in place until we had fully 
> committed to the cmake switchover. It's probably time to start that cleanup. 
> I suspect there are still some pieces of the old Windows build process left 
> as well. 
> 
> Rick
> 
>> On Mon, May 22, 2017 at 7:08 AM, Erich Steinböck 
>>  wrote:
>> Should `oorexx-config.1` and `oorexx-config.in` (including all references to 
>> those files) be removed from trunk?
>> 
>> Same for `oorexx.spec.in`, `postflight.in`, and `preflight.in` ?
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel