Bug#353452: LC_NUMERIC support
close 353452 quit * Martin Buck Don't get me wrong - I can fully understand the motivation behind your request, but I simply don't think that calc is the kind of application that should be locale-dependent. IMHO, this is something for GUI calculators or really simple command-line calculators, but not for complete programming languages with a well-defined syntax that would break due to changes like this. So you'll get my standard reply: I'm only packaging calc for Debian, but I'm not one of its developers. If you can convice the upstream developers that adding locale-support to a future release would be a good thing (and they find a clean way to do it), then this change will appear in the Debian package automatically. Just don't expect me to lobby for this change. No problem. It was only a wishlist anyway; refusing those is perfectly legitimate. :-) So as there's no point in having the report stick around to clutter your bug list, I'm closing it. Cheers -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353452: LC_NUMERIC support
On Mon, Feb 20, 2006 at 10:41:34AM +0100, Tore Anderson wrote: Personally I use it mostly as an interactive application, for whenever I need to do some calculation. Me too. I just like it better than bc. Anyway, in this case it is somewhat annoying that I always have to remember to use some foreign syntax of specifying the radix point. Also I usually cannot copy/paste numbers from documents or outputted by other programs into calc. I can copy paste easily between *all* calculators and programming languages I use - I simply don't set LC_NUMERIC (even though comma would be the official decimal separator here in Switzerland as well). :-) meaning to calc. If it hadn't it could probably had been made to interpret both the period and the comma as the radix point, which would ensure backwards compability as well as satisfy me. That would probably make you happy, but I'm sure there are countries out there using even more bizarre decimal (or thousands) separators, and supporting all of them without clashing with any of calc's operators (try help operator for a list) will be quite difficult. In any case, the output should in my humble opinion heed $LC_NUMERIC: I think that would be even worse - then you couldn't even copy paste within calc. Don't get me wrong - I can fully understand the motivation behind your request, but I simply don't think that calc is the kind of application that should be locale-dependent. IMHO, this is something for GUI calculators or really simple command-line calculators, but not for complete programming languages with a well-defined syntax that would break due to changes like this. So you'll get my standard reply: I'm only packaging calc for Debian, but I'm not one of its developers. If you can convice the upstream developers that adding locale-support to a future release would be a good thing (and they find a clean way to do it), then this change will appear in the Debian package automatically. Just don't expect me to lobby for this change. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353452: LC_NUMERIC support
* Martin Buck I'm not convinced that this would be a good thing. calc effectively is a programming language, and making the syntax of a programming language dependent on locale settings doesn't sound like a good idea to me (if gcc started to do that, I'm pretty sure it would get a few grave bugs within seconds of the upload). Personally I use it mostly as an interactive application, for whenever I need to do some calculation. I just like it better than bc. Anyway, in this case it is somewhat annoying that I always have to remember to use some foreign syntax of specifying the radix point. Also I usually cannot copy/paste numbers from documents or outputted by other programs into calc. It would be nice if it worked with the comma, that's all. And what should calc do with those operators that become inaccessible because LC_NUMERIC's decimal separator clashes with them (like ',' in your case)? No idea, really. I wasn't aware that the comma had some special meaning to calc. If it hadn't it could probably had been made to interpret both the period and the comma as the radix point, which would ensure backwards compability as well as satisfy me. I'm no authority on the subject, but I think those two are the only ones that are generally used. In any case, the output should in my humble opinion heed $LC_NUMERIC: C-style arbitrary precision calculator (version 2.11.11) Calc is open software. For license details type: help copyright [Type exit to exit, or help for help.] ; 1 / 2 0.5 That should've printed 0,5, given my locale. Kind regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353452: LC_NUMERIC support
Package: apcalc Severity: wishlist Hi. It would be great if calc supported LC_NUMERIC: $ LC_ALL=nn_NO calc '0,5 + 0,5' Line 1: unused value ignored Line 1: unused value ignored 5 The expected result here would be 1, as the Norwegian decimal separator is the comma (as it is in many other countries as well). -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353452: LC_NUMERIC support
On Sat, Feb 18, 2006 at 05:10:08PM +0100, Tore Anderson wrote: Hi. It would be great if calc supported LC_NUMERIC: I'm not convinced that this would be a good thing. calc effectively is a programming language, and making the syntax of a programming language dependent on locale settings doesn't sound like a good idea to me (if gcc started to do that, I'm pretty sure it would get a few grave bugs within seconds of the upload). And what should calc do with those operators that become inaccessible because LC_NUMERIC's decimal separator clashes with them (like ',' in your case)? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
