May 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113475] [Ruby master Bug#18933] Dir.tmpdir implemented in non-Ractor-safe manner
by headius (Charles Nutter) 14 May '23

14 May '23

Issue #18933 has been updated by headius (Charles Nutter). Why not just put this in a private constant? I believe that would be Ractor-safe and it would make more sense than a lazy class variable or class instance variable (that's not actually lazy). ---------------------------------------- Bug #18933: Dir.tmpdir implemented in non-Ractor-safe manner https://bugs.ruby-lang.org/issues/18933#change-103057 * Author: kreynolds (Kelley Reynolds) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- # Background Inside a Ractor, it is expected that generating a temporary directory using `Dir.tmpdir` will work. The current implementation uses a number of things which are not considered Rector-safe and will require refactoring. # How to reproduce ```ruby Ractor.new { Dir.tmpdir } ``` # Expectation and result The result is expected to be something along the lines of `"/var/folders/xm/y4c00x0s26sgf_zlnqjh_7800000gn/T"` but instead a `Ractor::IsolationError` exception is raised: ```ruby 3.1.2/lib/ruby/3.1.0/tmpdir.rb:23:in `tmpdir': can not access class variables from non-main Ractors (Ractor::IsolationError) ``` # Suggested solutions * Make cached class variable a shareable constant * Modify how random values are generated to be Rector-safe ---Files-------------------------------- tmpdir.diff (1.77 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113474] [Ruby master Feature#18258] Ractor.shareable? can be slow and mutates internal object flags.
by jeremyevans0 (Jeremy Evans) 14 May '23

14 May '23

Issue #18258 has been updated by jeremyevans0 (Jeremy Evans). Tracker changed from Bug to Feature Status changed from Open to Closed ruby -v deleted (3.0.2) Backport deleted (2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN) @headius and I discussed this and we agree it is not a bug, though potentially the situation could be improved. You could avoid the object flag mutation using a temporary hash per call to shareable, but that would likely make it even slower. It doesn't seem possible to cache that an object is not shareable without creating significant cache invalidation issues. Having String#freeze set the shareable flag if the string has no instance variables seems like a good idea, but that is more of a feature request than a bug fix. Changing `Ractor.shareable?` to only do a shallow check and not a full check seems like a large semantic change, not a bug fix, and would make Ractor.shareable? operate differently than Ractor.make_shareable. Maybe a new Ractor.flagged_shareable? method could be added to do a shallow check for the shareable flag, but I'm not sure how useful such a method would be. ---------------------------------------- Feature #18258: Ractor.shareable? can be slow and mutates internal object flags. https://bugs.ruby-lang.org/issues/18258#change-103055 * Author: ioquatix (Samuel Williams) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- On my computer, even with a relatively small object graph,`Ractor.shareable?` can be quite slow (around 1-2ms). The following example creates an object graph with ~40k objects as an example, and on my computer takes around 20ms to execute `Ractor.shareable?`. Because the object cannot be marked as `RB_FL_SHAREABLE` because it contains mutable state, every time we check `Ractor.shareable?` it will perform the same object traversal which is the slow path. ``` ruby require 'benchmark' class Borked def freeze end end class Nested def initialize(count, top = true) if count > 0 @nested = count.times.map{Nested.new(count - 1, false).freeze}.freeze end if top @borked = Borked.new end end attr :nested attr :borked end def test(n) puts "Creating nested object of size N=#{n}" nested = Nested.new(n).freeze shareable = false result = Benchmark.measure do shareable = Ractor.shareable?(nested) end pp result: result, shareable: shareable end test(8) ``` I propose we change `Ractor.shareable?` to only check `RB_FL_SHAREABLE` which gives (1) predictable and fast performance in every case and (2) avoids mutating internal object flags when performing what looks like a read-only operation. I respect that one way of looking at `Ractor.shareable?` is as a cache for object state. But this kind of cache can lead to unpredictable performance. As a result, something like `String#freeze` would not create objects that can be shared with Ractor. However, I believe we can mitigate this by tweaking `String#freeze` to also set `RB_FL_SHAREABLE` if possible. I believe we should apply this to more objects. It will lead to more predictable performance for Ruby. Since there are few real-world examples of Ractor, it's hard to find real world example of the problem. However, I believe such an issue will prevent Ractor usage as even relatively small object graphs (~1000 objects) can cause 1-2ms of latency, and this particular operation does not release the GVL either which means it stalls the entire VM. This issue came from discussion regarding https://bugs.ruby-lang.org/issues/18035 where we are considering using `RB_FL_SHAREABLE` as a flag for immutability. By fixing this issue, we make it easier to implement model for immutability because we don't need to introduce new flags and can instead reuse existing flags. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113473] [Ruby master Bug#17680] tab completion no longer works on irb3.0
by jeremyevans0 (Jeremy Evans) 14 May '23

14 May '23

Issue #17680 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This change from 2.5 is expected due to differences between reline and readline. As readline has been removed from stdlib, reline's behavior is now the only available behavior. Behavior is the same on JRuby. It's possible a pull request to reline to have tab completion behavior more compatible to readline may be considered, but that would be up to the reline maintainer. ---------------------------------------- Bug #17680: tab completion no longer works on irb3.0 https://bugs.ruby-lang.org/issues/17680#change-103054 * Author: simondedeo (Simon DeDeo) * Status: Closed * Priority: Normal * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin16] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- in irb2.5: rb(main):001:0> source 'li [then I hit tab...] linking.rb list_load.rb list_load_OLD.rb irb(main):001:0> source 'lis [then I hit tab again...] list_load.rb list_load_OLD.rb irb(main):001:0> source 'list_load.rb' [then I hit tab again...] in irb3.0, hitting tab after typing "source 'li" gives. irb(main):001:0' source 'li' Here are my version numbers: ayerie:simon$ irb3.0 -v irb 1.3.0 (2020-12-25) ayerie:CHLOE simon$ ruby3.0 -v ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin16] ayerie:simon$ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113472] [Ruby master Bug#16959] Weakmap has specs and third-party usage despite being a private API
by headius (Charles Nutter) 14 May '23

14 May '23

Issue #16959 has been updated by headius (Charles Nutter). Status changed from Open to Rejected WeakMap has now been in the wild with documentation and specs for several years, so I think it has become a de-facto public API. I'm fine closing this, though I still would like to see the other features I have described added to Weakref. ---------------------------------------- Bug #16959: Weakmap has specs and third-party usage despite being a private API https://bugs.ruby-lang.org/issues/16959#change-103052 * Author: headius (Charles Nutter) * Status: Rejected * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Weakmap is still described as an internal API, and the documentation points users at WeakRef as the official public API: https://github.com/ruby/ruby/blob/1fb16dbb6e28b9f32f92554d29e646e088b21a98/… However there are now specs for its current set of features, even though those features have never been discussed or approved as a public API: https://github.com/ruby/spec/tree/dd8437628a6f2de5b74b338d4960682bb1590a60/… And we are starting to see it being used by the community: * https://github.com/jruby/jruby/issues/6267 * https://github.com/rsim/oracle-enhanced/issues/2027 * https://github.com/rails/rails/pull/39121 One of two things needs to happen: * Weakmap is made a public API after some discussion. It would be an official public feature only in 2.8/3.0 or higher. * ~~The specs are be removed and Weakmap remains a private API not to be used by the community. I suspect the addition of the specs led to folks starting to use this private API.~~ (edit: The Rails PR was merged after the specs, but the change is actually a year old, as mentioned below. In any case there's plenty of in-the-wild uses of WeakMap that go back even further.) Personally, I'm in much more in favor of making WeakRef support all the features necessary to implement Weakmap in pure Ruby, rather than the other way around: https://bugs.ruby-lang.org/issues/6309 But whatever happens it needs to happen soon, since this use case is now a merged feature in Rails master. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113470] [Ruby master Bug#5179] Complex#rationalize and to_r with approximate zeros
by kjtsanaktsidis (KJ Tsanaktsidis) 14 May '23

14 May '23

Issue #5179 has been updated by kjtsanaktsidis (KJ Tsanaktsidis). I've explored the behaviour here a bit, and I think I do believe that `0.0` really does represent the concept of "zero". Specifically, it's the number that satisfies the following properties, for all possible non-NaN floats N: * `abs(0.0 * N) == 0.0` * `0.0 + N == N` You might obtain a bit pattern for 0.0 from the result of a calculation which might have otherwise produced a non-zero result if there was more precision; however that doesn't change the fact that the bit pattern you have really does satisfy the mathematical properties of zero. Additionally, I think the distinction that complex.c currently draws between floating-point and non-floating-point zero also results in some other surprising results: ``` irb(main):030:0> Complex(3, 7) ** 0.0 => (1.0+0.0i) irb(main):031:0> Complex(3, 7) ** 0 => (1+0i) irb(main):032:0> Complex(3.2, 7) ** 0 => (1+0i) irb(main):033:0> Complex(3.2, 7) ** 0.0 => (1.0+0.0i) ``` Why does the type of `A ** B` depend on whether B is a float or not, but not A? ``` irb(main):034:0> Complex(3.2, 7) ** Complex(1, 0.0) => (3.200000000000001+6.999999999999999i) irb(main):035:0> Complex(3.2, 7) ** Complex(1, 0) => (3.2+7i) ``` This doesn't _need_ to accumulate floating point error - the code in `rb_complex_pow` special-cases `(a + bi) ** (c + 0i) -->(a + bi) ** c`, but the special-casing is skipped if `0i` is `0.0i` instead. Also, `#to_i` and `#to_f` have the same issue as `#to_r`: ``` irb(main):037:0> Complex(3, 0.0).to_i (irb):37:in `to_i': can't convert 3+0.0i into Integer (RangeError) irb(main):038:0> Complex(3, 0.0).to_f (irb):38:in `to_f': can't convert 3+0.0i into Float (RangeError) ``` This is especially odd for `#to_i` because it of course has no problems truncating away the real part: ``` irb(main):040:0> Complex(3.1, 0).to_i => 3 ``` I think we should change all the checks for `k_exact_zero_p` in `complex.c` to `f_zero_p`; i.e. in all the places where `complex.c` special-cases integer zero, also make it special-case floating-point zero. If people agree with this (especially people who actually use Complex in their code - I have pretty much never used it!) I can send a pretty simple patch to cloe this out. ---------------------------------------- Bug #5179: Complex#rationalize and to_r with approximate zeros https://bugs.ruby-lang.org/issues/5179#change-103049 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) * ruby -v: r32354 ---------------------------------------- Currently, Complex#rationalize and Complex#to_r raise a RangeError if the imaginary part is nonzero *or is a Float*. Note that a BigDecimal(0) is accepted, though: Complex(1, 0).to_r # => Rational(1,1) Complex(1, BigDecimal("0.0")).to_r # => Rational(1,1) Complex(1, 0.0).to_r # => RangeError This is inconsistent. I recommend not raising an error for 0.0 (Float or BigDecimal). Any objection? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113464] [Ruby master Misc#16512] Improving `www.ruby-lang.org` reference by merging with `rubyreferences.github.io`
by hsbt (Hiroshi SHIBATA) 13 May '23

13 May '23

Issue #16512 has been updated by hsbt (Hiroshi SHIBATA). Assignee changed from zverok (Victor Shepelev) to hsbt (Hiroshi SHIBATA) I discussed this with @ufuk. We will work this to forward. ---------------------------------------- Misc #16512: Improving `www.ruby-lang.org` reference by merging with `rubyreferences.github.io` https://bugs.ruby-lang.org/issues/16512#change-103043 * Author: matz (Yukihiro Matsumoto) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- @zverok prepared better-looking reference pages at `rubyreferences.github.io`. I think there's room for improvement of reference pages on `www.ruby-lang.org`. @hsbt Is there a chance to work with? Matz. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113463] [Ruby master Feature#10602] Support multithreaded profiling
by ivoanjo (Ivo Anjo) 13 May '23

13 May '23

Issue #10602 has been updated by ivoanjo (Ivo Anjo). PR to implement this being discussed in https://github.com/ruby/ruby/pull/7784 ---------------------------------------- Feature #10602: Support multithreaded profiling https://bugs.ruby-lang.org/issues/10602#change-103042 * Author: mperham (Mike Perham) * Status: Open * Priority: Normal ---------------------------------------- The current `rb_profile_frames` captures the frame for whatever thread is current. This makes profiling a multithreaded system impossible. I'd like a `rb_thread_profile_frames` which captures a given thread. It seems like it would be a very simple change, something like this: ~~~ int rb_profile_frames(int start, int limit, VALUE *buff, int *lines) { rb_profile_frames(start, limit, buff, lines, GET_THREAD()) } int rb_thread_profile_frames(int start, int limit, VALUE *buff, int *lines, rb_thread_t *th) { int i; rb_control_frame_t *cfp = th->cfp, *end_cfp = RUBY_VM_END_CONTROL_FRAME(th); ... ~~~ This way profiling gems could lock to a specific thread. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113460] Ruby 3.3.0-preview1 Released
by NARUSE, Yui 12 May '23

12 May '23

We are pleased to announce the release of Ruby 3.3.0-preview1. Ruby 3.3 adds a new pure-Ruby JIT compiler named RJIT, uses lrama as a parser generator, and many performance improvements especially YJIT. ## RJIT * Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT. * RJIT supports only x86\_64 architecture on Unix platforms. * Unlike MJIT, it doesn't require a C compiler at runtime. * RJIT exists only for experimental purposes. * You should keep using YJIT in production. * If you are interested in developing JIT for Ruby, please check out [k0kubun's presentation on Day 3 of RubyKaigi](https://rubykaigi.org/2023/presentations/k0kubun.html#day3). ## Use Lrama instead of Bison * Replace Bison with [Lrama LALR parser generator](https://github.com/yui-knk/lrama) [Feature #19637] * If you have interest, please see [The future vision of Ruby Parser](https://rubykaigi.org/2023/presentations/spikeolaf.html) ## YJIT * Significant performance improvements over 3.2 * Splat and rest arguments support has been improved. * Registers are allocated for stack operations of the virtual machine. * More calls with optional arguments are compiled. * `Integer#!=`, `String#!=`, `Kernel#block_given?`, `Kernel#is_a?`, `Kernel#instance_of?`, `Module#===` are specially optimized. * Instance variables no longer exit to the interpreter with megamorphic Object Shapes. * Metadata for compiled code uses a lot less memory. * Improved code generation on ARM64 * Option to start YJIT in paused mode and then later enable it manually * `--yjit-pause` and `RubyVM::YJIT.resume` * This can be used to enable YJIT only once your application is done booting * Exit tracing option now supports sampling * `--trace-exits-sample-rate=N` * Multiple bug fixes ## Other Notable New Features ### Language ## Performance improvements * `defined?(@ivar)` is optimized with Object Shapes. ## Other notable changes since 3.2 ## Compatibility issues Note: Excluding feature bug fixes. ### Removed constants The following deprecated constants are removed. ### Removed methods The following deprecated methods are removed. ## Stdlib compatibility issues ### `ext/readline` is retired * We have `reline` that is pure Ruby implementation compatible with `ext/readline` API. We rely on `reline` in the future. If you need to use `ext/readline`, you can install `ext/readline` via rubygems.org with `gem install readline-ext`. * We no longer need to install libraries like `libreadline` or `libedit`. ## C API updates ### Updated C APIs The following APIs are updated. ### Removed C APIs The following deprecated APIs are removed. ## Standard library updates The following default gems are updated. * RubyGems 3.5.0.dev * bigdecimal 3.1.4 * bundler 2.5.0.dev * csv 3.2.7 * fiddle 1.1.2 * fileutils 1.7.1 * irb 1.6.4 * optparse 0.4.0.pre.1 * psych 5.1.0 * reline 0.3.3 * stringio 3.0.7 * strscan 3.0.7 * syntax_suggest 1.0.4 * time 0.2.2 * timeout 0.3.2 * uri 0.12.1 The following bundled gems are updated. * minitest 5.18.0 * rbs 3.1.0 * typeprof 0.21.7 * debug 1.8.0 See GitHub releases like [Logger](https://github.com/ruby/logger/releases) or changelog for details of the default gems or bundled gems. See [NEWS](https://github.com/ruby/ruby/blob/v3_3_0_preview1/NEWS.md) or [commit logs](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0_preview1) for more details. With those changes, [1922 files changed, 75283 insertions(+), 44896 deletions(-)](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0_preview1… since Ruby 3.2.0! Merry Christmas, Happy Holidays, and enjoy programming with Ruby 3.3! ## Download * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-preview1.tar.gz> SIZE: 20428213 SHA1: 5445eec1cd9ddb44e03e74568cac94209c91b42d SHA256: c3454a911779b8d747ab0ea87041030d002d533edacb2485fe558b7084da25ed SHA512: 0f891f140ddc6372aa7c4459f8784126e0c341db7b80e72c51e441c5153c43c2d7b965f7807c076862ac84b9b8b0c6a66bbf66fc341746016151397bb21c782a * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-preview1.tar.xz> SIZE: 15074600 SHA1: 4c22ebca287c87811e1050bf4d59b7d32255b212 SHA256: ae300b49e06c13087dd163b97eddd38db895dc8e0c9904284119795d75303fbb SHA512: 46c1134dba5810847f7f6b4298900a91f5225679d7873548b271f4ef2ad1dc168722562a2e468a2ccf136314176ee613d8c7792fd4411a3f7a44c80b93b417ee * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-preview1.zip> SIZE: 24846962 SHA1: 31774fa653c54107b6afc30adda3a0350d8f41d2 SHA256: 6ecafecf83f2cacf446b2326012f2b6ee1a0614d8dd29bb1fb3f105c27e2c553 SHA512: 794bef847fefbbdbbdced85975a00c9289ef6464810408af3f0f2055052d6b5ef5576dbd41e0d87bb73f1ad276d8e27c36018610f8e2b9936828c0e692f611f0 ## What is Ruby Ruby was first developed by Matz (Yukihiro Matsumoto) in 1993, and is now developed as Open Source. It runs on multiple platforms and is used all over the world especially for web development.

1 0

[ruby-core:113450] [Ruby master Feature#19637] Use Lrama LALR parser generator instead of Bison
by yui-knk (Kaneko Yuichiro) 12 May '23

12 May '23

Issue #19637 has been reported by yui-knk (Kaneko Yuichiro). ---------------------------------------- Feature #19637: Use Lrama LALR parser generator instead of Bison https://bugs.ruby-lang.org/issues/19637 * Author: yui-knk (Kaneko Yuichiro) * Status: Open * Priority: Normal ---------------------------------------- I want to propose to use Lrama LALR parser generator instead of Bison. https://github.com/yui-knk/lrama is a pure ruby parser generator which accepts Ruby's "parse.y" and generate compatible "parse.c" file. By this change, we never depend on Bison whose version is different for each environment. Future improvement, like Nonterminal attributes and so on, will be discussed other tickets. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111136] [Ruby master Bug#19168] "such file" is bad grammar
by masterleep2 (Bill Lipa) 12 May '23

12 May '23

Issue #19168 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #19168: "such file" is bad grammar https://bugs.ruby-lang.org/issues/19168 * Author: masterleep2 (Bill Lipa) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The error message for a missing required file has bad grammar: $ irb irb(main):001:0> require 'wuxx' <internal:/opt/local/lib/ruby3.1/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- wuxx (LoadError) The "such" should be removed. "cannot load file" reads more normally in English. -- https://bugs.ruby-lang.org/

7 6