Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rony G. Flatscher]

Rebuilt ooRexx from trunk:

On 29.11.2018 18:29, Rick McGuire wrote:
> On Thu, Nov 29, 2018 at 12:17 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
... cut ...

> Some remarks on the build process and running the interpreters initially:
>
>   * both, the 32- and 64-bit build process will pause at the point where 
> the img-file gets
> created; it is necessary to kill the rxapi-process (this despite the 
> fact, that no rxapi
> was running when starting the compilation process so assuming that it 
> is actually the
> rxapi that just got created)
>
> I just committed changes that should fix that problem.
Indeed!

>   * the first time launching "rexxtry.rex" caused a hang on start-up; 
> pressing ctl-c and then
> rerun "rexxtry.rex" succeeds;
>   o the reason seems to be that the very first time "rxapi" gets started, 
> but causes that
> input hang on "rexxtry.rex"; killing "rexxtry.rex" with ctl-c and 
> running it immediately
> afterwards works ("rxapi" runs already in this case)
>
> Same issue.
Fixed!

---rony

P.S.: Have to leave so cannot test on Linux and MacOSX, next slot with enough 
free time will be
Saturday.

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

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rony G. Flatscher]

O.K. finished both debug-Windows-installer packages and placed them on my 
Dropbox
(https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0).

To install at your own risk ;):

  * make sure that either ooRexx got uninstalled already or make sure that 
rxapi is not running
(kill it e.g. with Taskmanager or Sysinternals ProcessExplorer),
  * make sure that on the installation dialog you uncheck "install rxapi as a 
Windows service" (not
sure about the exact wording)

Have to run.

---rony

P.S.: Did not have the time to see/test whether currently the NSIS installer 
would allow parallel
installation of 32- and 64-bit ooRexx (and uninstall them independently from 
each other).





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

[Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

When creating the deb-package for Ubuntu-Linux installing (and uninstalling) it 
will report an error:

Installation:

rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -i 
ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb 
Selecting previously unselected package oorexx.
(Reading database ... 438687 files and directories currently installed.)
Preparing to unpack ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb ...
Unpacking oorexx (5.0.0) ...
Setting up oorexx (5.0.0) ...
cp: cannot stat '/usr/bin/rxapid': No such file or directory 
/var/lib/dpkg/info/oorexx.postinst:
47: /var/lib/dpkg/info/oorexx.postinst: /etc/init.d/rxapid: not found dpkg: 
error processing
package oorexx (--install): subprocess installed post-installation script 
returned error exit
status 127
Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ...
Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20180209-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 oorexx
rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ 


Deinstallation:

rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -r oorexx
(Reading database ... 438790 files and directories currently installed.)
Removing oorexx (5.0.0) ...
initctl: Unable to connect to Upstart: Failed to connect to socket 
/com/ubuntu/upstart:
Connection refused
insserv: warning: script 'binfmt-support' missing LSB tags and overrides
insserv: Default-Start undefined, assuming empty start runlevel(s) for 
script `binfmt-support'
insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for 
script `binfmt-support'
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ...
Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20180209-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ 

Probably the rxapid related commands need to be removed from CMake (do not know 
how to do that
correctly myself, hence cannot offer a patch).

---

Ad creating a RPM installer on Ubuntu: unfortunately, the resulting package is 
identified by "file"
as a DEB package, even though running:

cmake -DBUILD_RPM=1 -DOS_DIST=fedora  path/to/source
make
cpack ./

---

Another point on Linux and MacOS: library names. It seems that if binaries like 
external Rexx
function packages got created and linked to earlier Rexx libraries, at least 
symbolic links need to
be present to allow them to run against ooRexx 5.

Currently on Linux and MacOS the libraries that get created are in the form:

Linux:

librexxapi.so -> librexxapi.so.5.0.0
librexxutil.so -> librexxutil.so.5.0.0


MacOS (note 'dylib' after the version number, cf.
):

librexxapi.dylib -> librexxapi.5.0.0.dylib
librexxutil.dylib -> librexxutil.5.0.0.dylib
...

It seems that if one needs to use external Rexx function libraries that got 
created with earlier
versions of Rexx that there should be symbolic links like:

Linux:

librexxapi.so.4 -> librexx.so
librexxapi.so.3 -> librexx.so
librexxapi.so.2 -> librexx.so

librexxutil.so.4 -> librexxutil.so
librexxutil.so.3 -> librexxutil.so
librexxutil.so.2 -> librexxutil.so
...

MacOS (note 'dylib' after the version number, cf.
):

librexxapi.4.dylib -> librexx.dylib
librexxapi.3.dylib -> librexx.dylib
librexxapi.2.dylib -> librexx.dylib

librexxutil.4.dylib -> librexxutil.dylib
librexxutil.3.dylib -> librexxutil.dylib
librexxutil.2.dylib -> librexxutil.dylib
...

So the question would be: should CMake create those symbolic links on Linux and 
MacOS in addition?

---rony

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

Re: [Oorexx-devel] Time for the *ix users to pitch in.

[Rony G. Flatscher]

Fresh build, trying to compile until:

[ 76%] Building CXX object 
CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´int acquireLock(const char*)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:87:16:
 error: ´lockfd` was not declared in this scope
 if (flock (lockfd, LOCK_EX | LOCK_NB) < 0)
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´void releaseLock(const char*, int)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:108:24:
 error: ´unline` was not declared in this scope
 unline(lockFileName);
^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:
 In function ´int main(int, char**)`:

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:123:23:
 error: ´MAX_PATH` was not declared in this scope
 char lockFileName[MAX_PATH];
   ^

/home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp:137:14:
 error: ´lockFileName` was not declared in this scope
 snprintf(lockFileName, sizeof(lockFileName), 
"%s/.ooRexx-%d.%d.%d-%s.lock", homePath, ORX_VER, ORX_REL, ORX_MOD,
  ^
CMakeFiles/rxapi.dir/build.make:422: recipe for target 
'CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o' 
failed
make[2]: *** 
[CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o] 
Error 1
CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/rxapi.dir/all' 
failed
make[1]: *** [CMakeFiles/rxapi.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ 
 

---rony

On 01.12.2018 17:24, Rick McGuire wrote:
> I found a fairly simple example of using a lock file that was simpler than 
> using a pid file, so
> went with that.
>
> Rick
>
> On Sat, Dec 1, 2018 at 10:48 AM Erich Steinböck  > wrote:
>
> This question seems to exactly cover our situation:
> 
> https://stackoverflow.com/questions/30742508/linux-local-communication-sockets-why-is-bind-not-failing-as-expected
>
> The solution seems to better than what I proposed
>
> On Sat, Dec 1, 2018 at 4:13 PM Erich Steinböck  > wrote:
>
> try this again after commenting out the call to the method that 
> performs the unlink().
>
> If I comment out the call to checkServiceName, the bind fails (and 
> with it rxapi) even the
> "first" time, unless I manually remove the 
> $XDG_RUNTIME_DIR/.ooRexx-5.0.0-64.service
> special file
>
> kill the first instance and try launching rxapi again to see if 
> successfully binds.
>
> If rxapi is started successfully, and I kill it, the special file 
> still exists, and as
> such starting any further instances of rxapi fail, until I manually 
> remove the special
> file again.
>
> We probably need rxapi to open a second, standard file (in the same 
> XDG_RUNTIME_DIR
> location) that it opens, and any further rxapi instances would only 
> proceed if they could
> successfully unlink this file, which would be the case if the initial 
> rxapi instance has
> ended or was killed.  (Well, yes, that's probably exactly what you 
> describe as "still a
> need for a .pid file")
>
> On Sat, Dec 1, 2018 at 3:21 PM Rick McGuire  > wrote:
>
> Erich, 
>
> One more experiment. Since there is some automatic cleanup 
> involved with that file
> because of its location, could you try this again after 
> commenting out the call to the
> method that performs the unlink(). From what I've read, the 
> second bind should fail,
> which will cause the second instance to close. 
>
> However, there's another scenario I'm worried about. If the first 
> experiment works,
> kill the first instance and try launching rxapi again to see if 
> successfully binds.
>
> Rick
>
> On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck 
>  > wrote:
>
> One thing that needs to be checked out is what happens if 
> a second version of
> rxapi gets launched.
> .. there's also some code to unlink() the file before the 
> bind operation that
> I'm hoping will fail if the socket is still in use.  
>
>
> 

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

On 01.12.2018 17:33, Enrico Sorichetti via Oorexx-devel wrote:
> There are some typos to fix ..
> Unlink instead of online 
> PATH_MAX instead of MAX_PATH
> lockFd instead of lockfd
Thank you Erich, that made it pass!

---rony

>
>
>> On 1 Dec 2018, at 17:24, Rick McGuire > <mailto:object.r...@gmail.com>> wrote:
>>
>> Thought I had caught all of those. Just committed a fix. 
>>
>> Rick
>>
>> On Sat, Dec 1, 2018 at 11:06 AM Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> When creating the deb-package for Ubuntu-Linux installing (and 
>> uninstalling) it will report
>> an error:
>>
>> Installation:
>>
>> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -i 
>> ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb 
>> Selecting previously unselected package oorexx.
>> (Reading database ... 438687 files and directories currently 
>> installed.)
>> Preparing to unpack ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb ...
>> Unpacking oorexx (5.0.0) ...
>> Setting up oorexx (5.0.0) ...
>> cp: cannot stat '/usr/bin/rxapid': No such file or directory
>> /var/lib/dpkg/info/oorexx.postinst: 47: 
>> /var/lib/dpkg/info/oorexx.postinst:
>> /etc/init.d/rxapid: not found dpkg: error processing package oorexx 
>> (--install):
>> subprocess installed post-installation script returned error exit 
>> status 127
>> Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ...
>> Processing triggers for bamfdaemon 
>> (0.5.3~bzr0+16.04.20180209-0ubuntu1) ...
>> Rebuilding /usr/share/applications/bamf-2.index...
>> Processing triggers for mime-support (3.59ubuntu1) ...
>> Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
>> Processing triggers for man-db (2.7.5-1) ...
>> Errors were encountered while processing:
>>  oorexx
>> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ 
>>
>>
>> Deinstallation:
>>
>> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -r oorexx
>> (Reading database ... 438790 files and directories currently 
>> installed.)
>> Removing oorexx (5.0.0) ...
>> initctl: Unable to connect to Upstart: Failed to connect to socket 
>> /com/ubuntu/upstart:
>> Connection refused
>> insserv: warning: script 'binfmt-support' missing LSB tags and 
>> overrides
>> insserv: Default-Start undefined, assuming empty start runlevel(s) 
>> for script `binfmt-support'
>> insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) 
>> for script `binfmt-support'
>> Processing triggers for man-db (2.7.5-1) ...
>> Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ...
>> Processing triggers for bamfdaemon 
>> (0.5.3~bzr0+16.04.20180209-0ubuntu1) ...
>> Rebuilding /usr/share/applications/bamf-2.index...
>> Processing triggers for mime-support (3.59ubuntu1) ...
>> Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
>> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ 
>>
>> Probably the rxapid related commands need to be removed from CMake (do 
>> not know how to do
>> that correctly myself, hence cannot offer a patch).
>>
>> ---
>>
>> Ad creating a RPM installer on Ubuntu: unfortunately, the resulting 
>> package is identified by
>> "file" as a DEB package, even though running:
>>
>> cmake -DBUILD_RPM=1 -DOS_DIST=fedora  path/to/source
>> make
>> cpack ./
>>
>> ---
>>
>> Another point on Linux and MacOS: library names. It seems that if 
>> binaries like external Rexx
>> function packages got created and linked to earlier Rexx libraries, at 
>> least symbolic links
>> need to be present to allow them to run against ooRexx 5.
>>
>> Currently on Linux and MacOS the libraries that get created are in the 
>> form:
>>
>> Linux:
>>
>> librexxapi.so -> librexxapi.so.5.0.0
>> librexxutil.so -> librexxutil.so.5.0.0
>> 
>>
>> MacOS (note 'dylib' after the version number, cf.
>> <https://docstore.mik.ua/orelly/unix3/mac/ch05_04.htm>
>> <https://docstore.mik.ua/orelly/unix3/mac/ch0

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

On 01.12.2018 17:24, Rick McGuire wrote:
> Thought I had caught all of those. Just committed a fix.
Thank you very much!

LINUX:

Rev. 11549 can be installed and uninstalled without any error messages. The 
ooRexx test suite
runs through (with "-X native_API").

MacOS:

Rev. 11549: the ooRexx test suite runs through, if excluding 
"Macrospace.testGroup" (will
comment in the bug tracker) in addition to "native_API".

Having read Enrico's posting I did use "kill -s SIGHUP" to kill the rxapi 
instance, and removed
the special files ".ooRexx-5.0.0-64.lock" and ".oooRexx-5.0.0-64.service" 
files in my home
directory and then ran the entire test suite with "rexx testOORexx.rex -s 
-X native_API -x
Macrospace.testGroup" and got indeed the four failures in the 
"rxQueue.testGroup" as he has
reported.
Rerunning the test suite right afterwards with the same command will run 
them successfully.

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

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

On 01.12.2018 18:39, Rick McGuire wrote:
> Does the Mac not set the $XDG_RUNTIME_DIR environment variable?
No, this is a Linux thing only.

---rony



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

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

Sorry, was too fast: <https://www.freedesktop.org/wiki/Software/xdg-utils/>.

---rony


On 01.12.2018 18:41, Rony G. Flatscher wrote:
> On 01.12.2018 18:39, Rick McGuire wrote:
>> Does the Mac not set the $XDG_RUNTIME_DIR environment variable?
> No, this is a Linux thing only.
>
> ---rony
>



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

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

The same observation as on MacOS can be experienced on Linux (same four 
failures in
"rxQueue.testGroup").

---rony


On 01.12.2018 18:33, Rony G. Flatscher wrote:
> On 01.12.2018 17:24, Rick McGuire wrote:
>> Thought I had caught all of those. Just committed a fix.
> Thank you very much!
>
> LINUX:
>
> Rev. 11549 can be installed and uninstalled without any error messages. 
> The ooRexx test suite
> runs through (with "-X native_API").
>
> MacOS:
>
> Rev. 11549: the ooRexx test suite runs through, if excluding 
> "Macrospace.testGroup" (will
> comment in the bug tracker) in addition to "native_API".
>
> Having read Enrico's posting I did use "kill -s SIGHUP" to kill the rxapi 
> instance, and
> removed the special files ".ooRexx-5.0.0-64.lock" and 
> ".oooRexx-5.0.0-64.service" files in my
> home directory and then ran the entire test suite with "rexx 
> testOORexx.rex -s -X native_API
> -x Macrospace.testGroup" and got indeed the four failures in the 
> "rxQueue.testGroup" as he has
> reported.
> Rerunning the test suite right afterwards with the same command will run 
> them successfully.
>
> ---rony

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

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

Did an uninstall of rev 11549 on LINUX:

rxapi was still running (killed it with "kill -1")
the lock an service files ".oorexx-5.0.0-64.*" were still in 
XDG_RUNTIME_DIR ("/run/user/1000"),
so deleted them there

Checked out rev 11550, recreated the ooRexx LINUX interpreter and installed it: 
running the test
suite immediately causes the four failures in "rxQueue.testGroup".

---rony


On 01.12.2018 18:50, Rony G. Flatscher wrote:
>
> The same observation as on MacOS can be experienced on Linux (same four 
> failures in
> "rxQueue.testGroup").
>
> ---rony
>
>
> On 01.12.2018 18:33, Rony G. Flatscher wrote:
>> On 01.12.2018 17:24, Rick McGuire wrote:
>>> Thought I had caught all of those. Just committed a fix.
>> Thank you very much!
>>
>> LINUX:
>>
>> Rev. 11549 can be installed and uninstalled without any error messages. 
>> The ooRexx test suite
>> runs through (with "-X native_API").
>>
>> MacOS:
>>
>> Rev. 11549: the ooRexx test suite runs through, if excluding 
>> "Macrospace.testGroup" (will
>> comment in the bug tracker) in addition to "native_API".
>>
>> Having read Enrico's posting I did use "kill -s SIGHUP" to kill the 
>> rxapi instance, and
>> removed the special files ".ooRexx-5.0.0-64.lock" and 
>> ".oooRexx-5.0.0-64.service" files in my
>> home directory and then ran the entire test suite with "rexx 
>> testOORexx.rex -s -X native_API
>> -x Macrospace.testGroup" and got indeed the four failures in the 
>> "rxQueue.testGroup" as he
>> has reported.
>> Rerunning the test suite right afterwards with the same command will run 
>> them successfully.
>>
>> ---rony

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

[Oorexx-devel] A request for getting somehow the (svn) revision number of the current running/using ooRexx interpreter

[Rony G. Flatscher]

Currently it is quite a time consuming effort to make sure that all the 
different ooRexx builds on
all of the different operating systems have been built using the latest svn 
revision.

It would be of great help in such situations, if it became possible to learn 
the (svn) revision
number the current running ooRexx interpreter got built, something like:

"rexx -v" on the command line may append the svn revision number, e.g.

Open Object Rexx Version 5.0.0 - Internal Test Version - svn11550

or substituting it for the "revision" part of the ooRexx version number

Open Object Rexx Version 5.0.11550 - Intrenal Test Version
Open Object Rexx Version 5.0.svn11550 - Internal Test Version

Also from within ooRexx this piece of information would proof helpful and help 
save time! Maybe
something like:

"parse source s; say s"  yielding: "REXX-ooRexx_5.0.11550(MT)_32-bit 6.05 
29 Nov 2018"

"say .rexxinfo~revision" yielding "11550" or having a totally new .rexxinfo 
entry like
"svn.revision"

*Any* solution to this problem would help save a lot of time and effort at 
times! (Also in case of
error reports the svn revision might help to determine whether the error was 
already resolved or not.)

---rony

P.S.: This might be even more important in the future, when different ooRexx 
interpreters execute on
the same machine from different sources. Determining the exact (svn) revision 
of each of the ooRexx
interpreters on a single system may become necessary for maintenance purposes.

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

Re: [Oorexx-devel] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rony G. Flatscher]

On 01.12.2018 19:16, Erich Steinböck wrote:
> The latest commit to the rxapi sandbox builds and passes all tests on my 
> Ubuntu 16.04 VM.
> Have never had any rxqueue or Macrospace test failures with any of the 
> previous rxapi sandbox builds.
>
Maybe the postings crossed: my posting from 19:02 reported the behaviour on 
Linux with rev. 11550,
currently the latest version I have access to:

  * uninstalling ooRexx ("sudo dpkg -r oorexx")
  * killing "rxapi" and removing the "$XDG_RUNTIME_DIR/.ooRexx*" files

  * creating and installing ooRexx rev. 11550 anew
  * running the ooRexx test suite with "-X native_API" yields the four failures 
in
"rxQueue.testGroup" that Enrico reported for MacOS as well on Linux

The "Macrospace.testGroup" succeeds on Linux, but stops the test suite without 
an error and without
the test suite statistics on MacOS (will comment in [bug1576] ASAP).

---rony


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

Re: [Oorexx-devel] Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

On 02.12.2018 17:27, Rick McGuire wrote:
> Ok, I have a theory that I'd like you to test out. Run this simple one-line 
> program after you have
> killed rxapi, then run it a second time:
>
> say value('RXQUEUESESSION',,'ENVIRONMENT')
> I suspect the code gives up trying to connect to the rxapi process before I 
> has a chance to get fully. The first connection attempt occurs when it 
> creates the session queue and sets the RXSESSIONQUEUE
> env variable. If that never happens, then the rxqueue filter will add the 
> lines to the wrong session queue.

Running the command with "rexx -e say value('RXQUEUESESSION',,'ENVIRONMENT')" 
first yields an empty
string, the second time some value (in my case "0x15fa7").

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

Re: [Oorexx-devel] Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

Rev 11552:

  * running the "say value()" program will only show an empty value now,

  * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass)

  * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
testOORexx.rex -f
Macrospace.testGroup -s -S" stops without error and statistics while/after 
running the seventh
test "TEST_ADD_THREE_ARGS_OPTION"
  o dropping the trailing flags "-s" or "-s -S" yields dots, but it seems 
the test runs forever
killing it after approx. three minutes (on Windows test execution takes 
not even a second)

---rony

On 02.12.2018 17:53, Rick McGuire wrote:
> Great, think this is is a simple as adding a few sleep calls between 
> connection attempts.
>
> Rick
>
> On Sun, Dec 2, 2018 at 11:41 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> On 02.12.2018 17:27, Rick McGuire wrote:
>> Ok, I have a theory that I'd like you to test out. Run this simple 
>> one-line program after you
>> have killed rxapi, then run it a second time:
>>
>> say value('RXQUEUESESSION',,'ENVIRONMENT')
>> I suspect the code gives up trying to connect to the rxapi process 
>> before I has a chance to get fully. The first connection attempt occurs when 
>> it creates the session queue and sets the RXSESSIONQUEUE
>> env variable. If that never happens, then the rxqueue filter will add 
>> the lines to the wrong session queue.
>
> Running the command with "rexx -e say 
> value('RXQUEUESESSION',,'ENVIRONMENT')" first yields an
> empty string, the second time some value (in my case "0x15fa7").
>
> ---rony
>

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

[Oorexx-devel] Question ad running ooRexx without placing it on the PATH

[Rony G. Flatscher]

Now that the sandbox rxapi version of ooRexx can be run off a directory (and 
therefore also from a
stick), would it be possible to run/use ooRexx without even setting the PATH 
for it?

This probably would mean that ooRexx would have to be able to find the pieces 
that belong to it in
the location it resides itself, i.e. the directory where ooRexx (rexx.dll?) was 
started from, like
libraries and Rexx packages/commands.

This would allow to switch ooRexx interpreters to use by replacing a front-end 
script that starts
ooRexx or by just placing a link (junction/reparse point on Windows?) in a 
directory which already
gets looked up by the operating system.

---rony



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

Re: [Oorexx-devel] Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

On 02.12.2018 20:48, Rick McGuire wrote:
> Well, it's time for you to do some basic problem determination. Somethings to 
> try:
Will do.

> 1) run the tests in the debugger to see what is killing them. We've seen 
> cases in the past on all
> platforms where the OS just kills a process without giving us an indication. 
> This usually can be
> trapped in a debuffer.
On Apple I am lost with regards to the debugger, unfortunately. Maybe some of 
the Apple-savvy
developers can take on this task? Maybe Enrico?

> 2) Try commenting out the test that appears to be running to see if the 
> problem is isolated to
> that test. 
>
> 3) If 2) works, invert this and see if that test method fails in isolation. 
>
> 4) Add a trace instruction to the suspect test method to see if you can 
> further narrow down the
> problem.
Will try 2) to 4) and report back.

---rony

>
> On Sun, Dec 2, 2018 at 12:19 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Rev 11552:
>
>   * running the "say value()" program will only show an empty value now,
>
>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests 
> pass)
>
>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
> testOORexx.rex -f
> Macrospace.testGroup -s -S" stops without error and statistics 
> while/after running the
> seventh test "TEST_ADD_THREE_ARGS_OPTION"
>   o dropping the trailing flags "-s" or "-s -S" yields dots, but it 
> seems the test runs
> forever killing it after approx. three minutes (on Windows test 
> execution takes not
> even a second)
>
> ---rony
>
>     On 02.12.2018 17:53, Rick McGuire wrote:
>> Great, think this is is a simple as adding a few sleep calls between 
>> connection attempts.
>>
>> Rick
>>
>> On Sun, Dec 2, 2018 at 11:41 AM Rony G. Flatscher 
>> > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> On 02.12.2018 17:27, Rick McGuire wrote:
>>> Ok, I have a theory that I'd like you to test out. Run this simple 
>>> one-line program
>>> after you have killed rxapi, then run it a second time:
>>>
>>> say value('RXQUEUESESSION',,'ENVIRONMENT')
>>> I suspect the code gives up trying to connect to the rxapi process 
>>> before I has a chance to get fully. The first connection attempt occurs 
>>> when it creates the session queue and sets the RXSESSIONQUEUE
>>> env variable. If that never happens, then the rxqueue filter will 
>>> add the lines to the wrong session queue.
>>
>> Running the command with "rexx -e say 
>> value('RXQUEUESESSION',,'ENVIRONMENT')" first
>> yields an empty string, the second time some value (in my case 
>> "0x15fa7").
>>
>> ---rony
>>

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

Re: [Oorexx-devel] Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

Have to run to get to the dinner place before they close the kitchen, hence 
very brief:

  * it seems that in "Macrospace.testGroup" the method 
"test_add_three_args_option" causes the
problem (exiting everything without error and statistics)
  o injecting ".error~say"-statements at first no output took place
  + replacing it in one line once with ".stderr~say" caused output to 
be shown, changing it
back to ".error~say" then also showed the output
  o added a "signal on syntax", but does not get triggered
  o the program exits in the statement with option being "a"
  + "self~assertEquals(self~OK, SysAddRexxMacro("test_add", 
self~macroPath, option))

Cannot find out more, sorry.

---rony


On 02.12.2018 20:55, Rony G. Flatscher wrote:
>
> On 02.12.2018 20:48, Rick McGuire wrote:
>> Well, it's time for you to do some basic problem determination. Somethings 
>> to try:
> Will do.
>
>> 1) run the tests in the debugger to see what is killing them. We've seen 
>> cases in the past on all
>> platforms where the OS just kills a process without giving us an indication. 
>> This usually can be
>> trapped in a debuffer.
> On Apple I am lost with regards to the debugger, unfortunately. Maybe some of 
> the Apple-savvy
> developers can take on this task? Maybe Enrico?
>
>> 2) Try commenting out the test that appears to be running to see if the 
>> problem is isolated to
>> that test. 
>>
>> 3) If 2) works, invert this and see if that test method fails in isolation. 
>>
>> 4) Add a trace instruction to the suspect test method to see if you can 
>> further narrow down the
>> problem.
> Will try 2) to 4) and report back.
>
> ---rony
>
>>
>> On Sun, Dec 2, 2018 at 12:19 PM Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> Rev 11552:
>>
>>   * running the "say value()" program will only show an empty value now,
>>
>>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests 
>> pass)
>>
>>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
>> testOORexx.rex -f
>> Macrospace.testGroup -s -S" stops without error and statistics 
>> while/after running the
>> seventh test "TEST_ADD_THREE_ARGS_OPTION"
>>   o dropping the trailing flags "-s" or "-s -S" yields dots, but it 
>> seems the test runs
>> forever killing it after approx. three minutes (on Windows test 
>> execution takes not
>> even a second)
>>
>> ---rony
>>
>> On 02.12.2018 17:53, Rick McGuire wrote:
>>> Great, think this is is a simple as adding a few sleep calls between 
>>> connection attempts.
>>>
>>> Rick
>>>
>>> On Sun, Dec 2, 2018 at 11:41 AM Rony G. Flatscher 
>>> >> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>
>>> On 02.12.2018 17:27, Rick McGuire wrote:
>>>> Ok, I have a theory that I'd like you to test out. Run this simple 
>>>> one-line program
>>>> after you have killed rxapi, then run it a second time:
>>>>
>>>> say value('RXQUEUESESSION',,'ENVIRONMENT')
>>>> I suspect the code gives up trying to connect to the rxapi process 
>>>> before I has a chance to get fully. The first connection attempt occurs 
>>>> when it creates the session queue and sets the RXSESSIONQUEUE
>>>> env variable. If that never happens, then the rxqueue filter will 
>>>> add the lines to the wrong session queue.
>>>
>>> Running the command with "rexx -e say 
>>> value('RXQUEUESESSION',,'ENVIRONMENT')" first
>>> yields an empty string, the second time some value (in my case 
>>> "0x15fa7").
>>>
>>> ---rony
>>>

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

Re: [Oorexx-devel] Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

Forgot to mention:

self~macroPath shows the full path to the file "Macrospace.rex", self~ok 
the value "0"

---rony


On 02.12.2018 21:19, Rony G. Flatscher wrote:
>
> Have to run to get to the dinner place before they close the kitchen, hence 
> very brief:
>
>   * it seems that in "Macrospace.testGroup" the method 
> "test_add_three_args_option" causes the
> problem (exiting everything without error and statistics)
>   o injecting ".error~say"-statements at first no output took place
>   + replacing it in one line once with ".stderr~say" caused output to 
> be shown, changing
> it back to ".error~say" then also showed the output
>   o added a "signal on syntax", but does not get triggered
>   o the program exits in the statement with option being "a"
>   + "self~assertEquals(self~OK, SysAddRexxMacro("test_add", 
> self~macroPath, option))
>
> Cannot find out more, sorry.
>
> ---rony
>
>
> On 02.12.2018 20:55, Rony G. Flatscher wrote:
>>
>> On 02.12.2018 20:48, Rick McGuire wrote:
>>> Well, it's time for you to do some basic problem determination. Somethings 
>>> to try:
>> Will do.
>>
>>> 1) run the tests in the debugger to see what is killing them. We've seen 
>>> cases in the past on
>>> all platforms where the OS just kills a process without giving us an 
>>> indication. This usually
>>> can be trapped in a debuffer.
>> On Apple I am lost with regards to the debugger, unfortunately. Maybe some 
>> of the Apple-savvy
>> developers can take on this task? Maybe Enrico?
>>
>>> 2) Try commenting out the test that appears to be running to see if the 
>>> problem is isolated to
>>> that test. 
>>>
>>> 3) If 2) works, invert this and see if that test method fails in isolation. 
>>>
>>> 4) Add a trace instruction to the suspect test method to see if you can 
>>> further narrow down the
>>> problem.
>> Will try 2) to 4) and report back.
>>
>> ---rony
>>
>>>
>>> On Sun, Dec 2, 2018 at 12:19 PM Rony G. Flatscher >> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>
>>> Rev 11552:
>>>
>>>   * running the "say value()" program will only show an empty value now,
>>>
>>>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests 
>>> pass)
>>>
>>>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
>>> testOORexx.rex -f
>>> Macrospace.testGroup -s -S" stops without error and statistics 
>>> while/after running the
>>> seventh test "TEST_ADD_THREE_ARGS_OPTION"
>>>   o dropping the trailing flags "-s" or "-s -S" yields dots, but it 
>>> seems the test runs
>>> forever killing it after approx. three minutes (on Windows test 
>>> execution takes not
>>> even a second)
>>>
>>> ---rony
>>>
>>> On 02.12.2018 17:53, Rick McGuire wrote:
>>>> Great, think this is is a simple as adding a few sleep calls between 
>>>> connection attempts.
>>>>
>>>> Rick
>>>>
>>>> On Sun, Dec 2, 2018 at 11:41 AM Rony G. Flatscher 
>>>> >>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>>
>>>> On 02.12.2018 17:27, Rick McGuire wrote:
>>>>> Ok, I have a theory that I'd like you to test out. Run this 
>>>>> simple one-line program
>>>>> after you have killed rxapi, then run it a second time:
>>>>>
>>>>> say value('RXQUEUESESSION',,'ENVIRONMENT')
>>>>> I suspect the code gives up trying to connect to the rxapi 
>>>>> process before I has a chance to get fully. The first connection attempt 
>>>>> occurs when it creates the session queue and sets the RXSESSIONQUEUE
>>>>> env variable. If that never happens, then the rxqueue filter will 
>>>>> add the lines to the wrong session queue.
>>>>
>>>> Running the command with "rexx -e say 
>>>> value('RXQUEUESESSION',,'ENVIRONMENT')" first
>>>> yields an empty string, the second time some value (in my case 
>>>> "0x15fa7").
>>>>
>>>> ---rony
>>>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

Rev 11555, MacOSX.

  * running "rexx -e say value('RXQUEUESESSION',,'ENVIRONMENT')"
  o if no rxapi is running then an empty string is shown, otherwise a value 
like "0x790" gets
displayed

  * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass) 
in both situations: no
rxapi running, rxapi already running

  * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
testOORexx.rex -f
Macrospace.testGroup -s -S" stops without error and statistics while/after 
running the seventh
test "TEST_ADD_THREE_ARGS_OPTION"; it does not matter whether rxapi is 
already running or not

  o went back and created ooRexx without the flag 
"-DCMAKE_BUILD_TYPE=Release", assuming that a
Debug version gets created, the behaviour changed a little bit then:

  + the program gets killed, there is a note about "Segmentation fault: 
11" in the Terminal

  + then remembering some of Ernesto's snippets I ran the test case 
with "lldb" which seems
to be Apple's debugger, here the session:

wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f 
Macrospace.testGroup -s -S
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
"Macrospace.testGroup" "-s" "-S"
(lldb) 
(lldb) run
Process 1795 launched: '/usr/local/bin/rexx' (x86_64)
Searching for test containers..
Executing automated test suite
Executing testSuite [testCase: [] (an 
ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
 with [36] test cases ...
... running TestCase object [testCase: 
[TEST_ADD_ARG_OPTION_ILLEGAL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: 
[TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: 
[TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] 
(a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] 
(a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
Process 1795 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x40)
frame #0: 0x0001050059bc 
*librexx.5.0.0.dylib`ArrayClass::lastIndex()* + 12
librexx.5.0.0.dylib`ArrayClass::lastIndex:
->  0x1050059bc <+12>: movq   0x40(%rdi), %rax
0x1050059c0 <+16>: popq   %rbp
0x1050059c1 <+17>: retq   
0x1050059c2 <+18>: nopw   %cs:(%rax,%rax)
Target 0: (rexx) stopped.
(lldb) 

---rony


On 02.12.2018 18:18, Rony G. Flatscher wrote:
>
> Rev 11552:
>
>   * running the "say value()" program will only show an empty value now,
>
>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass)
>
>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
> testOORexx.rex -f
> Macrospace.testGroup -s -S" stops without error and statistics 
> while/after running the seventh
> test "TEST_ADD_THREE_ARGS_OPTION"
>   o dropping the trailing flags "-s" or "-s -S" yields dots, but it seems 
> the test runs
> forever killing it after approx. three minutes (on Windows test 
> execution takes not even a
> second)
>
> ---rony
>
> On 02.12.2018 17:53, Rick McGuire wrote:
>> Great, think this is is a simple as ad

Re: [Oorexx-devel] MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

OK, I am able to get "Macrospace.testGroup" to run!

As Ernesto and P.O. have been reporting that the test runs successfully, I went 
back to
"~/Application/ooRexx.5.0.0/bin" added that directory to PATH and created a 
DYLD_LIBRARY_PATH to
point to that location: ran the tests from there and lo and behold the 
"Macrospace.testGroup" ran
successfully to completion!

Just wanted to let you know, now trying to figure out why.

It may have to do with the configuration that is in place when using ooRexx 
installed via BSF4ooRexx
(which places the files in those places and directories the Apple developer 
rules suggest). In that
case there are symbolic links to /usr/local/bin and /usr/local/lib. Will 
double-double check whether
all files from the latest ooRexx.5.0.0 build are in the proper places.

---rony


On 03.12.2018 13:47, Rony G. Flatscher wrote:
>
> Rev 11555, MacOSX.
>
>   * running "rexx -e say value('RXQUEUESESSION',,'ENVIRONMENT')"
>   o if no rxapi is running then an empty string is shown, otherwise a 
> value like "0x790" gets
> displayed
>
>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass) 
> in both situations:
> no rxapi running, rxapi already running
>
>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
> testOORexx.rex -f
> Macrospace.testGroup -s -S" stops without error and statistics 
> while/after running the seventh
> test "TEST_ADD_THREE_ARGS_OPTION"; it does not matter whether rxapi is 
> already running or not
>
>   o went back and created ooRexx without the flag 
> "-DCMAKE_BUILD_TYPE=Release", assuming that
> a Debug version gets created, the behaviour changed a little bit then:
>
>   + the program gets killed, there is a note about "Segmentation 
> fault: 11" in the Terminal
>
>   + then remembering some of Ernesto's snippets I ran the test case 
> with "lldb" which
> seems to be Apple's debugger, here the session:
> wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f 
> Macrospace.testGroup -s -S
> (lldb) target create "rexx"
> Current executable set to 'rexx' (x86_64).
> (lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
> "Macrospace.testGroup" "-s" "-S"
> (lldb) 
> (lldb) run
> Process 1795 launched: '/usr/local/bin/rexx' (x86_64)
> Searching for test containers..
> Executing automated test suite
> Executing testSuite [testCase: [] (an 
> ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
> Executing testSuite [testCase: [The Macrospace.testGroup class] 
> (an 
> ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
>  with [36] test cases ...
> ... running TestCase object [testCase: 
> [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: 
> [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: 
> [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: 
> [TEST_ADD_THREE_ARGS_OPTION] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> Process 1795 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_ACCESS (code=1, address=0x40)
>         frame #0: 0x0001050059bc 
> *librexx.5.0.0.dylib`ArrayClass::lastIndex()* + 12

Re: [Oorexx-devel] MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

Dear Enrico,

very sorry to have used "Ernesto" mistakingly! :-((


On 03.12.2018 14:10, Enrico Sorichetti via Oorexx-devel wrote:
>
>> On 3 Dec 2018, at 14:04, Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> As Ernesto
>
>
> I thought that the Che had been out of the picture for a while 
>
> Anyway the whole test suite run successfully from /usr/local
>
>  *Hasta la victoria siempre*
>
> Enrico Che Guevara :-)
:-)

>
> I will try to write something about the different setup options
Yes, that would be really *very* helpful for me!

In the meantime I compared all the files from the directory where the test ran 
successfully with
/usr/local/bin and /usr/local/lib which are identical.

The Rexx-related files in /usr/local/bin are linked to
/Library/Frameworks/ooRexx.framework/Commands/rexx, the files in /usr/local/lib 
are linked to
/Library/Frameworks.framework/Libraries/librexx.dylib.

Hmm, the only - wild? - thing I can think of is that the files in the 
"[BSF4]ooRexx.framework"
sub|directories are not owned by root in the wheel (administrator) group. Could 
that make a
difference on MacOS in the context of the Macrospace.testGroup interactions 
with the system?

---rony


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

Re: [Oorexx-devel] MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

On 03.12.2018 14:30, Rony G. Flatscher wrote:

>> I will try to write something about the different setup options
> Yes, that would be really *very* helpful for me!
>
> In the meantime I compared all the files from the directory where the test 
> ran successfully with
> /usr/local/bin and /usr/local/lib which are identical.
>
> The Rexx-related files in /usr/local/bin are linked to
> /Library/Frameworks/ooRexx.framework/Commands/rexx, the files in 
> /usr/local/lib are linked to
> /Library/Frameworks.framework/Libraries/librexx.dylib.
>
> Hmm, the only - wild? - thing I can think of is that the files in the 
> "[BSF4]ooRexx.framework"
> sub|directories are not owned by root in the wheel (administrator) group. 
> Could that make a
> difference on MacOS in the context of the Macrospace.testGroup interactions 
> with the system?
Just tested it by changing ownership to root and group to wheel, still, the 
same Segmentation fault:
11 is created.

@Enrico: when using lldb, how could one get a stack trace in such a situation?

---rony


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

Re: [Oorexx-devel] MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

On 03.12.2018 13:58, Rick McGuire wrote:
> What is really needed is a stack trace for the macrospace exception.

Here is the stacktrace (thanks to Enrico for pointing out the command!):

wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f Macrospace.testGroup -s 
-S
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
"Macrospace.testGroup" "-s" "-S"
(lldb) r
Process 3206 launched: '/usr/local/bin/rexx' (x86_64)
Searching for test containers..
Executing automated test suite
Executing testSuite [testCase: [] (an 
ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
 with [36] test cases ...
... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
Process 3206 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x40)
frame #0: 0x0001040059bc 
librexx.5.0.0.dylib`ArrayClass::lastIndex() + 12
librexx.5.0.0.dylib`ArrayClass::lastIndex:
->  0x1040059bc <+12>: movq   0x40(%rdi), %rax
0x1040059c0 <+16>: popq   %rbp
0x1040059c1 <+17>: retq   
0x1040059c2 <+18>: nopw   %cs:(%rax,%rax)
Target 0: (rexx) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x40)
  * frame #0: 0x0001040059bc 
