New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Float parsing uses strtod
, but rline calls setlocale
#47
Comments
Can not reproduce?
These functions are simple wrappers around libm math functions and appear to be working as intended on the platforms I have tested on. |
I believe I have found the general area where the culprit is lurking, although I don't know what is going on, or how to fix it. I have focused solely on If I launch kuroko with the environment variable If I launch kuroko with any of (These were the available locales on my boxen.) My Python interpreter, as well as the S-Lang shell I'm gonna go out on a limb here, although it could be totally wrong: At least one of the characteristics of the locales that give the right result is that they use Now, irregardless of the locale, kuroko does not accept |
Using Kuroko with locales other than Please confirm that you get the misparse of |
This should not normally be an issue when running scripts, but rline calls If you wish to use the repl with a locale other than |
Well, that was an unfortunate turn of events…
Perhaps rline should not call There's something I don't understand: When setlocale(LC_ALL, "C.UTF-8"); why is the locale of the environment a problem at all? |
PS: Oh, and yes: the REPL does interpret |
rline needs to run
rline only does that on Windows. On other platforms, it calls
rline, of course, does not care about things like numeric formatting, and was originally written for a platform that had no locale support... |
math.ceil()
is identical to that of math.floor()
strtod
, but rline calls setlocale
Ah yes, I misread the I'm not sure I'm prepared to give up rline, so I have mitigated the problem by aliasing |
Changing the title of this issue to reflect the underlying problem, so it can be more directly addressed. Given that I want Kuroko to be usable in an embedded environment where someone else may have already been using I have a locale-oblivious I don't have a complete in-house float printer - the one in ToaruOS is very incomplete. |
I wonder if the issue could be mitigated for “everyone” in this way [until a more solid fix is in place]: Do the Windows/non-Windows if (get_decimal_separator() != '.') {
setlocale(LC_ALL, "C.UTF-8");
warn_user_that_locale_has_been_changed();
} |
Possibly. Checking the radix symbol in a portable manner is slightly tricky, but a quick hack might be to do |
Not going to print a warning for now, especially since |
Thanks, that quick hack works great for me. 👍 Is it really necessary to set the locale for each and every time
Could something like this be called portable (disclaimer, I don't speak C): #include <locale.h>
#include <stdio.h>
int main() {
(void) setlocale(LC_ALL, "");
struct lconv *lc = localeconv();
(void) printf("Decimal separator: %s\n", lc->decimal_point);
return 0;
} 📎 radix.c |
E.g.: #ifndef _WIN32
static int locale_has_been_initialized = 0;
if (locale_has_been_initialized == 0) {
(void) setlocale(LC_ALL, "");
struct lconv *lc = localeconv();
if (strcmp(lc->decimal_point, ".") != 0) {
(void) setlocale(LC_ALL, "C.UTF-8");
}
locale_has_been_initialized = 1;
}
#else |
Come to think of it: Let me see if I can provide a sensible pull-request… |
This misunderstands the relationship between Meanwhile, as long as Kuroko relies on the functionality of |
Thanks, I get your point. Makes sense. Meanwhile you could consider if the call to |
My current thought for an improved kludge is to have Once Kuroko is free of locale-dependent functions on its own, the C locale functionality can be exposed which will allow the locale to be set when calling, eg., Looking through the codebase, functions which may be locale-dependent include:
|
You know your code infinitely better than I do, so let me ask you this naive question: Would such a locale exist that considers HIRAGANA LETTER A (あ) “2 cells wide”, that would miscalculate e.g. LOTUS (🪷)? I recently had a problem with the editor JED not being able to correctly edit a line containing the LOTUS character: Perhaps HIRAGANA LETTER A will be enough to asses a locale, but I thought I'd mention it anyway. |
This is a complicated question. In order for any program to correctly handle this, its own |
I have made some progress towards implementing a proper in-house |
Thank you for your patience, it's highly appreciated. 🙏 |
The new I also deployed the described change to |
Great news, thanks! 🙏 |
I am pleased to note that in the in-progress
There is still some work to do to clean up and verify all of this before merging it. |
That branch has been merged, and Kuroko no longer uses |
Re.: commit f1d7bda
It seems
math.ceil(x)
andmath.floor(x)
returns the same value for a givenx
The text was updated successfully, but these errors were encountered: