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

[ruby-core:115669] [Ruby master Feature#20053] M:N Threads, now w/ macOS support (kqueue)
by jpcamara (JP Camara) 20 Dec '23

20 Dec '23

Issue #20053 has been reported by jpcamara (JP Camara). ---------------------------------------- Feature #20053: M:N Threads, now w/ macOS support (kqueue) https://bugs.ruby-lang.org/issues/20053 * Author: jpcamara (JP Camara) * Status: Open * Priority: Normal ---------------------------------------- I have a PR here that adds support for macOS to M:N threads using `kqueue`: https://github.com/ruby/ruby/pull/9178 It adds in `kqueue`/`kevent` calls when present in the OS. Technically this would open up support for FreeBSD as well, but I don't have a way of testing that so i'm not sure how well it does or doesn't work there. I wanted to get support going for macOS so more devs can try out M:N threads and test it. I do think there should be a larger discussion around the potential relationship between this and some of the awesome fiber scheduler work over the last few years (and the potential of utilizing anything from io-event?). But that can be a topic for another day - let's get macOS support in the meantime! Disclaimer: C isn't my day-to-day language, so I could definitely use feedback there. I'm also more of a kernel event queue (kqueue, epoll, io_uring) _enthusiast_, but `kqueue` isn't something I have specific experience writing with - just lots of reading code and small toy code up until this point. So someone like @ioquatix would probably be a good person to get eyes on it. -- https://bugs.ruby-lang.org/

3 4

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

20 Dec '23

Issue #18915 has been updated by Quintasan (Michał Zając). matz (Yukihiro Matsumoto) wrote in #note-14: > #note-13 explains my opinion well. What name candidate do you have? > > Matz. How about `AbstractMethodError` - the same as Java? ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105763 * 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:115813] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by naruse (Yui NARUSE) 20 Dec '23

20 Dec '23

Issue #18576 has been updated by naruse (Yui NARUSE). I strongly object that we change Encoding#name of ASCII-8BIT encoding into "BINARY" because of compatibility. I don't want people to fix the code which are correctly running now. However supporting people who newly writing a code is reasonable. I agree to add more information in Encoding#inspect and error message. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-105762 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115764] [Ruby master Feature#20069] Buffer class in stdlib
by pynix (Pynix wang) 20 Dec '23

20 Dec '23

Issue #20069 has been reported by pynix (Pynix wang). ---------------------------------------- Feature #20069: Buffer class in stdlib https://bugs.ruby-lang.org/issues/20069 * Author: pynix (Pynix wang) * Status: Open * Priority: Normal ---------------------------------------- ruby use `String` to deal with bytes, this cause error on irb "invalid byte sequence in utf-8" can we get a builtin class like Buffer or Bytes that represent as hex string -- https://bugs.ruby-lang.org/

7 8

[ruby-core:115731] [Ruby master Bug#20063] Inconsistent behavior with required vs optional parameters
by jemmai (Jemma Issroff) 20 Dec '23

20 Dec '23

Issue #20063 has been reported by jemmai (Jemma Issroff). ---------------------------------------- Bug #20063: Inconsistent behavior with required vs optional parameters https://bugs.ruby-lang.org/issues/20063 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Using repeated anonymous parameters, gives different behavior with the parameters in the same order based on whether they are required or optional. ``` def example_with_optional(_a = 1, _a = 2) _a end def example_with_required(_a, _a) _a end p example_with_optional # 2 p example_with_required(1, 2) # 1 ``` It is unexpected that these two methods would return differently given the parameters are in the same order, based on whether they are optional or required. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:115804] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by matz (Yukihiro Matsumoto) 20 Dec '23

20 Dec '23

Issue #18915 has been updated by matz (Yukihiro Matsumoto). #note-13 explains my opinion well. What name candidate do you have? Matz. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105753 * 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:115779] [Ruby master Bug#20072] free(): invalid pointer when compiled with --enable-shared --with-jemalloc
by misdoro (Mikhail Doronin) 20 Dec '23

20 Dec '23

Issue #20072 has been reported by misdoro (Mikhail Doronin). ---------------------------------------- Bug #20072: free(): invalid pointer when compiled with --enable-shared --with-jemalloc https://bugs.ruby-lang.org/issues/20072 * Author: misdoro (Mikhail Doronin) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-08-17T01:57:09Z test 5bb9462285) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When ruby is built with `--enable-shared --with-jemalloc` on Linux (current Gentoo, ubuntu22 in docker), running a rails app yields: ``` free(): invalid pointer Aborted ``` The issue started appearing after 5bb946228550c7f171c27725860b153a675404f3 https://github.com/ruby/ruby/commit/5bb946228550c7f171c27725860b153a675404f3 Related to https://bugs.ruby-lang.org/issues/18409 (workaround to LD_PRELOAD jemalloc from that issue works) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:115800] [Ruby master Feature#13383] [PATCH] Module#source_location
by matz (Yukihiro Matsumoto) 20 Dec '23

20 Dec '23

Issue #13383 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected I don't think “natural” is not a good reason for adding a new method, especially regarding open class/module definitions. I am not against if the feature is proposed for the debugger. Matz. ---------------------------------------- Feature #13383: [PATCH] Module#source_location https://bugs.ruby-lang.org/issues/13383#change-105746 * Author: koba789 (Hidekazu Kobayashi) * Status: Rejected * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- # Abstract It can inspect where the module or class is defined. # Background In debugging or development an application, I usually want to find out where the class definition of using library. There is Method#source_location but I could not find **Class** easily. # Implementation In Github: https://github.com/ruby/ruby/pull/1562 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113572] [Ruby master Bug#19683] ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby
by jeremyevans0 (Jeremy Evans) 19 Dec '23

19 Dec '23

Issue #19683 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19683: ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby https://bugs.ruby-lang.org/issues/19683 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [x86_64-openbsd7.3] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ruby-3.3.0-preview1 does not build with BSD make without `--with-baseruby`. However, it builds fine with GNU make and when using BSD make with `--with-baseruby`. Previous Ruby tarball releases have built fine with BSD make without `--with-baseruby`, so this issue has been introduced recently. When building with BSD make without `--with-baseruby`, building fails after generating RI format with: ``` /bin/sh: false: not found *** Error 127 in . (exts.mk:94 'ruby': @make UPDATE_LIBRARIES=no EXTENCS=dmyenc.o BASERUBY=echo\ executable\ host\ ruby\ is\ required.\ \ ...) *** Error 2 in /home/jeremy/local/ruby-3.3.0-preview1 (Makefile:948 'build-ext': @make -f exts.mk libdir="/usr/local/lib" LIBRUBY_EXTS=./...) ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115412] [Ruby master Bug#20008] f(**kw, &block) calls block.to_proc before kw.to_hash
by jeremyevans0 (Jeremy Evans) 19 Dec '23

19 Dec '23

Issue #20008 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20008: f(**kw, &block) calls block.to_proc before kw.to_hash https://bugs.ruby-lang.org/issues/20008 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-12 master 60e19a0b5f) [x86_64-openbsd] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The evaluation order expectation is that `kw.to_hash` is called first in this case. Ruby previously called `kw.to_hash` before `block.to_proc` in Ruby 2, but stopped doing so in Ruby 3.0. In master, `f(*a, **kw, &block)` is also affected. However, that is not true in Ruby 3.2 and earlier (though Ruby 2.0 and 2.1 called `kw.to_hash` before `a.to_a`). The reason for the current behavior is that `vm_caller_setup_arg_block` calls `block.to_proc` before `vm_sendish` is called. `kw.to_hash` is not called until `CALLER_SETUP_ARG` or `setup_parameters_complex`. I have a pull request that fixes this (https://github.com/ruby/ruby/pull/8877) by adding a `splatkw` VM instruction and calling it directly before any send instructions that have both `VM_CALL_ARGS_BLOCKARG` and `VM_CALL_KW_SPLAT` and not `VM_CALL_KW_SPLAT_MUT`. The `splatkw` instruction calls `kw.to_hash` if `kw` is not already a Hash. The `splatkw` instruction is not needed for mutable keyword splats, as `kw.to_hash` would have already been called by earlier instructions in that case. It is possible to fix this without a new VM instruction, by adding the logic to `vm_caller_setup_arg_block` or `rb_vm_send`. However, then an additional check is needed in every method call, instead of only before method calls that actually need it. I would guess that approach would be slower, though as I have not benchmarked that approach, it is not an educated guess. Currently, the `splatkw` instruction is inserted using the peephole optimizer. I'm not sure if using the optimizer to fix bugs is acceptable. If not, it could probably be moved to the compiler proper. I do not believe we should backport this fix, as I consider a new VM instruction invasive, and the benefit of backporting seems small. Example code: ```ruby o = Object.new o.define_singleton_method(:to_hash) {p :called_to_hash; {}} o.define_singleton_method(:to_proc) {p :called_to_proc; lambda{}} puts "p(**o, &o)" p(**o, &o) ``` Actual Output: ``` p(**o, &o) :called_to_proc :called_to_hash ``` Expected Output: ``` p(**o, &o) :called_to_hash :called_to_proc ``` -- https://bugs.ruby-lang.org/

1 2