Re: [Oorexx-devel] Question ad CMake and MacOS ("rxapi" related)

[J Leslie Turriff]

On 2018-11-26 04:30:15 P.O. Jonsson wrote:
> Dear all,
>
> I can confirm that Enricos installation runs (blazingly fast!) from a USB
> stick on a MAC without any elevated user rights whatsoever. I have run the
> complete test case suite (except the API) and they all work, see below. The
> USB installation (running from a not-so-fast USB2 stick) performs just as
> fast as my own installation in /opt on a SSD disk! WOW!
If this works from a USB stick, cannot the build to USB be adapted to 
build 
into /usr/local?

Leslie
>
> Enricos installation also come with some sugar that I would love to have in
> the official builds, the indication of the build revision, see below. When
> I build some days later than the SVN Update I get the current date (but a
> build from some days ago). Build revision would help when checking
> installers against eachother (BSF4ooRexx versus standalone for instance).
>
> Also I can confirm that rexx AND rxapi run as user „po“ in the USB build, 
> in a normal installation rxapi run as "root".
>
> rxapi seems to start only once the rexx process launches (intended I guess)
> and I have to use kill to stop rxapi before ejecting.
>
> The first time after I had killed rxapi and reinstalled my own installation
> I had a glitch:
>
> Searching for test containers.Segmentation fault: 11
>
> But redoing the command it worked and the entire test suite ran without
> problem, so not sure what happened. Maybe Enrico gets some idea? How should
> one stop running the USB build in the most unintrusive way?
>
> This is a leap forward!
>
> Last login: Mon Nov 26 10:34:35 on ttys001
>
> cd /Volumes/4GB
>
> source ooRexx_vars
>
> rexx -v
> Open Object Rexx Version 5.0.0 Rev:11523
> Build date: Nov 22 2018
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2018 Rexx Language Association. All rights reserved.
> This program and the accompanying materials are made available under the
> terms of the Common Public License v1.0 which accompanies this distribution
> or at http://www.oorexx.org/license.html
>
> rexx rexxcps
>
> - REXXCPS 2.1 -- Measuring REXX clauses/second -
>  REXX version is: REXX-ooRexx_5.0.0(MT)_64-bit 6.05 22 Nov 2018
>System is: DARWIN
>Averaging: 100 measures of 30 iterations
>
> Total (full DO): 0.00459054 secs (average of 100 measures of 30 iterations)
> Time for one iteration (1000 clauses) was: 0.000153018 seconds
>
>  Performance: 6535179 REXX clauses per second
>
> ./pathfind 1417
>
> proc 1417: /Volumes/4GB/bin/rxapi
>
> Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
>
> ooTest Framework - Automated Test of the ooRexx Interpreter
>
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 22 Nov 2018
> OS Name:DARWIN
> SysVersion: Darwin Darwin Kernel Version 16.7.0: Wed Oct 10
> 20:06:00 PDT 2018; root:xnu-3789.73.24~1/RELEASE_X86_64.16.7.0
>
> Tests ran:  22398
> Assertions: 375164
> Failures:   0
> Errors: 0
>
> File search:00:00:01.603582
> Suite construction: 00:00:01.395994
> Test execution: 00:03:05.549436
> Total time: 00:03:09.001582
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
> > Am 25.11.2018 um 18:26 schrieb Enrico Sorichetti via Oorexx-devel 
:
> >> I have just started work on a solution that no longer requires a single
> >> daemon for the platform but rather use a single process per Rexx user.
> >> Right now, I'm working on refactoring the code a bit to make it easier
> >> to plug in different management schemes, and the next step will be to
> >> convert Windows, which is the version that will require the most new
> >> code, then will address the *ix variants after that. I'll need so
> >> assistance from somebody on that step as I don't have a Linux setup any
> >> more. When this is all done, all of this daemon stuff, including the
> >> writing of the PID files should go away and things will get a lot
> >> simpler.
> >
> > As already told the only reason rxapi needs to be run as sudo is that it
> > writes to /var/run
> >
> > I have already - in my sandbox - modified rxapi
> > To get the OOREXX_PIDFILE environment variable and use it
> > I use export OOREXX_PIDFILE=/tmp/ooRexx.pid
> >
> > And since SysLocalAPIManager starts the rxapi process
> > Nothing has to be done
> >
> > I have been running for a few days with this setup and everything works
> > as a charm
> >
> > I run successfully the test suite ( the native api section needs a few
> > adjustments ) rexx testOORexx -s -X native_api with 0 errors
> >
> > I was able also  to build a fully relocatable binary that can run from a
> > usb stick with just a couple of exports The new PATH for the bin
> > directory of rexx, the NLSPATH for the rexx.cat and the OOREXX_PIDFILE 
> > for the rxapi thing
> >
> > I have sent my binaries to P.O and Rony to have a confirmation of my
> > findings As soon as they confirm 

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

[P.O. Jonsson]

I agree with Rony that a build number in the rexx -v would be very useful. I 
also have a number of systems and since the build is not linked to the day you 
actually compiled (that may be (much) later ) you are never really sure. Also I 
tried some times to make a standalone build to compare to the BSF4ooRexx 
installer, same problem, after a week or so you did not really remember.

