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

[ruby-core:115045] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by Quintasan 13 Oct '23

13 Oct '23

Issue #18915 has been updated by Quintasan (Michał Zając). tenderlovemaking (Aaron Patterson) wrote in #note-8: > I'm guilty of using `NotImplementedError` for abstract classes. I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class. Hence my proposal to introduce a new class. I didn't want to create a PR for either solution because I would welcome both of them. I'm slightly leaning towards a new exception class for this. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104919 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115043] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by tenderlovemaking (Aaron Patterson) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson). I'm guilty of using `NotImplementedError` for abstract classes. I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104917 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114782] [Ruby master Bug#19885] Invalid Warning for Default Gems That Will Move to Bundled Gems
by jeremyevans0 (Jeremy Evans) 13 Oct '23

13 Oct '23

Issue #19885 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19885: Invalid Warning for Default Gems That Will Move to Bundled Gems https://bugs.ruby-lang.org/issues/19885 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED ---------------------------------------- Starting in ruby 3.3.0-preview2, attempting to require bigdecimal, mutex_m, base64, or other libraries that will move to bundled gems in Ruby 3.4.0 results in a warning, even when bundler is not in use: ``` $ ruby33 -v -r bigdecimal -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` I think such warnings are bugs if bundler is not in use. When a library is moved from a default gem to a bundled gem, such code will work fine if not using bundler. It is only when using bundler where such code would have problems, and therefore, if Ruby warns at all, it should only warn when bundler is in use. The only time such a warning would make sense if bundler is not in use is if the library was not going to be a bundled gem. In that case, first the library should be moved from a default gem to a bundled gem, then the bundled gem that ships with Ruby should provide the warning, which you can avoid by installing an updated gem version. Note that you also get the warning when loading a gem that has bigdecimal as a runtime dependency (this example uses Sequel 5.72.0, which has a runtime dependency on bigdecimal as you can see at https://rubygems.org/gems/sequel/versions/5.72.0) ``` $ ruby33 -v -r sequel -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] /usr/local/lib/ruby/gems/3.3/gems/sequel-5.72.0/lib/sequel/core.rb:3: warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` This warning makes even less sense, because even if bigdecimal was removed as both a default gem and a bundled gem, installing Sequel 5.72.0 would install bigdecimal as a dependency. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115020] [Ruby master Bug#19923] Ractor / YJIT failures on PPC64LE
by vo.x (Vit Ondruch) 13 Oct '23

13 Oct '23

