GNOME Bugzilla – Bug 323150
Sqrt fails in non-English locales
Last modified: 2006-01-23 17:09:13 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".
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.
I am unable to reproduce the problem. I tried DE locale. Sqrt(4) gives 2. LANG=de_DE LANGUAGE=de_DE
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
Reinout, which version of gcalctool are you running (Help->About will give you this)? Also, which version of Linux, GNOME etc. ? Thanks.
Rich: gcalctool 5.7.11, Mandriva Cooker, GNOME 2.13.2.
Confirming this bug on a GNOME 2.12 install. Both nl_NL and de_DE fail to work properly, whereas "C" works fine.
*** Bug 324054 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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]
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.
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.
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.
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.
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!
According to the code in CVS HEAD, the minus button must be fixed too.
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?)
*** Bug 327999 has been marked as a duplicate of this bug. ***
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.
Created attachment 57875 [details] [review] Minus sign for parser to use This should fix the minus sign problem.
>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.
*** Bug 328242 has been marked as a duplicate of this bug. ***
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.
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/
Thanks a lot. Uploaded to Ubuntu.