On 3-5-2021 23:32, Gregory Farnum wrote:
On Sun, Apr 25, 2021 at 3:56 AM Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote:
Hi all,
Just sharing my sunday morning frustration of checking the build of my ports.
This occurs in ./src/test/encoding/check-generated.sh
In itself this type of problem if of course trivial to solve.
But in this case we use diff to compare the output, so there is
no easy way to fix this
2 DecayCounter
/tmp/typ-s31EUGoSy /tmp/typ-iLTjVqhpI differ: char 24, line 2
**** DecayCounter test 1 dump_json check failed ****
ceph-dencoder type DecayCounter select_test 1 dump_json > /tmp/typ-s31EUGoSy
ceph-dencoder type DecayCounter select_test 1 encode decode dump_json > /tmp/typ-iLTjVqhpI
2c2
< "value": 2.99990449484967,
---
"value": 2.9999046414456356,
Probably the easiest is to exclude the test and go on with life as it is.
But correct way is probably shorten the representation of the float printing.
So we end up with '2.9999' of perhaps even shorter which will make it '3.000'
Is that something that is appropriate to do in the dump_json part, if I can flesh
out the DecayCounter as "exception"
Yuck. I haven't looked into these specific tests, but we may want that
level of dumping for debugging.
Maybe (ugh) we could have an option to shorten floats when dumping for
the purposes of these tests? :/
I am a bit curious what the DecayCounter test is doing that results in
such wildly differing precisions, though. Most of them are quite
simple.
...and indeed, it's just generating a DecayCounter of value 3.0 and
storing it...but the dump() function invokes decay(). I'm a bit
surprised this has
ever worked, and I note that operator<< *does* set a precision there.
If you haven't already come up with a good workaround that looks to
allow
a lot of possibilities for a PR. :)
Hi Greg,
Thanx for the reply
ATM I took the cowards way out: exclude the test.
But it's on the list to fix.
--WjW
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
