Re: [Oorexx-devel] [CMake] Problems resolving PTHREAD_* symbols.

Follow on, now the build is successful on apple I found the oversight in rxsockfn.cpp at statement 89 instead of #if defined(OPSYS_AIX) || defined(OPSYS_LINUX) it is necessary to use #if defined(OPSYS_AIX) || defined(OPSYS_LINUX) || defined(OPSYS_DARWIN) and … [enrico@enrico-mbp bin]$./rexx

Re: [Oorexx-devel] [CMake] Problems resolving PTHREAD_* symbols.

another follow on :-) there a typo in config.h.in.cmake line 196 should be #define PACKAGE_NAME ${PACKAGE_NAME} enrico -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant

Re: [Oorexx-devel] [CMake] Problems resolving PTHREAD_* symbols.

Hello all, for an oversight in my apple-mail configuration my first post on the topic got lost in the network ( I do not find it in the archives ) here is the original post I guess I found the error/oversight the original CMakelists contains a set(CMAKE_REQUIRED_LIBRARIES

Re: [Oorexx-devel] Fwd: [CMake] Problems resolving PTHREAD_* symbols.

Hello all ! I guess I found the error/oversight the original CMakelists contains a set(CMAKE_REQUIRED_LIBRARIES “pthread;pthread_nonshared) just changing it to set(CMAKE_REQUIRED_LIBRARIES “pthread) solved the problem object of the thread and also solved the undetected functions problem

Re: [Oorexx-devel] More square brackets

My 2cents , IMHO short circuitry -given the amount of discussion it raises about its goods and evils - is probably a personal preference which affects the coding style and dictates the behaviour of a script/program as a whole so why not leave the operators alone and add a new statement or

Re: [Oorexx-devel] What needs installing to get ncurses to build?

on Centos 7 I had to install ncurses-devel Enrico On 28 Oct 2014, at 23:05, Rick McGuire object.r...@gmail.com wrote: -- ___ Oorexx-devel mailing list

Re: [Oorexx-devel] ooRexx Compiled on Mac 10.10.1

in heaven when not linux or windows the system is set to AIX Enrico Sorichetti On 06 Dec 2014, at 21:35, David Ashley w.david.ash...@gmail.com wrote: I got my used Mac Mini last Friday. It was pretty easy to set up. I updated it to OSX 10.10.1 and then install the Xcode application tools

[Oorexx-devel] odd behaviour

I just pulled svn Rev: 10882 it builds and works on APPLE Yosemite using — Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) it builds and seems to work on CENTOS 7 using — c++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) it fails on CENTOS 6 using — c++ (GCC) 4.4.7 20120313 (Red Hat

Re: [Oorexx-devel] odd behaviour

Thank You Rick, I will stick to clang ! Enrico On 10 Feb 2015, at 16:25, Rick McGuire object.r...@gmail.com wrote: There is a known bug in older versions of gcc with namespace support. Upgrading the compiler level is the only known fix. Rick

Re: [Oorexx-devel] Looking Forward (Skills and Talents)

Hello Jon, I have done in the last months a bit of experience with CMAKE and the quirks of CLANG on Yosemite and centos 6 ( I do not like the look of centos 7 ) Please look at my previous post and my work in progress ( I will share it anyway on bitbucket ) and let me know if I can be of help

Re: [Oorexx-devel] Looking Forward (Skills and Talents)

Hello Jon, I am contributing also to the Hercules ( s/370,s/390,zARCH) emulator and I wrote a few modules/functions/macros ( a few hundred lines of code ) to streamline the CMAKE build process and they are published in a couple of hercules repositories under the Q public licence

Re: [Oorexx-devel] building ooRexx 5 on the Raspberry Pi fails - notes

Hello René, probably instead of going for the CMAKE bleeding edge it would be safer to download the stable 3.2.3 which is available for all the platforms needed http://www.cmake.org/download/ I usually download the source and build it myself takes about 15 minutes right now I use

Re: [Oorexx-devel] building ooRexx 5 on the Raspberry Pi fails - notes

Hello René , the closest I have to debian is UBUNTU 14.04 LTS I just checked. apart gazillions of warnings, it build without errors cheers enrico -- ___ Oorexx-devel mailing

Re: [Oorexx-devel] An observation ...

> So my question is "Does the suggested shebang line work for all the *nix > flavors we support?" > > If so, it seems like a minimum amount of editing of the non-Windows-only > *.rex files to put this issue to bed. > Gil B. > On 2/24/2018 7:11 AM, Enrico Sorich

Re: [Oorexx-devel] An observation ...

the segmentation fault is due to Revision: 11358 everything works well at Revision: 11357 > On 24 Feb 2018, at 16:05, oor...@jonases.se wrote: > > POs-MacBook-Pro:ootest po$ rexx testOORexx -X native_api > Searching for test containers.. > Executing automated test suite >

Re: [Oorexx-devel] An observation ...

IMO the most flexible shebang line is #! /usr/env/bin xx in this case #! /usr/env/bin rexx it will pick up the executable according to the precedences set by $PATH environment variable most useful to test different version of Rexx I usually have a couple of them installed in different

Re: [Oorexx-devel] An observation ...

unfortunately just to be sure i just rebuilt Revision: 11358 with the original cmakelists ( which on apple installs to $HOME/Applications/… ) and running /Users/enrico/Applications/ooRexx5.0.0/bin/rexx -e "parse source s;say s;parse version v;say v" resulted in Segmentation fault: 11 while

Re: [Oorexx-devel] Releasing 5.0

Hello everybody, where to install things almost always resulted in a flame war, I speak for the *ix side… why not leave things as they were once upon a time ??? intall to /opt/oorexx if nothing is specified the advantage is that no root priviliges are needed no issues about the subdirectory

Re: [Oorexx-devel] An observation ...

and run full unit tests > for r11358 on Windows, some Linux systems, and Darwin. > > We'd need more details what's going on here. > Rony, can you try to build/run r11358 on Darwin and confirm whether you see a > failure? > > > > On Sat, Feb 24, 2018 at 10

Re: [Oorexx-devel] ooRexx for Mac

Hi Erich,René OSx installs on a case insensitive file system “pwd” reports the working directory with the casing used in the “cd” commands while directory() probably chases the directory chain the proper approach might be to find out if the file system is case sensitive or not and do a

Re: [Oorexx-devel] ooRexx for Mac

it might change across different file systems I just formatted a usb stick as Mac OS Extended (Case-sensitive, Journaled) created aaa and AAA and two files were created enrico > On 28 Feb 2018, at 13:30, Rick McGuire wrote: > > Is this guaranteed that it will always

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

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

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)

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.

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.

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.

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

, 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:

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

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

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

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.

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

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

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.

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.

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

> 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

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.

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

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?

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

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.

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

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.

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.

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.

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.

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.

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.

> 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

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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)

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

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

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)

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.

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

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

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)

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

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

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

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

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.

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.

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.

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

> 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

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

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)

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)

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)

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

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

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

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

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)

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?

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

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?

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

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

> 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

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

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

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 )

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

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

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 )

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

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

  1   2   3   >