|
Hi,
Sorry for the late reply.
>
And testtools bridgetest itself
Yes, bridgetest_javaserver
is the first one that need to be fix.
> Who says it's just performance? https://bugs.documentfoundation.org/show_bug.cgi?id=152943#c7: > "but Calc heavily [...] relies on NaN payload propagation in all math operators." > Calc without Math is a problem. I misused English word 'performance', my apologize. I
mean that when using LibreOffice Calc with GUI on riscv64, the error code showed correctly. It seems that the lack of NaN payload does not affect the error code at least in GUI mode. So I am quite confused which part does NaN payload affect. And that is why
I think it is not urgent to fix '[CUT] sc_ucalc_formula2',
because the failed tests 'sc_ucalc_formula2'
it are all related to error code mismatch. Besides, the only failed test in '[CUT] sal_rtl' is also 'test_payloadNaN'.
But these two test cases are key tests that should not be ignored. How the NaN propogation affect the Calc calculation need to be inspected
further.
>
I believe you, but wonder what exactly is broken.
This is how UITest work:
python(UITest) -> pyuno(written in cpp, on callerside) -> bridge(cpp2uno, on callerside) -> bridge(uno2cpp, on remote callee side) ->
cppfunc
Did I get that right? When pyuno get returned value from bridge(cpp2uno), some simple types cannot be properly proccessed, just like
This happens occasionally and 'ramdomly'. As far as I know, dirty bits which are not cleaned in the bridge might lead to these failed
test.
From,
Sakura286.
|