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

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

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.

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

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

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

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

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 > /usr/local/bin and

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 > > wrote: >> >> As Ernesto > > > I thought that the Che had been out of the picture

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.

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

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] MacOS observations (Re: Some observations on the failing rxqueue tests.

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

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

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