> I think option 1 (Avoid GET_EC() as much as possible and pass ec explicitly.) is not realistic because it requires rewriting a large amount of existing code. I agree that it's not a suitable solution short term, especially since in ...byroot (Jean Boussier)
Possibly a duplicate of [Bug #1720] where it was established that `Float::NaN == Float::NaN` is "undefined" therefore OK. It seems that the motivation was to not prevent optimization of `rb_equal`.byroot (Jean Boussier)
I noticed this while trying to cleanup and simplify `rb_equal`. ```ruby >> Float::NAN == Float::NAN => false > ... => 0 ``` I would expect it to return `nil`. `Array#index` is just an example, any core method, and even C ext...byroot (Jean Boussier)
> you like me to do that for PR #19360? We don't backport performance patches, only bugfixes. > ... I already saw it, but's that's not how Ruby works, that's not for me to decide such a big change with user visible (albeit minor) i...byroot (Jean Boussier)
> Let's ship a better algorithm in 4.1, and an even better one in 4.2, and an even better one if 4.3… It's not that simple though, there's a maintenance cost to all this (e.g. backports), and these algorithm can have subtly different ...byroot (Jean Boussier)
* [Feature 21308] Replacing dtoa.c implementation with a modern algorithm (byroot) * Not my ticket, but this has been open for a while. * While it's not a major hotspot for most applications, it's true that `Float#to_s` and `String...byroot (Jean Boussier)
> Conversions between Float and String: For this specifically [Feature #21308] has been open for a while. I'd like to see it addressed, but this is a field that's been strangely moving fast with new implementation coming out regularly...byroot (Jean Boussier)
It would be easier to discuss the implementation if you opened a pull request (even as draft). For instance I have several concerns about `hidden_ivar_get`: - Not using atomics (technically tearing isn't a concern for pointer siz...byroot (Jean Boussier)
> a child that an extension forks with fork(2) and then passes to rb_thread_atfork(), as the C API asks I remember this being discussed a while ago and I believe that the conclusion was that forking from C wasn't supported. I'm a bit ...byroot (Jean Boussier)