[Oorexx-devel] Ad multiple assignments idea (Re: Discussion: Adding variable references to ooRexx.

On 13.04.2018 09:48, Erich Steinböck wrote: > > This will generally be used in a few selective place, such as situations > where you wish to > return multiple values back from a call or method > > > A neat way to return multiple values might be a syntax like this: > >     r1, r2, .. =

Re: [Oorexx-devel] USE ARG default values with references.

On 16.04.2018 16:21, Rick McGuire wrote: > > > On Mon, Apr 16, 2018 at 9:54 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at > <mailto:rony.flatsc...@wu.ac.at>> wrote: > > On 16.04.2018 14:08, Rick McGuire wrote: >> >> On Mon, Apr 16, 2018 at 8:0

Re: [Oorexx-devel] Address With progress

On 19.04.2018 19:21, Erich Steinböck wrote: > I just committed the Unix implementation of a redirecting system command > handler, that passes all > tests in (an updated) ADDRESS.testGroup. > > It handles OUTPUT in the main thread, and INPUT and ERROR in additional > threads when required. >

Re: [Oorexx-devel] Address With progress

On 19.04.2018 19:21, Erich Steinböck wrote: > I just committed the Unix implementation of a redirecting system command > handler, that passes all > tests in (an updated) ADDRESS.testGroup. > > It handles OUTPUT in the main thread, and INPUT and ERROR in additional > threads when required. >

Re: [Oorexx-devel] USE ARG default values with references.

nces can help a lot in different use cases, including cases where multiple variables from the caller should be referenced/aliased such that they get directly updated in the called routines! ---rony On 18.04.2018 16:34, Rony G. Flatscher wrote: > On 17.04.2018 18:53, Rick McGuire

Re: [Oorexx-devel] Address With progress

A question ad implementation status: is the functionality in trunk already regarded to be fully implemented and functional such that one can start to test it under Windows, Linux and MacOSX? ---rony On 21.04.2018 20:43, Gil Barmwater wrote: > > Yep! Got a clean build after I got ALL the

[Oorexx-devel] Fwd: Address With progress

t.r...@gmail.com> To: Rony G. Flatscher <rony.flatsc...@wu.ac.at> Oops, RexxQueue objects can also be used with USING for both input and output.  Rick On Wed, Apr 25, 2018 at 9:10 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at <mailto:rony.flatsc...@wu.ac.at>> wrote:

Re: [Oorexx-devel] Address With progress

w of any pending work on Windows at least. Erich will > have to speak for the > other platforms.  > > Rick > > On Wed, Apr 25, 2018 at 7:55 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at > <mailto:rony.flatsc...@wu.ac.at>> wrote: > > A question ad imple

[Oorexx-devel] Yet a new update for BSF4ooRexx before the Aruba Rexx symposiuim ...

Just uploaded a new version of BSF4ooRexx for Windows, Linux and MacOSX to: . The MacOSX version includes ooRexx 5.0 from trunk (i.e. with the speed improvements). The zip-archive for Windows and Linux now also includes an

Re: [Oorexx-devel] First error trying to build ooRexx 5.0 on Xubuntu 16.04 x64

Just tried to create a debug version of the current ooRexx trunk on an up-to-date Ubuntu 64 bit and also cannot compile it while building rexxapi.dir/common/platform/unix/SystemSemaphore.cpp What follows are the full information of the attempt, preceeded with the versions of Ubuntu and the gcc

[Oorexx-devel] /usr/include/pthread.h (Re: First error trying to build ooRexx 5.0 on Xubuntu 16.04 x64

Here the /usr/include/pthread.h: /* Copyright (C) 2002-2016 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by

Re: [Oorexx-devel] /usr/include/pthread.h (Re: First error trying to build ooRexx 5.0 on Xubuntu 16.04 x64

On 18.03.2018 16:11, Rick McGuire wrote: > Thanks for including the pthread.h file, that helped me locate the problem  I > had to revert a > change I had made to CMakeLists.txt and add some comments to ensure it > doesn't get "fixed" that > way again. Please update and try again. Did an svn

[Oorexx-devel] A problem only when running more than a certain amount of test units with testOORexx.rex

While going after the current state of some of the reported crashes in the past (could not recreate any anymore) I stumbled over a problem, which may mostly be linked to changes I did to BSF4ooRexx in the past weeks, so will have to go after them one by one. One interesting thing maybe is as

[Oorexx-devel] Significant speed improvements in latest ooRexx 5.0

With Rick's speed improvement patch was applied to ooRexx 5.0 trunk, which are significant in at least calling routines, especially external routines, but also looking up classes and environment symbols if not mistaken. However, when having Rexx

Re: [Oorexx-devel] Significant speed improvements in latest ooRexx 5.0

On a new Linux machine the new ooRexx 5.0 code allows for impressive 1,670,000 external function calls/second! ---rony On 21.03.2018 12:52, Rony G. Flatscher wrote: > > With <http://sourceforge.net/p/oorexx/code-0/11375> Rick's speed improvement > patch was applied to >

Re: [Oorexx-devel] A problem only when running more than a certain amount of test units with testOORexx.rex

lookup in native code. In that case the error message is correct. So please ignore this posting. ---rony On 18.03.2018 22:12, Rony G. Flatscher wrote: > > While going after the current state of some of the reported crashes in the > past (could not > recreate any anymore) I s

Re: [Oorexx-devel] Releasing 5.0

On 23.03.2018 11:43, Michael Lueck wrote: > Greetings ooRexx'ers, > > rvjan...@xs4all.nl wrote: >> >> Would it be a bad idea to freeze a revision one of these days, have a close >> look at it,and try to >> bring it to GA. > > > Why is this still tagged "next release" since a year ago... > > "Add

Re: [Oorexx-devel] Address With progress

On 25.04.2018 18:40, Erich Steinböck wrote: > > Erich will have to speak for the other platforms > > > Unix should be fine.  I just noticed that somehow the latest commit, fixing > the environment for > spawn, didn't come through - did the commit now. > > For Windows there may still be work

Re: [Oorexx-devel] Problems with bug-tracker mailing list

cation eMails, supplying the > email headers of the > last two notification eMails that I received. > > Will report back, if anything new develops. > > —-rony > > Rony G. Flatscher (mobil/e) > > Am 30.09.2018 um 21:51 schrieb Erich Steinböck <mailto:eri

[Oorexx-devel] Ad # 1561

Tried to post this on , however Sourceforge always gets back with a "broken page" error, which I reported to Sourceforge. Maybe opening a new track item would be helpful, in the meantime posting it here. - In the

[Oorexx-devel] Ad debugging with gdb on Linux when Java is involved

While working on Linux and using gdb for debugging, there were constantly SIGSEGV errors that gdb reported and stopped execution. Researching this problem on the net it turns out that Java may refer to inaccessible memory addresses which it will handle when SIGSEGV occur. In the case of running

Re: [Oorexx-devel] CMake: not fetching correct svn revision, latest CMake gives a deprecation warning

On 28.10.2018 16:13, Erich Steinböck wrote: > > Jason, which version of ooRexx 5.0 do you use? > > > Rony, you may have posted this unintentionally here in this thread > Jason is running ooRexx on OpenIndiana, a SUN/Solaris fork Erich, you are right, it should have been a reply to his latest

[Oorexx-devel] CMake on Linux question attempting to build rpm on Ubuntu (Re: CMake: not fetching correct svn revision, latest CMake gives a deprecation warning

file ooRexx-5.0.0-11513.fedora.x86_64.deb yields a file type "Debian binary package (format 2.0)". Is it possible to create a rpm package on Debian? ---rony On 28.10.2018 14:10, Rony G. Flatscher wrote: > Erich, > > On 27.10.2018 18:09, Erich Steinböck wrote: >> R

Re: [Oorexx-devel] CMake: not fetching correct svn revision, latest CMake gives a deprecation warning

Jason, which version of ooRexx 5.0 do you use? Running the samples with rev 11503 work flawlessly on MacOSX and Linux in addition to Windows. ---rony On 28.10.2018 14:10, Rony G. Flatscher wrote: > Erich, > > On 27.10.2018 18:09, Erich Steinböck wrote: >> Rony, the i

Re: [Oorexx-devel] CMake: not fetching correct svn revision, latest CMake gives a deprecation warning

Erich, On 27.10.2018 18:09, Erich Steinböck wrote: > Rony, the issue with CMake not fetching the current SVN number should be > fixed with the latest > change to CMakeLists.txt in [r11506]. it works, great! ---rony ___ Oorexx-devel mailing list

[Oorexx-devel] New beta version of BSF4ooRexx available (version 20181025)

Dear fellow Rexxers, since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from: . BSF4ooRexx is an ooRexx external function package that allows Rexx programs to exploit Java classes. Requiring

Re: [Oorexx-devel] Problem building 32-bit Windows version of ooRexx

On 04.11.2018 21:22, Rick McGuire wrote: > I think I have this fixed in the latest revision. Thank you very much! ---rony ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] New beta version of BSF4ooRexx available (version 20181105)

Dear fellow Rexxers, since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from: , which resolves a bug when using bsf.invokeStrict(). As a result there are no open bugs recorded against this

Re: [Oorexx-devel] Advice needed on scserver.rex and scclient.rex sample programs

How about a configuration option that would allow one to have the "#!/usr/bin/env rexx" hashbang applied instead (this way allowing the default to be overriden)? ---rony On 08.11.2018 15:00, P.O. Jonsson wrote: > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se

[Oorexx-devel] Preparing the release version ...

This past year there have been many remarkable changes (performance improvements from 1.2x to 20x times, memory management, multi threading) and additions (ADDRESS...WITH, variable references) to ooRexx 5.0 beta, which already was great with respect to valuabel and new features a year ago!

[Oorexx-devel] Problem building 32-bit Windows version of ooRexx

Today I tried to cleanly compile ooRexx for the 32-bit Windows environment, but fail with: [ 6%] Building CXX object CMakeFiles/rexxapi.dir/common/platform/windows/SysThread.cpp.obj SysThread.cpp F:\work\svn\oorexx\main\trunk\common\platform\windows\SysThread.cpp(68): error C2664:

[Oorexx-devel] New beta version of BSF4ooRexx available (version 20181002)

Dear fellow Rexxers, since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from: . BSF4ooRexx is an ooRexx external function package that allows Rexx programs to exploit Java classes. Requiring

Re: [Oorexx-devel] Problems with bug-tracker mailing list

t/p/oorexx/admin/bugs/options are not configured to go to the mailing list. The following link contains guidelines on how to configure the mailing list. https://sourceforge.net/p/forge/documentation/Tickets/#options Sincerely, SourceForge Support On 28.09.2018 14:23, Rony G. Flatscher wro

Re: [Oorexx-devel] Problems with bug-tracker mailing list

On 29.09.2018 18:54, Erich Steinböck wrote: > > are others also affected by not receiving e-mails anymore (e.g. getting > the [bugs:#1557] as > <1...@bugs.oorexx.p.re.sourceforge.net > >)? > > Rony, I'm receiving notifications as always, e.g.

[Oorexx-devel] Ad 1557, new info added ( Re: Problems with bug-tracker mailing list

()/SendMessage()/NewArray() etc. in <https://sourceforge.net/p/oorexx/bugs/1557/>. ---rony On 28.09.2018 14:23, Rony G. Flatscher wrote: > > Experiencing problems with the bug tracker list, so I opened a ticket with > sourceforge: > <https://sourceforge.net/p/for

Re: [Oorexx-devel] Ad 1557, new info added ( Re: Problems with bug-tracker mailing list

On 28.09.2018 15:15, Rick McGuire wrote: > The email notifications are working just fine for me. Please do NOT send > follow up emails to the > list. It just adds to the overall noise level. Oh, sorry, I was not aware of that! ---rony ___

Re: [Oorexx-devel] Fwd: [oorexx:bugs] #1560 exposing stems

On 01.10.2018 19:57, Erich Steinböck wrote: > I just received a mail from Gil who writes "between 26 Sept and 30 Sept, I > did not get any > notifications from oorexx-bugs.  Prior to that I got them all AFAIK .. I've > gotten all the posts > for bug # 1560 today." Me too, I got those posts

Re: [Oorexx-devel] Fwd: [oorexx:bugs] #1560 exposing stems

On 01.10.2018 19:30, Erich Steinböck wrote: > As this change also didn't fix Rony's issue, I'll clear the mail forwarding > field again.  Rony, do > you agree? Yes let us try whether clearing it has an effect (other than removing bothering duplicates for the committers). ---rony > > On Mon,

Re: [Oorexx-devel] Fwd: [oorexx:bugs] #1560 exposing stems

Good idea! Will wait a few days hoping that Sourceforge comes back... —-rony Rony G. Flatscher (mobil/e) Am 01.10.2018 um 21:30 schrieb Erich Steinböck : >> Hovering over that symbol pops up "Unsubscribe from this tool" which >> indicates that I am subscribed. &

Re: [Oorexx-devel] Address With and variable references in 5.0.0

quot; > running command [ls -al] yielded the following output, stored in [HI.]: >     24 *-* do i=1 to hi.0 >        >K>     "TO" => "0" >        >>>     "1" > POs-12Core-Pro:addresswith po$  > > > > Hälsningar/Regards/Grüsse, >

Re: [Oorexx-devel] Address With and variable references in 5.0.0

Dear P.O.: On 03.09.2018 15:48, P.O. Jonsson wrote: > One remark: I noticed that "this is not an error“ came over as "his is not an > error“ (missing the > initial „t“) in usefilter1-usefilter3, can you have a 2nd look? interesting, I think you found a bug in the Unix implementations! The

Re: [Oorexx-devel] Latest release (r11494), problems when mutlithreading

018 17:04, Rony G. Flatscher wrote: > > OK, I have spent quite some time on the Linux box. Created debug versions for > ooRexx and > BSF4ooRexx and tried to use gdb to get at the data when the hanging or > exceptions occur. > > Unfortunately, gdb reports SIGSEGV (segmentatio

[Oorexx-devel] Problems with bug-tracker mailing list

rge.net/p/forge/site-support/18514/> Not getting messages about bug in tracker item, e.g. "https://sourceforge.net/p/oorexx/bugs/1557/"* *Status:* open *Created:* Fri Sep 28, 2018 12:21 PM UTC by Rony G. Flatscher *Last Updated:* Fri Sep 28, 2018 12:21 PM UTC *Owner:* nobody Since t

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

Found another way to get it to install by issuing a: install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} COMPONENT Core DESTINATION ${INSTALL_LIB_DIR}) Originally I tried to run "install(CODE...)" that would create the symbolic links. Given that I had arrived at many, many

[Oorexx-devel] A few questions ad CMake and libraries on Unix

Currently on Unix there are "lib*.5.0.0.dylib" (Apple) or "lib*.so.5.0.0" (Linux) shared libraries created where "*" stands for "hostemu", "orxncurses", "rexx", "rexxapi", "rexxutil", "rxmath", "rxregexp", "rxsock", "rxunixsys". In addition there are symbolic links created in the form of

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

Dear P.O., On 01.01.2019 21:44, P.O. Jonsson wrote: > I have just reinstalled a Mac with a completely clean Mojave Setup (to avoid > old file ownerships > etc to linger on etc) and am attacking exactly this question. If you can bear > with me a couple of > days I will report what I have found

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

OK, too long of a day, sent the wrong version! :( On 01.01.2019 21:39, Rony G. Flatscher wrote: > > Currently on Unix there are "lib*.5.0.0.dylib" (Apple) or "lib*.so.5.0.0" > (Linux) shared libraries > created where "*" stands for "hostemu&

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

On 01.01.2019 22:00, Rick McGuire wrote: > Have you tried this:  > > https://stackoverflow.com/questions/35765106/symbolic-links-cmake No, not yet, thank you for the hint! Will try to incorporate it as it allows to define a new target, which with

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

the GUI), hope to be back at the CMakeList for creating the links tomorrow. ---rony On 01.01.2019 22:50, Rony G. Flatscher wrote: > > Found another way to get it to install by issuing a: > > install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} > COMPONENT C

[Oorexx-devel] Ad CMakeList.txt

Doing a "[n]make clean" leaves the following files in bin (Linux, MacOSX): * rexx.1.gz * rexx.cat * rexxc.1.gz * rxqueue.1.gz * rxsubcom.1.gz on Windows, if built with "-DCMAKE_BUILD_TYPE=RELWITHDEBINFO" the following files are in bin left over: callrxnt.ilk callrxwn.ilk

[Oorexx-devel] r11661 builds

Temporarily you may find ooRexx r11661 builds for Windows (32- and 64-bit), Linux (deb+rpm in 64-bit) and MacOSX (64-bit) on my Dropbox at: to ease testing. It seems that if causing the rxapi process to start that

[Oorexx-devel] Releasing ooRexx 5.0?

What would be the thoughts about releasing the current trunk version of ooRexx 5.0 as "general available"? (In order for organisations/companies to adopt 5.0 or to replace older versions of Rexx/ooRexx with 5.0 it would be necessary that it becomes officially GA.) It would be still possible to

Re: [Oorexx-devel] [oorexx:code-0] New commit [r11653] by bigrixx

Just tested that: MacOS builds Linux gcc gets an error during compilation. ---rony P.S.: While cleaning the build directory with "rm -rf *" I mistakingly deleted my  home directory "~" so I will not be able to create builds for ooRexx or BSF4ooRexx for Linux 32- and 64-bit. :-( [As I alotted

Re: [Oorexx-devel] Discussion/questions on #730 Allow ::CONSTANT specified as expression

2) seems the most flexible/powerful one. Constants can be regarded as special attributes that can be accessed in the class object and in each of its instances. Currently their value is a symbol. As you are envisioning some sort of a method execution to determine the constant value, how about

Re: [Oorexx-devel] Building the docs

Use java -X for all switches —-rony Rony G. Flatscher (mobil/e) > Am 25.12.2018 um 22:40 schrieb Rony G Flatscher : > > Use -Xmx fir nax hesp size -Xms initial Java heap size > > —-rony > > Rony G. Flatscher (mobil/e) > >> Am 25.12.2018 um 22:35 schrie

[Oorexx-devel] Ad XDG-variables and sudo ...

Musing with my Ubuntu installation did the following experiments as user "rony": */--- commands as normal user "rony" (no SUDO_* environment variables set):/* rony@rony-linux:~/work/oorexx/trunk$ *env | grep XDG*

Re: [Oorexx-devel] Ad XDG-variables and sudo ...

On 23.12.2018 14:23, Rony G. Flatscher wrote: > Musing with my Ubuntu installation did the following experiments as user > "rony": ... cut ... > > Maybe a strategy could be: if determining that ooRexx executes as "root" > (e.g. comparing $LOGNAME > to &quo

[Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

While compiling for the 32-bit Windows version, svn rev. 11627, the compilation stops with the following error information: ... cut ... [ 72%] Linking CXX shared library bin\orexxole.dll Creating library bin\orexxole.lib and object bin\orexxole.exp [ 72%] Built target orexxole

Re: [Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

> > > > On Mon, Dec 17, 2018 at 8:10 AM Rony G. Flatscher <mailto:rony.flatsc...@wu.ac.at>> wrote: > > While compiling for the 32-bit Windows version, svn rev. 11627, the > compilation stops with the > following error information: > > ...

[Oorexx-devel] [RexxLA] New beta version of BSF4ooRexx available (version 20181221)

Dear fellow Rexxers, since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from: . BSF4ooRexx is an ooRexx external function package that allows Rexx programs to exploit all Java classes and

[Oorexx-devel] Ad Windows-versions ()rev 11542) ...

Created the 32- and the 64-bit versions of Rick's rxapi sandbox. It becomes possible to run the 32- and 64-bit ooRexx interpreters concurrently, at the same time, which is really *great*! This allows among other things to run both interpreters in parallel on the same machine, which especially

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

.exe F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\testUnits>kill 10776 kill: 10776: No such process ---rony On 29.11.2018 18:16, Rony G. Flatscher wrote: > Created the 32- and the 64-bit versions of Rick's rxapi sandbox. > > It becomes possible to run the 32- and 64-bit ooRexx

[Oorexx-devel] Fwd: Ad Windows-versions ()rev 11542) ...

Sorry, the reply-to did not address the list, hence forwarding my posting. ---rony Forwarded Message Subject:Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ... Date: Thu, 29 Nov 2018 18:34:40 +0100 From: Rony G. Flatscher To: Rick McGuire

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

Rebuilt ooRexx from trunk: On 29.11.2018 18:29, Rick McGuire wrote: > On Thu, Nov 29, 2018 at 12:17 PM Rony G. Flatscher <mailto:rony.flatsc...@wu.ac.at>> wrote: ... cut ... > Some remarks on the build process and running the interpreters initially: > > * bot

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

O.K. finished both debug-Windows-installer packages and placed them on my Dropbox (https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0). To install at your own risk ;): * make sure that either ooRexx got uninstalled already or make sure that rxapi is not running

[Oorexx-devel] Ad killing correct rxapi at uninstall of ooRexx

Now, that it has become possible to have different versions of ooRexx run in parallel (even with different bitnesses), how would one be able to figure out/address the correct rxapi process to be killed? Otherwise after installation the rxapi  process continues running (probably until a reboot).

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

While creating new installation packages from trunk for Windows, I have experimented with the different build types with CMake. Question: would the following create a DEBUG or a RELEASE version by default? cmake -G "NMake Makefiles" F:\work\svn\oorexx\main\trunk nmake nmake clean

[Oorexx-devel] revision 11569, MacOS, question ad shebang

revision 11569, MacOS, all ooRexx test units pass This time also warnings when running cmake: cmake -DCMAKE_BUILD_TYPE=relWithDebInfo ~/dev/oorexx_allura/main/trunk ... cut ... -- Looking for pwd.h CMake Warning (dev) at

[Oorexx-devel] Remaining warnings for rev. 11562 on Linux, Mac and Windows ...

As I have compiled ooRexx for all three platforms (temporarily available via my Dropbox at ) I was able to extract the warnings the compilers issue on all three platforms, so here they are in a simple and single-e-mail

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

On 04.12.2018 16:06, Rick McGuire wrote: > Debug compiles the code without a lot of optimizations and also creates the > debug information. > Release compiles with full optimizations and does not create the debug > information. RelWithDebInfo > is the same as Release, but also creates the debug

[Oorexx-devel] New beta version of BSF4ooRexx available (version 20181130)

Dear fellow Rexxers, since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from: . BSF4ooRexx is an ooRexx external function package that allows Rexx programs to exploit all Java classes and

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

On 02.12.2018 17:27, Rick McGuire wrote: > Ok, I have a theory that I'd like you to test out. Run this simple one-line > program after you have > killed rxapi, then run it a second time: > > say value('RXQUEUESESSION',,'ENVIRONMENT') > I suspect the code gives up trying to connect to the rxapi

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

aces and directories the Apple developer rules suggest). In that case there are symbolic links to /usr/local/bin and /usr/local/lib. Will double-double check whether all files from the latest ooRexx.5.0.0 build are in the proper places. ---rony On 03.12.2018 13:47, Rony G. Flatsche

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

01050059bc *librexx.5.0.0.dylib`ArrayClass::lastIndex()* + 12 librexx.5.0.0.dylib`ArrayClass::lastIndex: -> 0x1050059bc <+12>: movq 0x40(%rdi), %rax 0x1050059c0 <+16>: popq %rbp 0x1050059c1 <+17>: retq

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

On 03.12.2018 15:13, Rick McGuire wrote: > btw, this stacktrace is consistent with the mismatch theory. The > RexxAddMacro() api needs to > dynamically resolve and resolve the address of the > RexxTranslateInstoreProgram() callback to > translate the added macro. This stacktrace looks like what

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

On 03.12.2018 14:30, Rony G. Flatscher wrote: >> I will try to write something about the different setup options > Yes, that would be really *very* helpful for me! > > In the meantime I compared all the files from the directory where the test > ran successfully with > /u

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

Dear Enrico, very sorry to have used "Ernesto" mistakingly! :-(( On 03.12.2018 14:10, Enrico Sorichetti via Oorexx-devel wrote: > >> On 3 Dec 2018, at 14:04, Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote: >> >> As Ernesto > > >

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

Now that the sandbox rxapi version of ooRexx can be run off a directory (and therefore also from a stick), would it be possible to run/use ooRexx without even setting the PATH for it? This probably would mean that ooRexx would have to be able to find the pieces that belong to it in the

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

rt back. ---rony > > On Sun, Dec 2, 2018 at 12:19 PM Rony G. Flatscher <mailto:rony.flatsc...@wu.ac.at>> wrote: > > Rev 11552: > > * running the "say value()" program will only show an empty value now, > > * running "rexx testOORexx

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

Forgot to mention: self~macroPath shows the full path to the file "Macrospace.rex", self~ok the value "0" ---rony On 02.12.2018 21:19, Rony G. Flatscher wrote: > > Have to run to get to the dinner place before they close the kitchen, hence >

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

not get triggered o the program exits in the statement with option being "a" + "self~assertEquals(self~OK, SysAddRexxMacro("test_add", self~macroPath, option)) Cannot find out more, sorry. ---rony On 02.12.2018 20:55, Rony G. Flatscher wrote: > > O

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

On 03.12.2018 17:40, Rick McGuire wrote: > This appears to be working really well and solves a lot of problems. Indeed, it does! It is a really *great* and *very beneficial* improvement for ooRexx, which will allow to distribute ooRexx into segments that have been off-duty so far, because of the

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

On 03.12.2018 15:31, Rick McGuire wrote: > It doesn't matter if they are identical or not, the problem is getting two > different versions > loaded. The first one is the actual running interpreter, the second one is > loaded and nothing is > initialized in it, so the call crashes.  > > My guess

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

On 03.12.2018 13:58, Rick McGuire wrote: > What is really needed is a stack trace for the macrospace exception. Here is the stacktrace (thanks to Enrico for pointing out the command!): wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f Macrospace.testGroup -s -S (lldb) target create

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

When creating the deb-package for Ubuntu-Linux installing (and uninstalling) it will report an error: Installation: rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -i ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb Selecting previously unselected package oorexx. (Reading

Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

On 05.12.2018 21:53, Rick McGuire wrote: ... cut ... > This goes beyond just the shebang line though, the bigger question is what > should the > CMAKE_INSTALL_PREFIX be. The line that was added for the Darwin support is > clearly wrong. This > needs to be the expected install location to be used

[Oorexx-devel] Advice for ooRexx test suite: when subclassing ooTestCase and defining a proper constructor then do not forget ...

The ooRexx test framework allows one to create a test group with test cases by simply subclassing the class ooTestCase. If the subclass has a need for a constructor (defines the method 'INIT'), then it is mandatory to invoke the constructor in its superclass otherwise a runtime error will

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

This is just a comment ad SIGPIPE in the test suite, which according to should be either handled or ignored or the socket configured to not raise a

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

Fresh build, trying to compile until: [ 76%] Building CXX object CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp: In function ´int acquireLock(const char*)`:

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

On 01.12.2018 17:24, Rick McGuire wrote: > Thought I had caught all of those. Just committed a fix. Thank you very much! LINUX: Rev. 11549 can be installed and uninstalled without any error messages. The ooRexx test suite runs through (with "-X native_API"). MacOS: Rev. 11549: the

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

On 01.12.2018 18:39, Rick McGuire wrote: > Does the Mac not set the $XDG_RUNTIME_DIR environment variable? No, this is a Linux thing only. ---rony ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net

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

Sorry, was too fast: <https://www.freedesktop.org/wiki/Software/xdg-utils/>. ---rony On 01.12.2018 18:41, Rony G. Flatscher wrote: > On 01.12.2018 18:39, Rick McGuire wrote: >> Does the Mac not set the $XDG_RUNTIME_DIR environment variable? > No, this is a Linux thing

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

The same observation as on MacOS can be experienced on Linux (same four failures in "rxQueue.testGroup"). ---rony On 01.12.2018 18:33, Rony G. Flatscher wrote: > On 01.12.2018 17:24, Rick McGuire wrote: >> Thought I had caught all of those. Just committed a fix. &g

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

On 01.12.2018 19:16, Erich Steinböck wrote: > The latest commit to the rxapi sandbox builds and passes all tests on my > Ubuntu 16.04 VM. > Have never had any rxqueue or Macrospace test failures with any of the > previous rxapi sandbox builds. > Maybe the postings crossed: my posting from 19:02

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

Guire > <mailto:object.r...@gmail.com>> 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 > <mailto:rony.flatsc...@wu.ac.at>> wrote: >> >>

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

d the ooRexx LINUX interpreter and installed it: running the test suite immediately causes the four failures in "rxQueue.testGroup". ---rony On 01.12.2018 18:50, Rony G. Flatscher wrote: > > The same observation as on MacOS can be experienced on Linux (same four > failures in > &quo

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

Currently it is quite a time consuming effort to make sure that all the different ooRexx builds on all of the different operating systems have been built using the latest svn revision. It would be of great help in such situations, if it became possible to learn the (svn) revision number the

[Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

e current state on Apple, will split up such postings in the future. ... cut ... On Wed, Dec 5, 2018 at 8:54 AM Rony G. Flatscher mailto:rony.flatsc...@wu.ac.at>> wrote: > Ad shebang: on Mac after "make" and "make install" will read, e.g. in > rexxtry.rex: &g

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

Creating ooRexx from trunk from scratch into a new (empty) directory, which will create the following rxapi-related files: * ./bin/rxapi * ./bin/librexxapi.5.0.0.dylib * ./bin/librexxapi.dylib -> librexxapi.5.0.0.dylib Then doing a "make install" which will use the created interpreter and

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

Rather discussing general programming questions in bugs where the discussion results evaporate once the item gets closed, I think it makes more sense to discuss them here in the developer list. In the past weeks/months P.O. has started and has been doing an immensive amount of work in learning

<    4   5   6   7   8   9   10   11   12   13   >