Forth: Problem with "ttester.fs with extension for Codewars"

[g964]

About a function "buddy" that returns two numbers on the stack.
In each case input is: 23 4669. Correct answer is: 48 75.

test: <{ 23 4669 buddy -> 48 75 }> (expected is correct)
function returns: 48 75 (correct result)
test answer: test passed

test : <{ 23 4669 buddy -> 48 750 }> (expected is wrong)
function returns: 48 75 (correct result)
test answer: Expected 750 48 , got 75 48 (numbers are swapped)

test: <{ 23 4669 buddy -> 75 48 }> (expected is wrong)
function returns: 48 75 (correct result)
test answer: Expected 48 75 , got 75 48 (expected and actual are swapped)

test: test : <{ 23 4669 buddy -> 48 75 }> (expected is correct)
function returns: 75 48 (wrong result)
test answer: Expected 75 48 , got 48 75 (expected and actual are swapped)

[nomennescio]

Stack order in testcase has bottom of stack to the left, and top of stack to the right, as is customary in Forth. In the reporting, the top of the stack is reported first, then below items are shown. This might confuse some people. Therefore change the reporting such that the bottom of the stack is reported first, then items above it are shown. The result will be that the order of reporting is the same as the left-right order of the test case.

[g964]

Will that enhancement correct the swap of actual and expected when result or test are wrong?

[nomennescio]

Yes, it will display them "swapped" as you say.

[g964]

Thanks but I think it is not installed yet because I still have some problems.

[kazk]

I'll close this when #11 is deployed.

[kazk]

Deployed

[nomennescio]

Replying to comment of @g964

Seems correct.
Nevertheless when I ".s" at the end of my function that returns only two values (48 and 75 for example in this case) I get 6 values:

<6> 1566368372519787 0 1566368372519787 0 48 75 

Where "1566368372519787 0 1566368372519787 0" comes from? These numbers change from one run to another one.

See #8

Besides at the end appears:

Completed in 340253472524445438007248728644284340.624 ms

(or something else of the same kind) which seems a bit strange...

That can happen in case there's a stack depth mismatch, i.e. a mismatch in the number of arguments. In that case the user has a lot more to worry about than knowing the time it took the code to run to completion...

[g964]

That can happen in case there's a stack depth mismatch, i.e. a mismatch in the number of arguments. In that case the user has a lot more to worry about than knowing the time it took the code to run to completion...

It happens even if there is no stack mismatch and the test succeeds.

[nomennescio]

I don't see that when running tests. If you experience an issue with timing info, please open a new issue for that.