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
> very brief:
>
> * it seems that in "Macrospace.testGroup" the method
> "test_add_three_args_option" causes the
> problem (exiting everything without error and statistics)
> o injecting ".error~say"-statements at first no output took place
> + replacing it in one line once with ".stderr~say" caused output to
> be shown, changing
> it back to ".error~say" then also showed the output
> o added a "signal on syntax", but does 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:
>>
>> On 02.12.2018 20:48, Rick McGuire wrote:
>>> Well, it's time for you to do some basic problem determination. Somethings
>>> to try:
>> Will do.
>>
>>> 1) run the tests in the debugger to see what is killing them. We've seen
>>> cases in the past on
>>> all platforms where the OS just kills a process without giving us an
>>> indication. This usually
>>> can be trapped in a debuffer.
>> On Apple I am lost with regards to the debugger, unfortunately. Maybe some
>> of the Apple-savvy
>> developers can take on this task? Maybe Enrico?
>>
>>> 2) Try commenting out the test that appears to be running to see if the
>>> problem is isolated to
>>> that test.
>>>
>>> 3) If 2) works, invert this and see if that test method fails in isolation.
>>>
>>> 4) Add a trace instruction to the suspect test method to see if you can
>>> further narrow down the
>>> problem.
>> Will try 2) to 4) and report back.
>>
>> ---rony
>>
>>>
>>> On Sun, Dec 2, 2018 at 12:19 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>> <mailto:rony.flatsc...@wu.ac.at>> 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
>>>> <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>> 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:
>>>>>
>>>>> say value('RXQUEUESESSION',,'ENVIRONMENT')
>>>>> I suspect the code gives up trying to connect to the rxapi
>>>>> process before I has a chance to get fully. The first connection attempt
>>>>> occurs when it creates the session queue and sets the RXSESSIONQUEUE
>>>>> env variable. If that never happens, then the rxqueue filter will
>>>>> add the lines to the wrong session queue.
>>>>
>>>> Running the command with "rexx -e say
>>>> value('RXQUEUESESSION',,'ENVIRONMENT')" first
>>>> yields an empty string, the second time some value (in my case
>>>> "0x15fa7").
>>>>
>>>> ---rony
>>>>
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