Issue #19923 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19923: Ractor / YJIT failures on PPC64LE https://bugs.ruby-lang.org/issues/19923 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master e029375a7d) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Let me share snippet of the log: ~~~ ... snip ... + DISABLE_TESTS= + MSPECOPTS= + DISABLE_TESTS=' -n !/TestYJIT#test_bug_19316/' + make -C redhat-linux-build check 'TESTS=-v --show-skip -n !/TestYJIT#test_bug_19316/' 'MSPECOPT=-fs ' make: Entering directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' BASERUBY = echo executable host ruby is required. use --with-baseruby option.; false CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -fPIC -m64 XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/powerpc64le-linux -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/include -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/prism -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/enc/unicode/15.0.0 CPPFLAGS = DLDFLAGS = -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-soname,libruby.so.3.3 -fstack-protector-strong -m64 SOLIBS = -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lpthread LANG = C.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = no 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=/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build/yjit/target/release/' /builddir/build/BUILD/ruby-3.3.0-e029375a7d/yjit/src/lib.rs gcc (GCC) 13.2.1 20230918 (Red Hat 13.2.1-3) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. generating enc.mk making srcs under enc make[1]: Entering directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' ... snip ... make[1]: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' 2023-10-12 15:27:51 +0000 Driver is ruby 3.3.0dev (2023-10-12 master e029375a7d) [powerpc64le-linux] Target is ruby 3.3.0dev (2023-10-12 master e029375a7d) [powerpc64le-linux] test_attr.rb ... test_autoload.rb ........ test_block.rb .................................................... ...... test_class.rb ................................................ test_constant_cache.rb .......... test_env.rb .. test_eval.rb ........................................ test_exception.rb .................................. test_fiber.rb ..... test_finalizer.rb . test_flip.rb . test_flow.rb .................................................... .......... test_fork.rb .... test_gc.rb .. test_insns.rb .................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ................... test_io.rb .................. test_jump.rb ............................. test_literal.rb .................................................... ............................................................................... ......................... test_literal_suffix.rb ................................................ test_load.rb .. test_marshal.rb . test_massign.rb .................................. test_method.rb .................................................... ............................................................................... ............................................................................... ............. test_objectspace.rb ...... test_proc.rb ..................................... test_ractor.rb .Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_7_1222.rb:2:in `<main>' .Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_30_1224.rb:2:in `<main>' Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_37_1225.rb:2:in `<main>' ... snip ... <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_yjit_rust_port.rb_391_1855.rb:3:in `<main>' Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_yjit_rust_port.rb_401_1856.rb:2:in `<main>' .. Finished in 57.56 sec Fiber count: 10000 (skipping) #1222 test_ractor.rb:7: Ractor.new{}.class #=> "" (expected "Ractor") #1224 test_ractor.rb:30: r = Ractor.new name: 'test-name' do end r.name #=> "" (expected "test-name") ... snip ... #1856 test_yjit_rust_port.rb:401: r = Ractor.new do msg = Ractor.receive end r.send 'ok' r.take #=> "" (expected "ok") FAIL 95/1857 tests failed make: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' make: *** [uncommon.mk:886: yes-btest-ruby] Error 1 ~~~ The full log is in attachment. ---Files-------------------------------- build.log (1.01 MB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114943] [Ruby master Bug#19910] Set#delete_if behavior inconsistent with Array/Hash
by segiddins (Samuel Giddins) 13 Oct '23

13 Oct '23

Issue #19910 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19910: Set#delete_if behavior inconsistent with Array/Hash https://bugs.ruby-lang.org/issues/19910 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Given the following script: ```ruby #!/usr/bin/env ruby require 'set' def enum(collection) i = 0 collection.delete_if do i += 1 raise ArgumentError if i == 6 i.odd? end rescue ArgumentError return collection end pp enum([0, 1, 2, 3, 4, 5, 6, 7]) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_h { [_1, _1] }) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_set) ``` It results in: ``` [1, 3, 5, 6, 7] {1=>1, 3=>3, 5=>5, 6=>6, 7=>7} #<Set: {0, 1, 2, 3, 4, 5, 6, 7}> ``` As you can see, when an exception is raise inside `delete_if` on Hash/Array, the already-considered elements are still removed from the array. For `Set`, no elements are deleted (due to the implementation that builds up an intermediary list of elements to delete, then removes them from the underlying hash afterwards). It would be very helpful if `Set#delete_if` behaved consistently with other core collection types -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114399] [Ruby master Feature#19839] Need a method to check if two ranges overlap
by shouichi (Shouichi KAMIYA) 13 Oct '23

13 Oct '23

Issue #19839 has been reported by shouichi (Shouichi KAMIYA). ---------------------------------------- Feature #19839: Need a method to check if two ranges overlap https://bugs.ruby-lang.org/issues/19839 * Author: shouichi (Shouichi KAMIYA) * Status: Open * Priority: Normal ---------------------------------------- It would be convenient to have a method that checks if two ranges overlap. For example, ``` (0..10).overlap?(5..15) #=> true (0..10).overlap?(20..30) #=> false ``` -- https://bugs.ruby-lang.org/

12 26

