GNOME Bugzilla – Bug 520525
(5+3)/2 reports "Malformed expression" in arithmetic precedence mode.
Last modified: 2008-03-11 23:57:51 UTC
Steps to reproduce. 1/ Start gcalctool, in arithmetic precedence mode, Decimal base and scientific mode. 2/ Enter: ( 5 + 3 ) / 2 Return Expected results: 4 Actual results: "Malformed expression" in the status bar. Works correctly in left-to-right precedence mode. (Note I also tried: ((5+3)/2) there to not force the calculation until the last matching right bracket had been entered.
Sami, now that we've branched for GNOME 2.23, could you please take a look at this one. Thanks!
Hi, I am unable to reproduce the problem. Please try to run "make clean" and then "make". Does this help? ---- However, there seems to be regression (in expression editing) from previously released stable version. If I trite "(" to a cleared screen, the result is "0(" when it should be "(". I suggest that Robers checks that the rewritten editing logic (do_expression) is functionally equivalent to the previous one.
> Please try to run "make clean" and then "make". Does this help? Nope. Still fails. This is with latest Ubuntu Hardy (almost GNOME 2.22). Robert, what do you get with this one?
I can confirm the regression where the 0 remains in the display, it occurrs since 5.21.3 (works fine in 5.21.2). Patch attached and committed to SVN head. In terms of the initially described bug it only occurs for me in 5.21.3 onwards due to the 0 still remaining in the display, i.e. the performing the steps leads to "0(5+3)/2" in the display which is an invalid expression (though this should probably be interpreted as 0*(5+3)/2).
Created attachment 107030 [details] [review] Correctly clears the display to blank
If I apply the patch, then indeed the "0(..." problem goes away and so does the "(5+3)/2" one. Unfortunately, gcalctool initially comes up with "No sane value to convert" and the error icon in the status bar. Yes I did do a "make clean" followed by a "make" first.
I'll try to describe what happened here... The way gcalctool works (and as do most physical calculators I've used) is that when the calculation is empty (i.e. cleared) instead of nothing being in the display zero is displayed in the appropriate format. When the user starts a calculation this zero is replaced the first number/function entered. In gcalctool 5.21.2 this was achieved using a flag called "ghost_zero". When ghost_zero == TRUE the display was cleared when the next number/function was entered and ghost_zero set to FALSE. When the display was cleared ghost_zero was set to TRUE and the calculation set to "Ans" with register value 0. From gcalctool 2.21.3 onwards this variable was removed and the logic changed to "if the calculation is empty display 0 in its place".
Created attachment 107032 [details] [review] Makes usable_num() understand empty expressions
Rich, just noticed that too, see additional patch.
Fix looks good. I suggest it be also committed to the "gnome-2-22" branch. Thanks!
Fixed on branch, closing.