After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794515 - Rounding issue on WSL
Rounding issue on WSL
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Charting
unspecified
Other Windows
: Normal normal
: ---
Assigned To: Jean Bréfort
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2018-03-20 10:57 UTC by Frédéric Parrenin
Modified: 2018-03-23 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The .gnumeric file to reproduce the problem (5.29 KB, application/octet-stream)
2018-03-20 10:57 UTC, Frédéric Parrenin
Details
.png screenshot to illustrate the problem (49.44 KB, image/png)
2018-03-20 12:52 UTC, Frédéric Parrenin
Details
.png screenshot to illustrate the problem (52.46 KB, image/png)
2018-03-20 14:01 UTC, Frédéric Parrenin
Details

Description Frédéric Parrenin 2018-03-20 10:57:53 UTC
Created attachment 369901 [details]
The .gnumeric file to reproduce the problem

There is an issue with rounding when using gnumeric on ubuntu 16.04 on WSL (Windows 10).
I attach gnumeric file, look at the Y-axes of the graph.
I tested on a pure debian 9 and the issue does not show up, so apparently this is WSL-only.
I am wondering if WSL is a platform the gnumeric developers want to support.
Comment 1 Morten Welinder 2018-03-20 12:31:13 UTC
What am I looking for?
Comment 2 Frédéric Parrenin 2018-03-20 12:52:57 UTC
Created attachment 369905 [details]
.png screenshot to illustrate the problem

This is how the graph looks like on my ubuntu on WSL.
Comment 3 Morten Welinder 2018-03-20 13:36:24 UTC
Yes, that's not pretty.

I have a vague memory of having fixed something like that at some point.
What versions of Gnumeric and Goffice are in play?
Comment 4 Frédéric Parrenin 2018-03-20 13:42:35 UTC
This is goffice 0.10.28 and gnumeric 1.12.28.
Again, this is a WSL-only bug.
Comment 5 Frédéric Parrenin 2018-03-20 14:01:08 UTC
Created attachment 369909 [details]
.png screenshot to illustrate the problem

There is another issue.
If I try to modify the format of the ticks labels to have only two decimals, I get the following.
Note how it jumps from 0 to 0.02 and then 0.03.
Comment 6 Frédéric Parrenin 2018-03-20 15:17:00 UTC
So I checked with a git version, and the problem is still there.
Comment 7 Jean Bréfort 2018-03-20 15:19:26 UTC
I can't reproduce, quite weird.
Comment 8 Frédéric Parrenin 2018-03-20 15:29:46 UTC
Hi Jean, are you on WSL as well?
Comment 9 Jean Bréfort 2018-03-20 15:40:40 UTC
Debian sid, no Windows of any kind around.
Comment 10 Frédéric Parrenin 2018-03-21 17:05:01 UTC
FYI, I opened an issue on WSL:
https://github.com/Microsoft/WSL/issues/830
Comment 11 Frédéric Parrenin 2018-03-22 17:13:52 UTC
Sorry, this is the right link to the issue reported against WSL:
https://github.com/Microsoft/WSL/issues/3044

In issue 830, they propose to use:
_FPU_SETCW() as a workaround and to recompile.
Do you know where to put this code?
Thanks.
Comment 12 Morten Welinder 2018-03-22 17:34:59 UTC
Ugh.

"Where" is easy: very early in main() in src/main-application.c

The question is whether parts of the C library depends on the old setting.
You can try, I guess.

Some info: we use a printf derived from musl.  830 has comments from the
musl people that it requires the long-double floating point semantics.
Comment 13 Frédéric Parrenin 2018-03-22 18:00:41 UTC
So I tried the FPU_SETCW fix and the issue with rounding is gone.
I will keep you informed if I see other issues appearing.
Thanks.
Comment 14 Morten Welinder 2018-03-23 15:14:08 UTC
I added code for checking and fixing this.

This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
Comment 15 Frédéric Parrenin 2018-03-23 15:17:48 UTC
Thanks.