[ruby-core:115031] [Ruby master Misc#18984] Doc for Range#size for Float/Rational does not make sense
by mame (Yusuke Endoh) 13 Oct '23

13 Oct '23

Issue #18984 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. @matz said that he wanted to try to fix the behavior of Range#size instead of changing the document. If the incompatibilty is found significant, it will be reconsidered. ```ruby (0.51..5.quo(2)).size #=> TypeError (..0).size #=> TypeError ``` ---------------------------------------- Misc #18984: Doc for Range#size for Float/Rational does not make sense https://bugs.ruby-lang.org/issues/18984#change-104902 * Author: masasakano (Masa Sakano) * Status: Open * Priority: Normal ---------------------------------------- When `Range` consists of any Numeric, according to [Official docs for Ruby-3.1.2](https://ruby-doc.org/core-3.1.2/Range.html#method-i-size), `Range#size` should, > Returns the count of elements in self if both begin and end values are numeric; Indeed, when `Range` consists of only `Integer`, this makes sense. However, when the begin value of `Range` is a `Float` or `Rational`, "*the count of elements*" does not make sense. Such Ranges are not iteratable, suggesting there are no such things as "elements": ```ruby (0.51..5.quo(2)).each{} # => TypeError ``` Yet, `Range#size` of such Ranges returns an Integer ```ruby (0.51..5.quo(2)).size # => 2 ``` It seems both begin and end values of a Range are rounded (`Numeric#round`) to the nearest Integer before `Range#size` is calculated. If this is the specification, I suggest it should be clearly stated in the [Official docs](https://ruby-doc.org/core-3.1.2/Range.html#method-i-size), avoiding the confusing expression "the count of elements", because "elements" are not unambiguously defined for Range of Float/Rational. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115030] [Ruby master Bug#18903] Stack overflow signal handling seems to be triggered once and then not working after
by mame (Yusuke Endoh) 13 Oct '23

13 Oct '23

Issue #18903 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. @nobu said he would investigate if he could fix it with M2. Recovering from a stack overflow in C is not portable and complete, but it is a fact that they work almost well in Linux, which is the main production environment. If we make it a fatal error that cannot be rescued normally, it might impact on users of Rails apps, job queues like Sidekiq, etc. ---------------------------------------- Bug #18903: Stack overflow signal handling seems to be triggered once and then not working after https://bugs.ruby-lang.org/issues/18903#change-104901 * Author: chrisseaton (Chris Seaton) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- This program creates a recursive object graph and then tries to convert it to JSON with no max depth, so it stack overflows in C code that does no co-operative stack overflow checks, as the bytecode interpreter would. This therefore triggers a segmentation fault and the stack overflow detection there. It works the first time, but the second time around it doesn't and the program hard crashes on M1. Is there something like a guard page permission that is switched during the handling, and needs to switched back for the guard page to work again? Note that it isn't JSON specific - I think any stack overflow within C code would do it. ```ruby require 'json' a = [] a << a begin JSON.dump(a) rescue Exception puts 'rescued' end JSON.dump(a) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114661] [Ruby master Bug#19866] Future of `readline.rb`
by vo.x (Vit Ondruch) 13 Oct '23

13 Oct '23

Issue #19866 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19866: Future of `readline.rb` https://bugs.ruby-lang.org/issues/19866 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-05 master 7c8932365f) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I wonder what is the future of readline.rb? It still tries to load `readline.so` by default. Is this intended behavior? I'd say that instead, it should rather fire a deprecation warning and load reline. Or maybe the whole readline gem should be completely removed? -- https://bugs.ruby-lang.org/

5 5

[ruby-core:115012] [Ruby master Feature#13933] Add Range#empty?
by matz (Yukihiro Matsumoto) 12 Oct '23

12 Oct '23

Issue #13933 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected One drawback of `Range#empty?` is that we have several corner cases that cannot determine emptiness correctly (e.g., regarding exclude_end ranges or infinity). Upon the fact we don't see the real-world use-case yet, we reject the proposal for the moment. FYI, `Range#overlap?` has similar corner cases, it's better to document clearly somewhere. Matz. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104882 * Author: ted (Ted Johansson) * Status: Rejected * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0