Re: [Oorexx-devel] A simple benchmark result of the new GC code.

[Enrico Sorichetti via Oorexx-devel]

> I notice that below code now just ends without any indication on Windows and 
> will get automatically killed on Ubuntu after about 7 mio iterations (this is 
> on 64-bit builds on some specific machines; you might need to tweak n 
> depending on your system/memory configuration).
> … … ...

runs OK on apple High Sierra

then I decided to raise the bar 
and tried with i = 1
the system activity monitor gave for the rexx process 
a virtual storage utilisation of 49.92 GB
and the memory pressure after a while was at the upper limit
with a few intervals in the red zone
but the thing ended successfully  

cheers
enrico


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A simple benchmark result of the new GC code.

[Enrico Sorichetti via Oorexx-devel]

here are my results ( slightly modified the script )

[enrico@enrico-mbp oorexx.tests]$./gc2.rx
grabbed10gb   21:40:58.682841
grabbed20gb   21:41:05.994087
grabbed30gb   21:41:13.765010
grabbed40gb   21:41:21.462267
grabbed50gb   21:41:29.247617
grabbed60gb   21:41:36.993362
grabbed70gb   21:41:44.751140
grabbed80gb   21:41:52.625969
grabbed90gb   21:42:00.357083
grabbed   100gb   21:42:08.224718
grabbed   110gb   21:42:16.041285
grabbed   120gb   21:42:23.884021
grabbed   130gb   21:42:31.770514
grabbed   140gb   21:42:39.636356
Killed: 9
[enrico@enrico-mbp oorexx.tests]$
 

the script

#! /usr/bin/env rexx
m = .Array~new(100)
chunk = 1e6

signal on syntax
-- grab memory chunks until almost exhausted
loop
  m~append(.MutableBuffer~new(, chunk))
  say "grabbed " right(m~items * chunk / 1e9,4)"gb  " time(l)
end

say "SNO"
exit

syntax:
-- reclaim some memory as we could be down to almost zero
m~remove(1)
say "grabbed*" right(m~items * chunk / 1e9,4)"gb  " time(l)


frankly I do not expect any outstanding error recovery
when needing more than 140GB

cheers
enrico

> On 26 Aug 2018, at 20:40, Rick McGuire  wrote:
> 
> I’m guessing that we were getting  eom failures earlier with the old code so 
> we never reached the point of getting a livestock allocation failure.
> On Sun, Aug 26, 2018 at 1:23 PM Erich Steinböck  > wrote:
> I wonder why this is popping up only now.  Wouldn't we always have had a good 
> chance that the liveStack needed expansion (because we now have more active 
> objects than before) when a terminal out-of-memory exception triggered a GC?  
> Why then did this work until now?
> 
> 
> On Sun, Aug 26, 2018 at 7:00 PM, Rick McGuire  > wrote:
> Yes, I understand, but the root cause of this problem is a failure trying to 
> expand the liveStack during a garbage collection. The call to 
> reportException() at that time causes a recursive allocation failure, 
> resulting in the eventual out-of-stack condition. I suspect the only real way 
> to handle this situation is a calling logicError() to indicate there has been 
> an unrecoverable out of memory situation.
> 
> Rick
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[Enrico Sorichetti via Oorexx-devel]

The discussion about the libraries is getting more and more confusing …

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_dir}")
else()
SET( CMAKE_INSTALL_RPATH "$ORIGIN/../${_lib_dir}")
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)

Without the RPATH setting the exports are required 

( tested on El Capitan, high Sierra, Mojave and Fedora 29 )


I usually install to /opt/ooRexx  and add /opt/ooRexx/bin to the PATH


Until a few revision ago I could move the the installed  tree anywhere with any 
name 
And the test suite would run successfully 

Now something has changed, my scripts run 
But the test suite fails  with an abort trap 6 in the  bif/DATE.testGroup

E

> On 2 Jan 2019, at 23:13, René Jansen  wrote:
> 
> Hi P.O.,
> 
> what Erich meant is that for some time now the *environment variable* 
> containing the dyld library path is not inherited in subshells. We have to 
> use dyld as that is the way shared libraries on macOS work. We have to work 
> at making sure this environment variable is not needed anymore - and that it 
> will run on systems with SIP enabled, which would be most user systems. This 
> is possible using the install_name_tool, although for librexxutil a solution 
> must be found, for which, if I am not mistaken, Rick just opened a sandbox 
> directory. Did you try to run without either LD_LIBRARY_PATH or 
> DYLD_LIBRARY_PATH?
> 
> René.
> 
>> On 2 Jan 2019, at 18:00, P.O. Jonsson > > wrote:
>> 
>> A small remark:
>> 
>> Erich has found out that the dyld stuff will not work since it is not 
>> inherited. A rexx program calling another rexx program (example: test cases) 
>> fail. He can put it in more technical terms I am sure, but my take on it is 
>> that this is a dead end on Darwin/macOS
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se 
>> 
>> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

[Enrico Sorichetti via Oorexx-devel]

here are three snippets that show how to do it

APPLE

#include 
#include 
#include 
#include 

#include 


int main()
{
pid_t pid;

char path[1024];

int RC;
char *cp;

pid = getpid();
RC  = proc_pidpath (pid, path, sizeof(path));
if ( RC <= 0 )
{
exit(-1);
}
else
{
cp = strrchr(path,'/');
*cp=0;
printf("path '%s'\n",path ) ;
exit(0);
}
exit(-1);
}

Freebsd
/*  FreeBSD
*/
#include 
#include 

int main()
{
char path[1024];
int  size;

size = readlink( "/proc/curproc/file", path, sizeof(path)-1);

path[size] = '\0';

printf("* '%s'\n", path );

return(0);
}

linux

#include 
#include 

int main()
{
char path[1024];
int  size;

size = readlink( "/proc/self/exe", path, sizeof(path)-1);

path[size] = '\0';

printf("* '%s'\n", path );

return(0);
}

enrico


> On 5 Jan 2019, at 13:07, Rick McGuire  wrote:
> 
> My understanding on unix systems is that it is not possible determine the 
> location of the binary. Please correct me if I'm wrong on this point, but 
> David Ashley was quite insistent that it was not possible 

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

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

[Enrico Sorichetti via Oorexx-devel]

Having “.” In the PATH is against any good judgement 

A CD to the wrong directory might, will certainly open a can of worm


The rxapi thing is a pretty murky issue 

For basic things looks like the  is not really needed 

I moved the rxapi away from the path 

And a pretty complicated script run with no problem 

For some odd reason the performance was terrible 
My wild guess is that rexx keeps trying to start the rxapi things

But it worked 

Enrico


> On 5 Jan 2019, at 13:07, Rick McGuire  wrote:
> 
>  I'm pretty sure that the reason this failed is because the userids doing the 
> build did not have "." in the path, 

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

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

[Enrico Sorichetti via Oorexx-devel]

> On 5 Jan 2019, at 22:32, Gil Barmwater  wrote:
> 
>> Actually, the path we really need is the location of librexxapi. 


Why ?

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

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

[Enrico Sorichetti via Oorexx-devel]

Not necessary IMO, for the way ooRexx is structured now
the ooRexx binary directory MUST be in the PATH 
Otherwise a generic rexx, would never be able to use rxqueue and rxsubcom

Using objects locating them by the relative position might be needed only to
Guarantee consistency to the environment , multiple oorexx binary directories 
in the path
It might be important to do that when loading the rexx image, less important 
for the rexx.cat
( got burned a couple of times because of that ) 

Enrico


> On 5 Jan 2019, at 23:06, Rick McGuire  wrote:
> 
> 
> On Sat, Jan 5, 2019 at 4:54 PM Enrico Sorichetti via Oorexx-devel 
>  <mailto:oorexx-devel@lists.sourceforge.net>> wrote:
> 
> 
>> On 5 Jan 2019, at 22:32, Gil Barmwater > <mailto:gbarmwa...@alum.rpi.edu>> wrote:
>> 
>>> Actually, the path we really need is the location of librexxapi. 
> 
> 
> Why ?
> 
> Because ooRexx can be used by any application. so the program for the process 
> need not be one of the oorexx executables. For example, if you are using 
> bsfoorexx from a java application, then the process will be the java process. 
> rxapi will not be found at that location. However, it will be found at the 
> same location of the librexxapi (which is the bit of code that does the 
> launching). 
> 
> Rick
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

[Enrico Sorichetti via Oorexx-devel]

Sorry for the typo, I meant

Both case sensitive and case INsensitive file systems

E



> On 19 Jan 2019, at 00:37, Enrico Sorichetti  wrote:
> 
> APPLE supports both case sensitive and case sensitive filesystems
>  

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

Re: [Oorexx-devel] A couple of discussion questions about SysFileTree

[Enrico Sorichetti via Oorexx-devel]

APPLE supports both case sensitive and case sensitive filesystems
 
And since _PC_CASE_SENSITIVE is defined and pathconf works 
No reason at all to use a default.

For the sake of logical consistency You might want to add to theCMakelists the 
function_exists test

The testSuite MUST be fixed, it does not work on case insensitive filesystems 

E



> On 18 Jan 2019, at 23:58, Rick McGuire  wrote:
> 
>  However, the Mac normally uses a caseless file system. I'm thinking the 
> default for the Mac should be caseless too. 

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

Re: [Oorexx-devel] Welcome to the Haiku shell.

[Enrico Sorichetti via Oorexx-devel]

For a cleaner stat64 and friends handling I would consider trying
Like has been done for apple , something along the lines of

#if defined(__APPLE__) || defined(__HAIKU__)
# define lseek64 lseek
# define open64 open
// avoid warning: '(f)stat64' is deprecated: first deprecated in macOS 10.6
# define stat64 stat
# define fstat64 fstat
…
…

#endif

Less code intrusive 

 cheers
E




> On 15 Jan 2019, at 18:08, Jason Martin  wrote:
> 
> Starting patch for anyone who wants to fool around with it.
> 
> https://github.com/agrellum/NetRexx-Samples/blob/master/haiku-oorexx.patch
> 
> 
> 
> 
> 
> ___
> 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] Link to WIKI

[Enrico Sorichetti via Oorexx-devel]

From what I can see 

The links 
> https://sourceforge.net/projects/oorexx/ 
> And
> https://sourceforge.net/p/oorexx/ 
lead to the same place - NO LOGIN REQUIRED
 
But, IMBD(*), I could not find the way to reach the wiki from there 

The link
> https://sourceforge.net/p/oorexx/wiki/Home/ 
> 
Lead to the wiki page - LOGIN REQUIRED

E

(*) I Might Be Dumb

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

Re: [Oorexx-devel] FreeBSD

[Enrico Sorichetti via Oorexx-devel]

I searched around but I could not find anything about it
Any hints ?

Thank You

E

P.S.
Found some ifdefs related to open bad but nothing else


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

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

[Enrico Sorichetti via Oorexx-devel]

Strongly agree !
Enrico


> On 21 Dec 2018, at 23:15, Erich Steinböck  wrote:
> 
> majorVersion, release, and revision value
> As far as I can see IBM terminology is version.release.modification (plus 
> fix).
> I propose
> changing the current "revision" to "modification" and
> use "revision" for the source-control revision (currently SVN revision)
> 
> 
> On Sun, Sep 28, 2014 at 3:19 PM Rick McGuire  > wrote:
> Decided to also add majorVersion, release, and revision values to this to 
> return the pieces of the version number. 
> 
> Rick
> ___
> 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.

[Enrico Sorichetti via Oorexx-devel]

Any linux/BSD/Apple user knows that sudo and su are prone to create 
unpredictable results 
I would not waste time researching a solution for a murky situation 
I would mark it as a permanent restriction / producing unpredictable results 

I just created a test user and  found that 
The $HOME var points to the SU’ ed user home directory
But after the switch the working directory does not change 
Some environment variables are carried over ,some other not ,
As I said a murky situation overall, 
The  will never be clean 

On apple there is no need to SU, the SUPERUSER does not exists 
All is done thru the administrator attribute of any user
And SUDO to activate the super powers

In my experience for Linux and FeeBSD instances sudo is more than enough
On freebsd when doing the after install customisation 
it was faster to login as root and run the post install from there
The pkg command is quite picky

cheers
E





> On 22 Dec 2018, at 15:12, Rick McGuire  wrote:
> 
> It would be useful to have the feedback to see if always using the user's 
> home directory works or now. I'm concerned we might run into similar access 
> issues with the switch. If so, then we might need to use something in /tmp 
> and include the username in the files we create, which is less secure, but 
> will continue to work with a switch. 
> 
> Rick
> 
> On Sat, Dec 22, 2018 at 9:07 AM Erich Steinböck  > wrote:
> No, not yet.  Should we wait for Moritz' feedback, as he was the the one who 
> suggested using XDG_RUNTIME_DIR?
> 
> On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire  > wrote:
> Sounds like a reasonable solution...have you tried it yet? 
> 
> Rick
> 
> On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck  > wrote:
> With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running into 
> an issue if a Unix user switches users with the "su other-user" command.
> The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now 
> points to a location that other-user has no access to.
> At this point any rexx script will show the typical start delay due to rxapi 
> failing to start, and external queues return REX121 Storage for data queues 
> is exhausted.
> 
> In a scenario where a user switched to root (untested) with su root, things 
> might become even worse (a socket created by root now blocking the original 
> user from creating his rxapi socket).
> 
> I suggest dropping rxapi's use of $XDG_RUNTIME_DIR and instead make it always 
> use the user's home directory.  When using su, the HOME environment variable 
> will change to the other-user's home directory.
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

Re: [Oorexx-devel] Setting up VirtualBox

[Enrico Sorichetti via Oorexx-devel]

> So far, all I've gotten is suggestions for additional stuff to install. 

So far you have got suggestion from people with much more experience than you 
on the subject
Who are trying to make things easier for you

Before suggesting the use of vagrant I wanted to make an experiment 
Starting from scratch

Installed Virtual Box
Installed Vagrant
Researched the best FreeBSD image
Initialised the vagrant configuration 
Downloaded and Installed the local image

Customised the system to my taste 
Bash 
cmake
Subversion 

Cloned the repo 

Attempted the build

To see that ooRexx on freeBSD is not supported yet 

And
How long did it take me 
Just 30 minutes
And 5 minutes to compose the email

So just be a bit more flexible please

E

Season’ s greeting to everybody 


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

Re: [Oorexx-devel] Setting up VirtualBox

[Enrico Sorichetti via Oorexx-devel]

Probably because nobody ever tried

At  my first attempt I got som errors for missing DEFINES 

I will look into it 

E


> On 24 Dec 2018, at 20:49, Gil Barmwater  wrote:
> 
> Can someone help me remember why FreeBSD is not an ooRexx-supported 
> configuration?  Thanks!
> 

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

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

[Enrico Sorichetti via Oorexx-devel]

The SO_NOSIGPIPE is OK on macOS

But …
I get quite a few …