Enrico already posted a test where this feature was implemented I think? Would 
be great if this could be picked up on.

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



> Am 01.12.2018 um 19:15 schrieb 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

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

[P.O. Jonsson]

Dear Enrico,

The five „Boings“ come from the BIF BEEP.testGroup; on Windows you can play a 
cheesy little tune using the function beep(frequency, duration). I have used 
that to play „kings Quest“ on exit of a script (while on Windows, using IBM 
Rexx, in Neolithic times). On Mac it goes „Boing“ instead. Sorry I should have 
reported it when I remembered. This is not an error and not related to the 
problems in the macrospace.testGroup. I have commented out those tests failing 
waiting for a solution (the report that I think sparked this activity).

Thanks to all for going after this, it seems close to a very good non-sudo 
solution.

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



> Am 01.12.2018 um 18:56 schrieb Enrico Sorichetti via Oorexx-devel 
> :
> 
> IMO for the macro space thing things are a bit murky,
> Running
> 
> [enrico@enrico-imac ooRexx.testsuite]$rexx testOORexx.rex -s -X native_api
> 
> I get the five BOINGs but 
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 1 Dec 2018
> OS Name:DARWIN
> SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 
> PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0
> 
> Tests ran:  22398
> Assertions: 375209
> Failures:   0
> Errors: 0
> 
> File search:00:00:01.192486
> Suite construction: 00:00:01.002010
> Test execution: 00:02:58.055176
> Total time: 00:03:00.589207
>  
> 
> The test suite does not report any errors 
> 
> The ooRexx build was  run on 
> macOS High Sierra with Xcode 10.1
> 
> After that I copied the relevant directories 
> To my other systems running
> macOS El Capitan
> macOS Mojave 
> 
> And the results were exactly the same 
> 
> Cheers
> E
> 
> 
>  
> 
>> On 1 Dec 2018, at 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 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 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] Ad installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Erich Steinböck]

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.

On Sat, Dec 1, 2018 at 7:04 PM Rick McGuire  wrote:

> You might want to try again with the latest rev. Also, what happens if you
> run the full test suite a second time (vs. running just the one test
> group).
>
> Rick
>
> On Sat, Dec 1, 2018 at 12:50 PM 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 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 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.

[Rick McGuire]

You might want to try again with the latest rev. Also, what happens if you
run the full test suite a second time (vs. running just the one test
group).

Rick

On Sat, Dec 1, 2018 at 12:50 PM 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 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

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

[Enrico Sorichetti via Oorexx-devel]

After the first failure 
Running 

rexx testOORexx.rex -f rxQueue.testGroup


Did not report any error 

E



> On 1 Dec 2018, at 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 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.

[Enrico Sorichetti via Oorexx-devel]

IMO for the macro space thing things are a bit murky,
Running

[enrico@enrico-imac ooRexx.testsuite]$rexx testOORexx.rex -s -X native_api

I get the five BOINGs but 

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 1 Dec 2018
OS Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 
PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0

Tests ran:  22398
Assertions: 375209
Failures:   0
Errors: 0

File search:00:00:01.192486
Suite construction: 00:00:01.002010
Test execution: 00:02:58.055176
Total time: 00:03:00.589207
 

The test suite does not report any errors 

The ooRexx build was  run on 
macOS High Sierra with Xcode 10.1

After that I copied the relevant directories 
To my other systems running
macOS El Capitan
macOS Mojave 

And the results were exactly the same 

Cheers
E


 

> On 1 Dec 2018, at 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 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]

Sorry, was too fast: .

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

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.

[Rick McGuire]

Does the Mac not set the $XDG_RUNTIME_DIR environment variable?

On Sat, Dec 1, 2018 at 12:33 PM 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 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 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.

[Enrico Sorichetti via Oorexx-devel]

There are still a few things to review 

On macOS the first REXX invocation might fail depending on the rexx facilities 
used by the script 

My steps to reproduce the error 

Kill the rxapi instance 
Remove in the home dir the .ooRexx thingies 
Reset things to REXX never run before 

Run the test suite 
Got some failures 
Rerun the test suite for the rexx group involved 
SUCCESS

Here is the log 

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 1 Dec 2018
OS Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 
PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0

Tests ran:  22398
Assertions: 375189
Failures:   4
Errors: 0

[failure] [20181201 17:55:24.490826]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_CURRENT_DIR_FILTER
  Class:  rxQueue.testGroup
  File:   .../enrico/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   88
  Failed: assertSame
Expected: [[1], identityHash="-4521641281"]
Actual:   [[0], identityHash="-4521607153"]

[failure] [20181201 17:55:24.509583]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_MULTI_LINES
  Class:  rxQueue.testGroup
  File:   .../enrico/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   128
  Failed: assertSame
Expected: [[5], identityHash="-4522542041"]
Actual:   [[0], identityHash="-4521607153"]

[failure] [20181201 17:55:24.539363]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_RXQUEUE_MAXIMUM_LINE_LENGTH
  Class:  rxQueue.testGroup
  File:   .../enrico/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   195
  Failed: assertEquals
