[Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

[Jack Woehr]

Trying to build on IBM i PASE.
Freshly downloaded 4.2.0 source from SourceForge.
OORexx configures, but the build ends as follows, any tips?

Configure command:
export OBJECT_MODE=64; export LDFLAGS=-Wl,-brtl; ./configure
export OBJECT_MODE=64; export LDFLAGS=-Wl,-brtl; make # it's gmake
...
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=2
-DORX_MOD=0 -DORX_FIX=0 -DOOREXX_COPY_YEAR=\"2005-2013\"
-DORX_SYS_STR=\"unknown\" -DORX_CATDIR=\"/usr/bin\"
-DORX_SHARED_LIBRARY_EXT=\".so\" -I./lib -I./api -I./api/platform/unix
-I./common -I./common/platform/unix -I./interpreter
-I./interpreter/behaviour -I./interpreter/execution -I./interpreter/memory
-I./interpreter/package -I./interpreter/concurrency
-I./interpreter/expression -I./interpreter/instructions
-I./interpreter/classes -I./interpreter/classes/support
-I./interpreter/runtime -I./interpreter/parser -I./interpreter/messages
-I./interpreter/streamLibrary -I./interpreter/platform/common
-I./interpreter/platform/unix -g -O2 -g -O2 -DNOOPT -DPTHREAD_KERNEL
-D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DLINUX -DOPSYS_LINUX -MT
librexx_la-ThreadContextStubs.lo -MD -MP -MF
.deps/librexx_la-ThreadContextStubs.Tpo -c
./interpreter/api/ThreadContextStubs.cpp -o librexx_la-ThreadContextStubs.o
./interpreter/api/ThreadContextStubs.cpp: In function '_RexxPackageObject*
GetRoutinePackage(RexxThreadContext*, RexxRoutineObject)':
./interpreter/api/ThreadContextStubs.cpp:579:12: error: cannot convert
'bool' to 'RexxPackageObject {aka _RexxPackageObject*}' in return
 return false;
^
./interpreter/api/ThreadContextStubs.cpp: In function '_RexxPackageObject*
GetMethodPackage(RexxThreadContext*, RexxMethodObject)':
./interpreter/api/ThreadContextStubs.cpp:594:12: error: cannot convert
'bool' to 'RexxPackageObject {aka _RexxPackageObject*}' in return
 return false;
^
make: *** [Makefile:2566: librexx_la-ThreadContextStubs.lo] Error 1
-- 
Jack Woehr
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021

NON-DISCLOSURE NOTICE:  This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information.  If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited.  If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] OpenIndiana revision 11562

[Jason Martin]

Multiple runs all tests pass.

Drop/Close:

https://sourceforge.net/p/oorexx/patches/205/


man rxqueue: This still does not work but I believe there is a bug 
created already.



   ls | rxqueue MYQ /LIFO
  Place the output from the ls command onto the MYQ queue 
in last-

  in first-out order

   export RXQUEUE=MYQ;rxqueue /CLEAR
  Clear the contents of MYQ



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

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

[Erich Steinböck]

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

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

[Rick McGuire]

Erich,

Could you take care of these once I commit the merge? That way you can make
sure everything builds correctly in one step.

Rick

On Mon, Dec 3, 2018 at 1:29 PM Erich Steinböck 
wrote:

> Are people OK with this?
>>
> Yes!
>
> I believe these could be removed now:
> server/platform/unix/aix
> server/platform/unix/mac
> server/platform/unix/rxapid
>
> maybe also move
> server/platform/unix/linux/ApiService.cpp up one level into /unix and
> adjust CMake
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Commented out assertions in MacroSpace.testGroup.

[Rick McGuire]

I've managed to reproduce it and I think I understand what is causing
the problem.

Rick

On Mon, Dec 3, 2018 at 12:40 PM Erich Steinböck 
wrote:

> I need to get a RelWithDebInfo build set up to look at this further
>>
> A RelWithDebInfo build will also show the crash reasonably often - much
> more often than a debug build
> I'm not really seeing 100% repeat failures with a RELEASE build .. it's
> just about 50% with [r11555].
>
> I will try with the latest [r11556].
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[René Jansen]

+1

> On 3 Dec 2018, at 12:40, Rick McGuire  wrote:
> 
> This appears to be working really well and solves a lot of problems. And it 
> was a LOT smaller change than I expected. I suspect we should give this a 
> good beta shake out, so I'd like to merge these changes back into trunk 
> fairly quickly. Are people OK with this?
> 
> Rick
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



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

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

[Erich Steinböck]

>
> Are people OK with this?
>
Yes!

I believe these could be removed now:
server/platform/unix/aix
server/platform/unix/mac
server/platform/unix/rxapid

maybe also move
server/platform/unix/linux/ApiService.cpp up one level into /unix and
adjust CMake
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[Rony G. Flatscher]

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 is rexx launcher is picking up the version from the same directory, 
> but when RexxAddMacro
> dynamically loads the library, it is getting the first one encountered on the 
> lib path, which
> causes the problem. The solution is don't mix up your setups.
Well, finally I found the reason, which was just totally unexpected: while 
copying the libraries to
the distribution directory the symbolic links got resolved with the physical 
file, causing two
identical versions for each library under different names! This has not caused 
problems for years, tsk!