[  3%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/client/LocalAPIManager.cpp.o
/Users/enrico/rxapi.svn/rexxapi/client/LocalAPIManager.cpp:302:9: warning: 
delete called on 'ApiConnection' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connection;
^
/Users/enrico/rxapi.svn/rexxapi/client/LocalAPIManager.cpp:315:5: warning: 
delete called on 'ApiConnection' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connection;
^
/Users/enrico/rxapi.svn/rexxapi/client/LocalAPIManager.cpp:336:5: warning: 
delete called on 'ApiConnection' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connection;
^
3 warnings generated.


[ 80%] Building CXX object CMakeFiles/rxapi.dir/rexxapi/server/APIServer.cpp.o
/Users/enrico/rxapi.svn/rexxapi/server/APIServer.cpp:68:5: warning: delete 
called on 'ServerConnectionManager' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connectionManager;
^
/Users/enrico/rxapi.svn/rexxapi/server/APIServer.cpp:157:13: warning: delete 
called on 'ApiConnection' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connection;
^
/Users/enrico/rxapi.svn/rexxapi/server/APIServer.cpp:183:25: warning: delete 
called on 'ApiConnection' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connection;
^
/Users/enrico/rxapi.svn/rexxapi/server/APIServer.cpp:209:13: warning: delete 
called on 'ApiConnection' that is abstract but has
  non-virtual destructor [-Wdelete-non-virtual-dtor]
delete connection;
^


Build fails with 

[enrico@enrico-imac rxapi.svn.Release]$make
[  0%] Generating rexx.1.gz
[  0%] Built target rexx_man
[  0%] Generating rxsubcom.1.gz
[  0%] Built target rxsubcom_man
[  2%] Built target class_files
[  2%] Built target ncurses_cls
Scanning dependencies of target rexxapi
[  2%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/client/platform/unix/SysLocalAPIManager.cpp.o
[  2%] Linking CXX shared library bin/librexxapi.dylib
Undefined symbols for architecture x86_64:
  "SysLocalSocketConnection::~SysLocalSocketConnection()", referenced from:
  SysLocalAPIManager::newClientConnection() in SysLocalAPIManager.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/librexxapi.5.0.0.dylib] Error 1
make[1]: *** [CMakeFiles/rexxapi.dir/all] Error 2
make: *** [all] Error 2
[enrico@enrico-imac rxapi.svn.Release]$

But if I comment 

ApiConnection *SysLocalAPIManager::newClientConnection()
{
SysLocalSocketConnection *connection = new SysLocalSocketConnection();

// open the pipe to the server
if 
(!connection->connect(SysServerLocalSocketConnectionManager::generateServiceName()))
{
// don't leak memory!
// delete connection;
throw new ServiceException(SERVER_FAILURE, "Failure connecting to rxapi 
server");
}
return connection;
}

The build is  successful,  and at run time I get

[enrico@enrico-imac ooRexx.tests.svn]$lldb -- rexx testOORexx.rex -s -X 
native_api
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X" "native_api"
(lldb) r
Process 9445 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
Searching for test containers
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Process 9445 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0001003f7ba8 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000100502bd0) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
Target 0: (rexx) stopped.
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: 
[Y/n] 
[enrico@enrico-imac ooRexx.tests.svn]$

[Oorexx-devel] Good News

[Enrico Sorichetti via Oorexx-devel]

Hi . 

I moved out of the way the sandbox environment

Updated  my local copy of the main trunk
Updated my local copy of the test suite 

Both to revision 11562

And the test suite run smoothly until the end

Thank You all

E




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

[Enrico Sorichetti via Oorexx-devel]

All depends on the setuo …

The CMAKE_BUILD_TYPE 
Has the only effect to chose for the compilation and linking
The appropriate flags

The RELEASE,RELWITHDEBINFO,DEBUG,MINSIZEREL types
Are the ones handled automatically by CMAKE

The variable used for that are of the form
CMAKE_CXX_FLAGS_ 

CMAKE_CXX_FLAGS 
CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_RELEASE 
CMAKE_CXX_FLAGS_RELWITHDEBINFO 

And cmake will use the appropriate ones 

If no build type is specified 
The compiler and the linker flags are empty 

If You go to the build directory  the command 
Ccmake .
Will open a ncusers based cmake session
Where You can modify some CMAKE options 
It You enter t it will show all ( almost ) the variable used by CMAKE

In my projects I have an include module
to set defaults different from the cmake provided ones 
You should be able to look at them :-)

But cmake is smarter than most people think 

You can for example 

Cmake -DCMAKE_BUILD_TYPE=My … … …

And cmake will use the flags contained in the variables of the form
CMAKE_CXX_FLAGS_MY

E



> On 4 Dec 2018, at 15:25, Rony G. Flatscher  wrote:
> 
> 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

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

[Oorexx-devel] Revision 11563

[Enrico Sorichetti via Oorexx-devel]

Received 225 copies of 

/opt/ooRexx.svn/api/oorexxapi.h:2268:5: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^
/opt/ooRexx.svn/api/oorexxapi.h:2272:5: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^
2 warnings generated.


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

Re: [Oorexx-devel] unix/rexxutil event and mutex functions are really broken.

[Enrico Sorichetti via Oorexx-devel]

> On 7 Dec 2018, at 14:30, Rick McGuire  wrote:
> 
> That's a memory management library and doesn't appear to have anything to do 
> with cross-process semaphores.


But it has for threads … 

My mistake was not to look at the other sources involved to discover that 
semaphores support was only for pthreads 

What kind of performance do You expect from the implementation ?

And how stringent is the need to make it available ?

E





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

Re: [Oorexx-devel] unix/rexxutil event and mutex functions are really broken.

[Enrico Sorichetti via Oorexx-devel]

You might get some ideas by looking at how the Boehm GC does it
Enrico


> On 7 Dec 2018, at 14:15, Rick McGuire  wrote:
> 
> Ignoring for a moment the elephant in the corner of the Apple deprecated (and 
> non-functional) sem_* functions, the *ix versions of the semaphore functions 
> are really sort of broken. 
> 
> For the event semaphores, one of the functions is a reset, which uses 
> sem_init() to perform the reset. This probably doesn't work (or at least, is 
> not guaranteed to work) because the documentation states that using 
> sem_init() on an existing semaphore handle is undefined. 
> 
> The interpreter code uses the SysSemaphore class which implements all of the 
> desired behavior, but since it uses pthread, it only works for the unnamed 
> case. It would not be a huge effort to dual path named vs. unnamed, but the 
> sem_init() problems still exist for the named case. 
> 
> There are similar problems with the Mutex functions. These are implemented 
> using the same semaphore functions so a lot of the same issues exist. Also, 
> I'm not convinced that what is implemented here is a true mutex function. 
> Again, the classes implemented in SysSemaphore can be used here, but only for 
> the unnamed cases. I have not been able to find any equivalent to windows 
> named mutex semaphores in the linux world. 
> 
> In summary, fixing the unnamed versions of these would be a fairly simple 
> thing, fixing the named versions, I have no solutions. 
> 
> Rick
> 
> 
> ___
> 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] Some observations on the failing rxqueue tests.

[Enrico Sorichetti via Oorexx-devel]

Hello Rick here is the result 


[enrico@enrico-imac ooRexx.testsuite]$cd
[enrico@enrico-imac ~]$rm .ooRexx*
[enrico@enrico-imac ~]$ps -A |grep rxapi
 1186 ?? 0:00.81 rxapi
13242 ttys0000:00.00 grep rxapi
[enrico@enrico-imac ~]$kill 1186
[enrico@enrico-imac ~]$ps -A |grep rxapi
13244 ttys0000:00.00 grep rxapi
[enrico@enrico-imac ~]$cd -
/opt/ooRexx.testsuite
[enrico@enrico-imac ooRexx.testsuite]$rexx testOORexx.rex -f rxQueue.testGroup
Searching for test containers..
Running automated test suite86 *-* cmd "| rxqueue"
   122 *-* 'rexx' prg '| rxqueue'
   194 *-* "cat" long "| rxqueue"
   164 *-* 'rexx' prg stdErrToStdOut '| rxqueue'
..

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: 2
Failures:   4
Errors: 0

[failure] [20181202 14:04:42.734449]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_CURRENT_DIR_FILTER
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   89
  Failed: assertSame
Expected: [[1], identityHash="-4527560001"]
Actual:   [[0], identityHash="-4527525873"]

[failure] [20181202 14:04:42.765317]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_MULTI_LINES
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   129
  Failed: assertSame
Expected: [[5], identityHash="-4528460761"]
Actual:   [[0], identityHash="-4527525873"]

[failure] [20181202 14:04:42.794074]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_RXQUEUE_MAXIMUM_LINE_LENGTH
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   196
  Failed: assertEquals
Expected: [[2], identityHash="-4527603937"]
Actual:   [[0], identityHash="-4527525873"]

[failure] [20181202 14:04:42.825624]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_STDERR_TO_RXQUEUE
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   169
  Failed: assertSame
Expected: [[4], identityHash="-4527912937"]
Actual:   [[0], identityHash="-4527525873"]

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: 2
Failures:   4
Errors: 0

File search:00:00:00.016363
Suite construction: 00:00:00.000605
Test execution: 00:00:00.109244
Total time: 00:00:01.003310

[enrico@enrico-imac ooRexx.testsuite]$rexx testOORexx.rex -f rxQueue.testGroup
Searching for test containers..
Running automated test suite86 *-* cmd "| rxqueue"
   122 *-* 'rexx' prg '| rxqueue'
   194 *-* "cat" long "| rxqueue"
   201 *-* "rxqueue <" long
   164 *-* 'rexx' prg stdErrToStdOut '| rxqueue'
..

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.015935
Suite construction: 00:00:00.000536
Test execution: 00:00:00.140341
Total time: 00:00:01.003761

[enrico@enrico-imac ooRexx.testsuite]$

Hope that it helps 

E


> On 2 Dec 2018, at 13:59, Rick McGuire  wrote:
> 
> These tests have been driving me crazy, not because there are failures, but 
> because there are successes. Two of the six test methods in that group are 
> passing, and if there was a problem with the daemon, I would have expected 
> all of the rxqueue tests to fail for the same reason. I have noticed a key 
> difference between the failing tests and the passing tests. All of the 
> failing tests are using a Rexx program called as a command to generate the 
> output and the passing tests are just using type or cat to produce the 
> output. I'm wondering if some of the proceeding tests in the test suite are 
> somehow changing the environment such that the rexx command is failing. When 
> the testgroup is run on its own, those changes don't occur and everything 
> passes. 
> 
> Could your try adding a "::options trace commands" directive to the test 
> group and run both ways so I can see what commands are getting issued? 
> Unfortunately, the return code from piped commands are lost because of the 
> piping...that would have been useful information too.
> 
> Rick

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

[Enrico Sorichetti via Oorexx-devel]

Hi Rick 
Follow on …

And here is the result for 


rexx testOORexx -s -X native_API


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: 375210
Failures:   0
Errors: 0

File search:00:00:01.205401
Suite construction: 00:00:00.979385
Test execution: 00:03:00.447461
Total time: 00:03:02.941318

[enrico@enrico-imac ooRexx.testsuite]$


Enrico


> On 2 Dec 2018, at 13:59, Rick McGuire  wrote:
> 
> These tests have been driving me crazy, not because there are failures, but 
> because there are successes. Two of the six test methods in that group are 
> passing, and if there was a problem with the daemon, I would have expected 
> all of the rxqueue tests to fail for the same reason. I have noticed a key 
> difference between the failing tests and the passing tests. All of the 
> failing tests are using a Rexx program called as a command to generate the 
> output and the passing tests are just using type or cat to produce the 
> output. I'm wondering if some of the proceeding tests in the test suite are 
> somehow changing the environment such that the rexx command is failing. When 
> the testgroup is run on its own, those changes don't occur and everything 
> passes. 
> 
> Could your try adding a "::options trace commands" directive to the test 
> group and run both ways so I can see what commands are getting issued? 
> Unfortunately, the return code from piped commands are lost because of the 
> piping...that would have been useful information too.
> 
> Rick
> ___
> 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] Some observations on the failing rxqueue tests.

[Enrico Sorichetti via Oorexx-devel]

I thought I had been clear in my explanation …


NO rxapi Running … 

Some Rexx scripts run other fail 
The testOORexx script processing the rxQueue.group fails consistently 
Thats why I used it to report the error

The second execution of the same 
Rxapi Running, started by somebody else
The testOORexx script processing the rxQueue.group ends OK

The full test suite behaves in the same way …
No rxapi it fails
Rxapi running it succeeds

That’ what the terminal window paste showed .

To be sure I just  rerun the thing …

[enrico@enrico-imac ooRexx.testsuite]$ps -A |grep rxapi
13246 ?? 0:00.09 rxapi
14041 ttys0000:00.00 grep rxapi
[enrico@enrico-imac ooRexx.testsuite]$kill 13246
[enrico@enrico-imac ooRexx.testsuite]$ps -A |grep rxapi
14043 ttys0000:00.00 grep rxapi
[enrico@enrico-imac ooRexx.testsuite]$
[enrico@enrico-imac ooRexx.testsuite]$
[enrico@enrico-imac ooRexx.testsuite]$rexx testOORexx -s -X native_API
Searching for test containers...


As You see before invoking the test NO rxapi is running

And we get as forecasted  the error

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: 375190
Failures:   4
Errors: 0

[failure] [20181202 15:01:22.322756]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_CURRENT_DIR_FILTER
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   89
  Failed: assertSame
Expected: [[1], identityHash="-4349637953"]
Actual:   [[0], identityHash="-4349603825"]

[failure] [20181202 15:01:22.352226]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_MULTI_LINES
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   129
  Failed: assertSame
Expected: [[5], identityHash="-4350538713"]
Actual:   [[0], identityHash="-4349603825"]

[failure] [20181202 15:01:22.381386]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_RXQUEUE_MAXIMUM_LINE_LENGTH
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   196
  Failed: assertEquals
Expected: [[2], identityHash="-4349681889"]
Actual:   [[0], identityHash="-4349603825"]

[failure] [20181202 15:01:22.410175]
  svn:r11522   Change date: 2018-11-22 01:34:56 +0100
  Test:   TEST_STDERR_TO_RXQUEUE
  Class:  rxQueue.testGroup
  File:   /opt/ooRexx.testsuite/ooRexx/utilities/rxqueue/rxQueue.testGroup
  Line:   169
  Failed: assertSame
Expected: [[4], identityHash="-4349990889"]
Actual:   [[0], identityHash="-4349603825"]

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: 375190
Failures:   4
Errors: 0

File search:00:00:01.246389
Suite construction: 00:00:01.056062
Test execution: 00:02:59.653872
Total time: 00:03:02.227138

[enrico@enrico-imac ooRexx.testsuite]$


The error is triggered when the rxapi thing is not there.

But it does not always happen

My point was NOT the failure of the test suite 

But the behaviour with respect to rxapi already running or not


Hope to have been clear now 

cheers

Enrico


> On 2 Dec 2018, at 14:51, Rick McGuire  wrote:
> 
> OK, now I'm really confused. This is the opposite of what I was expecting to 
> see. I thought it only failed when run as a full suite and passed when run 
> alone, but this is showing me the opposite. And the full run is also missing 
> the trace lines. 

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

[Enrico Sorichetti via Oorexx-devel]

It runs for me from /opt/ooRexx

Installing in /usr/local 

I will keep You posted on the results

E


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

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

[Enrico Sorichetti via Oorexx-devel]

Hello  Rick

Pulled the last mods,
When running my one liner I noticed that the timings were quite different

[enrico@enrico-imac ooRexx.svn.Release]$pkill rxapi
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say 
queued() "
1

real0m0.082s
user0m0.011s
sys 0m0.016s
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say 
queued() "
1

real0m0.028s
user0m0.010s
sys 0m0.014s


See the higher real time when rxapi is not there

As compared to
real0m0.038s


Added a few printfs to check things 

[enrico@enrico-imac ooRexx.svn.Release]$pkill rxapi
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say 
queued() "
* 1
* connectionEstablished at line 264
* connectionEstablished at line 231
1

real0m0.080s
user0m0.010s
sys 0m0.015s
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say 
queued() "
* connectionEstablished at line 231
* connectionEstablished at line 231
1

real0m0.027s
user0m0.010s
sys 0m0.014s
[enrico@enrico-imac ooRexx.svn.Release]$


The sleep loop is entered once if rxapi is not active 

most certainly - because of the other modifications You made
And those might explain also the different timings 

The test suite runs until the end with no errors 

E






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

[Enrico Sorichetti via Oorexx-devel]

> On 3 Dec 2018, at 14:04, Rony G. Flatscher  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 :-) 

P.S.

I will try to write something about the different setup options 


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

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

[Enrico Sorichetti via Oorexx-devel]

Not yet !
Enrico

> On 2 Dec 2018, at 19:07, Rony G. Flatscher  wrote:
> 
> 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



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

[Enrico Sorichetti via Oorexx-devel]

It still fails

to keep it short …

No need to bother the oorexx test suite 


[enrico@enrico-imac ooRexx.testsuite]$pkill rxapi
[enrico@enrico-imac ooRexx.testsuite]$rexx -e "'pwd | rxqueue' ; say queued(); 
do queued();parse pull l; say l; end "
0
[enrico@enrico-imac ooRexx.testsuite]$rexx -e "'pwd | rxqueue' ; say queued(); 
do queued();parse pull l; say l; end "
1
/opt/ooRexx.testsuite
[enrico@enrico-imac ooRexx.testsuite]$



Not easy to debug without knowing the logic behind it

E

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

[Enrico Sorichetti via Oorexx-devel]

Both
e

> On 2 Dec 2018, at 23:07, Rick McGuire  wrote:
> 
> Which interval did you change? The first wait after the server launch or the 
> loop one?

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

[Enrico Sorichetti via Oorexx-devel]

Done it ,
Changed the sleep interval to 1000 msecs
it loops 6/8 times 

And the test suite runs fine fine
Even after having killed the rxapi process

The delay is negligible, and occurs only if rxapi is not running

e

P.S.
Time to start looking at the native api

> On 2 Dec 2018, at 22:36, Rick McGuire  wrote:
> 
> The logic for implementing the connection is in 
> LocalApiManager::establishServerConnection(). You might try fiddling with the 
> delay both after the server launch and between each of the connection 
> attempts.
> 

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

[Enrico Sorichetti via Oorexx-devel]

Hi Rick 

[enrico@enrico-imac ooRexx.svn.Release]$pkill rxapi
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say 
queued() "
sleeping 1000 msecs
 99 sleeping 1000 msecs
 98 sleeping 1000 msecs
 97 sleeping 1000 msecs
 96 sleeping 1000 msecs
 95 sleeping 1000 msecs
 94 sleeping 1000 msecs
1

real0m0.038s
user0m0.010s
sys 0m0.015s
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say 
queued() "
1

real0m0.027s
user0m0.010s
sys 0m0.013s
[enrico@enrico-imac ooRexx.svn.Release]$

Does not seem too much of a delay

E

PS .
They look more like microseconds to me


> On 2 Dec 2018, at 23:12, Rick McGuire  wrote:
> 
> So it was taking 7+ seconds for the process to get fully launched? Wow, 
> that's way longer than any of the other platforms. I may keep these smaller 
> than 1000 but increase the number of retries so that it will go at least 10 
> seconds before giving up. 
> 
> Rick
> 
> On Sun, Dec 2, 2018 at 5:09 PM Enrico Sorichetti via Oorexx-devel 
>  <mailto:oorexx-devel@lists.sourceforge.net>> wrote:
> Both
> e
> 
>> On 2 Dec 2018, at 23:07, Rick McGuire > <mailto:object.r...@gmail.com>> wrote:
>> 
>> Which interval did you change? The first wait after the server launch or the 
>> loop one?
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

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

[Enrico Sorichetti via Oorexx-devel]

Looks like I am the only one who did not have too many troubles
So it is OK for me 

E

P.S.

Still I do not understand all the issues about the MacroSpace.testGroup

> On 3 Dec 2018, at 17:40, Rick McGuire  wrote:
> 
> Are people OK with this?

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

Re: [Oorexx-devel] ooRexx auto-update

[Enrico Sorichetti via Oorexx-devel]

What operating system, how is ooRexx installed 

It is the responsibility  of  the operating system software manager to setup 
the infrastructure
To check at predefined intervals the remote software repositories for updates

Enrico


> On 9 Dec 2018, at 19:28, Adrian Baginski  wrote:
> 
> Hi guys,
>  
> I was just wondering, why is there no auto-update functionality for the 
> ooRexx package, where the user gets a popup to update to a newer version when 
> it is available? Currently, I have to remove the entire ooRexx package and 
> install another version in order to „update“ it, which can quickly become 
> fatigueing and encourages most users to not update at all.
>  
> Kind regards
> Adrian
>  
> ___
> 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 MacOS SIGPIPE (Re: Time for the *ix users to pitch in.

[Enrico Sorichetti via Oorexx-devel]

> On 29 Nov 2018, at 13:27, Rick McGuire  wrote:
> 
> Thanks, that looks useful. I probably won't be able to update this for a bit, 
> but it looks like a good thing to add.
> 
> Rick

I sprinkled a few printf around the "signal(SIGPIPE, SIG_IGN)”  occurrences
And the two I found were successful 

SystemInterpreter.cpp - ignore the SIGPIPE interrupt
SysLocalAPIManager.cpp - ignore the SIGPIPE interrupt

Any other places where they might be needed 
I might try to update things myself if I get some hints 

Enrico

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

Re: [Oorexx-devel] sem_init warning messages.

[Enrico Sorichetti via Oorexx-devel]

Hello Rick

The official answer fo macOS  semaphores 
Is to use Grand Central Dispatch's dispatch_semaphore_t.

If You google with dispatch_semaphore_t
You will find quite a few examples 

Or … very dumb suggestion 
Since it seems that named semaphores are still supported 
Why not use under the covers  a named semaphore with a dummy name 
As I said… it might be a dumb suggestion

E

> On 4 Dec 2018, at 22:21, Rick McGuire  wrote:
> 
> It appears that the sem_init deprecation warnings on the Mac are more than 
> just warnings. That function always returns an error on the Mac. 
> Unfortunately, it would prove difficult to replace it with an alternative 
> given how this function is currently constructed. I don't believe this 
> function has ever worked on the Mac, and I doubt it is used very often, since 
> it is fundamentally broken if you are trying to create an unnamed semaphore. 
> No sure how to proceed with this.
> 
> Rick
> ___
> 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]

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

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

[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] Question ad CMake and MacOS ("rxapi" related)

[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 I will post a patch for wider testing

Cheers

Enrico 







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

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

[Enrico Sorichetti via Oorexx-devel]

> On 21 Nov 2018, at 15:23, Rick McGuire  wrote:
> 
>  I believe writing the pid file at that location is part of the requirements 
> for running as a daemon on other unix-based systems.


Does not seem true for Mac OS

I have been running and ooRexx-ing  for a while with /tmp/ooRexx.pid
and everything seems too work 

Anyway I will keep experimenting with the different setups 

also, on Mac OS there are the Agents and the Daemons 

And the plist for starting an agent can be in ~/Library/LaunchAgents 

So again  no need to sudo anything,
But I will have to check what happens when alternating logins with different 
users
Without logging off 

I just looked and home-brew  does not need sudo because it assumes that 
/usr/local is not protected

And brew will …. ( from brew service help )
 If sudo is passed, operate on /Library/LaunchDaemons (started at boot).
 Otherwise, operate on ~/Library/LaunchAgents (started at login).




Cheers

Enrico






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

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

[Enrico Sorichetti via Oorexx-devel]

The only reason for having sudo privileges is to install the plist into 
/Library/LaunchDaemons

The only reason for having sudo privileges when starting by hand the rxapi 
thing is to write /var/run/ooRexx.pid

I just run a VERY quick and dirty test changing 
rexxapi/server/platform/unix/linux/APIService.cpp to write to /tmp/ooRexx.pid 

And at first glance everything seems to run smoothly 
Naturally more research and test is needed but …
it looks possible to install and use rexx without sudo privileges,
I will research a bit more and let You know 

Cheers

Enrico

PS

The change is really simple 

In /opt/ooRexx.alt/rexxapi/server/platform/unix/linux/APIService.cpp

Just change the first 
#define OOREXX_PIDFILE "/var/run/ooRexx.pid”
To
#define OOREXX_PIDFILE "/tmp/ooRexx.pid"











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

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

[Enrico Sorichetti via Oorexx-devel]

What Linux distro will You need …
I am pretty comfortable running centos if that is enough
Enrico


> On 26 Nov 2018, at 00:26, Rony  wrote:
> 
> 
>> Am 26.11.2018 um 00:13 schrieb Rick McGuire :
>> 
>> I need someone to do a little more than test it. I can write most of the 
>> code, but cannot compile or debug it. If you can do nothing more than try to 
>> build it for me once I have the Linux code written, that would be great.
> Sure, I can do that! 
> (Sometimes it may be the case that it may take a day or two if I am pinned 
> down in my day jpb. But as in the past I will try hard to help as quickly as 
> possible to keep the ball rolling.)
> 
> —-rony
> 
> Rony G. Flatscher (mobil/e)
> 
> 
> ___
> 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] Anybody with experience with AF_LOCAL (AF_UNIX) sockets.

[Enrico Sorichetti via Oorexx-devel]

> On 27 Nov 2018, at 22:33, Rick McGuire  wrote:
> 
…
…
...
> Do this make sense? Can the "~" form be used on the bind?
> 

NO the ~ is resolved by the shell 

IMO the best place would be a hidden file in the home dir

Which can be dynamically built using something like 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main (int argc, char* argv[])
{
const char *homepath;
const char *pidfile;

if ( (homepath = getenv("HOME")) == NULL) {
homepath = getpwuid(getuid())->pw_dir;
}
printf("HOME   : %s\n", homepath);
printf("might give : %s/%s\n", homepath,".ooRexx.pid");

if ( (pidfile = getenv("OOREXX_PIDFILE") ) ) {
printf("pidfile: %s\n", pidfile);
}

return 0;
}

To give
HOME   : /Users/enrico
might give : /Users/enrico/.ooRexx.pid
pidfile: /tmp/ooRexx.pid


The environment variable OOREXX_PIDFILE  is the approach I use
in the modified APIservice.cpp 

cheers

Enrico




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

Re: [Oorexx-devel] Anybody with experience with AF_LOCAL (AF_UNIX) sockets.

[Enrico Sorichetti via Oorexx-devel]

> On 27 Nov 2018, at 23:49, Rick McGuire  wrote:
> 
> This new setup does not require a pid file. 


Sorry…  I just did a cut and paste from a snippet used for testing.
And used the wrong terminology

You just need a token to serve as anchor point for a local connection 
The way  zeromq and nanomsg do
But it still maps to a file name without allocating it 

Cheers

Enrico



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

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

[Enrico Sorichetti via Oorexx-devel]

On 21 Nov 2018, at 17:21, CV Bruce  wrote:Enrico, I’m a little concerned that installing anything in ~/… will make it user specific, and not system wide.  Since only one copy of rxapi can run at a time, then only one user can use ooRexx.  In your explorations can you test for this?  "The main difference [on Mac OS] is that an agent is run on behalf of the logged in user while a daemon runs on behalf of the root user or any user you specify with the UserName key.”This may imply that if you log off the daemon may stop running, or the daemon may not start until the user logs on.Hello BruceThe situation is even murkier …I killed the daemon Executed the script I used to test the WITH stuff andMagically the daemon was there againLogged off, logged on and the daemon never stopped runningSo I guess that there should be no issues for a single user environment Probably not even the need to install anything Tested again and no need to install anythingI already modified /opt/ooRexx.alt/rexxapi/server/platform/unix/linux/APIService.cppTo  …Accept one argument with the pidfile FULL pathRetrieve the OOREXX_PIDFILE environment  variable If none of the above to use the hardware coded path The utilisation of the arg approach is needed To let the plist use a customised pathI tried to attach a zip file with the changed sources , but Zip attachments are not allowed CheersEnricoTesting with a tgz 

APIService.tgz
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[Enrico Sorichetti via Oorexx-devel]

> On 21 Nov 2018, at 17:11, Rick McGuire  wrote:
> 
> It might not be true for the Mac, but I believe it is true for Linux, which 
> means just changing that line is not the correct behavior. 


As I said It was just a VERY quick and dirty test…

The ooRexx.pid name/location could be a build option,
Or even better a run time option, I am testing it right now  to check the 
different alternatives without having to rebuild 

Enrico







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

[Enrico Sorichetti via Oorexx-devel]

> On 28 Nov 2018, at 16:32, Rick McGuire  wrote:
> 
> Also not going to happen. I'm not a Linux user, I don't like the tooling on 
> the system (editors, debuggers, etc.) If this is going to be done, it will be 
> because the community of people who do run on those systems help to make it 
> happen, not because I am expected to do all of the work. 

Nobody is asking/expecting You to do that, You certainly agree that
The back and forth for simple compilation errors is pretty annoying

The alternative just to check for clean builds would be to have a repository
 On GitHub  activating the option for travis CI

No need to learn unix/bsd 
You/somebody will just have to add a couple of files to trigger the travis jobs

It even supports apple builds 

Enrico




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

[Enrico Sorichetti via Oorexx-devel]

> On 28 Nov 2018, at 13:23, Rick McGuire  wrote:
> 
> https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rxapi 
> 

Just tried it , got 