Expected: [[2], identityHash="-4521685217"]
Actual:   [[0], identityHash="-4521607153"]

[failure] [20181201 17:55:24.558186]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_STDERR_TO_RXQUEUE
  Class:  rxQueue.testGroup
  File:   .../enrico/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   168
  Failed: assertSame
Expected: [[4], identityHash="-4521994217"]
Actual:   [[0], identityHash="-4521607153"]

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 1 Dec 2018
OS Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 
PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0

Tests ran:  22398
Assertions: 375189
Failures:   4
Errors: 0

File search:00:00:01.264237
Suite construction: 00:00:01.044386
Test execution: 00:02:59.105133
Total time: 00:03:01.654245

[enrico@enrico-imac ooRexx.testsuite]$rexx testOORexx.rex -f rxQueue.testGroup
Searching for test containers..
Executing automated test suite..

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 1 Dec 2018
OS Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 
PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0

Tests ran:  7
Assertions: 22
Failures:   0
Errors: 0

File search:00:00:00.016375
Suite construction: 00:00:00.000535
Test execution: 00:00:00.109437
Total time: 00:00:01.003811



Other simpler rexx scripts did not fail 

e

___
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 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 > > 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 > > 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.
>> 
>> ):
>>
>> 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.
>> 

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

[Enrico Sorichetti via Oorexx-devel]

There are some typos to fix ..
Unlink instead of online 
PATH_MAX instead of MAX_PATH
lockFd instead of lockfd

E


> On 1 Dec 2018, at 17:24, Rick McGuire  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  > 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. 
>  
> ):
> 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 
> 
> ___
> Oorexx-devel mailing 

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] Time for the *ix users to pitch in.

[Rick McGuire]

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 <
>>> erich.steinbo...@gmail.com> 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.


 On Linux, rxapi can be started a second time, with both of them
 continuing to listenForConnections()
 The reason is, as you suspected, with unlink, which returns 0 although
 the first rxapi still has this socket open.  The docs seem to confirm
 this.  https://linux.die.net/man/2/unlink "If the name referred to a
 socket, fifo or device the name for it is removed but processes which have
 the object open may continue to use it."

>>> ___
> 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 installation on Linux and MacOS ... (Re: Time for the *ix users to pitch in.

[Rick McGuire]

Thought I had caught all of those. Just committed a fix.

Rick

On Sat, Dec 1, 2018 at 11:06 AM Rony G. Flatscher 
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.
> 
> ):
>
> 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
>
___
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.

[Erich Steinböck]

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 <
>> erich.steinbo...@gmail.com> 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.
>>>
>>>
>>> On Linux, rxapi can be started a second time, with both of them
>>> continuing to listenForConnections()
>>> The reason is, as you suspected, with unlink, which returns 0 although
>>> the first rxapi still has this socket open.  The docs seem to confirm
>>> this.  https://linux.die.net/man/2/unlink "If the name referred to a
>>> socket, fifo or device the name for it is removed but processes which have
>>> the object open may continue to use it."
>>>
>>
___
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.

[Erich Steinböck]

>
> 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.
>>
>>
>> On Linux, rxapi can be started a second time, with both of them
>> continuing to listenForConnections()
>> The reason is, as you suspected, with unlink, which returns 0 although
>> the first rxapi still has this socket open.  The docs seem to confirm
>> this.  https://linux.die.net/man/2/unlink "If the name referred to a
>> socket, fifo or device the name for it is removed but processes which have
>> the object open may continue to use it."
>>
>
___
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.

[Rick McGuire]

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.
>
>
> On Linux, rxapi can be started a second time, with both of them continuing
> to listenForConnections()
> The reason is, as you suspected, with unlink, which returns 0 although the
> first rxapi still has this socket open.  The docs seem to confirm this.
> https://linux.die.net/man/2/unlink "If the name referred to a socket,
> fifo or device the name for it is removed but processes which have the
> object open may continue to use it."
> ___
> 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] Time for the *ix users to pitch in.

[Rick McGuire]

Rats. Looks like there is still a need for a .pid file. Fortunately, we can
store it in the same location, so there are still no privileges required.
The code can pretty much be copied from the old version.

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.
>
>
> On Linux, rxapi can be started a second time, with both of them continuing
> to listenForConnections()
> The reason is, as you suspected, with unlink, which returns 0 although the
> first rxapi still has this socket open.  The docs seem to confirm this.
> https://linux.die.net/man/2/unlink "If the name referred to a socket,
> fifo or device the name for it is removed but processes which have the
> object open may continue to use it."
> ___
> 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] Time for the *ix users to pitch in.

[Erich Steinböck]

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


On Linux, rxapi can be started a second time, with both of them continuing
to listenForConnections()
The reason is, as you suspected, with unlink, which returns 0 although the
first rxapi still has this socket open.  The docs seem to confirm this.
https://linux.die.net/man/2/unlink "If the name referred to a socket, fifo
or device the name for it is removed but processes which have the object
open may continue to use it."
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel