| Summary: | Can no longer parse some hexadecimal input | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Luke-Jr <luke-jr+kdebugs> |
| Component: | calculator | Assignee: | Alexander Lohnau <alexander.lohnau> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate, ped, plasma-bugs |
| Priority: | HI | Keywords: | regression |
| Version: | 5.20.4 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/a3b017ccb56be918163fed350e181ec4fd57db73 | Version Fixed In: | 5.21.1 |
|
Description
Luke-Jr
2021-01-09 18:11:00 UTC
Confirmed. Does "=hex(1ff)" work as expected? The issue seems that the x is interpreted as a multiplication operator. This was a feature request some time ago. Do you think it would be a good idea to exclude "0xwhatever" queries from this rule? (In reply to Alexander Lohnau from comment #2) > Does "=hex(1ff)" work as expected? Yep, works for me. > The issue seems that the x is interpreted as a multiplication operator. This > was a feature request some time ago. > > Do you think it would be a good idea to exclude "0xwhatever" queries from > this rule? I think that makes sense. *** Bug 431285 has been marked as a duplicate of this bug. *** Git commit 292d9d19250a81757128666c6b3784c41b3e1697 by Alexander Lohnau. Committed on 13/01/2021 at 19:22. Pushed by alex into branch 'master'. calculator runner: Fix handling of hexadecimal input/output - In case our query starts with 0x123abc we do not call the `userFriendlyMultiplication` method which replaces the x sign with the multiplication operator. We can be sure that the user wants to parse a hex value. Also the `=` is not mandatory anymore. - The hex=mydecimalnumber functionality was broken. The conversion of the hex value is only done inside of the if statement and before the values will be the same, unless we do some math operation. Test Plan: `=0xf` returns 15 `0xf` return 15 `7x7` returns 49 `hex=15` returns 0xF `hex=14+1` returns 0xF FIXED-IN: 5.21 M +7 -4 runners/calculator/calculatorrunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/292d9d19250a81757128666c6b3784c41b3e1697 So, in trivial cases it now works, but for non-trivial expressions it still leads to wrong results, like: =0x12+1 -> 19 =1+0x12 -> 1 While I get why the feature was added (for less tech users), it caused me already quite a disruption in my own usage, as I never expect it and sometimes it takes me some time to realize the result was actually wrong and I have to evade it with "0X" instead. I mean with 5.21 I will run into it lot less, as I mostly put hexa numbers at beginning of expression or convert only single number, but I'm not sure if that makes it actually even worse, because it may be more difficult to spot the result is wrong. I will try to write a fix for that in this week. Git commit ef4d5d0f6868fa6f010eaa6b427c5e84519eb37e by Alexander Lohnau. Committed on 22/02/2021 at 17:27. Pushed by alex into branch 'master'. calculatorrunner: Fix mixed hex+decimal calculations FIXED-IN: 5.21.1 M +1 -1 runners/calculator/calculatorrunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/ef4d5d0f6868fa6f010eaa6b427c5e84519eb37e Git commit a3b017ccb56be918163fed350e181ec4fd57db73 by Alexander Lohnau. Committed on 22/02/2021 at 19:45. Pushed by alex into branch 'Plasma/5.21'. calculatorrunner: Fix mixed hex+decimal calculations FIXED-IN: 5.21.1 M +1 -1 runners/calculator/calculatorrunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/a3b017ccb56be918163fed350e181ec4fd57db73 |