[  6%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/client/platform/unix/SysLocalAPIManager.cpp.o
In file included from 
/Users/enrico/rxapi.src/rexxapi/client/platform/unix/SysLocalAPIManager.cpp:44:
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:75:6: 
error: expected the class name after '~' to name a destructor
~SysInetSocketConnection();
 ^~~
 SysLocalSocketConnection
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:106:12: 
error: missing return type for function
  'SysServerLocalInetSocketConnectionManager'; did you mean the constructor 
name 'SysServerLocalSocketConnectionManager'?
inline SysServerLocalInetSocketConnectionManager() { }
   ^
   SysServerLocalSocketConnectionManager
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.hpp:117:10: 
error: expected ';' at end of declaration list
const char *boundServiceName;// the service name this instance is 
bound to.
 ^
 ;
3 errors generated.

Cheers
Enrico

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

[Enrico Sorichetti via Oorexx-devel]

> On 28 Nov 2018, at 13:42, Rick McGuire  wrote:
> 
> Thanks, fixes checked in. 
> 
> Rick
> 
> On Wed, Nov 28, 2018 at 7:32 AM Enrico Sorichetti via Oorexx-devel 
>  <mailto:oorexx-devel@lists.sourceforge.net>> wrote:

SysCSSStream.cpp and CSSStream naming mismatch

Used the right name but got more errors 


/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:71:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::read(void *buf, size_t bufsize, size_t *bytesread)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:102:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::write(void *buf, size_t bufsize, size_t *byteswritten)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:133:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::write(void *buf, size_t bufsize, void *buf2, size_t 
buf2size, size_t *byteswritten)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:194:6: 
error: use of undeclared identifier 'SysSocketConnection'
bool SysSocketConnection::disconnect()
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:217:1: 
error: use of undeclared identifier 'SysLocalSocketConnection'
SysLocalSocketConnection::SysLocalSocketConnection(const char *serviceName) : 
SysSocketConnection()
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:230:6: 
error: use of undeclared identifier 'SysLocalSocketConnection'
bool SysLocalSocketConnection::connect(const char *serviceName)
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:275:16: 
error: use of undeclared identifier 'SysServerSocketConnectionManager';
  did you mean 'ServerConnectionManager'?
ApiConnection *SysServerSocketConnectionManager::acceptConnection()
   ^~~~
   ServerConnectionManager
/Users/enrico/rxapi.src/rexxapi/common/CSStream.hpp:102:7: note: 
'ServerConnectionManager' declared here
class ServerConnectionManager
  ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:280:9: 
error: use of undeclared identifier 'c'
if (c == -1)
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:285:5: 
error: unknown type name 'SOCKET'
SOCKET client = accept(c, (struct sockaddr *) , );
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:285:28: 
error: use of undeclared identifier 'c'
SOCKET client = accept(c, (struct sockaddr *) , );
   ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:294:16: 
error: unknown type name 'SysSocketConnection'
return new SysSocketConnection(client);
   ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:303:6: 
error: use of undeclared identifier 'SysServerSocketConnectionManager';
  did you mean 'ServerConnectionManager'?
bool SysServerSocketConnectionManager::disconnect()
 ^~~~
 ServerConnectionManager
/Users/enrico/rxapi.src/rexxapi/common/CSStream.hpp:102:7: note: 
'ServerConnectionManager' declared here
class ServerConnectionManager
  ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:303:40: 
error: redefinition of 'disconnect'
bool SysServerSocketConnectionManager::disconnect()
   ^
/Users/enrico/rxapi.src/rexxapi/common/CSStream.hpp:117:18: note: previous 
definition is here
virtual bool disconnect() { return false; };
 ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:305:9: 
error: use of undeclared identifier 'c'
if (c != -1)
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:307:21: 
error: use of undeclared identifier 'c'
closesocket(c);
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:308:9: 
error: use of undeclared identifier 'c'
c = -1;
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:310:16: 
error: use of undeclared identifier 'boundServiceName'
unlink(boundServiceName);
   ^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:311:9: 
error: use of undeclared identifier 'boundServiceName'
boundServiceName = NULL;
^
/Users/enrico/rxapi.src/rexxapi/common/platform/unix/SysCSStream.cpp:316:22: 
error: use of undeclared identifier 'userServiceName'
free((void *)userServiceName);
 ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.


BTW I am testing on apple
cheers
Enrico


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

[Enrico Sorichetti via Oorexx-devel]

Same on apple High Sierra 


> On 28 Nov 2018, at 18:35, Erich Steinböck  wrote:
> 
> Should compile without error with latest commit.
> There's still a link error that needs to be resolved.  I checked the rexxapi 
> libray definition in CMakeLists.txt, but couldn't figure out what's wrong.
> ~~~
> bin/librexxapi.so.5.0.0: undefined reference to 
> `SysServerLocalSocketConnectionManager::userServiceName'
> ~~~
> 
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html 
> 
>  
> says:"$XDG_RUNTIME_DIR defines the base directory relative to which 
> user-specific non-essential runtime files and other file objects (such as 
> sockets, named pipes, ...) should be stored. The directory MUST be owned by 
> the user, and he MUST be the only one having read and write access to it. Its 
> Unix access mode MUST be 0700.
> The lifetime of the directory MUST be bound to the user being logged in. It 
> MUST be created when the user first logs in and if the user fully logs out 
> the directory MUST be removed. If the user logs in more than once he should 
> get pointed to the same directory, and it is mandatory that the directory 
> continues to exist from his first login to his last logout on the system, and 
> not removed in between. Files in the directory MUST not survive reboot or a 
> full logout/login cycle. "
> 
> Would that (see bold) mean that we couldn't keep a Rexx script running in the 
> background while logging out, because this would remove the socket?
> 
> ___
> 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.

[Enrico Sorichetti via Oorexx-devel]

Apple High Sierra

The build was successful

Started the test suite , but 

[enrico@enrico-imac ooRexx.tests.svn]$rexx testOORexx.rex -s -X native_api
Searching for test containers...
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Illegal instruction: 4


Where do I start to debug it 

I AM NOT ASKING YOU TO DO IT, 
I ASKING FOR A HINT ON HOW TO START

My best regards 

Dr. Enrico Sorichetti

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

[Enrico Sorichetti via Oorexx-devel]

First attempt with a script I wrote 


[enrico@enrico-imac zz]$lldb -- rexx unxmit FILE206.xmi
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "unxmit" "FILE206.xmi"
(lldb) run
Process 4488 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
unxmit   - Started : 23:03:45

unxmit   - Input   : FILE206.xmi
unxmit   - $$cbtdoc  recds( 145) bytes(  8231) 
file(FILE206/$$cbtdoc.txt)
unxmit   - $$pcdoc   recds( 139) bytes(  7895) file(FILE206/$$pcdoc.txt)
unxmit   - $updjcl   recds(  16) bytes(   593) file(FILE206/$updjcl.txt)
unxmit   - dcoljcl   recds( 118) bytes(  3560) file(FILE206/dcoljcl.txt)
unxmit   - parsrtn   recds(  80) bytes(  3549) file(FILE206/parsrtn.txt)
unxmit   - rexxrtn   recds(2837) bytes(103188) file(FILE206/rexxrtn.txt)
unxmit   - Ended   : 23:03:45 Elapsed : 0
*
Process 4488 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
Target 0: (rexx) stopped.
(lldb) frame info
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190) 
at CSStream.hpp:64
(lldb) frame 0
invalid command 'frame 0'.
(lldb) frame select 0
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101500190) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
(lldb) frame variable
(SysLocalSocketConnection *) this = 0x000101500190
(lldb) quit
Quitting LLDB will kill one or more processes. Do you really want to proceed: 
[Y/n] Y
[enrico@enrico-imac zz]$


The interrupt occurs after a say “*"
When processing the exit instruction,
Changing the exit to a return did not change anything


And now the result with the test suite,
[enrico@enrico-imac ooRexx.tests.svn]$lldb -- rexx testOORexx.rex -s -X 
native_api
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X" "native_api"
(lldb) r
Process 4562 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
Searching for test containers
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Process 4562 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
libsystem_kernel.dylib`__sendto:
->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
0x7fff711a9de4 <+12>: movq   %rax, %rdi
0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
0x7fff711a9dec <+20>: retq   
Target 0: (rexx) stopped.
(lldb) frame info
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
(lldb) frame select 0
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
libsystem_kernel.dylib`__sendto:
->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
0x7fff711a9de4 <+12>: movq   %rax, %rdi
0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
0x7fff711a9dec <+20>: retq   
(lldb) frame variable
(lldb) q


Do You have enough hints to proceed

E 



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

[Enrico Sorichetti via Oorexx-devel]

And here is the backtrace for the same situations 

My script 

[enrico@enrico-imac zz]$lldb -- rexx unxmit file206.xmi
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "unxmit" "file206.xmi"
(lldb) r
Process 4908 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
unxmit   - Started : 23:45:53

unxmit   - Input   : file206.xmi
unxmit   - $$cbtdoc  recds( 145) bytes(  8231) 
file(file206/$$cbtdoc.txt)
unxmit   - $$pcdoc   recds( 139) bytes(  7895) file(file206/$$pcdoc.txt)
unxmit   - $updjcl   recds(  16) bytes(   593) file(file206/$updjcl.txt)
unxmit   - dcoljcl   recds( 118) bytes(  3560) file(file206/dcoljcl.txt)
unxmit   - parsrtn   recds(  80) bytes(  3549) file(file206/parsrtn.txt)
unxmit   - rexxrtn   recds(2837) bytes(103188) file(file206/rexxrtn.txt)
unxmit   - Ended   : 23:45:53 Elapsed : 0
*
Process 4908 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101000120) 
at CSStream.hpp:64
   61   {
   62   public:
   63   inline ApiConnection() : errcode(CSERROR_OK), messageBuffer(NULL) { 
}
-> 64   inline ~ApiConnection() { disconnect(); if (messageBuffer != NULL) 
{ free(messageBuffer); } }
   65   
   66   inline CSErrorCodeT getError()
   67   {
Target 0: (rexx) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION 
(code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x0001003f7c48 
librexxapi.5.0.0.dylib`ApiConnection::~ApiConnection(this=0x000101000120) 
at CSStream.hpp:64
frame #1: 0x0001003f77a2 
librexxapi.5.0.0.dylib`LocalAPIManager::closeConnection(this=0x0001011003b0,
 connection=0x000101000120) at LocalAPIManager.cpp:336
frame #2: 0x0001003f73df 
librexxapi.5.0.0.dylib`LocalAPIManager::shutdownConnections(this=0x0001011003b0)
 at LocalAPIManager.cpp:165
frame #3: 0x0001003f72c2 
librexxapi.5.0.0.dylib`LocalAPIManager::shutdownInstance() at 
LocalAPIManager.cpp:89
frame #4: 0x000100400a59 
librexxapi.5.0.0.dylib`::RexxDeleteSessionQueue() at QueuesAPI.cpp:356
frame #5: 0x0001001d29c7 
librexx.5.0.0.dylib`Interpreter::terminateInterpreter() at Interpreter.cpp:252
frame #6: 0x000100106a3f 
librexx.5.0.0.dylib`::Terminate(c=0x000102011840) at 
InterpreterInstanceStubs.cpp:58
frame #7: 0x00012e06 
rexx`RexxInstance_::Terminate(this=0x000102011840) at oorexxapi.h:753
frame #8: 0x00012b90 rexx`main(argc=3, argv=0x7ffeefbff7f8) at 
rexx.cpp:174
frame #9: 0x7fff71059015 libdyld.dylib`start + 1
frame #10: 0x7fff71059015 libdyld.dylib`start + 1
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: 
[Y/n] Y


The test suite 

[enrico@enrico-imac ooRexx.tests.svn]$lldb -- rexx testOORexx.rex -s -X 
native_api
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X" "native_api"
(lldb) r
Process 4913 launched: '/Users/enrico/rxapi/bin/rexx' (x86_64)
Searching for test containers
Executing automated test suite
Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup
Executing tests from .../ooRexx/extensions/hostemu/hostemu.testGroup
Executing tests from .../extensions/platform/unix/rxunixsys/SysUnix.testGroup
Executing tests from .../ooRexx/extensions/rxsock/socketClass.testGroup
Executing tests from .../ooRexx/extensions/rxregexp/rxregexp.testGroup
Executing tests from .../ooRexx.tests.svn/ooRexx/extensions/json/json.testGroup
Executing tests from .../ooRexx/extensions/rxmath/RxMath.testGroup
Executing tests from .../ooRexx/utilities/rxqueue/rxQueue.testGroup
Process 4913 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
libsystem_kernel.dylib`__sendto:
->  0x7fff711a9de2 <+10>: jae0x7fff711a9dec; <+20>
0x7fff711a9de4 <+12>: movq   %rax, %rdi
0x7fff711a9de7 <+15>: jmp0x7fff711a0b0e; cerror
0x7fff711a9dec <+20>: retq   
Target 0: (rexx) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
  * frame #0: 0x7fff711a9de2 libsystem_kernel.dylib`__sendto + 10
frame #1: 0x0001004076ca 
librexxapi.5.0.0.dylib`SysSocketConnection::write(this=0x000100502060, 
buf=0x7ffeefbfa910, bufsize=600, byteswritten=0x7ffeefbfa828) at 
SysCSStream.cpp:115
frame #2: 0x000100407786 
librexxapi.5.0.0.dylib`SysSocketConnection::write(this=0x000100502060, 
buf=0x7ffeefbfa910, bufsize=600, buf2=0x, buf2size=0, 
byteswritten=0x7ffeefbfa828) at SysCSStream.cpp:145
frame #3: 

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

[Enrico Sorichetti via Oorexx-devel]

> On 9 Jan 2019, at 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.



Are You implying that the few thousands packages of the unix like world who use 
the traditional structure

Install prefix 
… bin
… include
… lib 
… share

Are designed and implemented by  people who impose a useless overhead ?

I  respectfully suggest that You read and meditate on

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

 
E







___
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

[Enrico Sorichetti via Oorexx-devel]

Right now You cannot relocate the installed thing 
Because the rpath is an absolute one 
I posted a few emails back the right constructs …

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)

Without the RPATH setting the exports are required 

( tested on El Capitan, high Sierra, Mojave and Fedora 29 )

Why would anybody set multiple paths ???

If things have been done properly no need.

Cheers
Enrico

> On 8 Jan 2019, at 15:46, Rony G. Flatscher  wrote:
> 
> 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?

___
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

[Enrico Sorichetti via Oorexx-devel]

I wonder why everybody refuses to use the proper constructs for the RPATH
Looks like I am wasting my time testing and making suggestions 
E

> On 8 Jan 2019, at 16:08, P.O. Jonsson  wrote:
> 
> With this convention - would it be possible to make the executables 
> relocatable?

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

[Enrico Sorichetti via Oorexx-devel]

Seems strange …
~/Applications is not provided by APPLE 
So it carries the privileges You had when You created it,
Pretty easy to chown and chmod 

E

> On 3 Jan 2019, at 17:18, René Jansen  wrote:
> 
> And one update: to my great astonishment, I cannot make a directory in 
> ~/Applications either (without sudo) - when I assumed that everything in my 
> home directory belongs to my userid. Strange.
> I’ll try to install to something else in my home dir after I tried /opt/rexx
> 

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

[Enrico Sorichetti via Oorexx-devel]

I does not make any difference …
As long as the RPATH is properly defined 

As an absolute path pointing to the  directory

Or as a relative path,  specified as  @executable_path/../lib
( my preferred way )

I just ran the test suite 

rexx testOORexx.rex -s -X native_API

Tests ran:  22523
Assertions: 376855
Failures:   0
Errors: 0

File search:00:00:01.065668
Suite construction: 00:00:01.123907
Test execution: 00:02:59.182203
Total time: 00:03:01.863946

E


> On 3 Jan 2019, at 17:07, René Jansen  wrote:
> 
> I cannot see how /opt/rexx would make a difference as opposed to 
> ~/Applications/ooRexx5.0.0, but I will gladly yield my point of view when it 
> can be explained, for example if @rpath works different there. 

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

[Enrico Sorichetti via Oorexx-devel]

Oops my bad,
I forgot to tell that I changed all my CMakeLists to use 

cmake_minimum_required( VERSION 3.12 )

And with that  CMAKE provides the proper RPATH handling 
Without specifying anything 
,
I just run otool -l  rexx 
And all the  rexx libraries are prefixed with the @rpath construct

Snip…

Load command 13
  cmd LC_LOAD_DYLIB
  cmdsize 56
 name @rpath/librexx.5.0.0.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
  current version 5.0.0
compatibility version 0.0.0
Load command 14
  cmd LC_LOAD_DYLIB
  cmdsize 56
 name @rpath/librexxapi.5.0.0.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
  current version 5.0.0
compatibility version 0.0.0


Snip...

Enrico 

PS.

If You want I can give You access to my bitbucket repo so that You can see my 
mods
Faster than cut and paste them  in the emails 
Just tell me what email You prefer  and I will put You in the authorised users 
list


> On 3 Jan 2019, at 18:06, René Jansen  wrote:
> 
> 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.
> 

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

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

[Enrico Sorichetti via Oorexx-devel]

Very little to look at ,
Tempnam is on the road of being deprecated also by gcc  
On fedora 29

rexxutil.cpp:(.text+0x14e): warning: the use of `tempnam' is dangerous, better 
use `mkstemp'

gcc --version
gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6)


The only problem with mkstemp is that it returns a handle to an open temporary 
file
While the rexx usage of tempnam asks only for a reasonable random file name 


And as far as the semaphore_ things 

I will try to put together a small script 
And I will keep You posted on the result

And as far as the dangling rexximage process  
Sometimes it happens sometimes not,
Not easy IMO to debug 

Enrico

> On 4 Jan 2019, at 17:42, Erich Steinböck  wrote:
> 
> Hi P.O., the compilation time warnings are unrelated to the rexximage issue.  
> We will look into it and will let you know.
> ___
> 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 ooRexx with Debug

[Enrico Sorichetti via Oorexx-devel]

The build types as defined by CMAKE provide as a courtesy to the developer
A set of predefined flags for the compiler and the linker 

CMAKE_C_FLAGS=''
CMAKE_C_FLAGS_DEBUG='-g'
CMAKE_C_FLAGS_MINSIZEREL='-Os -DNDEBUG'
CMAKE_C_FLAGS_RELEASE='-O3 -DNDEBUG'
CMAKE_C_FLAGS_RELWITHDEBINFO='-O2 -g -DNDEBUG'

CMAKE_CXX_FLAGS=''
CMAKE_CXX_FLAGS_DEBUG='-g'
CMAKE_CXX_FLAGS_MINSIZEREL='-Os -DNDEBUG'
CMAKE_CXX_FLAGS_RELEASE='-O3 -DNDEBUG'
CMAKE_CXX_FLAGS_RELWITHDEBINFO='-O2 -g -DNDEBUG'

An equivalent set of flags are provided for the linker 

You are free to define Your own build types 
As long as You define the same set of flags with the last token set
To the build type name 

CMAKE does not check the build type, 
Specifying an unknown build type  implies that no specific flags will be 
provided 

Enrico

  
Ps 

Find attached a function that will dump all the known CMAKE variables
At time of invocation

It will help in finding out the values of little known variables 

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
vDump.cmake
Copyright Enrico Sorichetti 2018 - 2019
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
#]]

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#]]
include_guard( GLOBAL )

#[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#]]
function( vdump _ARGlist _ARGline )

if( ${_ARGline} MATCHES   "^[0-9]+$" )
set( _line "${_ARGline}" )
string( LENGTH "${_line}"  _len )
math( EXPR _indx "${_len} - 4" )
string(SUBSTRING ${_line} ${_indx} -1 _line )
else()
string( REGEX REPLACE "[^a-zA-Z0-9_]" "_" _line  "${_ARGline}" )
endif()

get_filename_component( _list "${_ARGlist}" NAME_WE)
if( "${_line}" STREQUAL "" )
string( REGEX REPLACE "[^a-zA-Z0-9_]" "_"
_out "vars_for_${_list}")
else()
string( REGEX REPLACE "[^a-zA-Z0-9_]" "_"
_out "vars_for_${_list}_at_${_line}")
endif()

set( _out "${CMAKE_BINARY_DIR}/${_out}.txt" )
file( REMOVE ${_out} )

set( _buf "" )

get_cmake_property( _vars VARIABLES )

foreach( _var IN LISTS _vars )
string( LENGTH "${_var}"  _len )
if( _len LESS 4 )
continue()
endif()
if( "${_var}" MATCHES "^(_)" )
continue()
endif()
if( "${_var}" MATCHES "^(ARG)" )
continue()
endif()
if( "${_var}" STREQUAL "OUTPUT" )
continue()
endif()
if( "${_var}" MATCHES "(_CONTENT)$" )
continue()
endif()
if( "${_var}" MATCHES "(_COMPILER_ID_TOOL_MATCH_REGEX)$" )
continue()
endif()

string( APPEND _buf "[[ ${_var}='${${_var}}'\n" )
endforeach()

file( WRITE "${_out}" "${_buf}" )

endfunction()


Just invoke it with 

vdump( ${CMAKE_CURRENT_LIST_FILE} "${CMAKE_CURRENT_LIST_LINE}” )



> On 4 Jan 2019, at 20:53, P.O. Jonsson  wrote:
> 
> I think this is related to the question "Questions ad differences between 
> "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?“ asked by Rony  4 Dec 
> 2018, It would be most welcome to have this clarified on all platforms (what 
> switches and where do they interact with the build process).
> 
> I have tried to read cmakelists.txt for answers but does not get me any wiser 
> :-(.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] CMakeList.txt with rexx.img moved to the lib-directory (Re: A ...

[Enrico Sorichetti via Oorexx-devel]

Please do not do that …

The code used to retrieve the rexx.img location 

Is EXACTLY The same used to retrieve the rxapi location 

While where to put rexx.img can be debated to death
 
Rxapi is certainly an executable and it will be in the  bin-directory

And consistency of the terminology  and coding , in this particular case should 
have the priority

Thank You

E


> On 11 Jan 2019, at 08:45, Rony  wrote:
> 
>> moving rexx.img to the lib-directory at install time).

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

[Enrico Sorichetti via Oorexx-devel]

Unlike other systems where CMAKE is installed thru the system package manager

On APPLE  it has to be installed by  the user and most likely  the user will 
install the latest release

I have been a bit conservative when I talked about 3.12  ,

 I just checked and the download section of cmake proposes 3.13.2  and 3.12.4 

So no problem for apple 

Enrico 
 

> On 3 Jan 2019, at 22:15, Rick McGuire  wrote:
> 
> There has always been some opposition to increases, but I have no problem 
> with making it conditional on the platform (i.e., require that level for Mac 
> builds). 

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

Re: [Oorexx-devel] Current state ad memory enhancements, state of ooRexx 5.0 beta?

[Enrico Sorichetti via Oorexx-devel]

> On 15 Sep 2018, at 22:35, P.O. Jonsson  wrote:
> 
> I fear that will be very difficult,


difficult but not really impossible

I just run a quick and dirty test for my rexx  installed in /opt/oorexx

pkgbuild --identifier com.oorexx.pkg --install-location /opt/mytests --root 
/opt/oorexx  oorexx.pkg

after that 

open oorexx.pkg 

the usual apple dialog appeared

and the installation proceeded

into /opt/mytests

a few things to investigate

but the approach looks workable

cheers
enrico



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

Re: [Oorexx-devel] Current state ad memory enhancements, state of ooRexx 5.0 beta?

[Enrico Sorichetti via Oorexx-devel]

Hello P.OI am using a slightly modified CMakeLists find attached the diffs the command line used is ( naturally after having created the build directory at the same level of oorexx.alt )cmake ../oorexx.alt -DCMAKE_INSTALL_PREFIX=/opt/oorexx -DCMAKE_BUILD_TYPE=Releasebut I am considering to build usingcmake ../oorexx.alt -DCMAKE_INSTALL_PREFIX=/opt/oorexx -DCMAKE_BUILD_TYPE=RelwithDebInfofor unknown reasons sometimes the O3 optimization flag thrashes thingsand looking at various documents there is not too much difference between -O2 and -O3the -g flag is not that much intrusive and gives some debugging hintsafter that the usual make && make install( it would be nice to implement the ctest part of cmake, to provide some basic tests )the quirk is that the pkgbuild must be run pointing to the installed dir( IIRC xCode builds a phony install into /tmp )find attached also the plist built by   pkgbuildcheersenricoP.S.the BUILD TYPE is very important, without it the rexx performance sucks :-)rexxcps.rex gives ( -DCMAKE_BUILD_TYPE=RelwithDebInfo )Performance: 11038575 REXX clauses per second ( TOP )and is normally higher than 1050

oorexx_svn.2.oorexx_alt.diff
Description: Binary data
 

com.oorexx.pkg.plist
Description: Binary data
On 16 Sep 2018, at 10:29, P.O. Jonsson  wrote:Dear Enrico, can you please share with me your CMake command line? It would help me a lot. I use your CMakeLists.txt so I should be able to reproduce what you did.
Von meinen Macbook gesendetHälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se

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

Re: [Oorexx-devel] Current state ad memory enhancements, state of ooRexx 5.0 beta?

[Enrico Sorichetti via Oorexx-devel]

Hello Rony, P.O

Why not consider Apple OS as a member of the *ix/*BSD family
and install as it was done once into /opt/oorexx ?
after all even SUSE - IIRC - suggest to install USER things in /opt

I am against installing into /usr/local , 
too many are using homebrew and You all know how it clobbers the usr/local 
directory

furthermore  ( I do not know about the BSF… thing ) oorexx is NOT an 
application/framework  bundle
so installing into the Application/frameworks  folders is just plain 
illogic/inconsiderate

cheers 
enrico

PS.
my mention of the rexxcps  pseudo performance results
was just to compare the consequence of building oorexx 
without specifying the CMAKE_BUILD_TYPE
( the relevant cmake variables are empty - which implies NO optimization )
and using CMAKE_BUILD_TYPE Release/RelWithDebInfo with the proper flags 
about 2millions cps vs around 11millions cps

thats a common error when using cmake ( forgetting the CMAKE_BUILD_TYPE)
the CMakeLists should fill the unsuffixed optimization flags with reasonable 
defaults 
( I use the same values used for the RelWithDebInfo flags )



> On 16 Sep 2018, at 18:11, Rony G. Flatscher  wrote:
> 
> Dear P.O.:
> 
> On 16.09.2018 18:01, P.O. Jonsson wrote:
> hmm, I would not install the entire ooRexx package into its own directory 
> "ooRexx5.0.0" underneath
> "/usr/local" (otherwise the "/usr/local" directory gets "cluttered" by third 
> party installed
> software). Rather I would install it to "/opt" and only link those ooRexx 
> binaries constituting the
> ooRexx interpreter from there to "/usr/local/bin" and "/usr/local/lib".
> 
> This is because "/usr/local" seems to not be meant for installing "third 
> party packages", rather
> "/opt" is meant for that. [Under MacOSX in addition the Apple advised 
> location for installing
> applications and frameworks would be a possible choice from which then links 
> occur to
> "/usr/local/bin" and "/usr/local/lib". The BSF4ooRexx MacOSX packager does 
> that and honors the Apple
> "Framework" and "Application" installation structure and links from those 
> locations to
> "/usr/local/bin" and "/usr/local/lib".]
> 
> Best regards
> 
> ---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] Wha

[Enrico Sorichetti via Oorexx-devel]

> On 17 Sep 2018, at 11:49, P.O. Jonsson  wrote:
> 
> ~/Applications can be automated using pkgbuild so as to work for other users?

I do not think so, I just rechecked 
the path specified in the pkgbuild command,  when installing is rooted at /
the only way - if rexx is built correctly - to give the user maximum flexibility
is to use makeself  - available at https://makeself.io - tested and works well 
lets the user install things according to his/her standards
cheers
enrico___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Proposal: How about moving the sources for the binaries to the main source tree.

[Enrico Sorichetti via Oorexx-devel]

> Converting this to an out-of-source build might be tricky, 


I beg to disagree …

No more tricky than the same for somebody who wants to build a rexx external 
function

And would like to detect automatically the proper compiler and linker flags

for the unix like environments 

the thing is automated by using pkgconf/pkg-config ( present in all the linux 
installations )
And having ooRexx build the proper oorexx.pc 
As it would be a courtesy just build it straight away
… not difficult at all to do

Or … less elegant 
In the CMakeLists parse the output of the command “which rexx”
And if the oorexx installation respect the STANDARD unix structure (bin, 
include,lib)
It will be easy to determine the proper flags 

E 

Here is a sample snippet

set( _lc_all "$ENV{LC_ALL}" )
set( ENV{LC_ALL} "C" )
execute_process( COMMAND which rexx
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
RESULT_VARIABLE _res
ERROR_VARIABLE  _err
OUTPUT_VARIABLE OOREXXPATH
OUTPUT_STRIP_TRAILING_WHITESPACE )
set( ENV{LC_ALL} "${_lc_all}" )

message( "@@RESULT  '${_res}' " )   
message( "@@RESULT  '${_err}' ")
message( "@@RESULT  '${OOREXXPATH}' " ) 

if( NOT "${_res}" STREQUAL "0" )
message( FATAL_ERROR "
 Open Object Rexx is not installed" )
endif()

get_filename_component( OOREXXHOME "${OOREXXPATH}" REALPATH )

message( "@@Include flag'-I${OOREXXHOME}/include'" )
message( "@@Library flag'-I${OOREXXHOME}/lib'" )



Which when used in the CmakeLists gives ( when rexx is found )

@@  RESULT  '0' 
@@  RESULT  '' 
@@  RESULT  '/opt/ooRexx_Alt/bin/rexx' 
@@  Include flag'-I/opt/ooRexx_Alt/bin/rexx/include'
@@  Library flag'-I/opt/ooRexx_Alt/bin/rexx/lib'


And when not found …

@@  RESULT  '1' 
@@  RESULT  '' 
@@  RESULT  '' 
CMake Error at CMakeLists.txt.test:18 (message):
  

   Open Object Rexx is not installed
Call Stack (most recent call first):
  CMakeLists.txt:131 (include)


-- Configuring incomplete, errors occurre___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] r 11849

[Enrico Sorichetti via Oorexx-devel]

Upgraded everything to 11849 


[failure] [20190325 10:38:52.462233]
  svn:r11734   Change date: 2019-02-08 15:41:41 -0500
  Test:   TEST_NO_FILE
  Class:  SysFileSearch.testgroup
  File:   .../ooRexx/base/rexxutil/SysFileSearch.testGroup
  Line:   84
  Failed: assertSame
Expected: [[3], identityHash="-4517702401"]
Actual:   [[0], identityHash="-4847839793"]



E










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

Re: [Oorexx-devel] DARWIN build issue

[Enrico Sorichetti via Oorexx-devel]

Unfortunately it seems there are some issues with the centos 7 gcc compilers 
 they are a bit outdated g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

And  the build chokes with
 
In file included from 
/home/vagrant/ooRexx.svn.src/interpreter/platform/unix/SysRexxUtil.cpp:181:0:
/home/vagrant/ooRexx.svn.src/interpreter/runtime/RexxUtilCommon.hpp: In 
constructor 'TreeFinder::AttributeMask::AttributeMask()':
/home/vagrant/ooRexx.svn.src/interpreter/runtime/RexxUtilCommon.hpp:278:11: 
error: array used as initializer
   {

Installed clang and everything seems to work even if clang is not the latest one

clang version 3.4.2 (tags/RELEASE_34/dot2-final)

The cmake command  

cmake -G Ninja -DCMAKE_C_COMPILER=`which clang` -DCMAKE_CXX_COMPILER=`which 
clang++` -DCMAKE_INSTALL_PREFIX=/home/vagrant/ooRexx 
-DCMAKE_BUILD_TYPE=Release /home/vagrant/ooRexx.svn.src



To be sure I run the build 2 x 2 and the second run confirmed the first one

Clang works gcc does not
Ninja
E

> On 18 Feb 2019, at 22:15, Rick McGuire  wrote:
> 
> There are spurious leading "_" characters on the #ifdef test. I'll fix this 
> with the other issues you raised shortly. 
> 
> Rick
> 
> On Mon, Feb 18, 2019 at 3:53 PM Erich Steinböck  > wrote:
> Our Mac build slave finds _PC_CASE_SENSITIVE
> 
> ~~~
> -- Looking for _PC_CASE_SENSITIVE
> -- Looking for _PC_CASE_SENSITIVE - found
> ~~~
> 
> but still correctly builds SysFileSystem which seems impossible due to a typo 
> `if (res \= -1)` that should prevent compilation. (The bug repeats a few 
> lines further down).
> 
> The built Rexx executable incorrectly returns true for .File~isCaseSensitive 
> (the file system is not case sensitive).
> 
> SysFileSystem:
> 
> ~~~
> bool SysFileSystem::isCaseSensitive()
> {
> #ifndef _HAVE_PC_CASE_SENSITIVE
> return true;
> #else
> long res = pathconf("/", _PC_CASE_SENSITIVE);
> if (res \= -1)
> {
> return res == 1;
> }
> ~~~
> ___
> 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] DARWIN build issue

[Enrico Sorichetti via Oorexx-devel]

Here is the tested and WORKING code sequence 
IIRC I had to fix the testSuite in a couple of places

I did run the test suite twice , 
once on the boot volume ( case insensitive by default )
The second time on an external disk with a case sensitive file system


Pathconf needs  the  file or directory to exist 

Darwin case sensitiveness applies to each file system 
So in case of file not found it will return the system case sensitiveness 

On NOT Darwin systems it will just cost one extra call , 
If You are trying to squeeze performance to the last bit
The second call could be #ifdeffed  ,

Cheers 
E 



/**
 * indicate whether the file system is case sensitive.
 *
 * @return For Unix systems, always returns true. For MacOS,
 * this needs to be determined on a case-by-case basis.
 * This returns the information for the root file system
 */
