K Lange

Not going to print a warning for now, especially since `rline` does its locale setting every time a new prompt is shown, but see if this helps for you: https://github.com/kuroko-lang/kuroko/commit/0c8cb94b6acb52f4b9f00cda4f4b65bd3b02bf94

This misunderstands the relationship between `rline` and Kuroko. `rline` is not part of Kuroko, and it must independently ensure that it is operating in a viable locale to perform its...

My current thought for an improved kludge is to have `rline` only set the `LC_CTYPE` locale setting, and only if it determines the current locale does not think `(wchar_t)0x3024` (あ)...

This is a complicated question. In order for any program to correctly handle this, its own `wcwidth` results must match the _terminal_'s `wcwidth` results (or whatever the terminal uses to...

I have made some progress towards implementing a proper in-house `strtod` by making use of Kuroko's existing bigints: taking the decimal representation of the significant digits and dividing them by...

The new `long.__truediv__` implementation has been pushed, so at least now you can accurately write floats as the division of two large integers and that should always work regardless of...

I am pleased to note that in the in-progress `in-house-float-conversions` branch (https://github.com/kuroko-lang/kuroko/tree/in-house-float-conversions), we now have: - Accurately rounded `long.__truediv__`, which means double-precision floats can be accurately represented as fractions or...

That branch has been merged, and Kuroko no longer uses `strtod` to parse floats, or `printf` to convert them to strings.

Clever - that is, indeed, a very small window! This might be easily defeated with a small bit of locking around process creation, which is sorely needed anyway... Unfortunately, my...

This is such a tight window I wasn't able to get the PoC to work - but it did routinely exhaust memory from the hundreds of `sudo` processes (I really...