librexx.5.0.0.dylib`ArrayClass::lastIndex() + 12
frame #1: 0x0001040c3f31 
librexx.5.0.0.dylib`ActivityManager::findActivity(_opaque_pthread_t*) + 33
frame #2: 0x0001040c4181 
librexx.5.0.0.dylib`ActivityManager::findActivity() + 17
frame #3: 0x0001040c44fd 
librexx.5.0.0.dylib`ActivityManager::getRootActivity() + 13
frame #4: 0x00010412f14f 
librexx.5.0.0.dylib`Interpreter::createInterpreterInstance(RexxOption*) + 95
frame #5: 0x00010412f556 
librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 230
frame #6: 0x00010412f605 
librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 37
frame #7: 0x0001040c17fb 
librexx.5.0.0.dylib`ActivityDispatcher::invoke(_RXSYSEXIT*, char const*) + 59
frame #8: 0x00010406252f 
librexx.5.0.0.dylib`RexxTranslateInstoreProgram + 79
frame #9: 0x000100686e1e 
librexxapi.5.0.0.dylib`LocalMacroSpaceManager::translateRexxProgram(char 
const*, ManagedRxstring&) + 1118
frame #10: 0x000100686951 
librexxapi.5.0.0.dylib`LocalMacroSpaceManager::addMacroFromFile(char const*, 
char const*, unsigned long) + 65
frame #11: 0x00010068a69d librexxapi.5.0.0.dylib`RexxAddMacro + 109
frame #12: 0x00010038d960 
librexxutil.dylib`SysAddRexxMacro_impl(RexxCallContext_*, char const*, char 
const*, char const*) + 160
frame #13: 0x00010038d88c librexxutil.dylib`SysAddRexxMacro + 60
frame #14: 0x0001040922e6 
librexx.5.0.0.dylib`NativeActivation::callNativeRoutine(RoutineClass*, 
NativeRoutine*, RexxString*, RexxObject**, unsigned long, ProtectedObject&) + 
614
frame #15: 0x000104096746 
librexx.5.0.0.dylib`NativeRoutine::call(Activity*, RoutineClass*, RexxString*, 
RexxObject**, unsigned long, ProtectedObject&) + 150
frame #16: 0x00010403ddae 
librexx.5.0.0.dylib`RoutineClass::call(Activity*, RexxString*, RexxObject**, 
unsigned long, ProtectedObject&) + 110
frame #17: 0x0001040c0c83 
librexx.5.0.0.dylib`PackageManager::callNativeRoutine(Activity*, RexxString*, 
RexxObject**

Re: [Oorexx-devel] MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

On 03.12.2018 15:13, Rick McGuire wrote:
> btw, this stacktrace is consistent with the mismatch theory. The 
> RexxAddMacro() api needs to
> dynamically resolve and resolve the address of the 
> RexxTranslateInstoreProgram() callback to
> translate the added macro. This stacktrace looks like what would happen if a 
> second version of the
> rexx library got loaded and called. None of the static variables in the 
> classes have been
> initialized, so there is an exception. Not a bug, but a problem in your setup.
Thanks, that is what I have feared!

---

I could verify that all the files from the CMake defined installation directory
(~/Application/ooRexx5.0.0/bin) are identical to the ones in /usr/local/bin and 
/usr/local/lib which
stem from the BSF4ooRexx installation files. Or with other words: all ooRexx 
related files are
identical.

Setting PATH and DYLD_LIBRARY_PATH to ~/Application/ooRexx.5.0.0/bin makes the 
test run
successfully. (The ooRexx files used in the B4R installation package stem from 
that directory.)

As my Mac has been used for years for creating MacOS version of BSF4ooRexx and 
the installation
packages include ooRexx compiled on that machine over many years, I am not sure 
whether that may
have an influence on the result of running the Macrospace.testGroup.

Any hints, suggestions what might be a subtle cause for this behavior (where 
and in which order
would Darwin look for libraries) would be highly appreciated. (Maybe it has to 
do with the Framework
installation type?)

---rony



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

Re: [Oorexx-devel] Merging the rxapi sandbox into trunk

[Rony G. Flatscher]

On 03.12.2018 17:40, Rick McGuire wrote:
> This appears to be working really well and solves a lot of problems.
Indeed, it does! It is a really *great* and *very beneficial* improvement for 
ooRexx, which will
allow to distribute ooRexx into segments that have been off-duty so far, 
because of the super user
needs to install it!

> And it was a LOT smaller change than I expected. I suspect we should give 
> this a good beta shake
> out, so I'd like to merge these changes back into trunk fairly quickly. Are 
> people OK with this?
+1

---rony


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

[Oorexx-devel] Sovled (Re: MacOS observations (Re: Some observations on the failing rxqueue tests.

[Rony G. Flatscher]

On 03.12.2018 15:31, Rick McGuire wrote:
> It doesn't matter if they are identical or not, the problem is getting two 
> different versions
> loaded. The first one is the actual running interpreter, the second one is 
> loaded and nothing is
> initialized in it, so the call crashes. 
>
> My guess is rexx launcher is picking up the version from the same directory, 
> but when RexxAddMacro
> dynamically loads the library, it is getting the first one encountered on the 
> lib path, which
> causes the problem. The solution is don't mix up your setups.
Well, finally I found the reason, which was just totally unexpected: while 
copying the libraries to
the distribution directory the symbolic links got resolved with the physical 
file, causing two
identical versions for each library under different names! This has not caused 
problems for years, tsk!

Reinstating the symbolic links such that e.g. "librexxapi.dylib" is a symbolic 
link that points to
"librexxapi.5.0.0.dylib" etc. causes the Macrogroup.testGroup to run 
successfully!

Here, how I found out on Apple: found the environment variable 
"DYLD_PRINT_LIBRARIES=YES" which will
print all libraries an applications loads, in this case the following was 
printed:

wu114184:trunk rony$ DYLD_PRINT_LIBRARIES=YES rexx testOORexx.rex -f 
Macrospace.testGroup -s -S
dyld: loaded: /usr/local/bin/rexx
dyld: loaded: /usr/local/lib/librexx.5.0.0.dylib
*dyld: loaded: **/usr/local/lib/librexxapi.5.0.0.dylib*
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/libc++.1.dylib
dyld: loaded: /usr/lib/system/libcache.dylib

... cut ...

dyld: loaded: /usr/lib/libc++abi.dylib
dyld: loaded: /usr/local/lib/librexxutil.dylib
*dyld: loaded: **/usr/local/lib/librexxapi.dylib*
dyld: loaded: /usr/local/lib/librxregexp.dylib
Searching for test containers..
Executing automated test suite
Executing testSuite [testCase: [] (an 
ooTestSuite@n/a_-4508788545)@-4508788545] with [2] test cases ...
Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4508815297]
 with [36] test cases ...
... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
dyld: loaded: /usr/local/lib/librexx.dylib
*Segmentation fault: 11*
wu114184:trunk rony$ 

So the same library got loaded twice, once without the version number, once 
with the version number
(see above "/usr/local/lib/librexxapi.dylib " and 
"/usr/local/lib/librexxapi.5.0.0.dylib") .

Then doing a "ls -al /usr/local/lib" yielded:

wu114184:trunk rony$ ls -al /usr/local/lib/librexx*
lrwxr-xr-x  1 root  wheel  66 Dec  3 13:30 
/usr/local/lib/librexx.5.0.0.dylib -> 
/Library/Frameworks/ooRexx.framework/Libraries/librexx.5.0.0.dylib
lrwxr-xr-x  1 root  wheel  60 Dec  3 13:30 /usr/local/lib/librexx.dylib -> 
/Library/Frameworks/ooRexx.framework/Libraries/librexx.dylib
*lrwxr-xr-x 1 root wheel 69 Dec 3 13:30 
/usr/local/lib/librexxapi.5.0.0.dylib ->
/Library/Frameworks/ooRexx.framework/Libraries/librexxapi.5.0.0.dylib 
lrwxr-xr-x 1 root wheel 63
Dec 3 13:30 /usr/local/lib/librexxapi.dylib ->
/Library/Frameworks/ooRexx.framework/Libraries/librexxapi.dylib*
lrwxr-xr-x  1 root  wheel  70 Dec  3 13:30 
/usr/local/lib/librexxutil.5.0.0.dylib -> 
/Library/Frameworks/ooRexx.framework/Libraries/librexxutil.5.0.0.dylib
lrwxr-xr-x  1 root  wheel  64 Dec  3 13:30 /usr/local/lib/librexxutil.dylib 
-> /Library/Frameworks/ooRexx.framework/Libraries/librexxutil.dylib

Which allowed me to see that no symbolic links are present among the libraries 
there, just symbolic
links to the installation directory. Double checking 

[Oorexx-devel] Ad killing correct rxapi at uninstall of ooRexx

[Rony G. Flatscher]

Now, that it has become possible to have different versions of ooRexx run in 
parallel (even with
different bitnesses), how would one be able to figure out/address the correct 
rxapi process to be
killed? Otherwise after installation the rxapi  process continues running 
(probably until a reboot).

Also with the aim of cleaning out everything known reliably, how would one be 
able to determine the
name and location of the .ooRexx*-lock and -service files, in order to remove 
them upon uninstall?

Maybe a short (external) utility or BIF that would allow to kill that ooRexx 
version's rxapi and
remove its .ooRexx*-lock and -service files may be helpful for cleanup purposes?

---rony


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

[Oorexx-devel] Questions ad differences between "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?

[Rony G. Flatscher]

While creating new installation packages from trunk for Windows, I have 
experimented with the
different build types with CMake.

Question: would the following create a DEBUG or a RELEASE version by default?

cmake -G "NMake Makefiles" F:\work\svn\oorexx\main\trunk

nmake
nmake clean

Question: what is the difference between DEBUG and RELWITHDEBUGINFO?

DEBUG: creates the .PDB-files on Windows (however, for debugging they need 
to be present in the directory from which NSIS took them?)

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=DEBUG 
F:\work\svn\oorexx\main\trunk

RELWITHDEBUGINFO: does not create the .PDB-files on Windows, yet the 
nsis-exe-file's size is a little larger (ca. 130KB) than the RELEASE version
  and appr. 30 MB (!) smaller than the DEBUG version

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO  
F:\work\svn\oorexx\main\trunk

For creating the installation packages I used the following two definitions:

RELEASE:
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELEASE  
-DDOC_SOURCE_DIR=G:\oorexx.tmp\oorexxDocs -DOS_DIST=windows 
F:\work\svn\oorexx\main\trunk

DEBUG and RELWITHDEBUGINFO:
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO 
-DDOC_SOURCE_DIR=G:\oorexx.tmp\oorexxDocs -DOS_DIST=windows 
F:\work\svn\oorexx\main\trunk

nmake
nmake nsis_template_installer

Here the three installation packages using the three different 
-DCMAKE_BUILD_TYPE on Windows (they
are in my Dropbox, 32-bit versions to follow:
):

04.12.2018  15:1250.988.523 ooRexx.5.0.0.11562-x86_64-debug.exe
04.12.2018  14:3220.485.840 ooRexx.5.0.0.11562-x86_64-release.exe
04.12.2018  15:0220.611.448 
ooRexx.5.0.0.11562-x86_64-relWithDebugInfo.exe

Any answers/insights highly appreciated!

---rony

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

Re: [Oorexx-devel] Questions ad differences between "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?

[Rony G. Flatscher]

On 04.12.2018 16:06, Rick McGuire wrote:
> Debug compiles the code without a lot of optimizations and also creates the 
> debug information.
> Release compiles with full optimizations and does not create the debug 
> information. RelWithDebInfo
> is the same as Release, but also creates the debug information. 
>
> The installer stuff in CMakeLists.txt is supposed to install the .pdb for 
> both the Debug and
> RelWithDebInfo configurations, so I'm not sure why you are not seeing. 
> Perhaps the case of the
> option matters, but in that case, the Debug version would be missing the 
> information too.
Thank you for your information and also thanks to Enrico, who also spelled out 
all the default build
options and some more interesting CMake properties.

Looking at my build options it turns out that I have a spelling error, I wrote 
"RELWITHDEBUGINFO"
instead of "RELWITHDEBINFO" ("DEB" and not "DEBUG")!
(Did not notice that error as CMake would not warn about it.)

Now the pdb-files and the nsis installation package get built successfully!

---rony





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

[Oorexx-devel] Remaining warnings for rev. 11562 on Linux, Mac and Windows ...

[Rony G. Flatscher]

As I have compiled ooRexx for all three platforms (temporarily available via my 
Dropbox at
) I 
was able to extract
the warnings the compilers issue on all three platforms, so here they are in a 
simple and
single-e-mail form:

2018-12-04, rev. 11562
==


//\\
linux-compile-warnings
==

rony@rony-linux:~/work/oorexx/trunk$ make
>
Scanning dependencies of target rexx
... cut ...
CMakeFiles/rexx.dir/interpreter/platform/unix/SysFileSystem.cpp.o: In 
function `SysFileSystem::getTempFileName()':
SysFileSystem.cpp:(.text+0x3de): warning: the use of `tmpnam' is dangerous, 
better use `mkstemp'
... cut ...

>
Scanning dependencies of target rexxutil
CMakeFiles/rexxutil.dir/extensions/rexxutil/platform/unix/rexxutil.cpp.o: 
In function `SysTempFileName(char const*, unsigned long, _CONSTRXSTRING*, char 
const*, _RXSTRING*)':
rexxutil.cpp:(.text+0x5c3b): warning: the use of `tempnam' is dangerous, 
better use `mkstemp'
... cut ...

>
Scanning dependencies of target hostemu
... cut ...
[ 88%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.o
..\..\cmdparse.cpp: In function ‘int yyparse()’:
..\..\cmdparse.cpp:1603:35: warning: deprecated conversion from string 
constant to ‘char*’ [-Wwrite-strings]
..\..\cmdparse.cpp:1746:35: warning: deprecated conversion from string 
constant to ‘char*’ [-Wwrite-strings]




//\\
apple-compile-warnings
==

wu114184:oorexx_build rony$ make
>
Scanning dependencies of target rexxapi
... cut ...
[  9%] Building CXX object 
CMakeFiles/rexxapi.dir/common/platform/unix/SysThread.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/common/platform/unix/SysThread.cpp:76:32:
 warning: unknown warning group
  '-Wreturn-local-addr', ignored [-Wunknown-warning-option]
#pragma GCC diagnostic ignored "-Wreturn-local-addr"
   ^

>
Scanning dependencies of target rexx
... cut ...

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysActivity.cpp:140:32:
 warning: unknown warning group
  '-Wreturn-local-addr', ignored [-Wunknown-warning-option]
#pragma GCC diagnostic ignored "-Wreturn-local-addr"
   ^
[ 66%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/platform/unix/SysFileSystem.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysFileSystem.cpp:174:12:
 warning: 'tmpnam' is deprecated:
  This function is provided for compatibility reasons only. Due to 
security concerns inherent in the design of tmpnam(3),
  it is highly recommended that you use mkstemp(3) instead. 
[-Wdeprecated-declarations]
return tmpnam(NULL);
   ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdio.h:186:1:
 note:
  'tmpnam' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only. 
 Due to security concerns inherent in the ...
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:180:48:
 note:
  expanded from macro '__deprecated_msg'
#define __deprecated_msg(_msg) __attribute__((deprecated(_msg)))
  ^
[ 70%] Building CXX object 
CMakeFiles/rexx.dir/common/platform/unix/SysThread.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/common/platform/unix/SysThread.cpp:76:32:
 warning: unknown warning group
  '-Wreturn-local-addr', ignored [-Wunknown-warning-option]
#pragma GCC diagnostic ignored "-Wreturn-local-addr"
   ^

>
Scanning dependencies of target hostemu
... cut ...
[ 75%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.o
..\..\cmdparse.cpp:1603:20: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("syntax error"));
   ^
..\..\cmdparse.cpp:1746:16: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("memory exhausted"));

[Oorexx-devel] revision 11569, MacOS, question ad shebang

[Rony G. Flatscher]

revision 11569, MacOS, all ooRexx test units pass

This time also warnings when running cmake:

cmake -DCMAKE_BUILD_TYPE=relWithDebInfo ~/dev/oorexx_allura/main/trunk

... cut ...

-- Looking for pwd.h
CMake Warning (dev) at 
/opt/local/share/cmake-3.12/Modules/CheckIncludeFile.cmake:70 (message):
  Policy CMP0075 is not set: Include file check macros honor
  CMAKE_REQUIRED_LIBRARIES.  Run "cmake --help-policy CMP0075" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  CMAKE_REQUIRED_LIBRARIES is set to:

pthread

  For compatibility with CMake 3.11 and below this check is ignoring it.
Call Stack (most recent call first):
  CMakeLists.txt:337 (check_include_file)
This warning is for project developers.  Use -Wno-dev to suppress it.

... cut ...

-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command 
to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   hostemu
   orxclassic
   orxclassic1
   orxexits
   orxfunction
   orxinvocation
   orxmethod
   orxncurses
   rexx
   rexxapi
   rexxutil
   rxmath
   rxregexp
   rxsock
   rxunixsys
   wpipe1
   wpipe2
   wpipe3

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/rony/work/oorexx_build
wu114184:oorexx_build rony$

Warnings running "make":

make:

Scanning dependencies of target hostemu
[ 74%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/platform/unix/hostemu.cpp.o
[ 75%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.o
..\..\cmdparse.cpp:1603:20: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("syntax error"));
   ^
..\..\cmdparse.cpp:1746:16: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("memory exhausted"));
   ^
2 warnings generated.


Scanning dependencies of target rexxutil
[ 89%] Building CXX object 
CMakeFiles/rexxutil.dir/extensions/rexxutil/platform/unix/rexxutil.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp:1852:14:
 warning: 'sem_init' is
  deprecated [-Wdeprecated-declarations]
rc = sem_init(semdata->handle, 0, 0);
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:55:42:
 note: 
  'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:37:
 note: 
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp:1913:5:
 warning: 'sem_init' is
  deprecated [-Wdeprecated-declarations]
sem_init(semdata->handle, 1, 0);
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:55:42:
 note: 
  'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:37:
 note: 
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp:1957:13:
 warning: 'sem_destroy' is
  deprecated [-Wdeprecated-declarations]
if (sem_destroy(semdata->handle)) {
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:53:26:
 note: 
  'sem_destroy' has been explicitly marked deprecated here
int sem_destroy(sem_t *) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:37:
 note: 
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))

[Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

[Rony G. Flatscher]

On 05.12.2018 15:08, Rick McGuire wrote:
> Seriously, it would be way better to confine your emails to a single topic so 
> that all of this
> stuff does not get propagated in thread replies.
Hmm, thought I keep all related information in one e-mail to ease getting an 
overview on the current
state on Apple, will split up such postings in the future.

... cut ...

On Wed, Dec 5, 2018 at 8:54 AM Rony G. Flatscher mailto:rony.flatsc...@wu.ac.at>> wrote:

> Ad shebang: on Mac after "make" and "make install" will read, e.g. in 
> rexxtry.rex:
>
> 
> #!$,/Users/rony/Applications/ooRexx5.0.0,/usr>/bin/rexx
>
>
> This looks like a syntax error in the setting of the variable 
> CMAKE_INSTALL_PREFIX. This should
> not be including the $IF part. 
>
> Running "./rexxtry.rex" from a current build directory therefore would 
> only use rexx from the
> directory of the user who created the MacOS version, in my case
> "/Users/rony/Applications/ooRexx5.0.0 ". 
>
>
> CMAKE_INSTALL_PREFIX is intended to be the place where the package is going 
> to be installed.
> Making it based on the user doing to the build is wrong, and should be fixed.
>
>
> Also using the ooRexx Rexx programs in a distribution (like in 
> BSF4ooRexx) would not allow
> them to be run in the Unix style from the command line or by 
> double-clicking them on the Linux
> Explorer/Finder would cause these Rexx programs to not be executed, but 
> rather generate an error.
>
> That is obviously not the intended result, but a syntax error. 
>  
>
> Question: is there a cmake-option that I can set to also have the shebang 
> "#!/etc/env rexx" on
> a MacOS production in order to avoid that pitfall for the users? Which 
> one would that be and
> would it be possible to supply it in the cmake step on the commandline in 
> order to not have to
> edit the trunk version of CMakeLists.txt? Trying to define that value on 
> the command line with
>
>
> This should not be in the command line, but rather conditional logic in the 
> CMake configuration
> (as I already explained to PO in a previous email and he declined to provide 
> a fix). If someone
> who works on a Mac develops a patch and submits it, it will be considered. 
> I'm getting tired of
> the Mac community asking the none-Mac users to make all of the changes.
The reason for me to have a) Windows, b) Linux and c) Apple is simply to have 
all systems available
to create and maintain the external ooRexx function library BSF4ooRexx for 
them. Everything else in
BSF4ooRexx is portable to wherever ooRexx and Java are available and can be 
developed and maintained
on a single system.

BSF4ooRexx regarding c/c++ is a single file, so I have had no need of using &  
learning autotools or
CMake or the like (and have been saving the needed time to learn these systems 
being constantly
short of time, not because of lack of interest). Of course, if I can help on 
those platforms to
improve ooRexx, I have been doing that.  Having said that, currently I have no 
knowledge about CMake
to be able to take on CMake related problems in an estimable, finite amount of 
time and am therefore
dependent on hints and advice, hence posting my observations and asking 
questions.

Given that getting ooRexx on all platforms, compiling and testing is a *very* 
time-consuming effort
and is meant to support the ooRexx project, I hope that these efforts get 
appreciated.
Unfortunately, currently I have null/zero time to go out and learn everything 
in detail that is
needed to configure and compile a (really great, but of course very) complex 
project like ooRexx
(even learning CMake at this point in time is time wise not possible for me). 
The main reason for
this is of course that I do have a quite demanding (and as a result often very 
time consuming) day
job. Still, I have been trying to allocate as much time as possible to help 
debug/improve also the
ooRexx project. [The scarce time resources during the day are also the reason 
why I would have to
work into the nights or on weekends, if possible at all, to help out in good 
faith. BTW, that is
also the reason why many times I am also forced to work on BSF4ooRexx in the 
evening, on the
weekends or during University vacations where the students are away.]

---

Ad the shebang line:

My understanding about the shebang on Unix (i.e. Linux or Mac) has been that in 
the course of its
evolution the preference to hard coded paths to executables has been offset by 
making it more
flexible using /usr/bin/env to locate the program to execute the script with. 
Hence the standard
shebang line should probably read:

#!/usr/bin/env rexx

This way it is very easy and simple to have different versions of ooRexx 
installed in diff

Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

[Rony G. Flatscher]

On 05.12.2018 21:53, Rick McGuire wrote:
... cut ...
> This goes beyond just the shebang line though, the bigger question is what 
> should the
> CMAKE_INSTALL_PREFIX be. The line that was added for the Darwin support is 
> clearly wrong. This
> needs to be the expected install location to be used by an installer and 
> should not be tied to the
> userid of the person performing the build. 
>
> Once that is correct, then the shebang line will correctly point to that 
> executable. If you still
> decide that you want it to be "#!/usr/bin/env rexx" for the Mac, then submit 
> a patch that corrects
> that, but don't do what PO did and submit a patch that made the decision for 
> every other system.
Patch with explanations at: .

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

[Oorexx-devel] New beta version of BSF4ooRexx available (version 20181130)

[Rony G. Flatscher]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from 
Sourceforge, namely from:
.

BSF4ooRexx is an ooRexx external function package that allows Rexx programs to 
exploit all Java
classes and interact with Java as if it was ooRexx! Requiring the supplied 
ooRexx package "BSF.CLS"
camouflages the strictly typed, case-sensitive programming language Java as the 
dynamically typed,
case-insensitive language Rexx, making it considerably easy to interface with 
Java.

---

If after installing BSF4ooRexx you choose the menu option "BSF4ooRexx -> 
Samples" a folder/finder
window will open and display the Rexx samples. Locate the file "index.html" and 
click on it: this
will briefly describe each Rexx sample, such that you are able to quickly get 
an overview.

---

Also I would like to point out to you the latest beta versions of ooRexx 5.0 
which introduces many
valuable and helpful new features: 

. Regularly check for new builds there. [Temporarily there are installations 
packages of today's
ooRexx trunk, revision 11582, in my dropbox at:
.]

The quality of the current beta versions of ooRexx 5.0 is of type "release", 
includes many
interesting new features and contains many bug fixes over ooRexx 4.2.

Also please note: the BSF4ooRexx package for MacOSX already includes a fresh 
build of ooRexx 5.0
beta, revision 11582.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list

().

Cheers,

---rony




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

[Oorexx-devel] Advice for ooRexx test suite: when subclassing ooTestCase and defining a proper constructor then do not forget ...

[Rony G. Flatscher]

The ooRexx test framework allows one to create a test group with test cases by 
simply subclassing
the class ooTestCase.

If the subclass has a need for a constructor (defines the method 'INIT'), then 
it is mandatory to
invoke the constructor in its superclass otherwise a runtime error will occur.

E.g. defining a Rexx test group named "defaultMethods.testGroup" like this:

... cut ...
::class "testDefaultMethods" subclass ooTestCase public

::method init
  expose pkgName
  say self
... cut ...

will cause an error like:


F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\testUnits\bsf4rexx\java8\defaultMethods>rexx
 defaultMethods.testGroup
  1722 *-* return fName
  1733 *-* return "testCase:" pp(self~getName) "(a" || addN(className) 
className || "@" || -  self~definedInFile")"
68 *-* say self
   *-* Compiled method "NEW" with scope "Object".
  1808 *-*   self~addTest(testCaseClass~new(name))
   516 *-* forward class (super) continue
   *-* Compiled method "NEW" with scope "Object".
  1503 *-*   suite = .ooTestSuite~new(tClass)
54 *-* testResult = group~suite~execute~~print
Error 98 running F:\work\svn\oorexx\test\trunk\framework\OOREXXUNIT.CLS 
line 1722:  Execution error.
Error 98.986:  Reference to unassigned variable "FNAME".

Unfortunateyl, the error message does not really point to the cause, that the 
superclass' 'init'
method was not invoked.
[Ultimately this error goes back to the fact that the ooRexx test framework 
added the "::OPTIONS
NOVALUE ERROR" directive sometimes after this directive was introduced to 
ooRexx (which in principle
is good).]

So, to save you (potentially a *lot* of) time: whenever you have a need for a 
constructor (the
method named 'init') in your test group, the *first thing* you should do is 
invoke the superclass
constructor to avoid such runtime errors, e.g. like this:

... cut ...
::class "testDefaultMethods" subclass ooTestCase public

::method init
  expose pkgName

  *forward class (super) continue /* let the superclass first initialize 
everything it needs */*
  say "self:" self
... cut ...

which would output in this case:


F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\testUnits\bsf4rexx\java8\defaultMethods>rexx
 defaultMethods.testGroup
self: testCase: [TEST_01] (a 
testDefaultMethods@F:\work\svn\testUnits\bsf4rexx\java8\defaultMethods\defaultMethods.testGroup)

---rony

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

[Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

[Rony G. Flatscher]

While compiling for the 32-bit Windows version, svn rev. 11627, the compilation 
stops with the
following error information:

... cut ...
[ 72%] Linking CXX shared library bin\orexxole.dll
   Creating library bin\orexxole.lib and object bin\orexxole.exp
[ 72%] Built target orexxole
Scanning dependencies of target rexx_img
[ 72%] Generating bin/CoreClasses.orx
[ 72%] Generating bin/StreamClasses.orx
[ 72%] Generating bin/PlatformObjects.orx
[ 73%] Generating bin/orexxole.cls
[ 74%] Generating bin/rexx.img
56 *-* ::METHOD init EXTERNAL "LIBRARY OREXXOLE OLEObject_Init"
 2 *-* call 'orexxole.cls'
   118 *-* call 'PlatformObjects.orx' rexxPackage   -- now load 
platform-specific builtin classes
Error 98 running G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\orexxole.cls 
line 56:  Execution error.
Error 98.903:  Unable to load library "OREXXOLE".
Logic error: Error building kernel image.  Image not saved.
NMAKE : fatal error U1077: 
'G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\rexximage.exe' : return code '0xff'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

G:\oorexx.tmp\oorexxBuild\debug32.trunk>

Compiling for the 64-bit Windows version, svn rev. 11627, works.

---rony


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

Re: [Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

[Rony G. Flatscher]

On 17.12.2018 14:12, Rick McGuire wrote:
> What compiler version are you using?

G:\oorexx.tmp\oorexxBuild\debug32.trunk>cmake -G "NMake Makefiles" 
F:\work\svn\oorexx\main\trunk
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works

... cut ...
-- Building for a 32-bit architecture
... cut ...

---rony


>
>
>
> On Mon, Dec 17, 2018 at 8:10 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> While compiling for the 32-bit Windows version, svn rev. 11627, the 
> compilation stops with the
> following error information:
>
> ... cut ...
> [ 72%] Linking CXX shared library bin\orexxole.dll
>Creating library bin\orexxole.lib and object bin\orexxole.exp
> [ 72%] Built target orexxole
> Scanning dependencies of target rexx_img
> [ 72%] Generating bin/CoreClasses.orx
> [ 72%] Generating bin/StreamClasses.orx
> [ 72%] Generating bin/PlatformObjects.orx
> [ 73%] Generating bin/orexxole.cls
> [ 74%] Generating bin/rexx.img
> 56 *-* ::METHOD init EXTERNAL "LIBRARY OREXXOLE OLEObject_Init"
>  2 *-* call 'orexxole.cls'
>118 *-* call 'PlatformObjects.orx' rexxPackage   -- now load 
> platform-specific builtin classes
> Error 98 running 
> G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\orexxole.cls line 56:  Execution 
> error.
> Error 98.903:  Unable to load library "OREXXOLE".
> Logic error: Error building kernel image.  Image not saved.
> NMAKE : fatal error U1077: 
> 'G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\rexximage.exe' : return code 
> '0xff'
> Stop.
> NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
>
> G:\oorexx.tmp\oorexxBuild\debug32.trunk>
>
> Compiling for the 64-bit Windows version, svn rev. 11627, works.
>
> ---rony
>

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

[Oorexx-devel] Mac warnings, svn rev. 11627 (CMake, compiler)

[Rony G. Flatscher]

Here the Mac warnings when compiling svn rev. 11627 (there are some warnings 
about wrong format and
tempnam usage in rexxutil besides the semaphore warnings):

wu114215:oorexx_build rony$ export MACOSX_DEPLOYMENT_TARGET=10.9
wu114215:oorexx_build rony$ cmake -DCMAKE_BUILD_TYPE=relWithDebInfo 
~/dev/oorexx_allura/main/trunk

... cut ...
-- Looking for pwd.h
*CMake Warning (dev) at 
/opt/local/share/cmake-3.12/Modules/CheckIncludeFile.cmake:70 (message):*
  Policy CMP0075 is not set: Include file check macros honor
  CMAKE_REQUIRED_LIBRARIES.  Run "cmake --help-policy CMP0075" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  CMAKE_REQUIRED_LIBRARIES is set to:

pthread

  For compatibility with CMake 3.11 and below this check is ignoring it.
Call Stack (most recent call first):
  CMakeLists.txt:361 (check_include_file)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Looking for pwd.h - found
... cut ...

-- Configuring done
*CMake Warning (dev):*
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command 
to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   orxclassic
   orxclassic1
   orxexits
   orxfunction
   orxinvocation
   orxmethod
   wpipe1
   wpipe2
   wpipe3

This warning is for project developers.  Use -Wno-dev to suppress it.

... cut ...

[ 27%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/execution/RexxActivation.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/execution/RexxActivation.cpp:2118:9:
 warning: expression result unused
  [-Wunused-value]
(MethodClass *)executable;
^  ~~
1 warning generated.

... cut ...

Scanning dependencies of target hostemu
[ 74%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/platform/unix/hostemu.cpp.o

[ 75%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.o
..\..\cmdparse.cpp:1603:20: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("syntax error"));
   ^
..\..\cmdparse.cpp:1746:16: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("memory exhausted"));
   ^
2 warnings generated.
... cut ...

Scanning dependencies of target rexximage
[ 89%] Building CXX object 
CMakeFiles/rexximage.dir/utilities/rexximage/rexximage.cpp.o
[ 89%] Linking CXX executable bin/rexximage
[ 89%] Built target rexximage
Scanning dependencies of target rexxutil
[ 89%] Building CXX object 
CMakeFiles/rexxutil.dir/extensions/rexxutil/platform/unix/rexxutil.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp:1852:14:
 warning: 'sem_init' is
  deprecated [-Wdeprecated-declarations]
rc = sem_init(semdata->handle, 0, 0);
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:55:42:
 note:
  'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:37:
 note:
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp:1913:5:
 warning: 'sem_init' is
  deprecated [-Wdeprecated-declarations]
sem_init(semdata->handle, 1, 0);
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:55:42:
 note:
  'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:37:
 note:
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/extensions/rexxutil/platform/unix/rexxutil.cpp:1957:13:
 warning: 'sem_destroy' is
  deprecated [-Wdeprecated-declarations]
if (sem_destroy(semdata->handle)) {
^

/Applications/

Re: [Oorexx-devel] Discussion/questions on #730 Allow ::CONSTANT specified as expression

[Rony G. Flatscher]

2) seems the most flexible/powerful one.

Constants can be regarded as special attributes that can be accessed in the 
class object and in each
of its instances. Currently their value is a symbol.

As you are envisioning some sort of a method execution to determine the 
constant value, how about
allowing a method body (like an attribute setter method without an argument) to 
define the constant
value?

Something like:

::constant aconstant foo -- like now

::constant fullsize-- new: no value supplied, just the name
   expose fullsize
   fullsize=2**12

::constant halfsize-- new: no value supplied, just the name
   expose halfsize fullsize 
   halfsize=fullsize/2

::constant x_halfsize_x-- new: no value supplied, just the name
   expose x_halfsize_x 
   x_halfsize_x= self~x_fullsize_x/2   -- employ "self"

::constant x_fullsize_x 4096  -- like now

::constant abc-- new: no method body use name as value, 
hence will use "abc" as its constant value

---rony



On 17.12.2018 23:41, Rick McGuire wrote:
> I admit this is a feature I've wanted for some time but was not sure how to 
> actually do it. Since
> Erich opened the feature request, I thought I should give it a closer look. 
> I've gotten far enough
> into this that I believe it can be done, with some restrictions. There are a 
> few items where
> decisions need to be made on which direction to proceed. 
>
> So, basically this will work by building a special method that runs on the 
> class object during the
> package install process. Each class directive will have its own special 
> method and the
> instructions executed will be any ::constant directive that has a 
> non-constant expression value.
> There should be no restrictions on the expressions and the variables SELF and 
> SUPER will have the
> expected values for a method run on a class object. The expressions when run 
> will be traceable if
> ::options trace is used, even interactive trace. I've got most of the 
> mechanisms on how to do all
> of this worked out and it looks pretty clean. 
>
> My first thought was to apply the current rules for parsing ::CONSTANT and 
> anything that fell
> outside of the current rules would be a constant. This works, but there is a 
> gotcha. The current
> rules allow constants to be defined using 
>
> ::constant aconstant foo
>
> where foo is a symbol treated as a constant. Going this route means 
>
> ::constant aconstant self 
> ::constant anotherConstant (self)
>
> would produce different results. The parsing code could consider non-constant 
> symbols to be
> expressions, which would cause these to have the same values, and most 
> ::constant declarations
> would be unaffected because the variable would be uninitialized, and thus 
> have the same
> values...with the exception of the variables SELF and SUPER, which will have 
> a value. There's also
> the issue of ::options novalue error, which will suddenly start getting 
> tripped by instructions
> that were fine before. 
>
> Right now, I'm leaning toward an explicit syntax to indicate the value needs 
> to be computed at
> class creation time. We already have a precedent of using parens to indicate 
> a general expression,
> so I believe we should use that. No parens, old rule, in parens, an 
> expression to be evaluated. 
>
> Part of the processing I envision is the constant methods are created 
> initially, but are
> "incomplete" and if they are invoked before they are "completed", they will 
> raise a new subcode of
> error 97 to indicate the constant had not been initialized. Initialization 
> occurs in declaration
> order, so constants can refer to other constants of the same class, as long 
> as they were declared
> prior to the usage. That is
>
> ::constant fullsize (2**12)
> ::constant halfsize (self~fullsize/2)
>
> Would work, but 
>
> ::constant halfsize (self~fullsize/2)
> ::constant fullsize (2**12)
>
> would give an error evaluating self~fullsize. Directives with true constant 
> values will be
> available always, so 
>
> ::constant halfsize (self~fullsize/2)
> ::constant fullsize 4096
>
> would work because fullsize method was complete at parse time. 
>
> The next issue I'm wrestling with is when to perform the calculation. The 
> current package
> installation code does things in two passes. During parsing, the classes are 
> analyzed for
> inheritance dependencies and the classes are created so that classes that are 
> required by other
> classes are created first, so these are not done in top-down declaration 
> order.  
>
> Once all of the class objects have been created, a second pass is done to 
> call the activate()
> methods on the new class objects. 
>
> The dynamic constants (looking for a better name for these...) introduce a 
> third stage to this
> processing. I see three approaches that can be used: 
>
> 1) Completing the constants is part of the class creation, so it is done for 
> 

[Oorexx-devel] [RexxLA] New beta version of BSF4ooRexx available (version 20181221)

[Rony G. Flatscher]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from 
Sourceforge, namely from:
.

BSF4ooRexx is an ooRexx external function package that allows Rexx programs to 
exploit all Java
classes and interact with Java as if it was ooRexx! Requiring the supplied 
ooRexx package "BSF.CLS"
camouflages the strictly typed, case-sensitive programming language Java as the 
dynamically typed,
case-insensitive language Rexx, making it considerably easy to interface with 
Java.

---

If after installing BSF4ooRexx you choose the menu option "BSF4ooRexx -> 
Samples" a folder/finder
window will open and display the Rexx samples. Locate the file "index.html" and 
click on it: this
will briefly describe each Rexx sample, such that you are able to quickly get 
an overview.

---

Also I would like to point out to you the latest beta versions of ooRexx 5.0 
which introduces many
valuable and helpful new features: 

. Regularly check for new builds there. [Temporarily there are installations 
packages of today's
ooRexx trunk, revision 11636, in my dropbox at:
.]

The quality of the current beta versions of ooRexx 5.0 is of type "release", 
includes many
interesting new features and contains many bug fixes over ooRexx 4.2.

Also please note: the BSF4ooRexx package for MacOSX already includes a fresh 
build of ooRexx 5.0
beta, revision 11636.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
 
().

Cheers,

---rony



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

[Oorexx-devel] Ad XDG-variables and sudo ...

[Rony G. Flatscher]

Musing with my Ubuntu installation did the following experiments as user "rony":

*/--- commands as normal user "rony" (no SUDO_* environment 
variables set):/*

rony@rony-linux:~/work/oorexx/trunk$ *env | grep XDG*

/XDG_VTNR=7XDG_SESSION_ID=c4XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/ronyXDG_SESSION_TYPE=x11XDG_DATA_DIRS=/usr/share/mate:/usr/share/mate:/usr/local/share:/usr/share:/var/lib/snapd/desktop:/var/lib/snapd/desktopXDG_SESSION_DESKTOP=mateXDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0XDG_CURRENT_DESKTOP=MATEXDG_SEAT=seat0///*/XDG_RUNTIME_DIR=/run/user/1000/*///XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1XDG_CONFIG_DIRS=/etc/xdg/xdg-mate:/etc/xdg/

rony@rony-linux:~/work/oorexx/trunk$ *whoami*
/rony/

rony@rony-linux:~/work/oorexx/trunk$ *ls -al $XDG_RUNTIME_DIR*
/total 0drwx-- 9 rony rony 260 Dec 19 16:39 .drwxr-xr-x 3 root 
root 60 Dec 19 16:39
..srw-rw-rw- 1 rony rony 0 Dec 19 16:35 busdrwx-- 3 rony rony 
60 Dec 19 16:35
dbus-1drwx-- 2 rony rony 60 Dec 23 13:52 dconfdrwx-- 3 rony 
rony 160 Dec 23
13:52 gnupgdr-x-- 2 rony rony 0 Dec 19 16:35 gvfsdrwx-- 2 
rony rony 100 Dec 19
16:39 keyring///*/-rw-rw-rw- 1 rony rony 0 Dec 19 16:36 
.ooRexx-5.0.0-64.lock/**//**/srwxrwxrwx
1 rony rony 0 Dec 19 16:36 .ooRexx-5.0.0-64.service/*///drwx-- 2 rony 
rony 80 Dec 19 16:35
pulsedrwxr-xr-x 2 rony rony 80 Dec 19 16:35 systemd-rw--- 1 
rony rony 0 Dec 19 16:35
update-notifier.pidrony@rony-linux:~/work/oorexx/trunk$ /

rony@rony-linux:~/work/oorexx/trunk$ *env | grep SUDO*


*/--- same commands as sudo (the XDG* environment variables are 
not set, there is no
home directory "/usr/root" rather "/root"):/*

rony@rony-linux:~/work/oorexx/trunk$ *sudo env | grep XDG*

rony@rony-linux:~/work/oorexx/trunk$ *sudo whoami*
/root/

rony@rony-linux:~/work/oorexx/trunk$ *sudo ls -al /root*
/total 112drwx-- 24 root root 4096 Dec 19 16:37 .drwxr-xr-x 29 
root root 4096 Dec 11
16:40 ..drwx-- 2 root root 4096 Mar 7 2018 .aptitude-rw-r--r-- 
1 root root 3106 Feb
25 2012 .bashrcdrwx-- 10 root root 4096 Oct 24 2015 
.cachedrwx-- 9 root root
4096 Jun 8 2015 .configdrwx-- 3 root root 4096 Jun 10 2013 
.dbusdrwx-- 3 root
root 4096 Oct 25 2014 .gconfdrwx-- 2 root root 4096 Sep 30 2011 
.gconfddrwx-- 4
root root 4096 Feb 25 2012 .gnome2drwx-- 2 root root 4096 Aug 3 2011
.gnome2_privatedrwx-- 3 root root 4096 Sep 28 2016 
.gnupgdrwxr-xr-x 2 root root 4096
Aug 29 2011 .gstreamer-0.10drwx-- 2 root root 4096 Aug 2 2011 
.gvfsdrwxr-xr-x 3 root
root 4096 Oct 15 2013 .javadrwx-- 2 root root 4096 Aug 29 2011 
.kdedrwxr-xr-x 3 root
root 4096 Jul 27 2011 .libreofficedrwx-- 3 root root 4096 Aug 2 2011
.localdrwx-- 3 root root 4096 Aug 2 2011 
.mission-control///*/-rw-rw-rw- 1 root root 0
Dec 19 16:09 .ooRexx-5.0.0-64.lock/**//**/srwxrwxrwx 1 root root 0 Dec 19 
16:37
.ooRexx-5.0.0-64.service/*///drwxr-xr-x 2 root root 4096 Feb 4 2017
.oracle_jre_usage-rw-r--r-- 1 root root 148 Aug 17 2015 
.profiledrwx-- 2 root root
4096 Oct 14 2014 .pulse-rw--- 1 root root 256 Jun 7 2011 
.pulse-cookiedrwxr-xr-x 2
root root 4096 Jan 12 2017 .rpmdbdrwx-- 2 root root 4096 Jun 7 2011 
.sshdrwx-- 4
root root 4096 Mar 18 2018 .synapticdrwxrwxr-x 2 root root 4096 Feb 25 
2012
Templates-rw--- 1 root root 2983 Feb 6 2018 .viminfo/
rony@rony-linux:~/work/oorexx/trunk$ 

rony@rony-linux:~/work/oorexx/trunk$ *sudo env | grep root*
/MAIL=/var/mail/root LOGNAME=root USER=root USERNAME=root/
rony@rony-linux:~/work/oorexx/trunk$ 


rony@rony-linux:~/work/oorexx/trunk$ *sudo env | grep SUDO*

/SUDO_COMMAND=/usr/bin/envSUDO_USER=ronySUDO_UID=1000SUDO_GID=1000/
rony@rony-linux:~/work/oorexx/trunk$

Obviously last Wednesday ooRexx ran with root privileges and created the lock 
and service files
under "/root". Not sure whether this was caused by doing an "sudo dpkg -i 
ooRexx-deb-packages".

Maybe a strategy could be: if determining that ooRexx executes as "root" (e.g. 
comparing $LOGNAME to
"root"), then create the two special files in the root's homedirectory "/root". 
Otherwise, if
running without the XDG* environment variables set, then maybe in the user's 
home directory $HOME
(like on MacOSX)?

---rony




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

Re: [Oorexx-devel] Ad XDG-variables and sudo ...

[Rony G. Flatscher]

On 23.12.2018 14:23, Rony G. Flatscher wrote:
> Musing with my Ubuntu installation did the following experiments as user 
> "rony":
... cut ...
>
> Maybe a strategy could be: if determining that ooRexx executes as "root" 
> (e.g. comparing $LOGNAME
> to "root"), then create the two special files in the root's homedirectory 
> "/root". Otherwise, if
> running without the XDG* environment variables set, then maybe in the user's 
> home directory $HOME
> (like on MacOSX)?
>
Just as an appendix the ooRexx Unix installation code (for setting up 
BSF4ooRexx which needs to run
with root privileges when installing it globally) which determines the real 
user name (for the
installation logfile):

... cut ...
setupBSF.rex-   -- get and save logName and sudoUser-Name
setupBSF.rex-   cmd.eLogName  = value('LOGNAME',,'ENVIRONMENT')  -- get 
current logname, could be 'root' if sudo'ing
setupBSF.rex:   cmd.eSudoUser = value('SUDO_USER',  ,'ENVIRONMENT')  -- 
maybe sudo'ing, then who is the sudo user
setupBSF.rex-
setupBSF.rex-   if cmd.eLogName="root", cmd.eSudoUser<>"" then
setupBSF.rex-  cmd.eRealUserName=cmd.eSudoUser
setupBSF.rex-   else
setupBSF.rex-  cmd.eRealUserName=cmd.eLogName
... cut ...

---rony

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

Re: [Oorexx-devel] Building the docs

[Rony G Flatscher]

Use -Xmx fir nax hesp size -Xms initial Java heap size

—-rony

Rony G. Flatscher (mobil/e)

> Am 25.12.2018 um 22:35 schrieb Rick McGuire :
> 
> I went back and tried rebuilding just the rexxref, and it looks like this is 
> a heap space problem with java. I don't know if there is a way to increase 
> this. 
> 
> Rick
> 
>> On Tue, Dec 25, 2018 at 3:36 PM Rick McGuire  wrote:
>> I fired up a build on unbuntu before I left to walk my dog. It looks like 
>> everything but the rexxref built cleanly, and I think the failure there was 
>> related to the ulimit problem. When I try to issue the ulimit command you 
>> show, I get the following error:
>> 
>> bash: ulimit: open files: cannot modify limit: Operation not permitted.
>> 
>> This is using the latest publican install with Fop. 
>> 
>> Rick
>> 
>> On Tue, Dec 25, 2018 at 1:14 PM Erich Steinböck  
>> wrote:
>>>> That could mean, Publican is dead
>>> According to 
>>> https://www.redhat.com/archives/publican-list/2017-January/msg1.html 
>>> the Publican git was moved to
>>> https://sourceware.org/gerrit/#/admin/projects/publican
>>> 
>>> But for me, this new site is currently unavailable.
>>> 
>>> On Tue, Dec 25, 2018 at 6:51 PM Erich Steinböck 
>>>  wrote:
>>>>> OK, snag #1) fedorahosted.org has gone away
>>>> Well, as far as I understand this is where the Publican git was hosted.  
>>>> That could mean, Publican is dead.
>>>> 
>>>>> Do you still have the installer file? Perhaps we should add that to the 
>>>>> buildutils directory on sourceforge. 
>>>> Yes, I still have it.
>>>> I've packed it together with a bunch of my publican-related stuff into a 
>>>> ZIP and uploaded to
>>>> https://sourceforge.net/projects/oorexx/files/windows-build-tools/PublicanWindows.zip
>>>> (I just now see that there's also a oorexx-buildutils/ folder .. I haven't 
>>>> yet checked if we are keeping redundant files)
>>>> 
>>>> The ZIP contains the Publican-Installer-3.0.exe and various helper scripts 
>>>> that I wrote
>>>> e. g. a filter to get rid of thousands of fop warnings during build, or a 
>>>> fop front-end script, which runs fop-preprocess to remove unwanted 
>>>> whitespace.
>>>> The PublicanBuildHere script will run a build with above mentioned 
>>>> extensions
>>>> 
>>> ___
>>> 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] Building the docs

[Rony G Flatscher]

Use 

  java -X

for all switches

—-rony

Rony G. Flatscher (mobil/e)

> Am 25.12.2018 um 22:40 schrieb Rony G Flatscher :
> 
> Use -Xmx fir nax hesp size -Xms initial Java heap size
> 
> —-rony
> 
> Rony G. Flatscher (mobil/e)
> 
>> Am 25.12.2018 um 22:35 schrieb Rick McGuire :
>> 
>> I went back and tried rebuilding just the rexxref, and it looks like this is 
>> a heap space problem with java. I don't know if there is a way to increase 
>> this. 
>> 
>> Rick
>> 
>>> On Tue, Dec 25, 2018 at 3:36 PM Rick McGuire  wrote:
>>> I fired up a build on unbuntu before I left to walk my dog. It looks like 
>>> everything but the rexxref built cleanly, and I think the failure there was 
>>> related to the ulimit problem. When I try to issue the ulimit command you 
>>> show, I get the following error:
>>> 
>>> bash: ulimit: open files: cannot modify limit: Operation not permitted.
>>> 
>>> This is using the latest publican install with Fop. 
>>> 
>>> Rick
>>> 
>>> On Tue, Dec 25, 2018 at 1:14 PM Erich Steinböck 
>>>  wrote:
>>>>> That could mean, Publican is dead
>>>> According to 
>>>> https://www.redhat.com/archives/publican-list/2017-January/msg1.html 
>>>> the Publican git was moved to
>>>> https://sourceware.org/gerrit/#/admin/projects/publican
>>>> 
>>>> But for me, this new site is currently unavailable.
>>>> 
>>>> On Tue, Dec 25, 2018 at 6:51 PM Erich Steinböck 
>>>>  wrote:
>>>>>> OK, snag #1) fedorahosted.org has gone away
>>>>> Well, as far as I understand this is where the Publican git was hosted.  
>>>>> That could mean, Publican is dead.
>>>>> 
>>>>>> Do you still have the installer file? Perhaps we should add that to the 
>>>>>> buildutils directory on sourceforge. 
>>>>> Yes, I still have it.
>>>>> I've packed it together with a bunch of my publican-related stuff into a 
>>>>> ZIP and uploaded to
>>>>> https://sourceforge.net/projects/oorexx/files/windows-build-tools/PublicanWindows.zip
>>>>> (I just now see that there's also a oorexx-buildutils/ folder .. I 
>>>>> haven't yet checked if we are keeping redundant files)
>>>>> 
>>>>> The ZIP contains the Publican-Installer-3.0.exe and various helper 
>>>>> scripts that I wrote
>>>>> e. g. a filter to get rid of thousands of fop warnings during build, or a 
>>>>> fop front-end script, which runs fop-preprocess to remove unwanted 
>>>>> whitespace.
>>>>> The PublicanBuildHere script will run a build with above mentioned 
>>>>> extensions
>>>>> 
>>>> ___
>>>> 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] A few questions ad CMake and libraries on Unix

[Rony G. Flatscher]

Currently on Unix there are "lib*.5.0.0.dylib" (Apple) or "lib*.so.5.0.0" 
(Linux) shared libraries
created where "*" stands for "hostemu", "orxncurses", "rexx", "rexxapi", 
"rexxutil", "rxmath",
"rxregexp", "rxsock", "rxunixsys".

In addition there are symbolic links created in the form of "lib*.dylib" or 
"lib*.so" pointing to
the "5.0.0" shared libraries. An example with "hostemu" shared libraries would 
be:

Apple: libhostemu.dylib -> libhostemu.5.0.0.dylib
Linux: libhostemu.so-> libhostemu.so.5.0.0

If running executables that got linked to earlier versions of ooRexx (e.g. 
ooRexx 2, ooRexx 3 or
ooRexx 4) then such executables would not be able to run, unless there are also 
symbolic links
created that carry the version information "2", "3" or "4", like:

Apple: libhostemu2.dylib -> libhostemu.so
   libhostemu3.dylib -> libhostemu.so
   libhostemu4.dylib -> libhostemu.so

Linux: libhostemu2.so -> libhostemu.so
   libhostemu3.so -> libhostemu.so
   libhostemu4.so -> libhostemu.so

 points at this situation.

---

Now, as everyone is quite busy with different tasks I tried to start to figure 
out how to change the
CMakeList file such that it would create these symbolic links and install them. 
Not having knowledge
about CMake this has turned out to be a very time consuming task, where 
information is missing that
would allow me to conclude the experiment.

After many hours, I have become able to create the symbolic links in the
${CMAKE_LIBRARY_OUTPUT_DIRECTORY}, but have not been able to get these newly 
added files to copy to
the lib-directory at install time ("make install" or while creating the rpm or 
deb packages where
the shared libraries need to get copied to the packager's temporary 
subdirectories).

So any help or advice would be appreciated that would allow me to proceed, such 
that in the end I
could supply a patch for the project that creates these symbolic links!

---

Here a few questions:

  * why are the shared libraries created in the BINARY_DIR as in line # as
  o set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
  o on Apple there is an individual change to that value, such that a "lib" 
directory gets used
to place the shared libraries to

  * how would one cause all shared files in ${CMAKE_LIBRARY_OUTPUT_DIRECTORY} 
to be copied at
installation time ("make install") to the installation's target library 
directory?
  o Tried it to no avail with (at build time INSTALL_LIB_DIR points to the 
standard installation
location like "/usr/lib"):
    install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E chdir 
${INSTALL_LIB_DIR}
create_symlink ${targetName} ${linkName})")
hence looking for alternatives.
  o is there a means to inform CMake which library files need to be taken 
from the
CMAKE_LIBRARY_OUTPUT_DIRECTORY and be put into the appropriate library 
directory while
installing (and uninstalling)?

---rony


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

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

[Rony G. Flatscher]

OK, too long of a day, sent the wrong version! :(

On 01.01.2019 21:39, Rony G. Flatscher wrote:
>
> Currently on Unix there are "lib*.5.0.0.dylib" (Apple) or "lib*.so.5.0.0" 
> (Linux) shared libraries
> created where "*" stands for "hostemu", "orxncurses", "rexx", "rexxapi", 
> "rexxutil", "rxmath",
> "rxregexp", "rxsock", "rxunixsys".
>
> In addition there are symbolic links created in the form of "lib*.dylib" or 
> "lib*.so" pointing to
> the "5.0.0" shared libraries. An example with "hostemu" shared libraries 
> would be:
>
> Apple: libhostemu.dylib -> libhostemu.5.0.0.dylib
> Linux: libhostemu.so-> libhostemu.so.5.0.0
>
> If running executables that got linked to earlier versions of ooRexx (e.g. 
> ooRexx 2, ooRexx 3 or
> ooRexx 4) then such executables would not be able to run, unless there are 
> also symbolic links
> created that carry the version information "2", "3" or "4", like:
>
> Apple: libhostemu2.dylib -> libhostemu.so
>libhostemu3.dylib -> libhostemu.so
>libhostemu4.dylib -> libhostemu.so
>
The above link to "libhostemu.dylib", of course.

>
> Linux: libhostemu2.so -> libhostemu.so
>libhostemu3.so -> libhostemu.so
>libhostemu4.so -> libhostemu.so
>
> <https://sourceforge.net/p/oorexx/bugs/1421/> points at this situation.
>
> ---
>
> Now, as everyone is quite busy with different tasks I tried to start to 
> figure out how to change
> the CMakeList file such that it would create these symbolic links and install 
> them. Not having
> knowledge about CMake this has turned out to be a very time consuming task, 
> where information is
> missing that would allow me to conclude the experiment.
>
> After many hours, I have become able to create the symbolic links in the
> ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}, but have not been able to get these newly 
> added files to copy
> to the lib-directory at install time ("make install" or while creating the 
> rpm or deb packages
> where the shared libraries need to get copied to the packager's temporary 
> subdirectories).
>
> So any help or advice would be appreciated that would allow me to proceed, 
> such that in the end I
> could supply a patch for the project that creates these symbolic links!
>
> ---
>
> Here a few questions:
>
>   * why are the shared libraries created in the BINARY_DIR as in line # as
>   o set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
>   o on Apple there is an individual change to that value, such that a 
> "lib" directory gets
> used to place the shared libraries to
>
On Apple and Linux the "INSTALL_LIB_DIR" gets changed, not the 
"CMAKE_LIBRARY_OUTPUT_DIRECTORY".


>   * how would one cause all shared files in ${CMAKE_LIBRARY_OUTPUT_DIRECTORY} 
> to be copied at
> installation time ("make install") to the installation's target library 
> directory?
>   o Tried it to no avail with (at build time INSTALL_LIB_DIR points to 
> the standard
> installation location like "/usr/lib"):
>     install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E chdir 
> ${INSTALL_LIB_DIR}
> create_symlink ${targetName} ${linkName})")
> hence looking for alternatives.
>   o is there a means to inform CMake which library files need to be taken 
> from the
> CMAKE_LIBRARY_OUTPUT_DIRECTORY and be put into the appropriate 
> library directory while
> installing (and uninstalling)?
>
---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

[Rony G. Flatscher]

Dear P.O.,

On 01.01.2019 21:44, P.O. Jonsson wrote:
> I have just reinstalled a Mac with a completely clean Mojave Setup (to avoid 
> old file ownerships
> etc to linger on etc) and am attacking exactly this question. If you can bear 
> with me a couple of
> days I will report what I have found out. With the latest changes & the 
> daemon-free installation
> things have gotten much less complex. But I need some time to be completely 
> sure on what I have in
> mind, ok?

Well, if I can get some hints how to copy the created symbolic link files to 
the installation
lib-directory, then maybe I can supply a patch to the ooRexx project that may 
help you as well.

Here is the macro that creates the symbolic links:

   # define macro to create symlinks at installation time to allow programs 
compiled against older versions of Rexx and ooRexx to run
   macro(rgf_create_symlink target)

set(baseName   "${CMAKE_SHARED_LIBRARY_PREFIX}${target}")
set(targetName "${baseName}${CMAKE_SHARED_LIBRARY_SUFFIX}")

message(STATUS "---> macro rgf_create_symlink: 
$CMAKE_LIBRARY_OUTPUT_DIRECTORY=[${CMAKE_LIBRARY_OUTPUT_DIRECTORY}], 
$INSTALL_LIB_DIR=[${INSTALL_LIB_DIR}]")
message(STATUS "---> macro rgf_create_symlink: target=[${target}]; 
targetName=[${targetName}] in [${CMAKE_LIBRARY_OUTPUT_DIRECTORY}]")

# TODO: define range limits symbolically
foreach(loop_var RANGE 2 4)
  set(linkName "${baseName}.${loop_var}${CMAKE_SHARED_LIBRARY_SUFFIX}")

  add_custom_command(TARGET ${target} POST_BUILD
# does not work
#  COMMAND ${CMAKE_COMMAND} -E chdir 
${CMAKE_LIBRARY_OUTPUT_DIRECTORY} create_symlink ${targetName} ${linkName}
#  COMMAND ln -sf ${targetName} ${linkName} DEPENDS ${target}

 COMMAND ${CMAKE_COMMAND} -E chdir 
${CMAKE_LIBRARY_OUTPUT_DIRECTORY} ln -sf ${targetName} ${linkName} DEPENDS 
${target}
  COMMENT "--> --> [ln -sf ${targetName} ${linkName} DEPENDS 
${target}]"
  )

# does not work
# install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E chdir 
${INSTALL_LIB_DIR} create_symlink ${targetName} ${linkName})")

endforeach(loop_var)

   endmacro(rgf_create_symlink)

Best regards

---rony

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

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

[Rony G. Flatscher]

On 01.01.2019 22:00, Rick McGuire wrote:
> Have you tried this: 
>
> https://stackoverflow.com/questions/35765106/symbolic-links-cmake

No, not yet, thank you for the hint!

Will try to incorporate it as it allows to define a new target, which with

 use of
"install(TARGETS ...)" may help solve the problem. Will report back, if there 
is progress (and if
not in the next hour will try to turn back to this tomorrow).

---rony






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

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

[Rony G. Flatscher]

Found another way to get it to install by issuing a:

 install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} COMPONENT 
Core DESTINATION ${INSTALL_LIB_DIR})

Originally I tried to run "install(CODE...)" that would create the symbolic 
links. Given that I had
arrived at many, many variations I might not have done that right and will try 
tomorrow.

The macro (defined for UNIX and called at the end of the shared library 
definitions) currently looks
like:

   # define macro to create symlinks at installation time to allow programs 
compiled against older versions of Rexx and ooRexx to run
   macro(rgf_create_symlink target)

set(baseName   "${CMAKE_SHARED_LIBRARY_PREFIX}${target}")
set(targetName "${baseName}${CMAKE_SHARED_LIBRARY_SUFFIX}")

foreach(loop_var RANGE 2 4)
  set(linkName "${baseName}.${loop_var}${CMAKE_SHARED_LIBRARY_SUFFIX}")

  add_custom_command(TARGET ${target} POST_BUILD
  COMMAND ${CMAKE_COMMAND} -E chdir 
${CMAKE_LIBRARY_OUTPUT_DIRECTORY} ln -sf ${targetName} ${linkName} DEPENDS 
${target}
  COMMENT "--> --> [ln -sf ${targetName} ${linkName} DEPENDS 
${target}]"
  )

  install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} COMPONENT 
Core DESTINATION ${INSTALL_LIB_DIR})

endforeach(loop_var)

   endmacro(rgf_create_symlink)

Will do a few more experiments and if it works out on Apple too, I will tidy it 
up, test again and
supply a patch, hopefully tomorrow.

---rony

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

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

[Rony G. Flatscher]

Got carried away in the midst of testing a few variations of CMakeList (had to 
fix installations on
Apple for LibreOffice - it does not have all of the standard directories of OOo 
anymore - and in
addition Java 9 and higher on Apple for the OpenOffice/LibreOffice ooRexx 
scripts, if using the
GUI), hope to be back at the CMakeList for creating the links tomorrow.

---rony


On 01.01.2019 22:50, Rony G. Flatscher wrote:
>
> Found another way to get it to install by issuing a:
>
>  install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} 
> COMPONENT Core DESTINATION ${INSTALL_LIB_DIR})
>
> Originally I tried to run "install(CODE...)" that would create the symbolic 
> links. Given that I
> had arrived at many, many variations I might not have done that right and 
> will try tomorrow.
>
> The macro (defined for UNIX and called at the end of the shared library 
> definitions) currently
> looks like:
>
># define macro to create symlinks at installation time to allow 
> programs compiled against older versions of Rexx and ooRexx to run
>macro(rgf_create_symlink target)
>
> set(baseName   "${CMAKE_SHARED_LIBRARY_PREFIX}${target}")
> set(targetName "${baseName}${CMAKE_SHARED_LIBRARY_SUFFIX}")
>
> foreach(loop_var RANGE 2 4)
>   set(linkName 
> "${baseName}.${loop_var}${CMAKE_SHARED_LIBRARY_SUFFIX}")
>
>   add_custom_command(TARGET ${target} POST_BUILD
>   COMMAND ${CMAKE_COMMAND} -E chdir 
> ${CMAKE_LIBRARY_OUTPUT_DIRECTORY} ln -sf ${targetName} ${linkName} DEPENDS 
> ${target}
>   COMMENT "--> --> [ln -sf ${targetName} ${linkName} DEPENDS 
> ${target}]"
>   )
>
>   install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} 
> COMPONENT Core DESTINATION ${INSTALL_LIB_DIR})
>
> endforeach(loop_var)
>
>endmacro(rgf_create_symlink)
>
> Will do a few more experiments and if it works out on Apple too, I will tidy 
> it up, test again and
> supply a patch, hopefully tomorrow.
>
> ---rony
>

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

Re: [Oorexx-devel] dynamic linking on macOS (was: Re: A few questions ad CMake and libraries on Unix)

[Rony G. Flatscher]

Dear P.O.:

On 04.01.2019 14:26, P.O. Jonsson wrote:
> What about this statement that I have seen in some installers, is it still 
> necessary/valid=?
>
> export NLSPATH=$REXXPATH/bin/rexx.cat:$NLSPATH

No, this has been fixed in the meantime.

---rony


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

[Oorexx-devel] r11661 builds

[Rony G. Flatscher]

Temporarily you may find ooRexx r11661 builds for Windows (32- and 64-bit), 
Linux (deb+rpm in
64-bit) and MacOSX (64-bit) on my Dropbox at:
 to 
ease testing.

It seems that if causing the rxapi process to start that compared to earlier 
versions, this seems to
be now instantaneously.

---rony






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

[Oorexx-devel] Ad CMakeList.txt

[Rony G. Flatscher]

Doing a "[n]make clean" leaves the following files in bin (Linux, MacOSX):

  * rexx.1.gz
  * rexx.cat
  * rexxc.1.gz
  * rxqueue.1.gz
  * rxsubcom.1.gz

on Windows, if built with "-DCMAKE_BUILD_TYPE=RELWITHDEBINFO" the following 
files are in bin left over:

callrxnt.ilk
callrxwn.ilk
hostemu.ilk
ooDialog.ilk
ooDialog_com.pdb
ooDialog_exe.pdb
ooshapes.ilk
orexx.pdb
orexxole.ilk
orxclassic.ilk
orxclassic1.ilk
orxexits.ilk
orxfunction.ilk
orxinvocation.ilk
orxmethod.ilk
rexx.ilk
rexxapi.ilk
rexxapi1.ilk
rexxapi2.ilk
rexxapi3.ilk
rexxc.ilk
rexxexit.ilk
rexxhide.ilk
rexximage.ilk
rexxinstance.ilk
rexxpaws.ilk
rexxutil.ilk
runRexxProgram.ilk
rxapi.ilk
rxmath.ilk
rxqueue.ilk
rxregexp.ilk
rxsock.ilk
rxsubcom.ilk
rxwinsys.ilk
stackOverflow.ilk

and in the Windows lib-directory:

hostemu.exp
oodialog.exp
ooshapes.exp
orexxole.exp
orxclassic.exp
orxclassic1.exp
orxexits.exp
orxfunction.exp
orxinvocation.exp
orxmethod.exp
rexx.exp
rexxapi.exp
rexxapi1.exp
rexxapi2.exp
rexxapi3.exp
rexxutil.exp
rxmath.exp
rxregexp.exp
rxsock.exp
rxwinsys.exp

---rony

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

[Oorexx-devel] Question ad RPATH and MacOSX

[Rony G. Flatscher]

Would it be possible to define RPATH such, that it always looks in the 
directories ".", "./lib",
"../lib", "/usr/local/lib" (maybe even "/opt/local/lib") for the needed 
libraries?

This way a USB-stick version may have the executables in the same directory or 
lib in a companion or
subdirectory.

Currently, after a "make install" one cannot relocate the resulting binaries. 
Using the binaries
from the "make" step forces one to have "lib" in a sibling directory.

Probably with the help of
 
this could be solvable.
Alternatively, if one has XCode installed, one might use "install_name_tool" to 
manipulate all rpath
definitions. Another alternative would be to set DYLD_LIBRARY_PATH.

What do you think, which solution would be preferable?

---rony




___
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

[Rony G. Flatscher]

On 08.01.2019 15:52, Enrico Sorichetti via Oorexx-devel wrote:
> Right now You cannot relocate the installed thing 
> Because the rpath is an absolute one 
> I posted a few emails back the right constructs …

Hmm saw them, but was not sure what they were about and whether that was all 
that was needed (being
totally unfamiliar with RPATH)! :(

> Here they are again
>
> With these settings  all works fine for me without bothering 
> To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH
>
> # do not skip the full RPATH for the build tree
> SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
>
> # when building, don't use the install RPATH 
> # only later on when installing 
> SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>
> if( APPLE )
>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
> else()
>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
> endif()
>
> # add the automatically determined parts of the RPATH
> # which point to directories outside the build tree to the install RPATH
> SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

Is it correct to state in this case that the executable's libraries then get 
automatically searched
in the sibling "lib" directory?

> Without the RPATH setting the exports are required 
>
> ( tested on El Capitan, high Sierra, Mojave and Fedora 29 )

This is great, thank you very much indeed (also for your patience! :) ), will 
try it out on both
MacOSX and Linux!

>
> Why would anybody set multiple paths ???

Well, in Windows the libraries are usually on the PATH and hence a standalone 
("stick") version of
ooRexx on Windows might have the dlls in the same directory as ooRexx. Even 
though Windows should
not serve as the role model for Unix, nevertheless such layouts or solutions 
might be attempted
(easier understandable) for users (not developers).

People coming from Windows might therefore intend to place the shared libraries 
on Unix into the
executable directory as well or move "lib" to become local to the executable 
directory (this way a
subdirectory "oorexx" would point to the ooRexx executable and include all 
necessary files directly
there, including the libraries or the "lib" directory).

How would one add multiple RPATHs with CMake? Would just adding another 
directory to the path rpath
with a colon be correct, something like:

if( APPLE )
    SET( CMAKE_INSTALL_RPATH "@executable_path/../lib:@executable_path/.")
else()
    SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib:$ORIGIN/.")
endif()

Will test it, after first testing your "@executable_path/../lib"  definition.

Again, thank you very much, Enrico!

---rony






___
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

[Rony G. Flatscher]

Dear Enrico:

On 08.01.2019 16:11, Enrico Sorichetti via Oorexx-devel wrote:
> I wonder why everybody refuses to use the proper constructs for the RPATH
> Looks like I am wasting my time testing and making suggestions

please bear with us!

Not having *any* background knowledge of CMake and the usage of RPATH, it 
sometimes takes a second
or third push!

Also, I have noticed your posted CMake program which would display all set 
CMake variables and meant
to ask how to use it! Something that probably goes without saying for yourself, 
being obviously a
CMake master/expert/power user, but something that needs experiments/research 
from this side of a
total CMake amateur (who unfortunately does not have time at the moment to 
really go through
tutorials and background literature/sources to get acquainted with it). In the 
meantime I have been
carried away from testing it (with a popped up problem with BSF4ooRexx and 
OpenOffice/LibreOffice on
MacOSX that in the meantime got solved, after quite some efforts and two day's 
of work), but would
like to do that in any case as it would allow me to get a rough idea of what 
CMake variables are set
and used for a build.

Cheers,

---rony



___
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

[Rony G. Flatscher]

Dear P.O.,

On 08.01.2019 16:16, P.O. Jonsson wrote:
> For MAC at least a build to a USB stick is relocatable to another computer 
> since the name of the
> stick will be the name of the volume, automatically mounted to /Volumes

with RPATH defined the way Enrico suggests, there is no need to link/copy the 
libraries to any
special place, they will be located by the system relative to the place where 
the "rexx" executable
resides. Therefore the binaries (if moved with the lib directory) are fully 
relocatable.

Best regards

---rony



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

[Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

[Rony G. Flatscher]

O.K, Enrico's definitions work like a charm!
:)

Ad multiple RPATHs: this works as well, one needs to separate the paths with a 
semi-colon, not with
a colon, though. However, thinking about it in the meantime, this would not be 
really helpful on
Unix based systems, although Windows users might be happy. :) The reason being 
that probably all
Unix-based builds will have a "bin" and a "lib" directory as siblings.

Enrico's definitions should also work when installing to /usr/local as the 
executables land in
/usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib".

Will test Linux later and report back, should there be any unexpected problems.

Again, thank you very much Enrico for your advice! ooRexx now works in the most 
versatile fashion! :)

---

Just a question to the developers: is it helpful supplying a patch for 
CMakeList.txt?

The reason why I ask is that a patch got not picked up so far that creates 
symbolic links for Linux
and MacOSX. I attached it to the proper bug report, cf. 
<https://sourceforge.net/p/oorexx/bugs/1421/>.

The latest patch there is
<https://sourceforge.net/p/oorexx/bugs/_discuss/thread/4202a51e/4a68/2f6b/attachment/patch-sym-links-03.txt>
which in addition also includes two placing the libraries in the "lib" 
directory as per Enricos
suggestion and naming 64-bit rpm packages correctly. That patch got tested 
building ooRexx against
Windows, Linux and MacOSX.

---rony


On 08.01.2019 16:12, Rony G. Flatscher wrote:
> On 08.01.2019 15:52, Enrico Sorichetti via Oorexx-devel wrote:
>> Right now You cannot relocate the installed thing 
>> Because the rpath is an absolute one 
>> I posted a few emails back the right constructs …
> Hmm saw them, but was not sure what they were about and whether that was all 
> that was needed (being
> totally unfamiliar with RPATH)! :(
>
>> Here they are again
>>
>> With these settings  all works fine for me without bothering 
>> To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH
>>
>> # do not skip the full RPATH for the build tree
>> SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
>>
>> # when building, don't use the install RPATH 
>> # only later on when installing 
>> SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>
>> if( APPLE )
>>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
>> else()
>>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
>> endif()
>>
>> # add the automatically determined parts of the RPATH
>> # which point to directories outside the build tree to the install RPATH
>> SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> Is it correct to state in this case that the executable's libraries then get 
> automatically searched
> in the sibling "lib" directory?
>
>> Without the RPATH setting the exports are required 
>>
>> ( tested on El Capitan, high Sierra, Mojave and Fedora 29 )
> This is great, thank you very much indeed (also for your patience! :) ), will 
> try it out on both
> MacOSX and Linux!
>
>> Why would anybody set multiple paths ???
> Well, in Windows the libraries are usually on the PATH and hence a standalone 
> ("stick") version of
> ooRexx on Windows might have the dlls in the same directory as ooRexx. Even 
> though Windows should
> not serve as the role model for Unix, nevertheless such layouts or solutions 
> might be attempted
> (easier understandable) for users (not developers).
>
> People coming from Windows might therefore intend to place the shared 
> libraries on Unix into the
> executable directory as well or move "lib" to become local to the executable 
> directory (this way a
> subdirectory "oorexx" would point to the ooRexx executable and include all 
> necessary files directly
> there, including the libraries or the "lib" directory).
>
> How would one add multiple RPATHs with CMake? Would just adding another 
> directory to the path rpath
> with a colon be correct, something like:
>
> if( APPLE )
>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib:@executable_path/.")
> else()
>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib:$ORIGIN/.")
> endif()
>
> Will test it, after first testing your "@executable_path/../lib"  definition.
>
> Again, thank you very much, Enrico!
>
> ---rony
>
>
>



___
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

[Rony G. Flatscher]

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

Re: [Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

[Rony G. Flatscher]

Dear P.O.,

On 08.01.2019 17:17, P.O. Jonsson wrote:
>> Am 08.01.2019 um 17:10 schrieb Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>>:
>>
>> O.K, Enrico's definitions work like a charm!
>> :)
>>
>> Ad multiple RPATHs: this works as well, one needs to separate the paths with 
>> a semi-colon, not with
>> a colon, though. However, thinking about it in the meantime, this would not 
>> be really helpful on
>> Unix based systems, although Windows users might be happy. :) The reason 
>> being that probably all
>> Unix-based builds will have a "bin" and a "lib" directory as siblings.
>>
>> Enrico's definitions should also work when installing to /usr/local as the 
>> executables land in
>> /usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib“.
>
> I would strongly advice against installing directly into /usr/local/bin and 
> /usr/local/lib. Rather
> installing into /usr/local/oorexx5.0.0 (/bin,/lib etc) and Symlink all files 
> into /usr/local/bin
> etc. This is what all other installations do. Out of 215 files in /bin 211 
> are symlinks, not
> executables.

this depends on the installation philosophy. :)

Unlike you and René I use macports which installs into "/opt/local" (and its 
subdirectories "bin",
"lib", "include", "man", "share",  etc., nowadays.

Homebrew, I understand, installs like you suggest.

mvim (the Mac version of vi improved) installs into /usr/local, etc.

No matter which philosophy one follows the "@executable_path/../lib" in the 
binaries RPATH will
allow rexx to locate its libraries in its sibling "lib" directory.

The BSF4ooRexx installation installs, as you know, according to Apple's 
installation
recommendations, hence Framework and Application bundles are used there. The 
binaries in this
environment are then symbolically linked to /usr/local/bin and /usr/local/lib. 
Thinking of this
scenario it actually may make sense to have an additional RPATH defined in this 
case (speculating
that the system will resolve the symbolic path e.g. "/usr/local/bin/rexx ->
/Library/Frameworks/ooRexx.framework/Commands/rexx" for which its libraries are 
located in
"@executable_path/../Libraries"). Will test and report back, whether this would 
really be necessary.

---rony


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

[Oorexx-devel] Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

Thanks to Enrico I was able to compile ooRexx with RPATH for MacOS and Linux 
successfully which
allows one to use those interpreters "standalone" like on a stick.

The experimental standalone ooRexx interpreters for Windows (32- and 64-bit), 
Linux (64-bit) and
MacOSX (64-bit) can be temporarily found on my Dropbox:
. 
This Dropbox directory
includes a directory named "CMakeList" which contains the file CMakeList.txt 
used to create the
MacOS and Linux versions.

To use, unzip/untar the archives and run "rexx.exe"/"rexx" from the "bin" 
directory.

---rony







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

[Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

While testing the standalone version on Linux, everything works out fine if 
issuing "rexx".

However, if invoking "rexx" with a fully qualified path like:

~/some/path/to-standalone/bin/rexx -e "parse version v; say v"

an error "Logic error: no startup image" is raised and ooRexx gets aborted with 
a core dump. The
libraries seem to be found.

This is with r11665.

---rony

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

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

On 08.01.2019 19:15, Rony G. Flatscher wrote:
>
> While testing the standalone version on Linux, everything works out fine if 
> issuing "rexx".
>
Should have also mentioned: if putting the directory where rexx resides on to 
the path everything
works as well.

---rony


> However, if invoking "rexx" with a fully qualified path like:
>
> ~/some/path/to-standalone/bin/rexx -e "parse version v; say v"
>
> an error "Logic error: no startup image" is raised and ooRexx gets aborted 
> with a core dump. The
> libraries seem to be found.
>
> This is with r11665.
>
> ---rony
>

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

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

ld find the companion "bin" directory.

As one can see the "bin" directory on Unix includes the following binaries: 
"rexx", "rexx.img",
"rexx.cat", "rexxc", "rxsubcom", and "rxapi".
(In addition the C++ ooRexx samples "callrexx?" with "libwpipe?.dylib"get 
installed there too, which
I think should not be the case.)

So ooRexx would need to look for "rexx.img", "rexx.cat", "rxsubcom" and "rxapi" 
in the "bin"
directory, which relative to the "lib" directory can always be found with the 
relative path "../bin".

Enclosed please find an experiment with "CMakeList.txt" changed to use RPATH and
"common/platform/unix/SysProcess.cpp" to become able to locate "rexx.img" and 
the other binaries in
"bin", if moving the ooRexx directory away from its installation directory 
(currently being
"~/Applications" on MacOS)! With the enclosed patch applied it becomes possible 
to run ooRexx
without the "bin" directory being on the PATH altogether!

It got successfully tested even with using "address with":

wu114215:oha rony$ *./macos64/bin/rexx -e "out=.array~new; address '' 'ls 
-al' with output using (out); say out"*
total 0
drwxr-xr-x   4 rony  staff   128 Jan  9 13:58 .
drwxr-xr-x  89 rony  staff  2848 Jan  9 18:46 ..
drwxr-xr-x   6 rony  staff   192 Jan  9 13:57 macos64
drwxr-xr-x   6 rony  staff   192 Jan  9 13:58 old
wu114215:oha rony$ 

---

The only thing that the enclosed patch cannot handle is finding "rexx.cat", 
such that Rexx error
messages (e.g. for 'say 1/0') will instead cause a "REX0025E: Cannot open REXX 
message catalog
rexx.cat" message:

wu114215:oha rony$ *./macos64/bin/rexx -e "parse version v; say v"*
REXX-ooRexx_5.0.0(MT)_64-bit 6.05 9 Jan 2019
wu114215:oha rony$ 

wu114215:oha rony$ *./macos64/bin/rexx -e "say 'current directory:' 
directory()"*
current directory: /Users/rony/oha
wu114215:oha rony$ 

wu114215:oha rony$ *./macos64/bin/rexx -e "say 1/0"*
 1 *-* say 1/0
REX0042E: Cannot open REXX message catalog rexx.cat.  Not in NLSPATH or 
/Users/rony/Applications/ooRexx5.0.0/bin. 42 Cannot open REXX message catalog 
rexx.cat.  Not in NLSPATH or /Users/rony/Applications/ooRexx5.0.0/bin. INSTORE 
Cannot open REXX message catalog rexx.cat.  Not in NLSPATH or 
/Users/rony/Applications/ooRexx5.0.0/bin. 1:  Cannot open REXX message catalog 
rexx.cat.  Not in NLSPATH or /Users/rony/Applications/ooRexx5.0.0/bin.
    REX0413E: Cannot open REXX message catalog rexx.cat.  Not in NLSPATH or 
/Users/rony/Applications/ooRexx5.0.0/bin. 42.3:  Cannot open REXX message 
catalog rexx.cat.  Not in NLSPATH or /Users/rony/Applications/ooRexx5.0.0/bin.

"/Users/rony/Applications/ooRexx5.0.0" is the directory "make install" created 
and used.

---rony


>
>
> On Tue, Jan 8, 2019 at 1:21 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> On 08.01.2019 19:15, Rony G. Flatscher wrote:
>>
>> While testing the standalone version on Linux, everything works out fine 
>> if issuing "rexx".
>>
> Should have also mentioned: if putting the directory where rexx resides 
> on to the path
> everything works as well.
>
> ---rony
>
>
>> However, if invoking "rexx" with a fully qualified path like:
>>
>> ~/some/path/to-standalone/bin/rexx -e "parse version v; say v"
>>
>> an error "Logic error: no startup image" is raised and ooRexx gets 
>> aborted with a core dump.
>> The libraries seem to be found.
>>
>> This is with r11665.
>>
>> ---rony
>>

Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 11665)
+++ CMakeLists.txt  (working copy)
@@ -52,8 +52,8 @@
 include(CheckFunctionExists)
 include(CheckSymbolExists)
 include(CheckCSourceCompiles)
-set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
-set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
+set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib)
+set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib)
 set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
 set (CMAKE_PDB_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
 set (CMAKE_SAMPLES_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/samples)
@@ -250,6 +250,24 @@
set (INSTALL_LIB_DIR ${CMAKE_INSTALL_PREFIX}/lib)
  endif ()
endif ()
+
+   # do not skip the full RPATH for the build tree
+   SET( CMAKE_SKIP_B

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

On 09.01.2019 21:11, Rick McGuire wrote:
> This is not an acceptable patch because it imposes a directory structure that 
> is not necessary and
> is not necessarily what will be used on the other platforms. Just make the 
> simple one-line change
> to the CMakeLists.txt file to install rexx.img in the same directory as 
> librexxapi as it intended.

Unfortunately, this does not solve the problem at all in r11665.

Reverted ooRexx to trunk including CMakeList.txt and built for Mac and 
installed to the current
default directory "~/Applications". Moved ooRexx5.0.0 away from it, moved 
manually "bin/rexx.img" to
"lib" and experimented:

wu114215:bin rony$ mv rexx.img ../lib/

wu114215:bin rony$ ./rexx 
dyld: Library not loaded: @rpath/librexx.5.0.0.dylib
  Referenced from: /Users/rony/Applications/test/ooRexx5.0.0/bin/./rexx
  Reason: image not found
Abort trap: 6

Now making sure that libraries are found in "../lib":

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx *

Syntax is "rexx filename [arguments]"
or"rexx -e program_string [arguments]"
or"rexx -v".

However "Logic error: no startup image" occurs:

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx -e 
"out=.array~new;address '' 'ls -al' with output using
(out);say out"*
Logic error: no startup image
Illegal instruction: 4

wu114215:bin rony$ 
wu114215:bin rony$ *pwd*
/Users/rony/Applications/test/ooRexx5.0.0/bin
wu114215:bin rony$ *find .. -name rexx.img*
../lib/rexx.img

"rexx.img" is indeed located in "bin"'s sibling directory "lib".

---rony




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

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

On 10.01.2019 12:56, Rick McGuire wrote:
> I have tested exactly the situation on my Linux system, and everything works 
> fine. But I don't
> have your setup, so there's probably something different. 
>
> I suggest adding a printf() to the SystemInterpreter::loadImage() method (the 
> second one with the
> longer signature) and print out the names it is attempting to load from. One 
> concern I do have
> whether the getExecutableLocation() might need to resolve links to obtain the 
> real library
> location. I'm not sure what name dladdr() is returning. The printfs() will 
> show where it is
> looking and might give a good answer to this question.

OK, added printf's in FileSystem.cpp to the imageLoad() methods there.

However, in the process I noticed that although I had issued a "svn revert *" 
to the ooRexx
"main/trunk" the changes I had added yesterday were still present. After 
reverting them back
individually and making sure that all files were in sync with r11665 (svn 
stat), "rexx.img" got found!

Sorry for the false alarm about "../lib/rexx.img" not being found!

However the library not found problem still persists if running without 
Enrico's RPATH settings,
here a sample MacOS session:

wu114215:bin rony$ *pwd*
/Users/rony/Applications/mac64test20190110-1410/bin

wu114215:bin rony$ *./rexx*
dyld: Library not loaded: @rpath/librexx.5.0.0.dylib
  Referenced from: 
/Users/rony/Applications/mac64test20190110-1410/bin/./rexx
  Reason: image not found
Abort trap: 6

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx*

Syntax is "rexx filename [arguments]"
or"rexx -e program_string [arguments]"
or"rexx -v".

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx -e "say '--->' 
directory()"*
---> /Users/rony/Applications/mac64test20190110-1410/bin

wu114215:bin rony$ *./rexx -e "say '--->' directory()"*
dyld: Library not loaded: @rpath/librexx.5.0.0.dylib
  Referenced from: 
/Users/rony/Applications/mac64test20190110-1410/bin/./rexx
  Reason: image not found
Abort trap: 6

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

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

[Rony G. Flatscher]

On 10.01.2019 14:30, Rick McGuire wrote:
> Why are you removing Enrico's RPATH changes? They seem like a good idea and I 
> NEVER advocated
> against those. My discussion was totally about the appropriate location for 
> rexx.img.

Oh, o.k. As the changes have not been applied to trunk I thought they were not 
desired, hence going
back to the trunk version of CMakeList.txt. Will reapply and keep them (as well 
as the fixes to add
the symbolic links to let applications linked to older versions of ooRexx run 
with the current
version and fixing the rpm naming if 64-bit).

---rony




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

Re: [Oorexx-devel] Rethinking error messages.

[Rony G. Flatscher]

Applied your commits and re-built MacOS and Linux standalone versions and my 
preliminary tests show
that this is working perfectly, *great job*!

---rony

P.S.: Cf. eg. 
.

On 09.01.2019 23:07, Rick McGuire wrote:
> The purpose of the rexx.cat  file is (in theory), that by 
> having separation
> between the executables and the error texts, we can easily translate the 
> error messages. In
> reality, there has never been any attempt at having multiple versions of the 
> messages, and I
> suspect we have really been misusing the catopen() mechanisms in a way that 
> would really prevent
> multiple languages from happening. The move toward the USB execution only 
> complicates this since
> we desire to pick up a specific rexx.cat  file rather than 
> using the DLPATH
> capabilities. 
>
> In addition, the Windows version makes no attempt at implementing NLS 
> support. The error messages
> are bound into the rexx dll as string resources. To do any sort of 
> translation, you need to
> rebuild the interpreter with a different .rc file. There is no switching.
>
> As I'm working on code to locate the specific .cat file, it occurred to be 
> that it would be a
> trivial matter to implement something like Windows uses and have an internal 
> message table rather
> than have this external artifact that needs to be located. 
>
> Rick

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

Re: [Oorexx-devel] [oorexx:code-0] New commit [r11653] by bigrixx

[Rony G. Flatscher]

On 13.01.2019 18:27, Erich Steinböck wrote:
> Those two SET's were the fix for https://sourceforge.net/p/oorexx/bugs/1577
> Specific to CLANG on mac.  That's probably the reason why the mac builds 
> don't give those c++11
> warnings.

Interestingly there are no such warnings issued when compiling with gcc 7.3.0 
on Ubuntu.

---rony




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

Re: [Oorexx-devel] [oorexx:code-0] New commit [r11653] by bigrixx

[Rony G. Flatscher]

Just tested that: MacOS builds Linux gcc gets an error during compilation.

---rony

P.S.: While cleaning the build directory with "rm -rf *" I mistakingly deleted 
my  home directory
"~" so I will not be able to create builds for ooRexx or BSF4ooRexx for Linux 
32- and 64-bit. :-(

[As I alotted too much time to ooRexx in the past weeks I have to make up for 
it for my day job, so
it will be a while before I become able to compile on Linux again...]


On 13.01.2019 17:49, Rick McGuire wrote:
> Hmm, the following lines in CMakeLists.txt look suspicious. I think the SET 
> commands should be
> outside the conditional. 
>
> # Extra link library definitions
> # gcc (at least on Linux) requires linking with -lcrypt
> # clang (at least on Darwin) doesn't have libcrypt
> if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
> target_link_libraries(rxunixsys rexx rexxapi crypt 
> ${CMAKE_REQUIRED_LIBRARIES})
> else ()
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -stdlib=libc++")
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -stdlib=libc++ 
> -lc++abi")
>
> target_link_libraries(rxunixsys rexx rexxapi ${CMAKE_REQUIRED_LIBRARIES})
> endif ()

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

[Oorexx-devel] Releasing ooRexx 5.0?

[Rony G. Flatscher]

What would be the thoughts about releasing the current trunk version of ooRexx 
5.0 as "general
available"?
(In order for organisations/companies to adopt 5.0 or to replace older versions 
of Rexx/ooRexx with
5.0 it would be necessary that it becomes officially GA.)

It would be still possible to create some ooRexx 5.1, 5.2 and the like shortly 
after a GA release,
if new functionality would be added to it (e.g. applying sandbox development 
results or implementing
RFEs).

---rony



___
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

[Rony G. Flatscher]

On 22.01.2019 17:53, 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.

maybe the following can be helpful after running "make":

make DESTDIR=~/oorexx5 install   

"DESTDIR=someDestinationDirectory" allows one to install ooRexx anywhere on 
one's system. Then
"~/oorexx5/bin/rexx -e 'say address()' " should work.

---rony

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

[Oorexx-devel] Question ad AddCommandHandler()

[Rony G. Flatscher]

Question ad new C++ method "context->AddCommandEnvironment(name, handler, 
type);", where the
documentaiton for "type" reads:

"type": The type of command handler to add. DIRECT_COMMAND_ENVIRONMENT for 
a command handler
with no support for redirection.
REDIRECTING_COMMAND_ENVIRONMENT for a command handler that supports 
redirection.

How would the "handler" become able to support the new 
"REDIRECTING_COMMAND_ENVIRONMENT" ability?
How could the "handler" determine whether redirection is in place and if so, 
what should it
do/support for each kind of redirection?

---rony


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

Re: [Oorexx-devel] Question ad AddCommandHandler()

[Rony G Flatscher]

How does the implentation (have to?) differ? 

The readon of asking: once ooRexx 5 gets released, I plan a version of 
BSF4ooRexx that exploits the new ooRexx features. 

As the current version already supports command handlers implemented in Java 
(or in ooRexx via BSF4ooRexx) at interpreter creation time, I would like to 
support this new API in all of its facets.

—-rony


Rony G. Flatscher (mobil/e)

> Am 28.01.2019 um 21:15 schrieb Rick McGuire :
> 
> The two handler types have different call signatures. When you register the 
> handler, you are telling the interpreter which call signature is used to call 
> the handler. 
> 
> Rick
> 
>> On Mon, Jan 28, 2019 at 1:43 PM Rony G. Flatscher  
>> wrote:
>> Question ad new C++ method "context->AddCommandEnvironment(name, handler, 
>> type);", where the documentaiton for "type" reads: 
>> 
>> "type": The type of command handler to add. DIRECT_COMMAND_ENVIRONMENT for a 
>> command handler with no support for redirection. 
>> REDIRECTING_COMMAND_ENVIRONMENT for a command handler that supports 
>> redirection.
>> 
>> How would the "handler" become able to support the new 
>> "REDIRECTING_COMMAND_ENVIRONMENT" ability? How could the "handler" determine 
>> whether redirection is in place and if so, what should it do/support for 
>> each kind of redirection?
>> 
>> ---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

Re: [Oorexx-devel] Question ad AddCommandHandler()

[Rony G. Flatscher]

On 28.01.2019 22:24, Rick McGuire wrote:
> I suggest you look at the test command handler that Erich just added to the 
> test cases. This will
> show you how the command handlers are implemented and how to use the 
> redirection APIs.

Thanks, will do.

---rony




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

Re: [Oorexx-devel] Question ad AddCommandHandler()

[Rony G Flatscher]

Looked thru the code, a few quick questions:

If a command handler that has no redirection, would the last argument ioctl be 
NULL?
Can one query the list (names) of the currently loaded command handlers?
Would one be able to remove a command handler by name?

—-rony

Rony G. Flatscher (mobil/e)

> Am 29.01.2019 um 14:02 schrieb Rony G. Flatscher :
> 
>> On 28.01.2019 22:24, Rick McGuire wrote:
>> I suggest you look at the test command handler that Erich just added to the 
>> test cases. This will
>> show you how the command handlers are implemented and how to use the 
>> redirection APIs.
> 
> Thanks, will do.
> 
> ---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 AddCommandHandler()

[Rony G. Flatscher]

Thanks, one last question in this context.

On 29.01.2019 21:07, Rick McGuire wrote:
> On Tue, Jan 29, 2019 at 1:18 PM Rony G Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Looked thru the code, a few quick questions:
>
> If a command handler that has no redirection, would the last argument 
> ioctl be NULL?
>
> No, if the command handler is registered as a redirecting handler, then it 
> will always be passed
> an IOContext. You can then query the context to see if there has been any 
> redirection requested
> and what types.

There is a new IsRedirectionRequested() function listed and documented as:

8.17.100. *NEW* IsRedirectionRequested

This API is available in context I/O Redirector since ooRexx 5.0.

logical_t flag;
// Method Syntax Form(s)
flag = context->IsRedirectionRequested();

Tests whether for the current command any redirection was requested using 
the WITH subkeyword of
an ADDRESS instruction.

Arguments: None.

Returns: 1 if any redirection was requested, 0 otherwise.

See also methods *NEW* AreOutputAndErrorSameTarget, *NEW* 
IsErrorRedirected, *NEW*
IsInputRedirected, *NEW* IsOutputRedirected, *NEW* ReadInput, *NEW* 
ReadInputBuffer, *NEW*
WriteError, *NEW* WriteErrorBuffer, *NEW* WriteOutput, and *NEW* 
WriteOutputBuffer.


The function "AddCommandEnvironment(name,handler,type)" has a "type" argument 
that may be one of
two: DIRECT_COMMAND_ENVIRONMENT and REDIRECTING_COMMAND_ENVIRONMENT.

Question:

What is exactly the difference between the two?
E.g. the REDIRECTING_COMMAND_ENVIRONMENT must use the "ReadInput[Buffer]()" 
and the
"Write{Error|Output}[Buffer]()" functions, whereas the 
"DIRECT_COMMAND_ENVIRONMENT" must use
.input for reading, .output and .error for writing instead?

Question:

Can "IsRedirectionRequested()" be issued for both handler types?

And if so, in the case of a DIRECT_COMMAND_ENVIRONMENT would then the 
functions
"AreOutputAndErrorSameTarget()", "IsErrorRedirected()", 
"IsInputRedirected()",
"IsOutputRedirected()" be available as well? If so, how about the 
"Write[*]()" functions?

---rony



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

Re: [Oorexx-devel] Question ad AddCommandHandler()

[Rony G. Flatscher]

On 30.01.2019 11:57, Rick McGuire wrote:
>
> On Wed, Jan 30, 2019 at 5:51 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Thanks, one last question in this context.
>
> On 29.01.2019 21:07, Rick McGuire wrote:
>> On Tue, Jan 29, 2019 at 1:18 PM Rony G Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> Looked thru the code, a few quick questions:
>>
>> If a command handler that has no redirection, would the last 
>> argument ioctl be NULL?
>>
>> No, if the command handler is registered as a redirecting handler, then 
>> it will always be
>> passed an IOContext. You can then query the context to see if there has 
>> been any redirection
>> requested and what types.
>
... cut ...

> The type indicates what sort of handler you have written. The redirecting one 
> is passed an io
> context, the non-redirecting one does not. The non-redirecting ones are the 
> same as command
> handlers that exist for 4.2.0. The API merely allows one to be added by other 
> than an option when
> the interpreter instance is created.
>  

So then the difference is reflected in the called handler function as well,

for the non-directing signature:

RexxObjectPtr RexxEntry nonDirectingCommandHandler(RexxExitContext *context,
  RexxStringObject address,
  RexxStringObject command)

for the redirecting signature:

RexxObjectPtr RexxEntry reDirectingCommandHandler(RexxExitContext *context,
 RexxStringObject address,
 RexxStringObject command,
 RexxIORedirectorContext *ioContext)

Thanks!

---rony

P.S.: Sorry, the first reply went directly to Rick instead of to the list!

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

[Oorexx-devel] Ad Unix-based installations missing ooRexx samples and the ooRexx documentation ...

[Rony G. Flatscher]

The Unix based installations do not come with the IMHO extremely import 1) 
ooRexx samples and 2) the
ooRexx pdf documentation!

Is there any convention to allow installing 1) and 2) with the base ooRexx 
installation? Or would
there be a possibility to have an additional installation package that simply 
includes 1) and 2)?

---rony

P.S.: My BSF4ooRexx package for MacOSX includes ooRexx and all of 1) and 2), 
accessible via the
ooRexx menu there. But that is only possible, because the installation is 
Apple-specific.




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

[Oorexx-devel] Break up "rexxpg.pdf" into an "ooRexx Primer/Introduction" and a separate "C/C++ Programming Interfaces for ooRexx"?

[Rony G. Flatscher]

For unknown reasons the "Programmer Guide" of ooRexx, "rexxpg.pdf", includes a 
primer for ooRexx and
the documentation for savvy C/C++ programmers.

If a newcomer is looking for an introduction into ooRexx it would be great if 
there was a specific
pdf-book for it, like "ooRexx Primer - Introduction to the ooRexx Programming 
Language", i.e.
chapter one through chapter seven plus appendix A and appendix B, which gives a 
brief
characterizations of the ooRexx samples.

The remaining chapters 8 and 9 could then be entitled something like "Classic 
Rexx and C++ ooRexx
Application Programming Interfaces" with the appropriate appendixes.

---rony




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

[Oorexx-devel] Ad ooRexx pipe-samples

[Rony G. Flatscher]

 has another pipe-related patch by 
Matthé van der Lee
from December 3rd 2018, which might have been overlooked. Just in case a 
reminder.

Here is his statement: "For my own amusement, I have rewritten the pipe.rex 
sample, and included
support for multistream pipelines and for many of the pipeline stage commands 
as provided by CMS
Pipelines. I attach the source here, as well as that of the adapted demo 
usepipe.rex. Comments
welcomed." His version is attached to the above URL and can be directly 
downloaded for evaluation
and testing.

Would it be sensible to incorporate his changes?

---rony




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

[Oorexx-devel] New beta version of BSF4ooRexx available (version 641.20190203)

[Rony G. Flatscher]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from 
Sourceforge, namely from:

.


BSF4ooRexx is an ooRexx external function package that allows Rexx programs to 
exploit all Java
classes and interact with Java as if it was ooRexx! Requiring the supplied 
ooRexx package "BSF.CLS"
camouflages the strictly typed, case-sensitive programming language Java as the 
dynamically typed,
case-insensitive language Rexx, making it considerably easy to interface with 
Java.

---

Attention! This version of BSF4ooRexx does not accept abstract Java classes in
bsf.import(some_java_class) anymore!

Importing Java classes allows one to use the ooRexx new-message to create Java 
instances (the
imported Java class will be proxied as an ooRexx class and getting the class 
method new defined for
it). Clearly, abstract Java classes cannot be instantiated, hence this change! 
The error message
will point out the exact reason and a solution, namely to use 
bsf.loadClass(some_java_class)
instead, which then allows one to access the static fields and the concrete 
static methods of the
supplied Java class.

Although I have gone through all the sample code and Rexx packages coming with 
BSF4ooRexx to find
usages of bsf.importClass() with abstract Java classes and fix it, it may be 
the case that there are
samples that have gone unnoticed so far. In this case please file a bug report 
at
.

---

If after installing BSF4ooRexx you choose the menu option "BSF4ooRexx -> 
Samples" a folder/finder
window will open and display the Rexx samples. Locate the file "index.html" and 
click on it: this
will briefly describe each Rexx sample, such that you are able to quickly get 
an overview.

---

Also I would like to point out to you the latest beta versions of ooRexx 5.0 
which introduces many
valuable and helpful new features:
. Regularly 
check for new builds
there.

The quality of the current beta versions of ooRexx 5.0 is of type "release", 
includes many
interesting new features and contains many bug fixes over ooRexx 4.2.

Also please note: the BSF4ooRexx package for MacOSX already includes a fresh 
build of ooRexx 5.0
beta, revision 11636.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
 
().

Cheers,

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

[Oorexx-devel] Typos in oorexxapi.h ?

[Rony G. Flatscher]

While looking up oorexxapi.h I found the following two defines (in line # 82 
and # 85) with a
trailing "-- alias":

#define REXX_VALUE___uint64_t 27  -- aliased
#define REXX_VALUE___uintptr_t29  -- aliased

---rony



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

Re: [Oorexx-devel] Question on SysFileTree()

[Rony G. Flatscher]

On 07.02.2019 12:25, P.O. Jonsson wrote:
> Thanks for clarifying.
>
> Maybe you (or someone else) can help me with another issue: I am trying to 
> locate the build
> directory on Mac in FileUtils.cls. On the jenkins slave the build is located 
> in:
>
> //Users/jenkins/workspace/ooRexx-macOS1014-build/oorexxBuild/
>
> And in my clone installation:
>
> //Users/po/workspace/ooRexx-macOS1014-build/oorexxBuild/
>
> I was trying to locate it using SysSearchPath() but his does not work:
>
> /dir = SysSearchPath('~/workspace/ooRexx-macOS1014-build/oorexxBuild/bin', 
> "rexx")/
>
> Can you or someone else point me to a reliable way to locate the build 
> directory on Mac? I have
> tried the Unix alternatives in FileUtils.cls but they do not work.

If I understand your use case correctly, you would have a need to locate where 
"rexx[.exe]" (the
executable) that gets used is located?

If so, I do not know of a solution. If no one else has a reliable, 
multi-platform solution you could
open a RFE, e.g. that this path is supplied via the .rexxInfo class (cf. 
rexxref.pdf, 5.4.15) or the
like.

---rony


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

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

[Rony G. Flatscher]

What would you suggest/advise given your huge knowledge and experiences on so 
many different Unix
systems?

Should the test be adapted to check whether Ubuntu is the host system (e.g. "if
sysVersion()~caselessPos('Ubuntu')>0 then ...")?

Should the function work differently on Ubuntu to match the behaviour of other 
Unix systems? If so,
how could one determine/decide which behaviour should be expected/picked by 
Rexx programmers
employing them?

Should the functions behave according to the host system's behaviour, but 
document it? If so, then
maybe a means for querying the exact behaviour might become important for Rexx 
programmers to adjust
their logic accordingly (or pick a different function or use address).

How should differences among Unix versions be handled in principle?

Should maybe "PARSE SOURCE" return "UBUNTU" instead of "LINUX" to indicate that 
it behaves
differently compared to other Linuxes?

---rony



On 16.02.2019 15:53, Enrico Sorichetti via Oorexx-devel wrote:
> I started a bit earlier ( do You remember Slackware )
>
> After that I went for Red Hat
>
> And got used to the red-hat and friends terminology 
>
> I can agree on the Debian ways 
> But Ubuntu has taken things a bit too far
>
> Apart being too much much windowish for my taste ;-)
>
> This morning it took me  just 40 minutes to setup a Debian working 
> environment for ooRexx
> I tried last week with ubuntu and I stopped trying after one day 
>
> And … a couple of years ago developing with ubuntu
> Was really painful for the very bad choice they had made for the compiler and 
> the headers 
> Many configure.ac checks  had to be rewritten  because of that 
> ( I got burned by the atomic support detection )
>
>
> Cheers
> E
>
>> On 16 Feb 2019, at 15:31, Michael Lueck  wrote:
>>
>> Enrico Sorichetti via Oorexx-devel wrote:
>>> Unfortunately Ubuntu is well known also for its odd way of doing things
>>
>> haha...
>>
>> The Debian / Ubuntu way makes sense, the other distros are the odd ones! ;-)
>>
>> Seriously... I started out with Red Hat 5.2 back in probably 1999. Yuck. 
>> SuSE, Mandrake... more yuck.
>>
>> Then in 2004 my "right hand man in America" suggested I try Debian... which 
>> I had heard had a reputation of being "stick shift'ish"... and quickly 
>> connected with it.
>>
>> One of the big draws for me was that dpkg came with built-in package 
>> dependency checking whereas rpm lacked it.
>>
>> 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] "libao: a cross platform audio library", how about creating an external Rexx function library ?

[Rony G. Flatscher]

While researching a little bit about audio on Linux (after reading about the 
"portable beep
problem") et.al. I stumbled over an interesting cross-platform library named 
"libao" which seems to
have arrived a stable state.

Here various links for gaining a quick overview:

  * Homepage & overview: 
  * Documentation: 
  * API overview: 

  * Linux-from-scratch (how to install):

  * Infos about Ubuntu: 

At first sight it seems that the API is small and straight-forward.

So the idea: how about creating an external Rexx function library for libao and 
compile it for the
major operating system platforms Windows, MacOS and Linux? If possible with a 
CMakeLists.txt, such
that such a library also can serve as a role model for a) how to create 
external function library
and b) how to use CMake to make it simple to compile, link and create 
installers for the different
platforms?

Anyone who would find such an external Rexx function library useful/interesting 
and would try to
create it?

---rony


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

Re: [Oorexx-devel] "libao: a cross platform audio library", how about creating an external Rexx function library ?

[Rony G. Flatscher]

On 17.02.2019 14:03, Rick McGuire wrote:
>
> On Sun, Feb 17, 2019 at 8:00 AM Enrico Sorichetti via Oorexx-devel
>  > wrote:
>
> Already working on a simple external function skeleton,
>
> Which does nothing but … Print the arguments passed
>
> Will not take long to polish it and post it somewhere
>
> Does not use the native approach ,
>
> I was not able to find into the docs how to determine the number of 
> arguments passed
>
> From the samples looks like that the native mode functions only support a 
> fixed number of
> arguments
>
> But I would like if somebody pointed me on hoe to do it the native day
>
>
> You can also ask for all of the arguments to be passed to you in an array. 
> When used that way, no
> maximum is enforced. See the current unix rexxutil functions SysGetMessage 
> and SysGetMessageX to
> see how this works.

Maybe also interesting: , which 
is meant at allowing
C++ programmers to jump start creating external function libraries, which 
implement routines or
methods in native code.

---

It is a talk (the pdf-file) at an International Rexx Symposium (cf.
) where I tried to give a 
conceptual overview how
to create external Rexx function routines and external Rexx method routines. 
The zip archive
contains the files (sources, binaries in 32- and 64-bit) and Makefiles for 
Windows, Apple, Linux. As
you can see by looking at the Makefiles that a CMake solution (from someone in 
the know) would have
been even better for the project.

The native C++ API is documented in chapter 8 in "rexxpg.pdf" ("ooRexx 
Programming Guide").

---rony


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

Re: [Oorexx-devel] How to build external functions using cmake

[Rony G. Flatscher]

On 17.02.2019 19:09, Enrico Sorichetti via Oorexx-devel wrote:
>
> See here 
>
> git clone http://3...@bitbucket.org/3481/rxSnippets

Cloned it, skimming over it, it is electrifying!!

> Have a good time

Will take a few days, but will definitely have a good time!
:)

(This should help me to create - and perhaps understand a little bit more of - 
CMakeLists.txt for
BSF4ooRexx.cc and also for the "dbusoorexx" (ooRexx external function library 
for Linux' DBus
communication infrastructure), foregoing the Makefiles.)

>
> Tested only on Darwin 
>
> Working on the other platforms 
>
> I will keep You posted

Please do so! Having a minimal CMakeLists.txt for producing external Rexx 
function libraries for the
major platforms is really a great boon!

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

[Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

[Rony G. Flatscher]

Tried it on Windows:

G:\oorexx.tmp\enrico\win32>call "e:\Programme\Microsoft Visual Studio 
14.0\VC\vcvarsall.bat" x86
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE)
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian

--
-- configuration summary for project 'rxSnippets'
--
--   version string .. : 1.0.0
--   build ... : 0
--   revision  : Final
--   RCS . :  -
--
--   requires libraries .. : rexx;rexxapi
-- found . : rexx -
-- : rexxapi -
--
--   build type .. : Debug
--   word size ... : 32
--   platform  : LITTLE ENDIAN
--   install prefix .. : C:/Program Files (x86)/dummy
--
--   CMake version ... : 3.12.0-rc3
--   CMake modules path .. : G:/oorexx.tmp/enrico/rxSnippets
-- : 
G:/oorexx.tmp/enrico/rxSnippets/cmake/Modules
--
--
--   generator ... : NMake Makefiles
--   generator program ... : nmake -
--
--   enabled languages ... : C;CXX;RC
--
--   C   compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   C   compiler ID . : MSVC
--   C   compiler VERSION  : 19.0.24215.1
--   C   compiler flags .. : -g -DDEBUG
--
--   CXX compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   CXX compiler ID . : MSVC
--   CXX compiler VERSION  : 19.0.24215.1
--   CXX compiler flags .. : -g -DDEBUG
--
--   RC  compiler  : C:/Program Files (x86)/Windows 
Kits/8.1/bin/x86/rc.exe
--   RC  compiler ID . :
--   RC  compiler VERSION  :
--   RC  compiler flags .. : /D_DEBUG
--
--   compile definitions . : VERSION_STRING="1.0.0"
--
--   include directories . : G:/oorexx.tmp/enrico/win32
-- : 
e:/DropBox/Dropbox/xfer/orx/beta/sandbox_ooRexx/standalone/ooRexx32win/include
-- : 
G:/oorexx.tmp/enrico/rxSnippets/src/include
--
--   user options  :
--
-- end of configuration summary
--

-- Configuring done
-- Generating done
-- Build files have been written to: G:/oorexx.tmp/enrico/win32

G:\oorexx.tmp\enrico\win32>

G:\oorexx.tmp\enrico\win32>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target rxClassic
[ 25%] Building C object CMakeFiles/rxClassic.dir/src/rxClassic.c.obj
cl : Command line warning D9002 : ignoring unknown option '-g'
cl : Command line warning D9002 : ignoring unknown option '-g'
rxClassic.c
G:\oorexx.tmp\enrico\rxSnippets\src\rxClassic.c(12): fatal error C1083: 
Cannot open include file: 'rexx.h': No such file or directory
NMAKE : fatal error U1077: 'E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe' : return 
code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

ooRexx on Windows has the *.h files in "api" instead of "include".

Adjusted it by creat

Re: [Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

[Rony G. Flatscher]

A remark: forgot to delete the lines:

 cl : Command line warning D9002 : ignoring unknown option '-g'

Those warnings were issued, because I used "cmake -G ...", removing the "-G" 
(from a very, very,
very old note) removed the warning in my second runs. So please ignore them in 
my previous posting,
there are not there anymore.

---rony

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

Re: [Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

[Rony G. Flatscher]

On 18.02.2019 17:10, Rony G. Flatscher wrote:
> A remark: forgot to delete the lines:
>  cl : Command line warning D9002 : ignoring unknown option '-g'
>
> Those warnings were issued, because I used "cmake -G ...", removing the "-G" 
> (from a very, very,
> very old note) removed the warning in my second runs. So please ignore them 
> in my previous
> posting, there are not there anymore.
>
Rechecking. CMake: the "-G" switch is necessary. Doing a fresh run after 
removing the previous win32
directory does not show the above warnings anymore:

G:\oorexx.tmp\enrico\win32>cmake -G "NMake Makefiles" 
-DCMAKE_BUILD_TYPE=RELEASE -DOOREXX_INSTALL_PREFIX=%OOREXX_HOME_32% 
..\rxSnippets
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE)
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian

--
-- configuration summary for project 'rxSnippets'
--
--   version string .. : 1.0.0
--   build ... : 0
--   revision  : Final
--   RCS . :  -
--
--   requires libraries .. : rexx;rexxapi
-- found . : rexx -
-- : rexxapi -
--
--   build type .. : RELEASE
--   word size ... : 32
--   platform  : LITTLE ENDIAN
--   install prefix .. : C:/Program Files (x86)/dummy
--
--   CMake version ... : 3.12.0-rc3
--   CMake modules path .. : G:/oorexx.tmp/enrico/rxSnippets
-- : 
G:/oorexx.tmp/enrico/rxSnippets/cmake/Modules
--
--
--   generator ... : NMake Makefiles
--   generator program ... : nmake -
--
--   enabled languages ... : C;CXX;RC
--
--   C   compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   C   compiler ID . : MSVC
--   C   compiler VERSION  : 19.0.24215.1
--   C   compiler flags .. :-O2 -DNDEBUG
--
--   CXX compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   CXX compiler ID . : MSVC
--   CXX compiler VERSION  : 19.0.24215.1
--   CXX compiler flags .. :   -O2  -DNDEBUG
--
--   RC  compiler  : C:/Program Files (x86)/Windows 
Kits/8.1/bin/x86/rc.exe
--   RC  compiler ID . :
--   RC  compiler VERSION  :
--   RC  compiler flags .. :
--
--   compile definitions . : VERSION_STRING="1.0.0"
--
--   include directories . : G:/oorexx.tmp/enrico/win32
-- : 
e:/DropBox/Dropbox/xfer/orx/beta/sandbox_ooRexx/standalone/ooRexx32win/include
-- : 
G:/oorexx.tmp/enrico/rxSnippets/src/include
--
--   user options  :
--
-- end of configuration summary
--

-- Configuring done
-- Generating done
-- Build files have been written to: G:/oorexx.tmp/enrico/win32

G:\oorexx.tmp\enrico\win32>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target rxClassic
[ 25%] Building C object CMakeFiles/rxClassic.dir/src/rxClassic.c.obj
cl : Command line warning D9002 : ignoring unknown option '-g'
rxClassic.c

Re: [Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

[Rony G. Flatscher]

On 18.02.2019 17:22, Enrico Sorichetti via Oorexx-devel wrote:
> Dear Rony 
> I am very happy that it was useful 
>
> Looking at the status of variable for complex cmakelists 
> ( and I wrote a couple of them )
> Is usually the only way to debug cmakelists errors 
>
> The vdump module was the first one I wrote a long time ago
> To get a better knowledge of the cmake ways
>
> Using cmake -G should have caused different errors IIRC
>
> It tells to cmake which generator is being used, 
> ( I usually go with cmake -G Ninja … … … )
> So I do not see why it should meddle with the compiler options
>
> I will push an update to include the proper defaults for the  c / c++  
> compilers
> ( obviously the msvc stuff will empty )
>
> Just look at the README, I posted two different CMakeLists 
> A minimal and a platinum , the minimal does al that is needed with no frills

Hmm, just see probably the "minimal" which is ideal for a newbie to CMake like 
myself! :)

Researching about the exported symbols problem on Windows I ran around the 
following switch
"-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE", which solves the problem for the 
classic library problem.
Now both Rexx scripts work:

cmake -G "NMake Makefiles" -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE 
-DOOREXX_INSTALL_PREFIX=%OOREXX_HOME_32% ..\rxSnippets
...
nmake
...
G:\oorexx.tmp\enrico\win32>rexx rxClassic
rxClassicVersion at line 84' '1.0.0'

1.0.0
rxClassicWorker at line 103'
  Argc 0

rxClassicWorker at line 103'
  Argc 1
  Argv 0  'A'

rxClassicWorker at line 103'
  Argc 2
  Argv 0  'A'
  Argv 1  'B'


G:\oorexx.tmp\enrico\win32>rexx rxClassic
rxClassicVersion at line 84' '1.0.0'

1.0.0
rxClassicWorker at line 103'
  Argc 0

rxClassicWorker at line 103'
  Argc 1
  Argv 0  'A'

rxClassicWorker at line 103'
  Argc 2
  Argv 0  'A'
  Argv 1  'B'


G:\oorexx.tmp\enrico\win32>

This is really just *great*, thank you very much indeed!

---rony


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

[Oorexx-devel] Roundup on Windows (Re: Attempt on Windows (Re: How to build external functions using cmake

[Rony G. Flatscher]

Tested on 64-bit ooRexx as well and works like a charm, kudos to Enrico!

---

So a little roundup:

  * Enrico's CMake sample works on Windows as well, tested with both the 32 and 
64 bit Microsoft
compiler!!

  * Windows specifics:

  o the ooRexx installation copies the *.h and *.lib files to a directory 
named "api"

  + suggestion: create an "include" (for the *.h files) and a "lib" 
(for the *lib files)
directory on Windows instead of the "api" directory

  o the classic Rexx libraries need the loader function exported, pre 
ooRexx 5 interpreters need
the RexxGetPackage function exported: solution, needing at least CMake 
version 3.3: add the
switch "-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE"

  + would suggest to use that switch for both, the classic and native 
libraries to allow
them to be usable by earlier versions of

  o to compile the 32- and the 64-bit versions I used the 
"USB"-installation versions of ooRexx.
Now that it has become possible (kudos to Rick!) to run 32- and 64-bit 
ooRexx in parallel on
the same machine, this excercise has become very, very easy/efficient, 
a real great and
important boon!

This will allow me to experiment with the creation of the BSF4ooRexx and 
dbusoorexx libraries for
all platforms including Windows, which may become a breeze!

---rony

P.S.: Still, this will take some time as the day-job work-load increases due to 
the beginning of the
summer semester around here.


On 18.02.2019 17:39, Rony G. Flatscher wrote:
> On 18.02.2019 17:22, Enrico Sorichetti via Oorexx-devel wrote:
>> Dear Rony 
>> I am very happy that it was useful 
>>
>> Looking at the status of variable for complex cmakelists 
>> ( and I wrote a couple of them )
>> Is usually the only way to debug cmakelists errors 
>>
>> The vdump module was the first one I wrote a long time ago
>> To get a better knowledge of the cmake ways
>>
>> Using cmake -G should have caused different errors IIRC
>>
>> It tells to cmake which generator is being used, 
>> ( I usually go with cmake -G Ninja … … … )
>> So I do not see why it should meddle with the compiler options
>>
>> I will push an update to include the proper defaults for the  c / c++  
>> compilers
>> ( obviously the msvc stuff will empty )
>>
>> Just look at the README, I posted two different CMakeLists 
>> A minimal and a platinum , the minimal does al that is needed with no frills
>
> Hmm, just see probably the "minimal" which is ideal for a newbie to CMake 
> like myself! :)
>
> Researching about the exported symbols problem on Windows I ran around the 
> following switch
> "-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE", which solves the problem for the 
> classic library
> problem. Now both Rexx scripts work:
>
> cmake -G "NMake Makefiles" -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE 
> -DOOREXX_INSTALL_PREFIX=%OOREXX_HOME_32% ..\rxSnippets
> ...
> nmake
> ...
> G:\oorexx.tmp\enrico\win32>rexx rxClassic
> rxClassicVersion at line 84' '1.0.0'
>
> 1.0.0
> rxClassicWorker at line 103'
>   Argc 0
>
> rxClassicWorker at line 103'
>   Argc 1
>   Argv 0  'A'
>
> rxClassicWorker at line 103'
>   Argc 2
>   Argv 0  'A'
>   Argv 1  'B'
>
>
> G:\oorexx.tmp\enrico\win32>rexx rxClassic
> rxClassicVersion at line 84' '1.0.0'
>
> 1.0.0
> rxClassicWorker at line 103'
>   Argc 0
>
> rxClassicWorker at line 103'
>   Argc 1
>   Argv 0  'A'
>
> rxClassicWorker at line 103'
>   Argc 2
>   Argv 0  'A'
>   Argv 1  'B'
>
>
> G:\oorexx.tmp\enrico\win32>
>
> This is really just *great*, thank you very much indeed!
>
> ---rony
>

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

[Oorexx-devel] Ad loop counter on do...over ?

[Rony G. Flatscher]

Quite often, when using "do...over" there is a need for having a counter that 
increases
automatically on each loop.

Currently one needs to use a separate variable that gets explicitly increased 
within the loop, e.g.:

i=1
do idx over dir
say "entry #" i": idx="idx "dir[idx]="dir
i=i+1
end

It would be great if one could use optionally a counter in the do...over case 
as well, something like:

do idx over dir counter i
   say "entry #" i": idx="idx "dir[idx]="dir
end

where "counter" would be a subkeyword defining a loop variable which starts out 
with "1" and gets
increased by one after each loop.

---rony

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

Re: [Oorexx-devel] Ad loop counter on do...over ?

[Rony G Flatscher]

Erich,

yes. It is about the beed to number the output while doing a do...over 
beginning wirh the number 1 (a numbered list).

Cheers

—-rony

Rony G. Flatscher (mobil/e)

> Am 19.02.2019 um 21:09 schrieb Erich Steinböck :
> 
> Rony,
> are you aware of the new `DO WITH INDEX i ITEM j OVER collection` syntax?
> ___
> 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 loop counter on do...over ?

[Rony G Flatscher]

Erich:

How would you number a do with  over a table where the indices are not numbers, 
or over a set or bag where the items are not numbers, etc.?

—-rony

Rony G. Flatscher (mobil/e)

> Am 19.02.2019 um 23:15 schrieb Erich Steinböck :
> 
> That's exactly what you can do using the DO WITH syntax
> ___
> 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 loop counter on do...over ?

[Rony G. Flatscher]

On 20.02.2019 07:06, Erich Steinböck wrote:
>
> number a do with  over a table where the indices are not numbers, or over 
> a set or bag
>
>  
> Use
> do with index i item j over c~allItems

This is *not* the same collection as "c", but an array of all of the items in 
the "c" MapCollection!
The important information of which index is associated with which item gets 
lost.

The "do with...over" is meant to iterate over a supplier which is especially 
important for
non-orderable collections. 

In the case of Map/SetCollections the index object is as important as the item 
object, such that it
cannot be forgone. (The supplier is the only means for Map/SetCollections to 
get all
index-item-pairs, cf. e.g. for .Relation collections.)

---

One may be inclined to think that "do with...over" is fine for Orderable 
collections as array
collections demonstrate:

a=("a","z","b")
say a~class":"
do with index i item o over a
say "#" i":" pp(o)
end
say

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l
say "#" i":" pp(o)
end
say

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

G:\test\oorexx\201902doover>test_do_over.rex
The Array class:
# 1: [a]
# 2: [z]
# 3: [b]

The List class:
# 0: [a]
# 1: [y]
# 2: [b]

However the index value starting out with 0 in the List collection case! The 
expected output in the
case of the List class probably would have been:

The List class:
# 1: [a]
# 2: [y]
# 3: [b]

However, as one can see the List does not have a numeric index that start with 
1, like it is the
case with Array collections.

In the case of an Orderable collection only the "allitems" array will allow for 
using the index for
numbering, starting with one (because an array always starts with 1):

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l~allItems
say "#" i":" pp(o)
end
say

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

G:\test\oorexx\201902doover>test_do_over.rex
The List class:
# 1: [a]
# 2: [y]
# 3: [b]

=

Using allItems or allIndexes would not help in the case of Map/SetCollections, 
where the index
object is as important as the item object.

Example with a Table collection:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
say t~class":"

do with index i item o over t
say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over t~allItems
say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over t~allIndexes
say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over t
say "#" i":" pp(idx) "->" pp(o)
i=i+1
end
say

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

Yielding:

The Table class:
# berta: [female]
# caesar: [male]
# adam: [male]

--- now with t~allItems:
# 1: [female]
# 2: [male]
# 3: [male]

--- now with t~allIndexes:
# 1: [berta]
# 2: [caesar]
# 3: [adam]

--- the desired output:
# 1: [berta] -> [female]
# 2: [caesar] -> [male]
# 3: [adam] -> [male]



Example of a relation (index is a human, item a child of that human; a human 
may have more than one
child):

r=.relation~of(("adam","henry"), ("adam","julia"), ("berta","julia"), 
("caesar","denise"), ("caesar","mark") )
say r~class":"
do with index i item o over r
say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over r~allItems
say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over r~allIndexes
say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over r
say "#" i":" pp(idx) "->" pp(o)
i=i+1
end
say

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

Yielding:

The Relation class:
# caesar: [mark]
# caesar: [denise]
# berta: [julia]
# adam: [julia]
# adam: [henry]

--- now with t~allItems:
# 1: [mark]
# 2: [denise]
# 3: [julia]
# 4: [julia]
# 5: [henry]

--- now with t~allIndexes:
# 1: [caesar]
# 2: [caesar]
# 3: [berta]
# 4: [adam]
# 5: [adam]

--- the desired output:
# 1: [caesar] -> [mark]
# 2: [caesar] -> [denise]
# 3: [berta] -> [julia]
# 4: [adam] -> [julia]
# 5: [adam] -> [henry]

Having a "counter" subkeyword would allow numbering without the need to know 
the kind of collection
that is being iterated. E.g.

List exampl

Re: [Oorexx-devel] Ad loop counter on do...over ?

[Rony G. Flatscher]

Just opened a RFE <https://sourceforge.net/p/oorexx/feature-requests/743/> 
after studying the
current DO-keyword syntax.

---rony


On 20.02.2019 16:11, Gil Barmwater wrote:
>
> Just another couple of points:
>
> 1) the ~supplier message is not needed;  ooRexx will "supply" it
>
> 2) in the case of relation collections, the [] method will return the first 
> item with the
> specified index so relation collections with duplicate indices would need 
> different handling
> (thanks Rony for pointing that out to me off-list)
>
> Gil
>
> On 2/20/2019 9:18 AM, Gil Barmwater wrote:
>>
>> I think we are on the right track but it needs a little tweaking:
>>
>> t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
>> sayt~class":"
>>
>> dowithindexiitemoovert
>> say"#"i":"pp(o)
>> end
>> say
>>
>> say"--- the desired output:"
>> i=1
>> dowithindexidxitemoovert
>> say"#"i":"pp(idx) "->"pp(o)
>> i=i+1
>> end
>> say
>>
>> say"--- how about this?"
>> dowithindexiitemidxovert~allindexes~supplier
>> say"#"i":"pp(idx) "->"pp(t[idx])
>> end
>> say
>>
>> ::routinepp
>> return"["arg(1)"]"
>>
>> Gil B
>>
>> ---
>>
>> On 2/20/2019 8:06 AM, Rony G. Flatscher wrote:
>>> On 20.02.2019 07:06, Erich Steinböck wrote:
>>>>
>>>> number a do with  over a table where the indices are not numbers, or 
>>>> over a set or bag
>>>>
>>>>  
>>>> Use
>>>> do with index i item j over c~allItems
>>>
>>> This is *not* the same collection as "c", but an array of all of the items 
>>> in the "c"
>>> MapCollection! The important information of which index is associated with 
>>> which item gets lost.
>>>
>>> The "do with...over" is meant to iterate over a supplier which is 
>>> especially important for
>>> non-orderable collections. 
>>>
>>> In the case of Map/SetCollections the index object is as important as the 
>>> item object, such that
>>> it cannot be forgone. (The supplier is the only means for 
>>> Map/SetCollections to get all
>>> index-item-pairs, cf. e.g. for .Relation collections.)
>>>
>>> ---
>>>
>>> One may be inclined to think that "do with...over" is fine for Orderable 
>>> collections as array
>>> collections demonstrate:
>>>
>>> a=("a","z","b")
>>> say a~class":"
>>> do with index i item o over a
>>> say "#" i":" pp(o)
>>> end
>>> say
>>>
>>> l=.list~of("a","y","b")
>>> say l~class":"
>>> do with index i item o over l
>>> say "#" i":" pp(o)
>>> end
>>> say
>>>
>>> ::routine pp
>>>   return "["arg(1)"]"
>>> 
>>> ---
>>>
>>> G:\test\oorexx\201902doover>test_do_over.rex
>>> The Array class:
>>> # 1: [a]
>>> # 2: [z]
>>> # 3: [b]
>>>
>>> The List class:
>>> # 0: [a]
>>> # 1: [y]
>>> # 2: [b]
>>>
>>> However the index value starting out with 0 in the List collection case! 
>>> The expected output in
>>> the case of the List class probably would have been:
>>>
>>> The List class:
>>> # 1: [a]
>>> # 2: [y]
>>> # 3: [b]
>>>
>>> However, as one can see the List does not have a numeric index that start 
>>> with 1, like it is the
>>> case with Array collections.
>>>
>>> In the case of an Orderable collection only the "allitems" array will allow 
>>> for using the index
>>> for numbering, starting with one (because an array always starts with 1):
>>>
>>> l=.list~of("a","y","b")
>>> say l~class":"
>

[Oorexx-devel] A RFE for optionally allowing collection objects where stems get used in the SysUtil functions

[Rony G. Flatscher]

While working on a little utility to anonymize pipermail mbox archives from 
mailman, I have been
using sysFileTree(). In the light of the recent work on the SysUtil-functions 
and on SysFileTree()
the idea came up to optionally allow ooRexx collection objects as an option 
wherever currently a
stem is being used. Therefore the RFE at 
.

Using "do...over" over a stem would not work as the entry with the index "0" 
would be iterated as
well. However, when using a collection object instead, do...over would work 
(which would be simpler
IMHO).

---rony



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

[Oorexx-devel] An example of taking advantage of the new variable reference feature

[Rony G. Flatscher]

While writing a little script to rewrite mailman mbox archive files to 
anonymize e-mail addresses,
the routine generating a pseudo-e-mail address would increase a counter each 
time.

While developing it a need popped up for a switch when invoking the script that 
allows one to
determine whether the counter should restart at 1 for every new mbox archive 
file or whether to use
a global counter starting at 1. This got realized with a Rexx class defining a 
class attribute
"counter" ("global counter") set to 1 in the class constructor (method 
"::method init class"), and
an instance attribute "counter" ("instance counter") set to 1 in the instance 
constructor (method
"::method init").

Using an array with two elements storing the variable references to the class 
and to the instance
attribute (changed each time a new instance gets created) I was able to solve 
this problem in a
quite easy manner: when invoking the routine that creates the pseudo-e-mail it 
will receive a
variable reference to the class or instance "counter" attribute depending on 
the switch. The routine
itself will only fetch the variable reference and increase the attribute 
counter directly without
without knowing whether it is actually the global or the instance counter!

Thought it might be interesting to see the new ooRexx 5.0 feature "variable 
reference" applied in a
real world scenario!

---rony

P.S.: BTW, the script uses the new ooRexx 5.0 ".context~package~local" 
environment to store the
supplied switch and the array with the variable references (as well as the 
current settings of all
possible options), making it easy to refer to all of them via their environment 
symbol (name of the
entry prepended with a dot '.') in the Rexx script.




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