bool SysFileSystem::isCaseSensitive()
{
#ifdef HAVE_PC_CASE_SENSITIVE
long res = pathconf("/", _PC_CASE_SENSITIVE);
if (res != -1)
{
return (res==1);
}
#endif
// any error means this value is not supported for this file system
// so the result is most likely true (unix standard)
return true;
}

/**
 * test if an individual file is a case sensitive name
 *
 * @return For Unix systems, always returns true. For MacOS,
 * this needs to be determined on a case-by-case basis.
 */
bool SysFileSystem::isCaseSensitive(const char *name)
{
#ifdef HAVE_PC_CASE_SENSITIVE
long res = pathconf(name, _PC_CASE_SENSITIVE);
if (res != -1)
{
return (res==1) ;
}
// probably file not found
// returns the information for the root file system
res = pathconf("/", _PC_CASE_SENSITIVE);
if (res != -1)
{
return (res==1) ;
}
#endif
// any error means this the value is not supported for this file system
// so the result is most likely true (unix standard)
return true;
}




> On 18 Feb 2019, at 21:52, Erich Steinböck  wrote:
> 
> PC_CASE_SENSITIVE

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

[Oorexx-devel] FILE.testGroup ( filesystem case sensitiveness )

[Enrico Sorichetti via Oorexx-devel]

The fragment of code in

ooRexx/base/class/File.testGroup

  subdir = .File~new("Y/Z", f)

  if .File~separator == "\" then  -- verify the separator translation
  self~assertEquals(f~absolutePath||"\Y\Z", subdir~path)

  if \.File~isCaseSensitive then do
  subdir2 = .File~new("y\z", f)
  self~assertEquals(subdir, subdir2)
  end



Is pretty confusing ,

Anyway it fails when the code to detect the filesystem case sensitivity is 
enabled


[failure] [20190225 21:11:21.756899]
  svn:r11775   Change date: 2019-02-17 20:41:37 +0100
  Test:   TEST_RELATIVE
  Class:  File.testGroup
  File:   .../ooRexx/base/class/File.testGroup
  Line:   185
  Failed: assertEquals
Expected: [[/Users/enrico/ooRexx.svn.testSuite//Y/Z], 
identityHash="-4933862865"]
Actual:   [[/Users/enrico/ooRexx.svn.testSuite//y\z], 
identityHash="-4933872305"]


To enable the check 

The relevant lines in
config.h.in.cmake

Should be changed to
/* Define to 1 if _PC_CASE_SENSITIVE is a valid value */
#cmakedefine HAVE_PC_CASE_SENSITIVE


E



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

Re: [Oorexx-devel] Segmentation fault in rexx executable

[Enrico Sorichetti via Oorexx-devel]

Dear P.O.

Running the test suite is not the best the way - IMO - to debug rexx
The testSuite is sensitive to what is written to stdout and stderr 
And it will usually report testSuite related non existent errors , 
broken pipe, output mismatches, the most recurring ones
And because of that it will nor run many sections of the test

Just isolate the section of the script being investigated 
And run it outside of the test suite

Cheers 
E

BTDTGTTS - been there  done that got the tee shirt


> On 27 Feb 2019, at 12:40, P.O. Jonsson  wrote:
> 
> Dear Moritz,
> 
> Sorry about the delay but I had pressing task and no time for ooRexx. Now I 
> have tried to run the debugger (first-time-noob) but I do not understand the 
> rexx core“ business, can you elaborate?
> 
> osboxes@osboxes:~/workspace/ooRexx-mint19-test$ ulimit -c 100
> 
> osboxes@osboxes:~/workspace/ooRexx-mint19-test$ gdb -silent rexx core
> Reading symbols from rexx...done.
> /home/osboxes/workspace/ooRexx-mint19-test/core: No such file or directory.
> (gdb)
> 
> This works, at least to some extent
> 
> osboxes@osboxes:~/workspace/ooRexx-mint19-test$ gdb -silent -ex=r --args rexx 
> testOORexx.rex -s -R ooRexx/samples
> Reading symbols from rexx...done.
> Starting program: /usr/bin/rexx testOORexx.rex -s -R ooRexx/samples
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Searching for test containers[New Thread 0x77f56700 (LWP 7612)]
> ..
> Executing automated test suite
> Executing .../ooRexx/samples/arithmeticEvaluation.testGroup
> Executing .../ooRexx/samples/month.testGroup
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 27 Feb 2019
> OS Name:LINUX
> SysVersion: Linux 4.15.0-45-generic
> 
> Tests ran:  11
> Assertions: 90
> Failures:   0
> Errors: 0
> 
> File search:00:00:00.120060
> Suite construction: 00:00:00.000917
> Test execution: 00:00:00.256227
> Total time: 00:00:00.760014
> 
> [Thread 0x77f56700 (LWP 7612) exited]
> [Inferior 1 (process 7605) exited normally]
> (gdb)
> 
> And in a real run (a shell script executing the test suite) I got some errors 
> (that are not there when I run the suite outside the debugger)
> 
> osboxes@osboxes:~/workspace$ bash testooRexx.sh
> + cd /home/osboxes/workspace/ooRexx-mint19-test
> + svn update
> Updating '.':
> At revision 11810.
> + . ./setTestEnv.sh
> ++ UNAME_SYSTEM=Linux
> ++ case "${UNAME_SYSTEM}" in
> ++ echo 'Setting env for Linux'
> Setting env for Linux
> +++ pwd
> +++ pwd
> ++ 
> frameworkPath=/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:
> ++ export 
> PATH=/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> ++ 
> PATH=/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> +++ pwd
> ++ export 
> LD_LIBRARY_PATH=/home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:/home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:
> ++ 
> LD_LIBRARY_PATH=/home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:/home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:
> + echo
> 
> + echo 
> /home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> /home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/home/osboxes/workspace/ooRexx-mint19-test:/home/osboxes/workspace/ooRexx-mint19-test/framework:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> + echo
> 
> + echo 
> /home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:/home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:
> /home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:/home/osboxes/workspace/ooRexx-mint19-test/bin/LINUX:
> + echo
> 
> + rexx -e 'parse version v; say v '\''r'\'' || .RexxInfo~revision'
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 27 Feb 2019 r11810
> + sleep 1
> + ulimit -c 100
> + gdb -silent -ex=r --args rexx testOORexx.rex -s -X native_API
> Reading symbols from rexx...done.
> Starting program: /usr/bin/rexx testOORexx.rex -s -X native_API
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Searching for test containers[New Thread 

Re: [Oorexx-devel] Segmentation fault in rexx executable

[Enrico Sorichetti via Oorexx-devel]

Unfortunately the fix breaks more things than it fixes 


[enrico@enrico-imac ooRexx.svn.testSuite]$lldb -- rexx testOORexx.rex -s -X 
native_API -x FUNCTION.testGroup
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-s" "-X" "native_API" 
"-x" "FUNCTION.testGroup"
(lldb) r
Process 29014 launched: '/Users/enrico/ooRexx/bin/rexx' (x86_64)
Process 29014 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=EXC_I386_GPFLT)
frame #0: 0x00010015c3d5 
librexx.5.0.0.dylib`MemoryObject::live(this=0x00010023e428, liveMark=66) at 
RexxMemory.cpp:846
   843  GlobalProtectedObject *p = protectedObjects;
   844  while (p != NULL)
   845  {
-> 846  memory_mark(p->protectedObject);
   847  p = p->next;
   848  }
   849  }
Target 0: (rexx) stopped.


E



> On 28 Feb 2019, at 18:08, Rick McGuire  wrote:
> 
> I just committed a fix that I think closes a GC problem window. Not terribly 
> confident this is a fix for the crash you were seeing, but the stack traces 
> you provided at least hint that it might be. 
> 
> Rick

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

Re: [Oorexx-devel] FILE.testGroup ( filesystem case sensitiveness )

[Enrico Sorichetti via Oorexx-devel]

Hello Erich!
Thank You for trying :-)


Unfortunately things got mixed up

The file separator test was run , resulting in 
  Line:   182
  Failed: assertEquals
Expected: [[/Users/enrico/ooRexx.svn.testSuite//Y/Z], 
identityHash="-4533781185"]
Actual:   [[/Users/enrico/ooRexx.svn.testSuite//Y\Z], 
identityHash="-4533779233"]


An the second test would run only for windows

but this worked,
First test skipped, second test run 


  thisSep = .File~separator
  subdir = .File~new("Y" || thisSep || "Z", f)

  -- verify the separator translation
  if .RexxInfo~platform~caselessStartsWith("Windows") then do
othrSep = thisSep~translate("\/", "/\")
self~assertEquals(f~absolutePath || othrSep || "Y" || othrSep || "Z", 
subdir~path)
  end

  -- verify the case sensitiveness
  if \.File~isCaseSensitive then do
  subdir2 = .File~new("y" || thisSep || "z", f)
  self~assertEquals(subdir, subdir2)
  end


Cheers
E 



> On 2 Mar 2019, at 20:02, Erich Steinböck  wrote:
> 
> Hi Enrico,
> this should be fixed with [r11817]

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

Re: [Oorexx-devel] Segmentation fault in rexx executable

[Enrico Sorichetti via Oorexx-devel]

I got the same a few times …
unfortunately thats a bug almost impossible to fix
Being in the right place at the right time 

I did build a debug version, run rexx under the lldb covers 
But I never got anything out of it ( NEVER CRASHED )

E


On 20 Feb 2019, at 14:59, P.O. Jonsson  wrote:
> 
> Dear developers,
> 
> I am building & testing on a number of different platforms and sometimes on 
> macOS/Darwin I get this when I come to the test (it all runs from a shell 
> script):
> 
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
> Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  
> 4122 Segmentation fault: 11  rexx testOORexx.rex -s -X native_API
> 
> Today I had the same on Ubuntu for the first time:
> 
> Searching for test containers...
> /home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault  
> (core dumped) rexx testOORexx.rex -s -X native_API
> osboxes@ubuntu18-04:~/workspace$ ^C
> osboxes@ubuntu18-04:~/workspace$
> 
> There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
> the culprit but apart from that I could get no further information out. 
> Trying again a 2nd time it always work.
> 
> Is there a way (on macOS or Ubuntu or any other system) to find out more 
> about this? I build „release“ version on all systems. Is such information at 
> all useful for U?
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

Re: [Oorexx-devel] Haiku now at full speed.

[Enrico Sorichetti via Oorexx-devel]

Here is the first draft of the  mods
It passes the testSuite on Darwin 

E 
P.S. 
There are some more, I will keep researching



[enrico@enrico-imac ooRexx.svn.src]$svn diff
Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 11796)
+++ CMakeLists.txt  (working copy)
@@ -344,7 +344,20 @@
 set (ORX_SYSLIB_PTHREAD pthread)
 endif ()
 
+
 # Check header files and functions. These are all defined to the config.h file.
+check_include_file(alloca.h HAVE_ALLOCA_H)
+check_include_file(fnmatch.h HAVE_FNMATCH_H)
+check_include_file(sched.h HAVE_SCHED_H)
+check_include_file(sys/sched.h HAVE_SYS_SCHED_H)
+check_include_file(sys/time.h HAVE_SYS_TIME_H)
+check_include_file(time.h HAVE_TIME_H)
+check_include_file(utime.h HAVE_UTIME_H)
+check_include_file(wordexp.h HAVE_WORDEXP_H)
+
+check_function_exists(wordexp HAVE_WORDEXP)
+check_function_exists(euidaccess HAVE_EUIDACCESS)
+
 check_include_file(ctype.h HAVE_CTYPE_H)
 check_include_file(float.h HAVE_FLOAT_H)
 check_include_file(limits.h HAVE_LIMITS_H)
@@ -360,7 +373,6 @@
 check_include_file(stdio.h HAVE_STDIO_H)
 check_include_file(stdlib.h HAVE_STDLIB_H)
 check_include_file(string.h HAVE_STRING_H)
-check_include_file(time.h HAVE_TIME_H)
 check_function_exists(vprintf HAVE_VPRINTF)
 check_include_file(fcntl.h HAVE_FCNTL_H)
 check_function_exists(nanosleep HAVE_NANOSLEEP)
@@ -411,10 +423,10 @@
return 0;}"
   HAVE_DLADDR)
   check_symbol_exists(_PC_CASE_SENSITIVE unistd.h HAVE_PC_CASE_SENSITIVE)
+
   check_symbol_exists(FNM_CASEFOLD fnmatch.h HAVE_FNM_CASEFOLD)
   check_symbol_exists(KDMKTONE linux/kd.h HAVE_KDMKTONE)
   check_include_file(pwd.h HAVE_PWD_H)
-  check_include_file(sched.h HAVE_SCHED_H)
   check_function_exists(sighold HAVE_SIGHOLD)
   check_function_exists(strdup HAVE_STRDUP)
   check_include_file(strings.h HAVE_STRINGS_H)
@@ -428,7 +440,6 @@
   check_include_file(sys/socket.h HAVE_SYS_SOCKET_H)
   check_include_file(sys/stat.h HAVE_SYS_STAT_H)
   check_include_file(sys/syscall.h HAVE_SYS_SYSCALL_H)
-  check_include_file(sys/time.h HAVE_SYS_TIME_H)
   check_include_file(sys/types.h HAVE_SYS_TYPES_H)
   check_include_file(sys/utsname.h HAVE_SYS_UTSNAME_H)
   check_include_file(sys/wait.h HAVE_SYS_WAIT_H)
Index: common/platform/unix/SysSemaphore.cpp
===
--- common/platform/unix/SysSemaphore.cpp   (revision 11796)
+++ common/platform/unix/SysSemaphore.cpp   (working copy)
@@ -50,16 +50,26 @@
 #include 
 #include 
 #include 
-#include 
-#ifdef AIX
-#include 
-#include 
+
+#if defined( HAVE_SYS_SCHED_H )
+# include 
 #endif
+#if defined( HAVE_SCHED_H )
+# include 
+#endif
 
-#if defined(OPSYS_SUN) || defined(__HAIKU__)
-#include 
+#if defined( HAVE_SYS_TIME_H )
+# include 
 #endif
 
+#if defined( HAVE_TIME_H )
+# include 
+#endif
+
+#if defined( HAVE_UTIME_H )
+#include 
+#endif
+
 #include 
 
 #include "SysSemaphore.hpp"
Index: config.h.in.cmake
===
--- config.h.in.cmake   (revision 11796)
+++ config.h.in.cmake   (working copy)
@@ -1,5 +1,37 @@
 /* config.h.in.  Generated from CMake.  */
 
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_SYS_SCHED_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_SCHED_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_SYS_TIME_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_TIME_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_UTIME_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_ALLOCA_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_FNMATCH_H
+
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_WORDEXP_H
+
+
+/* Define to 1 if you have the `wordexp' function. */
+#cmakedefine HAVE_WORDEXP
+
+/* Define to 1 if you have the `euidaccess' function. */
+#cmakedefine HAVE_EUIDACCESS
+
+
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_ATTR_XATTR_H
 
@@ -97,7 +129,7 @@
 #cmakedefine HAVE_DLADDR
 
 /* Define to 1 if _PC_HAVE_CASE_SENSITIVE is a valid value */
-#cmakedefine HAVE_PC_HAVE_CASE_SENSITIVE
+#cmakedefine HAVE_PC_CASE_SENSITIVE
 
 /* Define to 1 if FNM_CASEFOLD is a valid value */
 #cmakedefine HAVE_FNM_CASEFOLD
@@ -108,9 +140,6 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_PWD_H
 
-/* Define to 1 if you have the  header file. */
-#cmakedefine HAVE_SCHED_H
-
 /* Define to 1 if you have the `setlocale' function. */
 #cmakedefine HAVE_SETLOCALE
 
@@ -171,8 +200,6 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SYS_SYSCALL_H
 
-/* Define to 1 if you have the  header file. */
-#cmakedefine HAVE_SYS_TIME_H
 
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SYS_TYPES_H
@@ -183,9 +210,6 @@
 /* 

Re: [Oorexx-devel] DARWIN build issue

[Enrico Sorichetti via Oorexx-devel]

Good Idea… I will run a few tests and let You know 

But …  the backtracking to an existing directory might be murky

E

> On 19 Feb 2019, at 13:23, Rick McGuire  wrote:
> 
> I did what you suggested, but wouldn't performing the check on the directory 
> the file is in give a more accurate result?
> 

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

Re: [Oorexx-devel] Haiku now at full speed.

[Enrico Sorichetti via Oorexx-devel]

The main problem is that the logic for header inclusion is seriously flawed …

The test should be on the availability of features features 
( HEADERS, FUNCTIONS, LIBRARIES)
Not on the system name (*)

Working on it
 As soon I find all the things to fix 
 I will email  the svn diff report with some suggested modifications


I did point them out
And again … the test should not be on the system name 
In my private ooRexx development copy 
I do not care about the system name …
In the CMakeLists I run a compilation of

#include 
int main()
{
charPath[1000];
char   *dPath = Path;
struct  stat file;
lstat64( dPath, );
return (0);
}

And if it fails I set the flag

E

(*)
The only instance where it is needed, because on the different prototype 
definition
#if defined(FREEBSD) || defined(OPENBSD)
return context->WholeNumberToObject((wholenumber_t)setpgrp(0, 0));
#else
return context->WholeNumberToObject((wholenumber_t)setpgrp());
#endif


> On 20 Feb 2019, at 19:35, Jason Martin  wrote:
> 
> This is not all the HAIKU patches but I looked at what I had to do to fix 
> OpenIndiana build.
> 
> GCC or OpenIndiana knew I needed 
> 
> 
> Someone pointed them out with my first patches.
> 
> Regina Rexx get most all right here, including enviroment and Address 
> statements.
> 
> But it is C and ooRexx would be better on Haiku. (C++ OS and C++ GUI)
> 
> OpenBSD ok before the 5.0.0 release you be extra GREAT too!
> 
> The more OSes the better the code.
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Testsuite

[Enrico Sorichetti via Oorexx-devel]

The  code to detect the system is pretty outdated



   -- test for default command processor
   parse source os .  -- get name of operating system
   os1=os~left(1)~translate   -- get first character in uppercase
   if pos(os1, "O W") > 0 then do -- OS2, Windows ?
  self~assertSame("CMD", addr, "default address environment for" 
pp(os)"="pp(addr) "not" pp("CMD"))
  end
   else do-- all Unix platforms should default to 
"sh"
  self~assertSame("sh", addr, "default address environment for" 
pp(os)"="pp(addr) "not" pp("sh"))
  end




It does not detect OPenBSD

E



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

[Oorexx-devel] Testsuite

[Enrico Sorichetti via Oorexx-devel]

In
 
ooRexx/base/keyword/SIGNAL.testGroup
And
ooRexx/base/keyword/CALL.testGroup

The current coding should be changed to

   -- Prevent error messages from the shell printing on the console.
   select
 when .ooRexxUnit.OSName == "WINDOWS"then toNull = '1>nul 2>&1'
 otherwise toNull = '>/dev/null 2>&1'
   end


Also in 
framework/ooRexxUnit.cls


pathCompact

Is still broken for long paths 
and the compaction does not produce an easy readable  information

Executing 
.../ooRexx.testSuite/ooRexx/base/class/CollectionSetlikeMethods.testGroup

is much more readable IMO than  

Executing /Users/enrico/testSuite/.../class/CollectionSetlikeMethods.testGroup


Here is the coding that truncates the head 

\* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*/
::routine pathCompact public
  use strict arg path, len

  if path~length <= len then return path

  sl = .ooRexxUnit.directory.separator

  -- get the last len chars of the path
  head  = "..."
  tail = path~right(len)
  offs = tail~pos(sl)
  tail = tail~substr(offs)
  return head || tail
-- End pathCompact( path, len )


TESTED AND WORKING

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

Re: [Oorexx-devel] rxapi queues

[Enrico Sorichetti via Oorexx-devel]

“ps -ef” is a linux command 
 

But the same happens on Darwin  after around 200 iterations 

E


> On 5 Mar 2019, at 11:44, Rick McGuire  wrote:
> 
> What operating system are you running this on?
> 
> Rick
> 
> On Tue, Mar 5, 2019 at 4:54 AM Bob Martin via Oorexx-devel 
>  > wrote:
> I have a program which runs every few seconds to check that several tasks are 
> still running,
> and restarts them if not.
> The program fails on every build of ooRexx 5 that I have tried it on, back to 
> 11642
> 
> I have reduced the code to the minimum required to produce the error:
> 
> --
> queue_name = rxqueue('Create')
> call rxqueue 'Set',queue_name
> 
> do forever
>'ps -ef | grep rexx | rxqueue' queue_name
>do while queued() <> 0
>   parse pull line
>end
>call SysSleep 1
> end
> exit
> --
> 
> It fails after about 1000 passes through the loop with:
> 
> The REXX rxapi queuing system is not available.
> grep: write error: Broken pipe
> 
> 
> 
> ___
> 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] testSuite revision 11818

[Enrico Sorichetti via Oorexx-devel]

It does not fix anything
It behaves like a politician… it just ignores the problem 

There was not even the need to run the test
Just looking at the code it was easy enough to spot that 
It just runs the  tests on windows only


  subdir = .File~new("Y/Z", f)
  -- verify the separator translation
  -- qualify will translate / to \ on Windows only
  -- on Unix-like systems \ isn't translated to /
  if .File~separator == "\" then do
  self~assertEquals(f~absolutePath||"\Y\Z", subdir~path)
  if \.File~isCaseSensitive then do
  subdir2 = .File~new("y\z", f)
  self~assertEquals(subdir, subdir2)
  end
  end



Jus a little reminder …
On most systems the case sensitivity is an operating system property
On Darwin the case sensitivity is a property of each filesystems
( that is the reason I always run the tests twice ,
On the “Macintosh HD” filesystem and on an usb drive with a case sensitive 
filesystem ) 

the test for case sensitiveness - at least on Darwin - must be done on a real 
file name 

Using.File~isCaseSensitive   returns the case sensitiveness of the boot 
volume  

The docs should be fixed to mention it

So as a courtesy - while I still have some left -
I am posting again the proper solution with a small correction 
Retested on both types of filesystems 


The separator translation and the case sensitivity do NOT depend on each other

  subdir = .File~new("Y/Z", f)
  -- verify the separator translation
  -- qualify will translate / to \ on Windows only
  -- on Unix-like systems \ isn't translated to /
  if .File~separator == "\" then do
  self~assertEquals(f~absolutePath||"\Y\Z", subdir~path)
  end

  -- verify that case sensitivity is properly handled
  —- note the test is done on a Real file  
  subdir = .File~new("Y" || .File~separator || "Z", f)
  if \subdir~isCaseSensitive then do
subdir2 = .File~new("y" || .File~separator || "z", f)
self~assertEquals(subdir, subdir2)
  end


rexx testOORexx.rex -s -F File.testGroup

Run on a case sensitive file system
/Volumes/My Passport for Mac/ooRexx.svn.testSuite

Executing .../ooRexx/base/class/File.testGroup

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 2 Mar 2019
OS Name:DARWIN
SysVersion: Darwin 17.7.0

Tests ran:  29
Assertions: 162
Failures:   0
Errors: 0



rexx testOORexx.rex -s -F File.testGroup

Run on a case insensitive file system
/Users/enrico/ooRexx.svn.testSuite

Executing .../ooRexx/base/class/File.testGroup

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 2 Mar 2019
OS Name:DARWIN
SysVersion: Darwin 17.7.0

Tests ran:  29
Assertions: 163
Failures:   0
Errors: 0













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

Re: [Oorexx-devel] Missing "interpreter/classes/EventSemaphore.cpp" when building from "sandbox\rick\sem"

[Enrico Sorichetti via Oorexx-devel]

I do not see any EventSemaphore.cpp
In main/trunk

Only a SysSemaphore.cpp

common/platform/unix 
Common/platform/windows

E


> On 5 Mar 2019, at 19:40, Rony G. Flatscher  wrote:
> 
> EventSemaphore.cpp

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

Re: [Oorexx-devel] Testcases for sample files

[Enrico Sorichetti via Oorexx-devel]

Do You realise that You are being rude without any reason  ???

E

> On 1 Mar 2019, at 13:09, Rick McGuire  wrote:
> 
> and you should probably have already contributed those corrections rather 
> than just sitting on the information

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

Re: [Oorexx-devel] At revision r11833

[Enrico Sorichetti via Oorexx-devel]

It works !
Thank You
Enrico

PS 
Now it is time to find out why rexx does not complain about 

d = copies("D",6000)
call sysmkdir(d)


f = copies("F",6000)
call lineout f , "a truckload of waste"


o=.stream~new(f)
o~open("replace" )
o~lineout("a truckload of waste" )
o~close

Same behaviour since 4.1.2 ( at least )




> On 11 Mar 2019, at 11:29, Rick McGuire  wrote:
> 
> Ok, I found it...I am really, really surprised this never happened when I was 
> running the tests or Rony had never seen this when he was playing around with 
> the classes. 
> 
> Rick

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

[Oorexx-devel] At revision r11833

[Enrico Sorichetti via Oorexx-devel]

Running the testSuite 

10 times on 10 runs  


Process 7363 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x1b8)
frame #0: 0x000100170a69 
librexx.5.0.0.dylib`Activity::cleanupMutexes(this=0x00010200ef10) at 
Activity.cpp:3505
   3502 {
   3503 if (heldMutexes != OREF_NULL)
   3504 {
-> 3505 Protected semaphores = heldMutexes->allIndexes();
   3506 for (size_t i = 1; i <= semaphores->items(); i++)
   3507 {
   3508 MutexSemaphoreClass *mutex = (MutexSemaphoreClass 
*)semaphores->get(i);
Target 0: (rexx) stopped.


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

Re: [Oorexx-devel] At revision r11833

[Enrico Sorichetti via Oorexx-devel]

No tests were running 
All happened after the display of the final report 
E 




> On 11 Mar 2019, at 10:56, Rick McGuire  wrote:
> 
> Do you know what test was being run? An exception at that point doesn't 
> really make sense. 
> 
> Rick
> 



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

Re: [Oorexx-devel] At revision r11833

[Enrico Sorichetti via Oorexx-devel]

Then it should raise one also on 


f = copies("F",444)
o=.stream~new(f)


Enrico


PS
ooRexx competitor…  regina 
Issues the proper error message

[enrico@enrico-imac tests]$/opt/Regina/bin/rexx d.regina
 3 +++ call lineout f , "a truckload of waste"
Error 40 running "/Users/enrico/tests/d.regina", line 3: Incorrect call to 
routine
Error 40.27: LINEOUT argument 1, must be a valid stream name; found . . . . . .


> On 11 Mar 2019, at 11:59, Rick McGuire  wrote:
> 
> Because it is not allowed to. Rexx streams raise a NOTREADY condition for any 
> failures. 

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

[Oorexx-devel] MAXIMUM_FILENAME_LENGTH and more

[Enrico Sorichetti via Oorexx-devel]

POINT ONE

The logic to determine the MAXIMUM_FILENAME_LENGTH is broken

 the relevant code form the rexx sources 

#include 
#include 

#if defined(PATH_MAX)
# define MAXIMUM_PATH_LENGTH PATH_MAX + 1
#elif defined(_POSIX_PATH_MAX)
# define MAXIMUM_PATH_LENGTH _POSIX_PATH_MAX + 1
#else
# define MAXIMUM_PATH_LENGTH
#endif

#if defined(FILENAME_MAX)
# define MAXIMUM_FILENAME_LENGTH FILENAME_MAX + 1
#elif defined(_MAX_FNAME)
# define MAXIMUM_FILENAME_LENGTH _MAX_FNAME + 1
#elif defined(_POSIX_NAME_MAX)
# define MAXIMUM_FILENAME_LENGTH _POSIX_NAME_MAX + 1
#else
# define MAXIMUM_FILENAME_LENGTH 256
#endif

int main() {
printf("MAXIMUM_PATH_LENGTH %d\n", MAXIMUM_PATH_LENGTH);
printf("MAXIMUM_FILENAME_LENGTH %d\n", MAXIMUM_FILENAME_LENGTH);
return (0);
}


Gives 


APPLE / FreeBSD / OpenBSD
MAXIMUM_PATH_LENGTH 1025
MAXIMUM_FILENAME_LENGTH 1025

Fedora29/Debian9
MAXIMUM_PATH_LENGTH 4097
MAXIMUM_FILENAME_LENGTH 4097



The right coding 


#include 
#include 

#if defined(PATH_MAX)
# define MAXIMUM_PATH_LENGTH PATH_MAX + 1
#elif defined(_POSIX_PATH_MAX)
# define MAXIMUM_PATH_LENGTH _POSIX_PATH_MAX + 1
#else
# define MAXIMUM_PATH_LENGTH 1025
#endif

#if defined(NAME_MAX)
# define MAXIMUM_FILENAME_LENGTH NAME_MAX + 1
#elif defined(_POSIX_NAME_MAX)
# define MAXIMUM_FILENAME_LENGTH _POSIX_NAME_MAX + 1
#else
# define MAXIMUM_FILENAME_LENGTH 256
#endif

int main() {
printf("MAXIMUM_PATH_LENGTH %d\n", MAXIMUM_PATH_LENGTH);
printf("MAXIMUM_FILENAME_LENGTH %d\n", MAXIMUM_FILENAME_LENGTH);
return (0);
}


Returns 

Darwin/FreeBSD/OpenBSD  

MAXIMUM_PATH_LENGTH 1025
MAXIMUM_FILENAME_LENGTH 256


Debian9/Fedora29  

MAXIMUM_PATH_LENGTH 4097
MAXIMUM_FILENAME_LENGTH 256

Also the maximum path length should be defined to something
Or the build should be aborted

# define MAXIMUM_PATH_LENGTH 1025
Should be a reasonable value

The current
# define MAXIMUM_PATH_LENGTH
Results in 
/Users/enrico/ooRexx.svn.src/interpreter/platform/unix/SysFileSystem.hpp:85:49: 
error: expected expression
 MaximumPathLength = MAXIMUM_PATH_LENGTH,


POINT TWO

The utilisation of 

MaximumPathLength
MaximumFileNameLength
MAXIMUM_PATH_LENGTH
MAXIMUM_FILENAME_LENGTH
.rexxinfo~maxpathlength

Is consistently inconsistent ,
Sometime they are used as the length of the items 
Sometime they are used as the length of the buffer to be allocated

POINT THREE

It might be useful
To have also a  .rexxinfo~maxfilenamelength

POINT FOUR. 

Test:   TEST_REXXINFO_DATE

Given the current coding is likely to fail randomly

The dates are filled using the compiler builtin __DATE__

The two terms to be compared are build by different sources 

In an incremental build ( as per make/ninja logic ) 
the two sources might not be built at the same time resulting in the mismatch 

Just happened a few minutes ago 

POINT FIVE 

please run  - on a unix like system 

d  = copies("D",5000)
call sysmkdir(d)

f = copies("F",5000)
call lineout f , "a truckload of equine nitrogen waste”

o=.stream~new(f)
o~open("replace" )
o~lineout( "a truckload of equine nitrogen waste" )
o~close



This  just very small oversight 
has been there at least  since ooRexx-4.1.2
( could not test one previous versions ) 

To give You a hint … 
Nothing is told, nothing happens
The script runs happily without any error

Regina rexx nicely complains

DOES NOT DEPEND ON POINTS ONE/TWO 

E 

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

Re: [Oorexx-devel] Revision 11826/11827 Build failure on Darwin

[Enrico Sorichetti via Oorexx-devel]

Thank You Rick,
It builds and runs the testsuite
E


> On 9 Mar 2019, at 12:45, Rick McGuire  wrote:
> 
> I found some code that can be used as a replacement for 
> pthread_mutex_timedlock if it is not available. This builds cleanly for me on 
> Ubuntu in "fake out" mode. Please try building with the latest version to 
> verify it builds. 
> 
> Rick

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

Re: [Oorexx-devel] Revision 11826/11827 Build failure on Darwin

[Enrico Sorichetti via Oorexx-devel]

f you have the  header file. */
 #cmakedefine HAVE_PWD_H
 
@@ -111,16 +114,16 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SCHED_H
 
-/* Define to 1 if you have the `setlocale' function. */
+/* Define to 1 if you have the 'setlocale' function. */
 #cmakedefine HAVE_SETLOCALE
 
