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

Funny … after setting a missing CPACK variable Before ooRexx-5.0.0-11767.x86_64.deb The name had a reference to the svn revision After ooRexx-5.0.0-Linux.deb Nothing Weird ??? E ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net

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

something built on a certain a platform WILL NOT run on a different one LINUX will be even more selective There are subtle differences between the different distributions And there are also common practices to deal with … xx.deb is likely a package for Debian family system x.rpm

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

ere it could > be retrieved by a new attribute such as .rexxinfo~distro? > > On 2/16/2019 1:17 PM, Enrico Sorichetti via Oorexx-devel wrote: >> Cmake should return “sunOS” >> >> From the compiler builtin macro >> >> #elif defined(__sun) || defined(sun) >&g

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

Cmake should return “sunOS” From the compiler builtin macro #elif defined(__sun) || defined(sun) # define PLATFORM_ID "SunOS" > On 16 Feb 2019, at 18:40, Jason Martin wrote: > > agrellum@openindiana:~$ uname -v > illumos-c78b1a4529 > > Not OpenIndiana and Not SunOS > > > > >

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

> Should maybe "PARSE SOURCE" return "UBUNTU" instead of "LINUX" to indicate > that it behaves > differently compared to other Linuxes? Parse source return the info provides by CMAKE_SYSTEM_NAME And by some tweak of configure.ac before that I just run a cmake --system-information info.txt

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

had to be rewritten because of that ( I got burned by the atomic support detection ) Cheers E > On 16 Feb 2019, at 15:31, Michael Lueck wrote: > > Enrico Sorichetti via Oorexx-devel wrote: >> Unfortunately Ubuntu is well known also for its odd way of doing things > > >

Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766 and testsuite at r11767

You should be more open minded and Spend more time to learn about the different Linux distributions behaviour I spent a couple of hours installing one more Linux distribution I choose Debian, much more trustworthy as a high lever developer platform … And guess what ??? Executing

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

Unfortunately Ubuntu is well known also for its odd way of doing things > On 16 Feb 2019, at 12:55, Rick McGuire wrote: > > It is Unbuntu's though. ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net

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

Well… that’ not Fedora Linux opinion Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 16 Feb 2019 OS Name:LINUX SysVersion: Linux 4.20.7-200.fc29.x86_64 Tests ran: 22641 Assertions: 377418 Failures: 1 Errors: 0 [failure]

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

Certainly different from windows , On unix it behaves according to the docs deleteFile uses unlink which does not check the permissions on the file E Quoting the libc manual 14.6 Deleting Files <> <> <>You can delete a file with unlink or remove. Deletion actually deletes a file name. If

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

Seems to work, But It looks like [failure] [20190216 09:49:03.638306] svn:r11734 Change date: 2019-02-08 15:41:41 -0500 Test: TEST_FILE_EXISTS Class: SysFileXXX.testgroup File: /Users/enrico/ooRexx.testSuite/.../base/rexxutil/SysFileXXX.testGroup Line: 116 Failed:

[Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11765

[enrico@enrico-imac ooRexx.testSuite]$rexx -v Open Object Rexx Version 5.0.0 r11765 Build date: Feb 16 2019 Addressing mode: 64 Copyright (c) 1995, 2004 IBM Corporation. All rights reserved. Copyright (c) 2005-2019 Rexx Language Association. All rights reserved. This program and the accompanying

Re: [Oorexx-devel] testSuite

NOPE :-) E. [enrico@enrico-imac ooRexx.testSuite]$rexx -v Open Object Rexx Version 5.0.0 r11761 Build date: Feb 15 2019 Addressing mode: 64 Copyright (c) 1995, 2004 IBM Corporation. All rights reserved. Copyright (c) 2005-2019 Rexx Language Association. All rights reserved. This program and the

Re: [Oorexx-devel] errors that are NOT really Rexx errors

m 11:14 schrieb P.O. Jonsson > <mailto:oor...@jonases.se>>: >> >> In test suite from today 11759 there is a modified setTestEnv.sh only >> considering Linux, probably a local version from a developer. Also >> OOREXXUNIT.CLS is modified. I tried replacing both wit

[Oorexx-devel] errors that are NOT really Rexx errors

Just to let You all know Running the test suite Expected: [[REXX-ooRexx_5.0.0(MT)_64-bit 6.05 14 Feb 2019], identityHash="-34387144817"] Actual: [[REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019], identityHash="-34383169473"] Message: .RexxInfo~name should be equal to parse

[Oorexx-devel] testSuite

Fixed the build errors but unfortunately [enrico@enrico-imac ooRexx.testSuite]$rexx testOORexx.rex -s -X native_API -x FUNCTION.testGroup Searching for test containers.. Executing automated test suite ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter:

Re: [Oorexx-devel] Build 11759

Just add to interpreter/classes/NumberStringClass.cpp interpreter/classes/StringClass.cpp interpreter/runtime/RexxUtilCommon.cpp #include #include E > On 15 Feb 2019, at 09:46, P.O. Jonsson wrote: > > For Darwin/macOS I am getting for the first time an error, probably for the > same

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

Dear P.O Having extra separators does not make a path invalid Just try with playing around with ls Just checked ls opt/ooRexx/bin///rexx ls opt/ooRexx/bin/ E > On 7 Feb 2019, at 11:09, P.O. Jonsson wrote: > > Dear Developers, > > When working on modifying

Re: [Oorexx-devel] Releasing ooRexx 5.0? Building on Debian Linux Shared Web Hosting as non-root

Why not simply wrap the build of the ncurses stuff with , for example If( HAVE_NCURSES_H ) the ncurses stuff endif() So that if the curses-devel gets installed there will be no need to revisit the cmakelists.txt E > On 5 Feb 2019, at 23:18, Michael Lueck wrote: > >> >> If you really

Re: [Oorexx-devel] Problems with testgroup FUNCTION.testGroup

For a clean run of the installed use … rexx testOORexx.rex -s -X native_API -x FUNCTION.testGroup And do not bother about the setTestEnv.sh Also the instruction in the readme are just plain wrong They say to invoke it as a command … which implies that the changes to the environment are

Re: [Oorexx-devel] Problems with testgroup FUNCTION.testGroup

Everything works if You run the tests from the Build directory rather than using the installed rexx Cheers E > On 3 Feb 2019, at 14:37, P.O. Jonsson wrote: > > Hi Erich, > > Before I could try ooRexx was already on r11710 and the problem persists. > Could it be that the changes in r11709

Re: [Oorexx-devel] Need some help with linux debugging.

Hi Rick, I gave it a try with svn checkout https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rexxutil oorexx.rick svn info Path: . Working Copy Root Path: /opt/oorexx.rick URL: https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rexxutil Relative URL: ^/sandbox/rick/rexxutil Repository

[Oorexx-devel] Odd behaviour

Hi all I was trying to understand the flow of the library loading so I modified common/platform/unix/SysLibrary.cpp adding one printf after line 93 91 >>// if not found, then try from /usr/lib 92 >>if (libraryHandle == NULL) 93 >>{ ADDED printf("* !!!

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 mailing list

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

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] 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] A potential problem related to the rexximage problem.

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

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.

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] Building ooRexx with Debug

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

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)

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

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

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

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

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

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

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

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

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.

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.

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

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

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

<    1   2