- ruby-core - ml.ruby-lang.org

[ruby-core:113303] [Ruby master Feature#19610] GC.delay_promotion
by peterzhu2118 (Peter Zhu) 19 May '23

19 May '23

Issue #19610 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19610: GC.delay_promotion https://bugs.ruby-lang.org/issues/19610 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub Pull Request: https://github.com/ruby/ruby/pull/7683 I'm proposing `GC.delay_promotion`, which is a feature that changes characteristics of the garbage collector. When set to `false` (the default value), the GC keeps the original behavior. This means that references from an old object to a write barrier protected young object will immediately promote the young object. References from an old object to a write barrier unprotected object will place the write barrier unprotected object in the remember set for marking during minor collections. When set to `true`, references from an old object to a write barrier protected young object will not immediately promote the young object. Instead, the young object will age just like any other object, meaning that it has to survive three collections before being promoted to the old generation. References from an old object to a write barrier unprotected object will place the parent object in the remember set for marking during minor collections. This allows the child object to be reclaimed in minor collections at the cost of increased time for minor collections. On one of [Shopify's highest traffic Ruby apps, Storefront Renderer](https://shopify.engineering/how-shopify-reduced-storefront-response-times-rewrite), we saw significant improvements after deploying this feature in production. In the graphs below, we compare the GC time and response time of web workers that have `GC.delay_promotion = false` (non-experimental group) and `GC.delay_promotion = true` (experimental group). We see that with this feature we spend significantly less time in the GC, 0.81x on average, 0.88x on p99, and 0.45x on p99.9. ![](Screenshot%202023-04-20%20at%2011.50.26%20AM.png) This translates to improvements in average response time (0.96x) and p99 response time (0.92x). ![](Screenshot%202023-04-20%20at%2011.50.38%20AM.png) In benchmarks, this feature performs better in some scenarios and worse in others. However, these benchmarks are usually not a good indicator as there are few old objects and major collections are not a significant bottleneck. ``` -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- bench master (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr master/branch activerecord 70.7 0.2 54.4 70.5 0.3 54.7 1.01 1.00 erubi_rails 20.5 2.0 103.0 20.7 2.2 102.2 0.94 0.99 hexapdf 2470.1 0.3 275.6 2475.4 0.7 215.9 1.03 1.00 liquid-c 65.2 1.4 39.8 65.4 0.3 39.7 1.05 1.00 liquid-compile 59.5 3.4 38.9 57.5 3.0 38.3 0.99 1.04 liquid-render 164.3 1.1 36.1 159.8 0.2 35.5 1.02 1.03 mail 135.7 0.2 50.2 135.3 0.1 50.0 1.00 1.00 psych-load 2053.0 0.0 36.4 2003.3 0.1 35.3 1.03 1.02 railsbench 2001.8 0.7 107.1 1965.1 0.0 107.3 1.00 1.02 ruby-lsp 67.1 8.7 94.6 65.1 0.8 92.8 0.97 1.03 sequel 72.4 0.2 40.4 71.3 0.2 40.4 1.01 1.02 -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- ``` ---Files-------------------------------- Screenshot 2023-04-20 at 11.50.26 AM.png (527 KB) Screenshot 2023-04-20 at 11.50.38 AM.png (350 KB) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:113513] [Ruby master Feature#19678] Don't immediately promote children of old objects
by peterzhu2118 (Peter Zhu) 18 May '23

18 May '23

Issue #19678 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19678: Don't immediately promote children of old objects https://bugs.ruby-lang.org/issues/19678 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- This is an alternate proposal to #19610 where the feature is not configurable and always enabled. GitHub Pull Request: https://github.com/ruby/ruby/pull/7821 References from an old object to a write barrier protected young object will not immediately promote the young object. Instead, the young object will age just like any other object, meaning that it has to survive three collections before being promoted to the old generation. References from an old object to a write barrier unprotected object will place the parent object in the remember set for marking during minor collections. This allows the child object to be reclaimed in minor collections at the cost of increased time for minor collections. On one of [Shopify's highest traffic Ruby apps, Storefront Renderer](https://shopify.engineering/how-shopify-reduced-storefront-response-times-rewrite), we saw significant improvements after deploying this feature in production. In the graphs below, we compare the GC time and response time of web workers that have `GC.delay_promotion = false` (non-experimental group) and `GC.delay_promotion = true` (experimental group). We see that with this feature we spend significantly less time in the GC, 0.81x on average, 0.88x on p99, and 0.45x on p99.9. ![](Screenshot%202023-04-20%20at%2011.50.26%20AM.png) This translates to improvements in average response time (0.96x) and p99 response time (0.92x). ![](Screenshot%202023-04-20%20at%2011.50.38%20AM.png) In benchmarks, this feature performs better in some scenarios and worse in others. However, these benchmarks are usually not a good indicator as there are few old objects and major collections are not a significant bottleneck. ``` -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- bench master (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr master/branch activerecord 70.7 0.2 54.4 70.5 0.3 54.7 1.01 1.00 erubi_rails 20.5 2.0 103.0 20.7 2.2 102.2 0.94 0.99 hexapdf 2470.1 0.3 275.6 2475.4 0.7 215.9 1.03 1.00 liquid-c 65.2 1.4 39.8 65.4 0.3 39.7 1.05 1.00 liquid-compile 59.5 3.4 38.9 57.5 3.0 38.3 0.99 1.04 liquid-render 164.3 1.1 36.1 159.8 0.2 35.5 1.02 1.03 mail 135.7 0.2 50.2 135.3 0.1 50.0 1.00 1.00 psych-load 2053.0 0.0 36.4 2003.3 0.1 35.3 1.03 1.02 railsbench 2001.8 0.7 107.1 1965.1 0.0 107.3 1.00 1.02 ruby-lsp 67.1 8.7 94.6 65.1 0.8 92.8 0.97 1.03 sequel 72.4 0.2 40.4 71.3 0.2 40.4 1.01 1.02 -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- ``` ---Files-------------------------------- Screenshot 2023-04-20 at 11.50.26 AM.png (527 KB) Screenshot 2023-04-20 at 11.50.38 AM.png (350 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113507] [Ruby master Bug#19677] Failed to build ruby from the source code when following the guide
by tagomoris (Satoshi TAGOMORI) 18 May '23

18 May '23

Issue #19677 has been reported by tagomoris (Satoshi TAGOMORI). ---------------------------------------- Bug #19677: Failed to build ruby from the source code when following the guide https://bugs.ruby-lang.org/issues/19677 * Author: tagomoris (Satoshi TAGOMORI) * Status: Open * Priority: Normal * ruby -v: git clone github.com/ruby/ruby (master HEAD cea9c30fa549885e36471f1782359df2bdcf895a) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I followed the document "Building Ruby" (doc/contributing/building_ruby.md) and got build errors. At the step of "5. Build Ruby: make install", the errors below happened: ``` MBA:build tagomoris$ make -j 8 BASERUBY = /Users/tagomoris/.rbenv/shims/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -dynamiclib CFLAGS = -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wundef -pipe XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT -fPIE -I. -I.ext/include/arm64-darwin22 -I../include -I.. -I../enc/unicode/15.0.0 CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT DLDFLAGS = -L/opt/homebrew/opt/bison/lib -Wl,-multiply_defined,suppress -Wl,-undefined,dynamic_lookup -fstack-protector-strong -Wl,-pie -framework CoreFoundation SOLIBS = -ldl -lobjc -lpthread LANG = LC_ALL = LC_CTYPE = UTF-8 MFLAGS = - --jobserver-fds=4,5 -j RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/Users/tagomoris/gh/ruby/build/yjit/target/release/' ../yjit/src/lib.rs Apple clang version 14.0.3 (clang-1403.0.22.14.1) Target: arm64-apple-darwin22.4.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin compiling ../compile.c compiling ../complex.c compiling ../cont.c compiling ../debug.c compiling ../debug_counter.c compiling ../dir.c compiling ../dln_find.c compiling ../encoding.c compiling ../enum.c compiling ../enumerator.c making ../warning.rbinc ../compile.c:2455:38: error: call to undeclared function 'ISEQ_IS_ENTRY_START'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] IC ic = &ISEQ_IS_ENTRY_START(body, type)[ic_index].ic_cache; ^ ../compile.c:2455:69: error: subscripted value is not an array, pointer, or vector IC ic = &ISEQ_IS_ENTRY_START(body, type)[ic_index].ic_cache; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ ../compile.c:2484:28: error: use of undeclared identifier 'TS_ICVARC'; did you mean 'TS_IVC'? case TS_ICVARC: /* inline cvar cache */ ^~~~~~~~~ TS_IVC ../insns_info.inc:44:5: note: 'TS_IVC' declared here TS_IVC = 'A', ^ (snip) ``` I got a successful build when I tried `make ruby; make install` instead. So, I'm assuming that the build script has a bug, or the document should be updated. My environment summary: ``` $ uname -a Darwin Moris-Air 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103 arm64 $ clang --version Apple clang version 14.0.3 (clang-1403.0.22.14.1) Target: arm64-apple-darwin22.4.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument
by shioyama (Chris Salzberg) 18 May '23

18 May '23

Issue #19633 has been reported by shioyama (Chris Salzberg). ---------------------------------------- Feature #19633: Allow passing block to `Kernel#autoload` as alternative to second `filename` argument https://bugs.ruby-lang.org/issues/19633 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#autoload` takes two arguments, a symbol `module` representing the constant to be autoloaded, and a `filepath` to load the constant from (with `require`). Currently, Zeitwerk has to [monkeypatch `Kernel#require`](https://github.com/fxn/zeitwerk/blob/a7c4a983df0f4e4058f32c610dac1e8b99f687da/lib/zeitwerk/kernel.rb) to fetch the loader for the file being loaded, then run the original (aliased) `require`, then run autoload callbacks. In addition to the monkeypatch, this also requires a registry (`Zeitwerk::Registry`) to map file paths to loaders, to know which loader should be used for a given autoload-triggered `require`. In fact, Zeitwerk has to _assume_ that the monkey-patched `require` call came from an autoload trigger; there is no way to really be sure of the source. If Ruby allowed passing a block as an alternative to the explicit filepath, then I think this could be improved and would eliminate the need for a monkeypatch. So something like this: ```ruby autoload(:B) do require "lib/b" # trigger callback, etc end ``` I am implementing a gem called [Im](https://github.com/shioyama/im) which is a fork of Zeitwerk, and in the case of this gem, such a feature would be even more useful. Im implements autoloads on anonymous modules by registering an autoload and then "catching" the require and converting it into a `load`, passing the module as the second argument (see [here](https://github.com/shioyama/im/blob/44ce348639a1aae563a5be7a40602761e….) This is currently quite tricky because, again, it's hard to know _where_ a `require` came from. In addition to removing the monkeypatch (inherited from Zeitwerk), Im would further benefit from the block argument because then it could simply access the module via a closure, rather than pulling it from a registry: ```ruby mod.autoload(:Foo) do load "lib/foo.rb", mod end ``` I don't know how hard or easy this would be to implement, but if there is interest in this as a feature I'd be happy to look into implementing it. -- https://bugs.ruby-lang.org/

3 15

[ruby-core:113505] [Ruby master Feature#12165] Hash#first, Hash#last
by bughit (bug hit) 17 May '23

17 May '23

Issue #12165 has been updated by bughit (bug hit). nobu (Nobuyoshi Nakada) wrote in #note-5: > Although I've not thought about `Hash#last`, once when `st_table` got keeping the insertion order I proposed `Hash#reverse_each` (`st_reverse_foreach` for it precisely) to matz, but was rejected. Is it not reasonable for a user to expect that core/std lib code will be at least not, knowingly, intentionally, horribly sub-optimal? Since at least two people tried to fix `Hash#reverse_each` and were rejected, that's exactly what it is at this point, knowingly, intentionally, horribly sub-optimal. ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103100 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113501] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nobu (Nobuyoshi Nakada) 17 May '23

17 May '23

Issue #18743 has been updated by nobu (Nobuyoshi Nakada). Seems find to me. One thing I concerned, `stop_exc` will be re-created every times, and no way to know where it was first used up. How about chaining by `cause`? ```diff diff --git a/enumerator.c b/enumerator.c index b33c1713718..1cc8f9108cf 100644 --- a/enumerator.c +++ b/enumerator.c @@ -30,6 +30,9 @@ #include "internal/rational.h" #include "ruby/ruby.h" +extern ID ruby_static_id_cause; +#define id_cause ruby_static_id_cause + /* * Document-class: Enumerator * @@ -787,8 +790,16 @@ get_next_values(VALUE obj, struct enumerator *e) { VALUE curr, vs; - if (e->stop_exc) - rb_exc_raise(e->stop_exc); + if (e->stop_exc) { + VALUE exc = e->stop_exc; + VALUE result = rb_attr_get(exc, id_result); + VALUE mesg = rb_attr_get(exc, idMesg); + if (!NIL_P(mesg)) mesg = rb_str_dup(mesg); + VALUE stop_exc = rb_exc_new_str(rb_eStopIteration, mesg); + rb_ivar_set(stop_exc, id_result, result); + rb_ivar_set(stop_exc, id_cause, exc); + rb_exc_raise(stop_exc); + } curr = rb_fiber_current(); ``` In the test, save `$!` at the first `rescue` then `assert_same(cause, exc.cause)`. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103096 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113500] [Ruby master Feature#12165] Hash#first, Hash#last
by nobu (Nobuyoshi Nakada) 17 May '23

17 May '23

Issue #12165 has been updated by nobu (Nobuyoshi Nakada). Although I've not thought about `Hash#last`, once when `st_table` got keeping the insertion order I proposed `Hash#reverse_each` (`st_reverse_foreach` for it precisely) to matz, but was rejected. ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103095 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113499] [Ruby master Feature#12165] Hash#first, Hash#last
by bughit (bug hit) 16 May '23

16 May '23

Issue #12165 has been updated by bughit (bug hit). @nobu Since you commented recently, what do you think about about a performant Hash#last(n=1) and a related performant Hash#reverse_each ? Should any ordered collection have those? ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103094 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113497] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 16 May '23

16 May '23

Issue #18743 has been updated by marcper (Marcelo Pereira). Hey again, @ko1. This is just a reminder that the patch is pushed to Github and is waiting for a decision. Best, Marcelo ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103093 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113494] [Ruby master Bug#11582] On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float
by ngoto (Naohisa Goto) 16 May '23

16 May '23

Issue #11582 has been updated by ngoto (Naohisa Goto). Status changed from Third Party's Issue to Closed This issue is solved by [Misc #15347]. In the C99 spec, The behavior of pow(3) in corner cases are clearly defined. Since Ruby 2.7, C99 is required to compile CRuby source code, and thus Ruby's pow method conforms to the C99 standard. ---------------------------------------- Bug #11582: On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float https://bugs.ruby-lang.org/issues/11582#change-103079 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- For instance, > Rational(0, 1) ** -1.0 => +Infinity on most platforms, -Infinity on Solaris by default. The Rational is implicitly converted to the Float value 0.0, and the libm function pow(0.0, -1.0) is called. Should this kind of behavior be made consistent by Ruby or should we accept this as dependent on the libm/libc used? They are likely other edges cases for pow() which might differ, and I think in general Ruby should try to unify these cases so the behavior is consistent across platforms at least for arithmetic. For more details, please see https://github.com/ruby/rubyspec/issues/134 reported by ngoto. -- https://bugs.ruby-lang.org/

1 0