-/* Define to 1 if you have the `sighold' function. */
+/* Define to 1 if you have the 'sighold' function. */
 #cmakedefine HAVE_SIGHOLD
 
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SIGNAL_H
 
-/* Define to 1 if you have the `sigprocmask' function. */
+/* Define to 1 if you have the 'sigprocmask' function. */
 #cmakedefine HAVE_SIGPROCMASK
 
 /* Define to 1 if you have the  header file. */
@@ -132,7 +135,7 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_STDLIB_H
 
-/* Define to 1 if you have the `strdup' function. */
+/* Define to 1 if you have the 'strdup' function. */
 #cmakedefine HAVE_STRDUP
 
 /* Define to 1 if you have the  header file. */
@@ -198,7 +201,7 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_NCURSES_H
 
-/* Define to 1 if you have the `vprintf' function. */
+/* Define to 1 if you have the 'vprintf' function. */
 #cmakedefine HAVE_VPRINTF
 
 /* Name of package */


E



> On 9 Mar 2019, at 09:44, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> I am reporting what the compiler and the docs tell
> 
> Fact
> 1) the function is not present on Darwin 
> Finding ( why )
> 2) the function is not a POSIX standard so the  system does not have to 
> provide it
> 
> The function would work if it was there, but it is not
> 
> AMEN
> 
> 
>> On 9 Mar 2019, at 02:21, Rick McGuire > <mailto:object.r...@gmail.com>> wrote:
>> 
>>  Saying not to use it doesn't help if you are basically saying the function 
>> can't work. 
> 
> ___
> 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] Revision 11826/11827 Build failure on Darwin

[Enrico Sorichetti via Oorexx-devel]

I am reporting what the compiler and the docs tell

Fact
1) the function is not present on Darwin 
Finding ( why )
2) the function is not a POSIX standard so the  system does not have to provide 
it

The function would work if it was there, but it is not

AMEN


> On 9 Mar 2019, at 02:21, Rick McGuire  wrote:
> 
>  Saying not to use it doesn't help if you are basically saying the function 
> can't work. 

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

[Oorexx-devel] Revision 11826/11827 Build failure on Darwin

[Enrico Sorichetti via Oorexx-devel]

/Users/enrico/ooRexx.svn.rem.src/common/platform/unix/SysSemaphore.cpp:235:12: 
error: use of undeclared identifier 'result'
while (result == 0 && !this->postedCount) // Has it been posted? Spurious 
wakeups may occur
   ^
/Users/enrico/ooRexx.svn.rem.src/common/platform/unix/SysSemaphore.cpp:237:9: 
error: use of undeclared identifier 'result'
result = pthread_cond_timedwait(&(this->semCond), &(this->semMutex), 
);
^
/Users/enrico/ooRexx.svn.rem.src/common/platform/unix/SysSemaphore.cpp:241:12: 
error: use of undeclared identifier 'result'
return result != ETIMEDOUT;
   ^
/Users/enrico/ooRexx.svn.rem.src/common/platform/unix/SysSemaphore.cpp:336:12: 
error: use of undeclared identifier 'pthread_mutex_timedlock'
return pthread_mutex_timedlock(, ) == 0;
   ^
4 errors generated.


Easy to fix the result thing

Please note that 

pthread_mutex_timedlock 

is not part of the POSIX pthreads specifications

So to provide maximum portability it should not be used, 

E


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

Re: [Oorexx-devel] MAXIMUM_FILENAME_LENGTH and more

[Enrico Sorichetti via Oorexx-devel]

You are the expert on that!
 I just cloned the logic already implemented for maxpathlength

Enrico

PS.

For my education I will try to implement both of them as methods of the .File 
class
In my sandbox 


> On 7 Mar 2019, at 23:27, Rick McGuire  wrote:
> 
> Would really work better as a class method of the .File class rather than on 
> RexxInfo. That's where we tend to put file system related stuff. 
> 
> Rick

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

Re: [Oorexx-devel] MAXIMUM_FILENAME_LENGTH and more

[Enrico Sorichetti via Oorexx-devel]

Here is the patch to 
fix the MAXIMUM_FILENAME_LENGTH glitch
Implement .RexxInfo~getMaxFileNameLength

[enrico@enrico-imac tests]$rexx -e "say .rexxinfo~maxfilenamelength"
255
[enrico@enrico-imac tests]$rexx -e "say .rexxinfo~maxpathlength"
1024
[enrico@enrico-imac tests]$


Index: interpreter/classes/RexxInfoClass.cpp
===
--- interpreter/classes/RexxInfoClass.cpp   (revision 11825)
+++ interpreter/classes/RexxInfoClass.cpp   (working copy)
@@ -457,7 +457,18 @@
 return new_integer(Numerics::MIN_EXPONENT);
 }

+/**
+ * Return the maximum FileName length allowed by the file system
+ *
+ * @return (Windows) MAX_PATH - 1 or (Unix) NAME_MAX, as an Integer object.
+ */
+RexxObject *RexxInfo::getMaxFileNameLength()
+{
+// usable length is one less, as one char is reserved for the terminating 
NUL
+return new_integer(SysFileSystem::MaximumFileNameLength - 1);
+}

+
 /**
  * Return the maximum path length allowed by the file system
  *
Index: interpreter/classes/RexxInfoClass.hpp
===
--- interpreter/classes/RexxInfoClass.hpp   (revision 11825)
+++ interpreter/classes/RexxInfoClass.hpp   (working copy)
@@ -91,6 +91,7 @@
 RexxObject *getInternalMinNumber();
 RexxObject *getMaxExponent();
 RexxObject *getMinExponent();
+RexxObject *getMaxFileNameLength();
 RexxObject *getMaxPathLength();
 RexxObject *getMaxArraySize();

Index: interpreter/execution/CPPCode.cpp
===
--- interpreter/execution/CPPCode.cpp   (revision 11825)
+++ interpreter/execution/CPPCode.cpp   (working copy)
@@ -1213,6 +1213,7 @@
 CPPM(RexxInfo::getInternalMinNumber),
 CPPM(RexxInfo::getMaxExponent),
 CPPM(RexxInfo::getMinExponent),
+CPPM(RexxInfo::getMaxFileNameLength),
 CPPM(RexxInfo::getMaxPathLength),
 CPPM(RexxInfo::getMaxArraySize),

Index: interpreter/memory/Setup.cpp
===
--- interpreter/memory/Setup.cpp(revision 11825)
+++ interpreter/memory/Setup.cpp(working copy)
@@ -1240,6 +1240,7 @@
 AddMethod("internalMinNumber", RexxInfo::getInternalMinNumber, 0);
 AddMethod("maxExponent", RexxInfo::getMaxExponent, 0);
 AddMethod("minExponent", RexxInfo::getMinExponent, 0);
+AddMethod("maxFileNameLength", RexxInfo::getMaxFileNameLength, 0);
 AddMethod("maxPathLength", RexxInfo::getMaxPathLength, 0);
 AddMethod("maxArraySize", RexxInfo::getMaxArraySize, 0);

Index: interpreter/platform/unix/SysFileSystem.hpp
===
--- interpreter/platform/unix/SysFileSystem.hpp (revision 11825)
+++ interpreter/platform/unix/SysFileSystem.hpp (working copy)
@@ -56,13 +56,11 @@
 #elif defined(_POSIX_PATH_MAX)
 #define MAXIMUM_PATH_LENGTH _POSIX_PATH_MAX + 1
 #else
-#define MAXIMUM_PATH_LENGTH
+#define MAXIMUM_PATH_LENGTH 1025
 #endif

-#if defined(FILENAME_MAX)
-#define MAXIMUM_FILENAME_LENGTH FILENAME_MAX + 1
-#elif defined(_MAX_FNAME)
-#define MAXIMUM_FILENAME_LENGTH _MAX_FNAME + 1
+#if defined(NAME_MAX)
+#define MAXIMUM_FILENAME_LENGTH NAME_MAX + 1
 #elif defined(_POSIX_NAME_MAX)
 #define MAXIMUM_FILENAME_LENGTH _POSIX_NAME_MAX + 1
 #else

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

Re: [Oorexx-devel] Revision 11826/11827 Build failure on Darwin

[Enrico Sorichetti via Oorexx-devel]

OOPS …
I had forgotten to run svn update for the test-suite

The ooRexx/base/class/MutexSemaphore.testGroup

Hangs  on statement 72

IMO the test group should not be run on Darwin,
The documentation is clear, unnamed semaphores are not supported

E



> On 9 Mar 2019, at 13:04, Enrico Sorichetti  wrote:
> 
> Thank You Rick,
> It builds and runs the testsuite
> E
> 
> 
>> On 9 Mar 2019, at 12:45, Rick McGuire > > wrote:
>> 
>> I found some code that can be used as a replacement for 
>> pthread_mutex_timedlock if it is not available. This builds cleanly for me 
>> on Ubuntu in "fake out" mode. Please try building with the latest version to 
>> verify it builds. 
>> 
>> Rick
> 

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