Ah, they are...that function was supposed to sleep milliseconds. I need to
tweak things again so that all platforms sleep the same time.
On Sun, Dec 2, 2018 at 5:22 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:
> Hi Rick
>
> [enrico@enrico-imac
Hi Rick
[enrico@enrico-imac ooRexx.svn.Release]$pkill rxapi
[enrico@enrico-imac ooRexx.svn.Release]$time rexx -e "'pwd | rxqueue' ; say
queued() "
sleeping 1000 msecs
99 sleeping 1000 msecs
98 sleeping 1000 msecs
97 sleeping 1000 msecs
96 sleeping 1000 msecs
95 sleeping 1000 msecs
94
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
So it was taking 7+ seconds for the process to get fully launched? Wow,
that's way longer than any of the other platforms. I may keep these smaller
than 1000 but increase the number of retries so that it will go at least 10
seconds before giving up.
Rick
On Sun, Dec 2, 2018 at 5:09 PM Enrico
Both
e
> On 2 Dec 2018, at 23:07, Rick McGuire wrote:
>
> Which interval did you change? The first wait after the server launch or the
> loop one?
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
Which interval did you change? The first wait after the server launch or
the loop one?
Rick
On Sun, Dec 2, 2018 at 5:01 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:
> Done it ,
> Changed the sleep interval to 1000 msecs
> it loops 6/8 times
>
> And the test
Done it ,
Changed the sleep interval to 1000 msecs
it loops 6/8 times
And the test suite runs fine fine
Even after having killed the rxapi process
The delay is negligible, and occurs only if rxapi is not running
e
P.S.
Time to start looking at the native api
> On 2 Dec 2018, at 22:36, Rick
Do you see about a 1-second delay on the first one?
The logic of it is the first launch tries to connect to the server, finds
it is not able to connect, so it launches rxapi, waits 50msec, then makes
100 attempts to connect with a 10msec delay between each attempt before it
gives up. So it
It still fails
to keep it short …
No need to bother the oorexx test suite
[enrico@enrico-imac ooRexx.testsuite]$pkill rxapi
[enrico@enrico-imac ooRexx.testsuite]$rexx -e "'pwd | rxqueue' ; say queued();
do queued();parse pull l; say l; end "
0
[enrico@enrico-imac ooRexx.testsuite]$rexx -e
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
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
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
For the sandbox rxapi version, the Unix rxapid script has become obsolete
and could be removed from trunk.
Interestingly rxapid didn't only start or stop rxapi, but it also used
binfmt_misc functions to enable compiled Rexx programs to run without
preceding them with "rexx".
Do we want to
Not yet !
Enrico
> On 2 Dec 2018, at 19:07, Rony G. Flatscher wrote:
>
> Now that the sandbox rxapi version of ooRexx can be run off a directory (and
> therefore also from a
> stick), would it be possible to run/use ooRexx without even setting the PATH
> for it?
>
> This probably would mean
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
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
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
d Oct 10
> 23:06:14 PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0
>
> Tests ran: 22398
> Assertions: 375190
> Failures: 4
> Errors: 0
>
> [failure] [20181202 15:01:22.322756]
> svn:r11522 Change date: 2018-11-22 01:34:5
Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14
PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0
Tests ran: 22398
Assertions: 375190
Failures: 4
Errors: 0
[failure] [20181202 15:01:22.322756]
svn
OK, now I'm really confused. This is the opposite of what I was expecting
to see. I thought it only failed when run as a full suite and passed when
run alone, but this is showing me the opposite. And the full run is also
missing the trace lines.
Rick
On Sun, Dec 2, 2018 at 8:27 AM Enrico
Hi Rick
Follow on …
And here is the result for
rexx testOORexx -s -X native_API
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 1 Dec 2018
OS Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 17.7.0:
on 17.7.0: Wed Oct 10 23:06:14
PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64.17.7.0
Tests ran: 7
Assertions: 2
Failures: 4
Errors: 0
[failure] [20181202 14:04:42.734449]
svn:r11522 Change date: 2018-11-22 01:34:56 +0100
Test: T
These tests have been driving me crazy, not because there are failures, but
because there are successes. Two of the six test methods in that group are
passing, and if there was a problem with the daemon, I would have expected
all of the rxqueue tests to fail for the same reason. I have noticed a
23 matches
Mail list logo
