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

2018-08-25 Thread 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). > … … ...

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

2018-08-26 Thread 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

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

2019-01-02 Thread 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

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

2019-01-05 Thread 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);

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

2019-01-05 Thread 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

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

2019-01-05 Thread 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.

2019-01-05 Thread Enrico Sorichetti via Oorexx-devel
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 li

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

2019-01-18 Thread 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

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

2019-01-18 Thread 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

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

2019-01-15 Thread 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 #

Re: [Oorexx-devel] Link to WIKI

2018-12-13 Thread 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

Re: [Oorexx-devel] FreeBSD

2018-12-13 Thread 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

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

2018-12-21 Thread 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

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

2018-12-22 Thread 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

Re: [Oorexx-devel] Setting up VirtualBox

2018-12-24 Thread 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

Re: [Oorexx-devel] Setting up VirtualBox

2018-12-24 Thread 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! >

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

2018-11-29 Thread 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

[Oorexx-devel] Good News

2018-12-04 Thread 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

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

2018-12-04 Thread 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_

[Oorexx-devel] Revision 11563

2018-12-04 Thread 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

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

2018-12-07 Thread 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

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

2018-12-07 Thread 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

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

2018-12-02 Thread 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

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

2018-12-02 Thread 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:

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

2018-12-02 Thread 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

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

2018-12-03 Thread 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

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

2018-12-03 Thread 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

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

2018-12-03 Thread 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

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

2018-12-02 Thread 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

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

2018-12-02 Thread 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

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

2018-12-02 Thread 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

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

2018-12-02 Thread 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

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

2018-12-02 Thread Enrico Sorichetti via Oorexx-devel
t 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,

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

2018-12-03 Thread 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? ___

Re: [Oorexx-devel] ooRexx auto-update

2018-12-09 Thread 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,

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

2018-11-29 Thread 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

Re: [Oorexx-devel] sem_init warning messages.

2018-12-04 Thread 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

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

2018-12-01 Thread 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

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

2018-12-01 Thread 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

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

2018-12-01 Thread 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

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

2018-12-01 Thread 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

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

2018-11-25 Thread 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

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

2018-11-21 Thread 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

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

2018-11-21 Thread 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

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

2018-11-25 Thread 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

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

2018-11-27 Thread 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

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

2018-11-27 Thread 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

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

2018-11-21 Thread 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

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

2018-11-21 Thread 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

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

2018-11-28 Thread 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 >

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

2018-11-28 Thread 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

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

2018-11-28 Thread 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 mism

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

2018-11-28 Thread 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. > ~~~

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

2018-11-28 Thread 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

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

2018-11-28 Thread 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'

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

2018-11-28 Thread 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:

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

2019-01-10 Thread 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

Re: [Oorexx-devel] Question ad RPATH and MacOSX

2019-01-08 Thread 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

Re: [Oorexx-devel] Question ad RPATH and MacOSX

2019-01-08 Thread 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?

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

2019-01-03 Thread 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

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

2019-01-03 Thread 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:

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

2019-01-03 Thread Enrico Sorichetti via Oorexx-devel
> On 3 Jan 2019, at 17:26, René Jansen wrote: > > are all your cmake changes checked in to 11657, trunk? No… I use a slimmed cmakelists Wrote a cmake unifdef to get rid of all the stuff irrelevant to my environment But You can use the mods I posted to make the appropriate changes to the

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

2019-01-03 Thread 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

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

2019-01-04 Thread 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

Re: [Oorexx-devel] Building ooRexx with Debug

2019-01-04 Thread 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

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

2019-01-11 Thread 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

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

2019-01-03 Thread 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

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

2018-09-15 Thread 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

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

2018-09-16 Thread 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

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

2018-09-16 Thread 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

Re: [Oorexx-devel] Wha

2018-09-17 Thread 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

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

2018-12-09 Thread 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

[Oorexx-devel] r 11849

2019-03-25 Thread 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],

Re: [Oorexx-devel] DARWIN build issue

2019-02-18 Thread 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:

Re: [Oorexx-devel] DARWIN build issue

2019-02-18 Thread 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

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

2019-02-25 Thread 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",

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

2019-02-27 Thread 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

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

2019-02-28 Thread 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"

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

2019-03-02 Thread 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:

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

2019-02-20 Thread 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: > >

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

2019-02-21 Thread 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

Re: [Oorexx-devel] DARWIN build issue

2019-02-19 Thread 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?

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

2019-02-20 Thread 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

[Oorexx-devel] Testsuite

2019-02-25 Thread 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 ?

[Oorexx-devel] Testsuite

2019-02-22 Thread 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 =

Re: [Oorexx-devel] rxapi queues

2019-03-05 Thread 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 >

[Oorexx-devel] testSuite revision 11818

2019-03-05 Thread 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

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

2019-03-05 Thread 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

Re: [Oorexx-devel] Testcases for sample files

2019-03-01 Thread 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

Re: [Oorexx-devel] At revision r11833

2019-03-11 Thread 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

[Oorexx-devel] At revision r11833

2019-03-11 Thread 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

Re: [Oorexx-devel] At revision r11833

2019-03-11 Thread 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 > ___

Re: [Oorexx-devel] At revision r11833

2019-03-11 Thread 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

[Oorexx-devel] MAXIMUM_FILENAME_LENGTH and more

2019-03-07 Thread 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

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

2019-03-09 Thread 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

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

2019-03-09 Thread Enrico Sorichetti via Oorexx-devel
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 >

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

2019-03-09 Thread 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

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

2019-03-08 Thread 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 ^

Re: [Oorexx-devel] MAXIMUM_FILENAME_LENGTH and more

2019-03-07 Thread 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

Re: [Oorexx-devel] MAXIMUM_FILENAME_LENGTH and more

2019-03-07 Thread 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:

  1   2   >