Reinstating the symbolic links such that e.g. "librexxapi.dylib" is a symbolic 
link that points to
"librexxapi.5.0.0.dylib" etc. causes the Macrogroup.testGroup to run 
successfully!

Here, how I found out on Apple: found the environment variable 
"DYLD_PRINT_LIBRARIES=YES" which will
print all libraries an applications loads, in this case the following was 
printed:

wu114184:trunk rony$ DYLD_PRINT_LIBRARIES=YES rexx testOORexx.rex -f 
Macrospace.testGroup -s -S
dyld: loaded: /usr/local/bin/rexx
dyld: loaded: /usr/local/lib/librexx.5.0.0.dylib
*dyld: loaded: **/usr/local/lib/librexxapi.5.0.0.dylib*
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/libc++.1.dylib
dyld: loaded: /usr/lib/system/libcache.dylib

... cut ...

dyld: loaded: /usr/lib/libc++abi.dylib
dyld: loaded: /usr/local/lib/librexxutil.dylib
*dyld: loaded: **/usr/local/lib/librexxapi.dylib*
dyld: loaded: /usr/local/lib/librxregexp.dylib
Searching for test containers..
Executing automated test suite
Executing testSuite [testCase: [] (an 
ooTestSuite@n/a_-4508788545)@-4508788545] with [2] test cases ...
Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4508815297]
 with [36] test cases ...
... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
dyld: loaded: /usr/local/lib/librexx.dylib
*Segmentation fault: 11*
wu114184:trunk rony$ 

So the same library got loaded twice, once without the version number, once 
with the version number
(see above "/usr/local/lib/librexxapi.dylib " and 
"/usr/local/lib/librexxapi.5.0.0.dylib") .

Then doing a "ls -al /usr/local/lib" yielded:

wu114184:trunk rony$ ls -al /usr/local/lib/librexx*
lrwxr-xr-x  1 root  wheel  66 Dec  3 13:30 
/usr/local/lib/librexx.5.0.0.dylib -> 
/Library/Frameworks/ooRexx.framework/Libraries/librexx.5.0.0.dylib
lrwxr-xr-x  1 root  wheel  60 Dec  3 13:30 /usr/local/lib/librexx.dylib -> 
/Library/Frameworks/ooRexx.framework/Libraries/librexx.dylib
*lrwxr-xr-x 1 root wheel 69 Dec 3 13:30 
/usr/local/lib/librexxapi.5.0.0.dylib ->
/Library/Frameworks/ooRexx.framework/Libraries/librexxapi.5.0.0.dylib 
lrwxr-xr-x 1 root wheel 63
Dec 3 13:30 /usr/local/lib/librexxapi.dylib ->
/Library/Frameworks/ooRexx.framework/Libraries/librexxapi.dylib*
lrwxr-xr-x  1 root  wheel  70 Dec  3 13:30 
/usr/local/lib/librexxutil.5.0.0.dylib -> 
/Library/Frameworks/ooRexx.framework/Libraries/librexxutil.5.0.0.dylib
lrwxr-xr-x  1 root  wheel  64 Dec  3 13:30 /usr/local/lib/librexxutil.dylib 
-> /Library/Frameworks/ooRexx.framework/Libraries/librexxutil.dylib

Which allowed me to see that no symbolic links are present among the libraries 
there, just symbolic
links to the installation directory. Double checking 

Re: [Oorexx-devel] Commented out assertions in MacroSpace.testGroup.

[Erich Steinböck]

>
> I need to get a RelWithDebInfo build set up to look at this further
>
A RelWithDebInfo build will also show the crash reasonably often - much
more often than a debug build
I'm not really seeing 100% repeat failures with a RELEASE build .. it's
just about 50% with [r11555].

I will try with the latest [r11556].
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[Rony G. Flatscher]

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 super user
needs to install it!

> And it was a LOT smaller change than I expected. I suspect we should give 
> this a good beta shake
> out, so I'd like to merge these changes back into trunk fairly quickly. Are 
> people OK with this?
+1

---rony


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

Re: [Oorexx-devel] Commented out assertions in MacroSpace.testGroup.

[Rick McGuire]

Ah, I missed the generateLoad line. I suspect I might have fixed this
problem this morning. I need to get a RelWithDebInfo build set up to look
at this further.

Rick

On Mon, Dec 3, 2018 at 12:17 PM Erich Steinböck 
wrote:

> I uncomment all `/*Dbg` lines (including the `self~generateLoad` line) in
> the Macrospace.testGroup and run it with "rexx Macrospace.testGroup" (or
> "rexx testoorexx -s -f Macrospace")
>
> With a 64-bit RELEASE build it fails almost 100% (not sure if I ever tried
> a 32-bit build)
>
> On Mon, Dec 3, 2018 at 6:06 PM Rick McGuire  wrote:
>
>> The stack on the bug report looks like it came from Linux. How are you
>> running it on Windows to produce the problem?
>>
>> Rick
>>
>> On Mon, Dec 3, 2018 at 11:55 AM Erich Steinböck <
>> erich.steinbo...@gmail.com> wrote:
>>
>>> Yes, I'm still able to reproduce on Windows with [r11555] trunk and
>>> sandbox rxapi
>>> I can't remember if I ever tested this on Linux.
>>>
>>> The failure is very rare when running a DEBUG build, but almost 100%
>>> with a RELEASE build
>>> Stacktrace as reported in [bugs:#1496]
>>> 
>>>
>>>
>>> On Sun, Dec 2, 2018 at 11:18 PM Rick McGuire 
>>> wrote:
>>>
 Erich,

 I just noticed the commented out assertions in MacroSpace.testGroup. I
 restored all of those assertions and was not able to get this to fail under
 and circumstances. Are you able to reproduce that exception any more?

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

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

Re: [Oorexx-devel] Commented out assertions in MacroSpace.testGroup.

[Erich Steinböck]

I uncomment all `/*Dbg` lines (including the `self~generateLoad` line) in
the Macrospace.testGroup and run it with "rexx Macrospace.testGroup" (or
"rexx testoorexx -s -f Macrospace")

With a 64-bit RELEASE build it fails almost 100% (not sure if I ever tried
a 32-bit build)

On Mon, Dec 3, 2018 at 6:06 PM Rick McGuire  wrote:

> The stack on the bug report looks like it came from Linux. How are you
> running it on Windows to produce the problem?
>
> Rick
>
> On Mon, Dec 3, 2018 at 11:55 AM Erich Steinböck <
> erich.steinbo...@gmail.com> wrote:
>
>> Yes, I'm still able to reproduce on Windows with [r11555] trunk and
>> sandbox rxapi
>> I can't remember if I ever tested this on Linux.
>>
>> The failure is very rare when running a DEBUG build, but almost 100% with
>> a RELEASE build
>> Stacktrace as reported in [bugs:#1496]
>> 
>>
>>
>> On Sun, Dec 2, 2018 at 11:18 PM Rick McGuire 
>> wrote:
>>
>>> Erich,
>>>
>>> I just noticed the commented out assertions in MacroSpace.testGroup. I
>>> restored all of those assertions and was not able to get this to fail under
>>> and circumstances. Are you able to reproduce that exception any more?
>>>
>>> Rick
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[Enrico Sorichetti via Oorexx-devel]

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

E

P.S.

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

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

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

Re: [Oorexx-devel] Commented out assertions in MacroSpace.testGroup.

[Rick McGuire]

The stack on the bug report looks like it came from Linux. How are you
running it on Windows to produce the problem?

Rick

On Mon, Dec 3, 2018 at 11:55 AM Erich Steinböck 
wrote:

> Yes, I'm still able to reproduce on Windows with [r11555] trunk and
> sandbox rxapi
> I can't remember if I ever tested this on Linux.
>
> The failure is very rare when running a DEBUG build, but almost 100% with
> a RELEASE build
> Stacktrace as reported in [bugs:#1496]
> 
>
>
> On Sun, Dec 2, 2018 at 11:18 PM Rick McGuire 
> wrote:
>
>> Erich,
>>
>> I just noticed the commented out assertions in MacroSpace.testGroup. I
>> restored all of those assertions and was not able to get this to fail under
>> and circumstances. Are you able to reproduce that exception any more?
>>
>> Rick
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Commented out assertions in MacroSpace.testGroup.

[Erich Steinböck]

Yes, I'm still able to reproduce on Windows with [r11555] trunk and sandbox
rxapi
I can't remember if I ever tested this on Linux.

The failure is very rare when running a DEBUG build, but almost 100% with a
RELEASE build
Stacktrace as reported in [bugs:#1496]



On Sun, Dec 2, 2018 at 11:18 PM Rick McGuire  wrote:

> Erich,
>
> I just noticed the commented out assertions in MacroSpace.testGroup. I
> restored all of those assertions and was not able to get this to fail under
> and circumstances. Are you able to reproduce that exception any more?
>
> Rick
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Merging the rxapi sandbox into trunk

[Rick McGuire]

This appears to be working really well and solves a lot of problems. And it
was a LOT smaller change than I expected. I suspect we should give this a
good beta shake out, so I'd like to merge these changes back into trunk
fairly quickly. Are people OK with this?

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

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

[Rick McGuire]

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 is rexx launcher is picking up the version from the same
directory, but when RexxAddMacro dynamically loads the library, it is
getting the first one encountered on the lib path, which causes the
problem. The solution is don't mix up your setups.

Rick

Rick

On Mon, Dec 3, 2018 at 9:21 AM Rony G. Flatscher 
wrote:

> 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 would happen
> if a second version of the
> > rexx library got loaded and called. None of the static variables in the
> classes have been
> > initialized, so there is an exception. Not a bug, but a problem in your
> setup.
> Thanks, that is what I have feared!
>
> ---
>
> I could verify that all the files from the CMake defined installation
> directory
> (~/Application/ooRexx5.0.0/bin) are identical to the ones in
> /usr/local/bin and /usr/local/lib which
> stem from the BSF4ooRexx installation files. Or with other words: all
> ooRexx related files are
> identical.
>
> Setting PATH and DYLD_LIBRARY_PATH to ~/Application/ooRexx.5.0.0/bin makes
> the test run
> successfully. (The ooRexx files used in the B4R installation package stem
> from that directory.)
>
> As my Mac has been used for years for creating MacOS version of BSF4ooRexx
> and the installation
> packages include ooRexx compiled on that machine over many years, I am not
> sure whether that may
> have an influence on the result of running the Macrospace.testGroup.
>
> Any hints, suggestions what might be a subtle cause for this behavior
> (where and in which order
> would Darwin look for libraries) would be highly appreciated. (Maybe it
> has to do with the Framework
> installation type?)
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

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

[Rony G. Flatscher]

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 would happen if a 
> second version of the
> rexx library got loaded and called. None of the static variables in the 
> classes have been
> initialized, so there is an exception. Not a bug, but a problem in your setup.
Thanks, that is what I have feared!

---

I could verify that all the files from the CMake defined installation directory
(~/Application/ooRexx5.0.0/bin) are identical to the ones in /usr/local/bin and 
/usr/local/lib which
stem from the BSF4ooRexx installation files. Or with other words: all ooRexx 
related files are
identical.

Setting PATH and DYLD_LIBRARY_PATH to ~/Application/ooRexx.5.0.0/bin makes the 
test run
successfully. (The ooRexx files used in the B4R installation package stem from 
that directory.)

As my Mac has been used for years for creating MacOS version of BSF4ooRexx and 
the installation
packages include ooRexx compiled on that machine over many years, I am not sure 
whether that may
have an influence on the result of running the Macrospace.testGroup.

Any hints, suggestions what might be a subtle cause for this behavior (where 
and in which order
would Darwin look for libraries) would be highly appreciated. (Maybe it has to 
do with the Framework
installation type?)

---rony



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

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

[Rick McGuire]

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 would happen if a second version of the
rexx library got loaded and called. None of the static variables in the
classes have been initialized, so there is an exception. Not a bug, but a
problem in your setup.

Rick

On Mon, Dec 3, 2018 at 9:02 AM Rony G. Flatscher 
wrote:

>
> 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 "rexx"
> Current executable set to 'rexx' (x86_64).
> (lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
> "Macrospace.testGroup" "-s" "-S"
> (lldb) r
> Process 3206 launched: '/usr/local/bin/rexx' (x86_64)
> Searching for test containers..
> Executing automated test suite
> Executing testSuite [testCase: [] (an 
> ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
> Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
> ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
>  with [36] test cases ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> Process 3206 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x40)
> frame #0: 0x0001040059bc librexx.5.0.0.dylib`ArrayClass::lastIndex() 
> + 12
> librexx.5.0.0.dylib`ArrayClass::lastIndex:
> ->  0x1040059bc <+12>: movq   0x40(%rdi), %rax
> 0x1040059c0 <+16>: popq   %rbp
> 0x1040059c1 <+17>: retq
> 0x1040059c2 <+18>: nopw   %cs:(%rax,%rax)
> Target 0: (rexx) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x40)
>   * frame #0: 0x0001040059bc librexx.5.0.0.dylib`ArrayClass::lastIndex() 
> + 12
> frame #1: 0x0001040c3f31 
> librexx.5.0.0.dylib`ActivityManager::findActivity(_opaque_pthread_t*) + 33
> frame #2: 0x0001040c4181 
> librexx.5.0.0.dylib`ActivityManager::findActivity() + 17
> frame #3: 0x0001040c44fd 
> librexx.5.0.0.dylib`ActivityManager::getRootActivity() + 13
> frame #4: 0x00010412f14f 
> librexx.5.0.0.dylib`Interpreter::createInterpreterInstance(RexxOption*) + 95
> frame #5: 0x00010412f556 
> librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 
> 230
> frame #6: 0x00010412f605 
> librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 
> 37
> frame #7: 0x0001040c17fb 
> librexx.5.0.0.dylib`ActivityDispatcher::invoke(_RXSYSEXIT*, char const*) + 59
> frame #8: 0x00010406252f 
> librexx.5.0.0.dylib`RexxTranslateInstoreProgram + 79
> frame #9: 0x000100686e1e 
> librexxapi.5.0.0.dylib`LocalMacroSpaceManager::translateRexxProgram(char 
> const*, ManagedRxstring&) + 1118
> frame #10: 0x000100686951 
> librexxapi.5.0.0.dylib`LocalMacroSpaceManager::addMacroFromFile(char const*, 
> char const*, unsigned long) + 65
> frame #11: 0x00010068a69d librexxapi.5.0.0.dylib`RexxAddMacro + 109
> frame #12: 0x00010038d960 
> librexxutil.dylib`SysAddRexxMacro_impl(RexxCallContext_*, char const*, char 
> const*, char const*) + 160
> frame #13: 0x00010038d88c librexxutil.dylib`SysAddRexxMacro + 60
> frame #14: 0x0001040922e6 
> librexx.5.0.0.dylib`NativeActivation::callNativeRoutine(RoutineClass*, 
> NativeRoutine*, Rex

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

[Rick McGuire]

I thought you said everything was working and the problems were caused by a
mix up of file versions?

Rick

On Mon, Dec 3, 2018 at 9:02 AM Rony G. Flatscher 
wrote:

>
> 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 "rexx"
> Current executable set to 'rexx' (x86_64).
> (lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
> "Macrospace.testGroup" "-s" "-S"
> (lldb) r
> Process 3206 launched: '/usr/local/bin/rexx' (x86_64)
> Searching for test containers..
> Executing automated test suite
> Executing testSuite [testCase: [] (an 
> ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
> Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
> ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
>  with [36] test cases ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> Process 3206 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x40)
> frame #0: 0x0001040059bc librexx.5.0.0.dylib`ArrayClass::lastIndex() 
> + 12
> librexx.5.0.0.dylib`ArrayClass::lastIndex:
> ->  0x1040059bc <+12>: movq   0x40(%rdi), %rax
> 0x1040059c0 <+16>: popq   %rbp
> 0x1040059c1 <+17>: retq
> 0x1040059c2 <+18>: nopw   %cs:(%rax,%rax)
> Target 0: (rexx) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=1, address=0x40)
>   * frame #0: 0x0001040059bc librexx.5.0.0.dylib`ArrayClass::lastIndex() 
> + 12
> frame #1: 0x0001040c3f31 
> librexx.5.0.0.dylib`ActivityManager::findActivity(_opaque_pthread_t*) + 33
> frame #2: 0x0001040c4181 
> librexx.5.0.0.dylib`ActivityManager::findActivity() + 17
> frame #3: 0x0001040c44fd 
> librexx.5.0.0.dylib`ActivityManager::getRootActivity() + 13
> frame #4: 0x00010412f14f 
> librexx.5.0.0.dylib`Interpreter::createInterpreterInstance(RexxOption*) + 95
> frame #5: 0x00010412f556 
> librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 
> 230
> frame #6: 0x00010412f605 
> librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 
> 37
> frame #7: 0x0001040c17fb 
> librexx.5.0.0.dylib`ActivityDispatcher::invoke(_RXSYSEXIT*, char const*) + 59
> frame #8: 0x00010406252f 
> librexx.5.0.0.dylib`RexxTranslateInstoreProgram + 79
> frame #9: 0x000100686e1e 
> librexxapi.5.0.0.dylib`LocalMacroSpaceManager::translateRexxProgram(char 
> const*, ManagedRxstring&) + 1118
> frame #10: 0x000100686951 
> librexxapi.5.0.0.dylib`LocalMacroSpaceManager::addMacroFromFile(char const*, 
> char const*, unsigned long) + 65
> frame #11: 0x00010068a69d librexxapi.5.0.0.dylib`RexxAddMacro + 109
> frame #12: 0x00010038d960 
> librexxutil.dylib`SysAddRexxMacro_impl(RexxCallContext_*, char const*, char 
> const*, char const*) + 160
> frame #13: 0x00010038d88c librexxutil.dylib`SysAddRexxMacro + 60
> frame #14: 0x0001040922e6 
> librexx.5.0.0.dylib`NativeActivation::callNativeRoutine(RoutineClass*, 
> NativeRoutine*, RexxString*, RexxObject**, unsigned long, ProtectedObject&) + 
> 614
> frame #15: 0x000104096746 
> librexx.5.0.0.dylib`NativeRoutine::call(Activity*, RoutineClass*, 
> RexxString*, RexxObject**, unsigned long, ProtectedObject&) + 150
> frame #16: 0x00010403ddae 
> librexx.5.0.0.dylib`RoutineClass::call(Activity*, RexxString*, RexxObject*

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

[Rony G. Flatscher]

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 "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
"Macrospace.testGroup" "-s" "-S"
(lldb) r
Process 3206 launched: '/usr/local/bin/rexx' (x86_64)
Searching for test containers..
Executing automated test suite
Executing testSuite [testCase: [] (an 
ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
 with [36] test cases ...
... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
Process 3206 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x40)
frame #0: 0x0001040059bc 
librexx.5.0.0.dylib`ArrayClass::lastIndex() + 12
librexx.5.0.0.dylib`ArrayClass::lastIndex:
->  0x1040059bc <+12>: movq   0x40(%rdi), %rax
0x1040059c0 <+16>: popq   %rbp
0x1040059c1 <+17>: retq   
0x1040059c2 <+18>: nopw   %cs:(%rax,%rax)
Target 0: (rexx) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x40)
  * frame #0: 0x0001040059bc 
librexx.5.0.0.dylib`ArrayClass::lastIndex() + 12
frame #1: 0x0001040c3f31 
librexx.5.0.0.dylib`ActivityManager::findActivity(_opaque_pthread_t*) + 33
frame #2: 0x0001040c4181 
librexx.5.0.0.dylib`ActivityManager::findActivity() + 17
frame #3: 0x0001040c44fd 
librexx.5.0.0.dylib`ActivityManager::getRootActivity() + 13
frame #4: 0x00010412f14f 
librexx.5.0.0.dylib`Interpreter::createInterpreterInstance(RexxOption*) + 95
frame #5: 0x00010412f556 
librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 230
frame #6: 0x00010412f605 
librexx.5.0.0.dylib`InstanceBlock::InstanceBlock(_RXSYSEXIT*, char const*) + 37
frame #7: 0x0001040c17fb 
librexx.5.0.0.dylib`ActivityDispatcher::invoke(_RXSYSEXIT*, char const*) + 59
frame #8: 0x00010406252f 
librexx.5.0.0.dylib`RexxTranslateInstoreProgram + 79
frame #9: 0x000100686e1e 
librexxapi.5.0.0.dylib`LocalMacroSpaceManager::translateRexxProgram(char 
const*, ManagedRxstring&) + 1118
frame #10: 0x000100686951 
librexxapi.5.0.0.dylib`LocalMacroSpaceManager::addMacroFromFile(char const*, 
char const*, unsigned long) + 65
frame #11: 0x00010068a69d librexxapi.5.0.0.dylib`RexxAddMacro + 109
frame #12: 0x00010038d960 
librexxutil.dylib`SysAddRexxMacro_impl(RexxCallContext_*, char const*, char 
const*, char const*) + 160
frame #13: 0x00010038d88c librexxutil.dylib`SysAddRexxMacro + 60
frame #14: 0x0001040922e6 
librexx.5.0.0.dylib`NativeActivation::callNativeRoutine(RoutineClass*, 
NativeRoutine*, RexxString*, RexxObject**, unsigned long, ProtectedObject&) + 
614
frame #15: 0x000104096746 
librexx.5.0.0.dylib`NativeRoutine::call(Activity*, RoutineClass*, RexxString*, 
RexxObject**, unsigned long, ProtectedObject&) + 150
frame #16: 0x00010403ddae 
librexx.5.0.0.dylib`RoutineClass::call(Activity*, RexxString*, RexxObject**, 
unsigned long, ProtectedObject&) + 110
frame #17: 0x0001040c0c83 
librexx.5.0.0.dylib`PackageManager::callNativeRoutine(Activity*, RexxString*, 
RexxObject**

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

[Rony G. Flatscher]

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
> /usr/local/bin and /usr/local/lib which are identical.
>
> The Rexx-related files in /usr/local/bin are linked to
> /Library/Frameworks/ooRexx.framework/Commands/rexx, the files in 
> /usr/local/lib are linked to
> /Library/Frameworks.framework/Libraries/librexx.dylib.
>
> Hmm, the only - wild? - thing I can think of is that the files in the 
> "[BSF4]ooRexx.framework"
> sub|directories are not owned by root in the wheel (administrator) group. 
> Could that make a
> difference on MacOS in the context of the Macrospace.testGroup interactions 
> with the system?
Just tested it by changing ownership to root and group to wheel, still, the 
same Segmentation fault:
11 is created.

@Enrico: when using lldb, how could one get a stack trace in such a situation?

---rony


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

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

[Rony G. Flatscher]

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

>
> 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
/usr/local/bin and /usr/local/lib which are identical.

The Rexx-related files in /usr/local/bin are linked to
/Library/Frameworks/ooRexx.framework/Commands/rexx, the files in /usr/local/lib 
are linked to
/Library/Frameworks.framework/Libraries/librexx.dylib.

Hmm, the only - wild? - thing I can think of is that the files in the 
"[BSF4]ooRexx.framework"
sub|directories are not owned by root in the wheel (administrator) group. Could 
that make a
difference on MacOS in the context of the Macrospace.testGroup interactions 
with the system?

---rony


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

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

[Enrico Sorichetti via Oorexx-devel]

> On 3 Dec 2018, at 14:04, Rony G. Flatscher  wrote:
> 
> As Ernesto


I thought that the Che had been out of the picture for a while 

Anyway the whole test suite run successfully from /usr/local

 Hasta la victoria siempre

Enrico Che Guevara :-) 

P.S.

I will try to write something about the different setup options 


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

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

[Rony G. Flatscher]

OK, I am able to get "Macrospace.testGroup" to run!

As Ernesto and P.O. have been reporting that the test runs successfully, I went 
back to
"~/Application/ooRexx.5.0.0/bin" added that directory to PATH and created a 
DYLD_LIBRARY_PATH to
point to that location: ran the tests from there and lo and behold the 
"Macrospace.testGroup" ran
successfully to completion!

Just wanted to let you know, now trying to figure out why.

It may have to do with the configuration that is in place when using ooRexx 
installed via BSF4ooRexx
(which places the files in those places 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. Flatscher wrote:
>
> Rev 11555, MacOSX.
>
>   * running "rexx -e say value('RXQUEUESESSION',,'ENVIRONMENT')"
>   o if no rxapi is running then an empty string is shown, otherwise a 
> value like "0x790" gets
> displayed
>
>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass) 
> in both situations:
> no rxapi running, rxapi already running
>
>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
> testOORexx.rex -f
> Macrospace.testGroup -s -S" stops without error and statistics 
> while/after running the seventh
> test "TEST_ADD_THREE_ARGS_OPTION"; it does not matter whether rxapi is 
> already running or not
>
>   o went back and created ooRexx without the flag 
> "-DCMAKE_BUILD_TYPE=Release", assuming that
> a Debug version gets created, the behaviour changed a little bit then:
>
>   + the program gets killed, there is a note about "Segmentation 
> fault: 11" in the Terminal
>
>   + then remembering some of Ernesto's snippets I ran the test case 
> with "lldb" which
> seems to be Apple's debugger, here the session:
> wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f 
> Macrospace.testGroup -s -S
> (lldb) target create "rexx"
> Current executable set to 'rexx' (x86_64).
> (lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
> "Macrospace.testGroup" "-s" "-S"
> (lldb) 
> (lldb) run
> Process 1795 launched: '/usr/local/bin/rexx' (x86_64)
> Searching for test containers..
> Executing automated test suite
> Executing testSuite [testCase: [] (an 
> ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
> Executing testSuite [testCase: [The Macrospace.testGroup class] 
> (an 
> ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
>  with [36] test cases ...
> ... running TestCase object [testCase: 
> [TEST_ADD_ARG_OPTION_ILLEGAL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: 
> [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: 
> [TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> ... running TestCase object [testCase: 
> [TEST_ADD_THREE_ARGS_OPTION] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
> Process 1795 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_ACCESS (code=1, address=0x40)
> frame #0: 0x0001050059bc 
> *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   
> 0x1050059c2 <+18>: nopw   %cs:(%rax,%rax)
> Target 0: (rexx) stopped.
> (lldb) 
>
> ---rony
>
>
> On 02.12.2018 18:18, Rony G. Flatscher wrote:
>>
>> Rev 11552:
>>
>>   * running the "say value()" program will only show an em

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

[Enrico Sorichetti via Oorexx-devel]

It runs for me from /opt/ooRexx

Installing in /usr/local 

I will keep You posted on the results

E


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

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

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

[Rick McGuire]

What is really needed is a stack trace for the macrospace exception.

Rick

On Mon, Dec 3, 2018 at 7:48 AM Rony G. Flatscher 
wrote:

> Rev 11555, MacOSX.
>
>- running "rexx -e say value('RXQUEUESESSION',,'ENVIRONMENT')"
>   - if no rxapi is running then an empty string is shown, otherwise a
>   value like "0x790" gets displayed
>
>   - running "rexx testOORexx.rex -f rxQueue.testGroup" works (all
>tests pass) in both situations: no rxapi running, rxapi already running
>
>- running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx
>testOORexx.rex -f Macrospace.testGroup -s -S" stops without error and
>statistics while/after running the seventh test
>"TEST_ADD_THREE_ARGS_OPTION"; it does not matter whether rxapi is already
>running or not
>
>- went back and created ooRexx without the flag
>   "-DCMAKE_BUILD_TYPE=Release", assuming that a Debug version gets 
> created,
>   the behaviour changed a little bit then:
>
>   - the program gets killed, there is a note about "Segmentation
>  fault: 11" in the Terminal
>
>  - then remembering some of Ernesto's snippets I ran the test
>  case with "lldb" which seems to be Apple's debugger, here the 
> session:
>
>  wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f 
> Macrospace.testGroup -s -S
>  (lldb) target create "rexx"
>  Current executable set to 'rexx' (x86_64).
>  (lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
> "Macrospace.testGroup" "-s" "-S"
>  (lldb)
>  (lldb) run
>  Process 1795 launched: '/usr/local/bin/rexx' (x86_64)
>  Searching for test containers..
>  Executing automated test suite
>  Executing testSuite [testCase: [] (an 
> ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
>  Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
> ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
>  with [36] test cases ...
>  ... running TestCase object [testCase: [TEST_ADD_ARG_OPTION_ILLEGAL] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  ... running TestCase object [testCase: 
> [TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  ... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  ... running TestCase object [testCase: [TEST_ADD_FOUR_ARGS_TOO_MANY] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  ... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  ... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  ... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] 
> (a 
> Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
>  ...
>  Process 1795 stopped
>  * thread #1, queue = 'com.apple.main-thread', stop reason = 
> EXC_BAD_ACCESS (code=1, address=0x40)
>  frame #0: 0x0001050059bc 
> *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
>  0x1050059c2 <+18>: nopw   %cs:(%rax,%rax)
>  Target 0: (rexx) stopped.
>  (lldb)
>
>
>
> ---rony
>
>
> On 02.12.2018 18:18, Rony G. Flatscher wrote:
>
> Rev 11552:
>
>- running the "say value()" program will only show an empty value now,
>
>- running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests
>pass)
>
>- running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx
>testOORexx.rex -f Macrospace.testGroup -s -S" stops without error and
>statistics while/after running the seventh test 
> "TEST_ADD_THREE_ARGS_OPTION"
>   - dropping the trailing flags "-s" or "-s -S" yields dots, but it
>   seems the test runs forever killing it after approx. three minutes (on
>   Windows test execution takes not even a second)
>
> ---rony
>
> On 02.12.2018 17:53, Rick McGuire wrote:
>
> Great, think this is is a simple as adding a few sleep calls between
> connection attempts.
>
> Rick
>
> On Sun, Dec 2, 2018 at 11:41 AM Rony G. Flatscher 
> wrote:
>
>> On 02.12.2018 17:27, Rick McGuire wrote:
>>
>> Ok,

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

[Rony G. Flatscher]

Rev 11555, MacOSX.

  * running "rexx -e say value('RXQUEUESESSION',,'ENVIRONMENT')"
  o if no rxapi is running then an empty string is shown, otherwise a value 
like "0x790" gets
displayed

  * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass) 
in both situations: no
rxapi running, rxapi already running

  * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
testOORexx.rex -f
Macrospace.testGroup -s -S" stops without error and statistics while/after 
running the seventh
test "TEST_ADD_THREE_ARGS_OPTION"; it does not matter whether rxapi is 
already running or not

  o went back and created ooRexx without the flag 
"-DCMAKE_BUILD_TYPE=Release", assuming that a
Debug version gets created, the behaviour changed a little bit then:

  + the program gets killed, there is a note about "Segmentation fault: 
11" in the Terminal

  + then remembering some of Ernesto's snippets I ran the test case 
with "lldb" which seems
to be Apple's debugger, here the session:

wu114184:trunk rony$ lldb -- rexx testOORexx.rex -f 
Macrospace.testGroup -s -S
(lldb) target create "rexx"
Current executable set to 'rexx' (x86_64).
(lldb) settings set -- target.run-args  "testOORexx.rex" "-f" 
"Macrospace.testGroup" "-s" "-S"
(lldb) 
(lldb) run
Process 1795 launched: '/usr/local/bin/rexx' (x86_64)
Searching for test containers..
Executing automated test suite
Executing testSuite [testCase: [] (an 
ooTestSuite@n/a_-4321004065)@-4321004065] with [2] test cases ...
Executing testSuite [testCase: [The Macrospace.testGroup class] (an 
ooTestSuite@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)@-4321030817]
 with [36] test cases ...
... running TestCase object [testCase: 
[TEST_ADD_ARG_OPTION_ILLEGAL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: 
[TEST_ADD_ARG_PATH_NOT_EXISTING] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ARG_PATH_NULL] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: 
[TEST_ADD_FOUR_ARGS_TOO_MANY] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_NO_ARG_TOO_FEW] (a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_ONE_ARG_TOO_FEW] 
(a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
... running TestCase object [testCase: [TEST_ADD_THREE_ARGS_OPTION] 
(a 
Macrospace.testGroup@/Users/rony/dev/oorexx_allura/test/trunk/ooRexx/base/rexxutil/Macrospace.testGroup)]
 ...
Process 1795 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_BAD_ACCESS (code=1, address=0x40)
frame #0: 0x0001050059bc 
*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   
0x1050059c2 <+18>: nopw   %cs:(%rax,%rax)
Target 0: (rexx) stopped.
(lldb) 

---rony


On 02.12.2018 18:18, Rony G. Flatscher wrote:
>
> Rev 11552:
>
>   * running the "say value()" program will only show an empty value now,
>
>   * running "rexx testOORexx.rex -f rxQueue.testGroup" works (all tests pass)
>
>   * running "rexx testOORexx.rex -f Macrospace.testGroup -s" or "rexx 
> testOORexx.rex -f
> Macrospace.testGroup -s -S" stops without error and statistics 
> while/after running the seventh
> test "TEST_ADD_THREE_ARGS_OPTION"
>   o dropping the trailing flags "-s" or "-s -S" yields dots, but it seems 
> the test runs
> forever killing it after approx. three minutes (on Windows test 
> execution takes not even a
> second)
>
> ---rony
>
> On 02.12.2018 17:53, Rick McGuire wrote:
>> Great, think this is is a simple as adding a few sleep calls between 
>> connection attempts.
>>
>> Rick
>>
>> On Sun, Dec 2, 2018 at 11:41 AM Rony G. Flatscher > > wrote:
>>
>> 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:
>>>
>>>  

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

[Enrico Sorichetti via Oorexx-devel]

Hello  Rick

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

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

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

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


See the higher real time when rxapi is not there

As compared to
real0m0.038s


Added a few printfs to check things 

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

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

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


The sleep loop is entered once if rxapi is not active 

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

The test suite runs until the end with no errors 

E






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