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 323150 - Sqrt fails in non-English locales
Sqrt fails in non-English locales
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
5.7.x
Other Linux
: Urgent major
: ---
Assigned To: Sami Pietilä
Sami Pietilä
: 324054 327999 328242 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-03 21:51 UTC by Reinout van Schouwen
Modified: 2006-01-23 17:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Patch from Sami to fix the problem. (5.92 KB, text/plain)
2005-12-19 15:38 UTC, Rich Burridge
  Details
Minus sign for parser to use (396 bytes, patch)
2006-01-22 21:11 UTC, Sami Pietilä
none Details | Review

Description Reinout van Schouwen 2005-12-03 21:51:36 UTC
Start gcalctool in a non-English locale (I have tested in nl_NL and de_DE).
Switch to Advanced mode. Make sure View > Use arithmetic precedence is enabled.

Enter Sqrt(4).

Expected result: 2
Actual result: "Invalid expression".
Comment 1 Rich Burridge 2005-12-05 15:33:49 UTC
Assigning to Sami, as the arithmetic precedence mode is his code.
In non-AOP mode, you enter the number you want to take the square
root of first, then hit the Sqrt button. I expected hitting the Sqrt
key in AOP mode to surron the current display value with "Sqrt(" ... ")".
In AOP in en locale, I got this to work, by entering:

4
Sqrt
)
=

Having to add the extra closing right parentheseis seems non-obvious to me.
Comment 2 Sami Pietilä 2005-12-06 19:12:21 UTC
I am unable to reproduce the problem. I tried DE locale. Sqrt(4) gives 2.

LANG=de_DE
LANGUAGE=de_DE
Comment 3 Dennis Krul (dweazle) 2005-12-06 20:11:50 UTC
I can reproduce this.

Sqrt doesn't work with locale nl_NL@euro
Sqrt works with en_US

I'm using gcalctool 5.6.31
Comment 4 Rich Burridge 2005-12-06 20:15:50 UTC
Reinout, which version of gcalctool are you running
(Help->About will give you this)?  Also, which version
of Linux, GNOME etc. ?

Thanks.
Comment 5 Reinout van Schouwen 2005-12-06 20:27:51 UTC
Rich: gcalctool 5.7.11, Mandriva Cooker, GNOME 2.13.2.
Comment 6 Wouter Bolsterlee (uws) 2005-12-06 23:44:03 UTC
Confirming this bug on a GNOME 2.12 install. Both nl_NL and de_DE fail to work
properly, whereas "C" works fine.
Comment 7 Rich Burridge 2005-12-14 15:43:21 UTC
*** Bug 324054 has been marked as a duplicate of this bug. ***
Comment 8 Rich Burridge 2005-12-15 17:28:05 UTC
Confirming that I too can see this problem with latest gcalctool
when in the it_IT.ISO8859-1 locale. Sami, I'll see if I can add
some debug output to help you track it done.
Comment 9 Rich Burridge 2005-12-15 18:07:56 UTC
I turned on yydebug'ing for you. I added:

fprintf(stderr, "yychar is char: %c dec val: %d\n", yychar, yychar);

just before doing:

      yytoken = YYTRANSLATE (yychar);
      YYDSYMPRINTF ("Next token is", yytoken, &yylval, &yylloc);

(about line 1213 in ce_parser.tab.c).

After entering:

Sqrt(4)=

the following is output to stderr:

Starting parse
Entering state 0
Reading a token: yychar is char: S dec val: 83
Next token is token $undefined ()
Shifting error token, Entering state 1
Reducing stack by rule 3 (line 110), error -> statement

Hopefully that's enough for you to determine what's going on.
Comment 10 Rich Burridge 2005-12-15 18:12:12 UTC
One other thing that might be worth mentioning. The label for
square root gcalctool button is the squart root symbol, rather
than "Sqrt" which is what it is in the C locale.
Comment 11 Rich Burridge 2005-12-15 18:22:13 UTC
Okay, last one (label on key) is a red herring. I just tried
changing the label to "Sqrt" and gcalctool still barfed with
Malformed Expression. 

It's somewhere in your parser code Sami.
Comment 12 Rich Burridge 2005-12-19 15:38:33 UTC
Created attachment 56165 [details]
Patch from Sami to fix the problem.

I've tried this is the "it" and C locales, and it seems to work fine.
Note that we no longer need syntax_translation.[c,h]
Comment 13 Rich Burridge 2005-12-19 15:49:18 UTC
Changes checked into CVS HEAD. I've bumped the version number in
configure.in to 5.7.17. I'll generate a new tarball for GNOME 2.13.4,
(probably near the end of the week as I'll by on vacation on 2nd Jan
2006).

Thanks.
Comment 14 Daniel Holbach 2006-01-18 20:57:38 UTC
According to https://launchpad.net/distros/ubuntu/+source/gcalctool/+bug/28928 this still happens to users with gcalctool 5.7.26:


 can't make gcalctool compute any square-root. E.g. to compute sqrt(9) I do this:
1. start gcalctool
2. switch to 'advanced view'.
3. click on the button with the sqrt-symbol.
4. click on the button with the nine.
5. click on the button with the closing bracket.
6. click on the button with the '='.

The display is not updated, and the status bar says 'malformed expression'. Googleing for this (http://www.google.com/search?q=gcalctool%20sqrt) turns up similar bugreports in Debian and Ubuntu, but I can't find the latter anymore. Those reports suggest the LC_ALL environment variable is related, but I can't find any relation: sqrt never works, regardless of the LC_ALL (or any LC/LANG variable) value.
Comment 15 Rich Burridge 2006-01-18 23:01:41 UTC
I'm going to reopen this. Sami could you investigate please?

The 5.7.26 release includes a change where the label on the 
Square Root button is now the Unicode symbol for square root.
I've no idea if this has had a detrimental effect on the previous
fix, but I thought I'd better mention it.
Comment 16 Sami Pietilä 2006-01-19 22:14:09 UTC
The content of the *str variable in the button struct is copied into the expression if the *symname variable is NULL. 

The fix is to change the *symname variable from NULL into N_("Sqrt") in the sqrt button struct.
Comment 17 Rich Burridge 2006-01-19 22:45:22 UTC
Well Bugzilla goes splat when I try to add an attachment at the moment, so as
it's a small one I'll paste it here:

 % cat /tmp/DIFFS
Index: calctool.c
===================================================================
RCS file: /cvs/gnome/gcalctool/gcalctool/calctool.c,v
retrieving revision 1.102
diff -u -r1.102 calctool.c
--- calctool.c  17 Jan 2006 02:16:11 -0000      1.102
+++ calctool.c  19 Jan 2006 22:38:42 -0000
@@ -400,7 +400,7 @@
     's',
     M_NONE,
     do_immed,
-    NULL,
+    N_("Sqrt"),
     func
 },
 {

Could one of the bug reporters please try it out in a non-English
locale and see if it works for them. If it does, then I'll check 
it into CVS HEAD. Thanks!
Comment 18 Sami Pietilä 2006-01-20 07:30:45 UTC
According to the code in CVS HEAD, the minus button must be fixed too.
Comment 19 Rich Burridge 2006-01-20 17:22:28 UTC
Can you send me the changes needed here please?
Or better yet, attach them to this bug report.

Three other buttons recently had their labels changed:

  - division
  - multiplication
  - plus/minus

Are there any similar changes needed for them?

(The token parser really should break if you change the
labels on the calculator buttons. Are there any other
places where this might happen? Why not always put the
correct tokens in symname field of the button struct?)
Comment 20 Rich Burridge 2006-01-21 22:50:59 UTC
*** Bug 327999 has been marked as a duplicate of this bug. ***
Comment 21 Rich Burridge 2006-01-21 22:52:48 UTC
Changing the priority to Urgent. This is a bad bug 
(subtraction broken in AOP mode for non-English locales)
that needs to be fixed as soon as possible.
Comment 22 Sami Pietilä 2006-01-22 21:11:46 UTC
Created attachment 57875 [details] [review]
Minus sign for parser to use

This should fix the minus sign problem.
Comment 23 Sami Pietilä 2006-01-22 21:26:06 UTC
>Three other buttons recently had their labels changed:
>
>  - division
>  - multiplication
>  - plus/minus
>
>Are there any similar changes needed for them?

Those seem to have their *symname defined.

>(The token parser really should break if you change the
>labels on the calculator buttons. Are there any other
>places where this might happen? Why not always put the
>correct tokens in symname field of the button struct?)

For most cases the *str is what parser expects to see. Support for NULL *symname is to prevent string duplication.
Comment 24 Rich Burridge 2006-01-23 15:43:55 UTC
*** Bug 328242 has been marked as a duplicate of this bug. ***
Comment 25 Rich Burridge 2006-01-23 15:46:58 UTC
In the overall scheme of things, having extra strings in there
for each symname is not going to "bloat" the application. In some
cases, the strings aren't going to be duplicates (as we've just 
found out).

Thanks for the second fix. I'll check it into CVS HEAD and generate
a new tarball.
Comment 26 Rich Burridge 2006-01-23 16:12:05 UTC
Changes checked into CVS HEAD. Version number in configure.in
bumped to 5.7.27. I've also generated a new tarball. You can
find it under:

 http://ftp.gnome.org/pub/GNOME/sources/gcalctool/5.7/

Comment 27 Daniel Holbach 2006-01-23 17:09:13 UTC
Thanks a lot. Uploaded to Ubuntu.