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

[ruby-core:112208] [Ruby master Bug#19409] Object's shape is reset after a ractor move
by luke-gru (Luke Gruber) 04 Jan '24

04 Jan '24

Issue #19409 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19409: Object's shape is reset after a ractor move https://bugs.ruby-lang.org/issues/19409 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I believe an object should have the same shape after being moved from 1 ractor to another. ```ruby class Obj attr_accessor :a, :b, :c, :d def initialize @a = 1 @b = 2 @c = 3 end end r = Ractor.new do obj = receive #p RubyVM::Shape.of(obj) obj.d = 4 p obj.a, obj.b, obj.c, obj.d # gets wrong values due to object shape id being reset on object end obj = Obj.new #p RubyVM::Shape.of(obj) r.send(obj, move: true) r.take ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112211] [Ruby master Bug#19411] GC issue with moved objects
by luke-gru (Luke Gruber) 04 Jan '24

04 Jan '24

Issue #19411 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19411: GC issue with moved objects https://bugs.ruby-lang.org/issues/19411 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This crashes: ```ruby class Obj def initialize @obj = 3 end end GC.stress = true r = Ractor.new do obj = receive p obj end obj = Obj.new r.send(obj, move: true) r.take ``` It only crashes with nested objects, if you remove the ivar set in `initialize` it works fine. Maybe missing `RB_GC_GUARD`? -- https://bugs.ruby-lang.org/

1 2

[ruby-core:115671] [Ruby master Feature#20054] Replace the use of `def` in endless method definitions with a new sigil
by sawa (Tsuyoshi Sawada) 04 Jan '24

04 Jan '24

Issue #20054 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #20054: Replace the use of `def` in endless method definitions with a new sigil https://bugs.ruby-lang.org/issues/20054 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- I propose to remove the use of keyword `def` from the syntax of endless method definition, and introduce a new sigil instead of it. There are several possibilities for what character to use as the sigil, but the most seemingly promising one to me at this point is the colon. So, instead of: ```rb def foo = method_body ``` I propose to write ```rb :foo = method_body ``` There a few reasons to dispense with `def` in endless method definition. First, the current syntax for endless method definition looks too similar to conventional method definition. Without endless method definition, we could already define a method in a single line: ```rb def foo; method_body end ``` and compared to this, what the endless method definition does is that, it only saves you from typing the `end` keyword just by replacing the semicolon with an equal sign. This actually had not made much sense to me. Just saving you from typing the keyword `end` looks too small of a change for introducing new syntax. In order for endless method definition syntax to be justified (as a shorthand for conventional method definition), it needs to save more typing. Second, in #19392, some people are claiming to change the precedence involving endless method definition. I agree with Matz and other developers who support the current precedence in which: ```rb def foo = bar and baz ``` is interpreted as: ```rb (def foo = bar) and baz ``` and I understand that the controversy is due to the look and feel of the keyword `def`. `def` has lower precedence than `and` in conventional method definition, although `=` has higher precedence than `and` in variable/constant assignment. Mixing the low-precedence `def` and the high-precedence `=` into a single syntax was the cause of the trouble, according to my opinion. Thence, we should get rid of `def`. Once we do so, we need to distinguish endless method definition from variable/constant assignment in a new way. What came to my mind was to use a single character: a sigil. Especially, using the colon seems to make sense to me for several reasons: Most importantly, assignment to a symbol is impossible, and it currently raises a syntax error, so it would not conflict with variable/constant assignment syntax. Within Ruby syntax, symbol is naturally used to represent a method name. For example, in `foo(&:bar)` constructions, users are used to passing a method name as a symbol. Also, a method definition returns a symbol representing the method name. So, making the endless method definition syntax look superficially like an "assignment to a symbol" would make sense. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:115980] [Ruby master Misc#17815] Snapcraft Ruby plugin
by paddor (Patrik Wenger) 30 Dec '23

30 Dec '23

Issue #17815 has been updated by paddor (Patrik Wenger). This can be closed. I've implemented a Ruby build plugin on v1 and v2. ---------------------------------------- Misc #17815: Snapcraft Ruby plugin https://bugs.ruby-lang.org/issues/17815#change-105943 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal ---------------------------------------- I'm working on a Ruby build plugin for the Snapcraft v2 plugin AP, since the v1 Ruby plugin does not work on the Ubuntu `core20` image. The v2 API only allows to influence the build step, which means there's no nice way for the plugin to set environment variables that apply during runtime. The problem is that the final paths to Ruby's stdlib are unknown during compile time. I've got it to work by renaming the `ruby` executable to `ruby.bare` and creating a wrapper script `ruby` that sets the `$RUBYLIB` and `$GEM_PATH` env variables based on `$SNAP` before `exec`ing `ruby.bare`. I don't like that it requires a wrapper script though, since it would have to awkwardly determine the arch-specific stdlib directory to support any platform. The current wrapper script is this: ```sh #!/bin/sh export RUBYLIB="$SNAP/lib/ruby/snap:$SNAP/lib/ruby/snap/x86_64-linux:$RUBYLIB" export GEM_PATH="$SNAP/lib/ruby/gems/snap:$GEM_PATH" exec `dirname $0`/ruby.bare "$@" ``` What possible solutions are there? I could maybe fix the shebangs of Ruby executables like `gem` and `bundle`, but not `ruby` itself since it's binary. Also, I'm not sure if env variable expansion even works in shebang. Can the configure script's `--with-search-path` be made to support env variable expansion during runtime? That still wouldn't solve the issue about the arch-specific directory. Python apparently determines its load paths relative to the executable being run. Does Ruby support anything like that? Any other ideas? Current state: https://github.com/paddor/snapcraft-ruby-plugin-v2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112010] [Ruby master Bug#19375] File objects are currently shareable
by luke-gru (Luke Gruber) 29 Dec '23

29 Dec '23

Issue #19375 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19375: File objects are currently shareable https://bugs.ruby-lang.org/issues/19375 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I don't know the internals of file.c but I don't think files are thread-safe. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:115919] [Ruby master Feature#20093] Syntax or keyword to reopen existing classs/modules, never to define new classs/modules
by tagomoris (Satoshi Tagomori) 29 Dec '23

29 Dec '23

Issue #20093 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #20093: Syntax or keyword to reopen existing classs/modules, never to define new classs/modules https://bugs.ruby-lang.org/issues/20093 * Author: tagomoris (Satoshi Tagomori) * Status: Open * Priority: Normal ---------------------------------------- `class A` and `module B` will reopen existing class A or module B to add/re-define methods if A/B exists. Otherwise, these will define the new class/module A/B. But, in my opinion, the code of `class A` for patching existing classes doesn't work expectedly when `A` is not defined beforehand. It expects other codes to define `A` before being called. For example: ```ruby # string_exclude.rb class String def exclude?(string) !include?(string) end end ``` This code expects that there is the `String` class, and it has the `include?` method. This code doesn't work if the file is loaded in the way below: ```ruby load('string_exclude.rb', true) ``` This code doesn't raise errors and will define an almost empty class (only with a method `exclude?` to raise NameError). It should be unexpected for every user. So, I want to propose a new syntax to reopen the existing class/module or raise errors if the specified class/module is not defined. ```ruby class extension String def exclude?(string) !include?(string) end end # adds #exclude? to String class class extension Stroooong def exclude?(string) !include?(string) end end # will raise NameError (or something else) ``` Some additional things: * `class extension String` (and `module extension String`) causes a compile error (SyntaxError) on Ruby 3.3. So we have space to add a keyword between class/module and the class/module name. * I don't have a strong opinion about the keyword name `extension`. An alternative idea is `reopen`. -- https://bugs.ruby-lang.org/

8 10

[ruby-core:115909] [Ruby master Bug#20087] Uninitialized instance variable warning - obsolete documentation
by semaperepelitsa (Simon Perepelitsa) 28 Dec '23

28 Dec '23

Issue #20087 has been reported by semaperepelitsa (Simon Perepelitsa). ---------------------------------------- Bug #20087: Uninitialized instance variable warning - obsolete documentation https://bugs.ruby-lang.org/issues/20087 * Author: semaperepelitsa (Simon Perepelitsa) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This warning got removed from Ruby 3.0: https://bugs.ruby-lang.org/issues/17055 But the documentation (ruby/doc/syntax/assignment.rdoc@master) still says: > An uninitialized instance variable has a value of +nil+. If you run Ruby with > warnings enabled, you will get a warning when accessing an uninitialized > instance variable. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115969] [Ruby master Feature#13821] Allow fibers to be resumed across threads
by ioquatix (Samuel Williams) 28 Dec '23

28 Dec '23

Issue #13821 has been updated by ioquatix (Samuel Williams). > This proposal breaks Fiber semantics so fundamentally I don't disagree with you, and I don't have a strong opinion one way or another, but there is nothing about coroutine semantics which prevents them from being passed between threads which is what the MN implementation is already doing (it uses the same coroutines). So, I'd like to experiment with it. Alternatively, maybe we can re-implement `Enumerator` with `Thread+Queue` which is more flexible, at least that deals with one of the problems that is often brought up in these discussions. ---------------------------------------- Feature #13821: Allow fibers to be resumed across threads https://bugs.ruby-lang.org/issues/13821#change-105928 * Author: cremes (Chuck Remes) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Given a Fiber created in ThreadA, Ruby 2.4.1 (and earlier releases) raise a FiberError if the fiber is resumed in ThreadB or any other thread other than the one that created the original Fiber. Sample code attached to demonstrate problem. If Fibers are truly encapsulating all of the data for the continuation, we should be allowed to move them between Threads and resume their operation. Why? One use-case is to support the async-await asynchronous programming model. In that model, a method marked async runs *synchronously* until the #await method is encountered. At that point the method is suspended and control is returned to the caller. When the #await method completes (asynchronously) then it may resume the suspended method and continue. The only way to capture this program state, suspend and resume, is via a Fiber. example: ``` class Wait include AsyncAwait def dofirst async do puts 'Synchronously print dofirst.' result = await { dosecond } puts 'dosecond is complete' result end end def dosecond async do puts 'Synchronously print dosecond from async task.' slept = await { sleep 3 } puts 'Sleep complete' slept end end def run task = dofirst puts 'Received task' p AsyncAwait::Task.await(task) end end Wait.new.run ``` ``` # Expected output: # Synchronous print dofirst. # Received task # Synchronously print dosecond from async task. # Sleep complete # dosecond is complete # 3 ``` Right now the best way to accomplish suspension of the #dofirst and #dosecond commands and allow them to run asynchronously is by passing those blocks to *another thread* (other than the callers thread) so they can be encapsulated in a new Fiber and then yielded. When it's time to resume after #await completes, that other thread must lookup the fiber and resume it. This is lots of extra code and logic to make sure that fibers are only resumed on the threads that created them. Allowing Fibers to migrate between threads would eliminate this problem. ---Files-------------------------------- fiber_across_threads.rb (377 Bytes) wait.rb (728 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115931] [Ruby master Bug#20097] Regexp#match? with empty capture group repeat is inconsistent
by tompng (tomoya ishida) 28 Dec '23

28 Dec '23

Issue #20097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20097: Regexp#match? with empty capture group repeat is inconsistent https://bugs.ruby-lang.org/issues/20097 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) +MN [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It sometimes matches and sometimes does not, depend on repeat quantifier number. ~~~ruby # empty capture group repeat p /(a(){1,4}){2}/.match?('aa') #=> true p /(a(){1,5}){2}/.match?('aa') #=> false # repeat of capture group that match to empty string p /(a(|){1,2}){2}/.match?('aa') #=> true p /(a(|){1,3}){2}/.match?('aa') #=> false p /(a(x?y?|z){1,2}){2}/.match?('aa') #=> false ~~~ non-capturing group seems ok. ~~~ruby p /(a(?:){1,4}){2}/.match?('aa') #=> true p /(a(?:){1,5}){2}/.match?('aa') #=> true p /(a(?:|){1,2}){2}/.match?('aa') #=> true p /(a(?:|){1,3}){2}/.match?('aa') #=> true p /(a(?:x?y?|z){1,2}){2}/.match?('aa') #=> true ~~~ Same behavior in ruby 3.0, 3.1, 3.2 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115965] [Ruby master Bug#20103] rb_internal_thread_remove_event_hook() hangs when called from within a Thread hook
by osyoyu (Daisuke Aritomo) 28 Dec '23

28 Dec '23

Issue #20103 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #20103: rb_internal_thread_remove_event_hook() hangs when called from within a Thread hook https://bugs.ruby-lang.org/issues/20103 * Author: osyoyu (Daisuke Aritomo) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2023-12-28T14:53:15Z master e81a5453e3) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ## Problem The Ruby process hangs when `rb_internal_thread_remove_event_hook()` is called from within a Thread hook registered by `rb_internal_thread_add_event_hook()`. The thread is waiting for the thread event execution lock (`pthread_rwlock_wrlock(&rb_internal_thread_event_hooks_rw_lock))`), which is acquired by its caller, `rb_thread_execute_hooks()`. https://github.com/ruby/ruby/blob/e81a5453e3c76c4348da042d86debde7689254fe/… This situation would occur when one wants to register a *oneshot* hook that performs something on a Thread for only a single time. The hook would remove itself after its main procedure. In my case, I'm doing a timer_create(3) on each pthread for profiling purposes. ## Expected behavior The process won't hang, or at least print some kind of warning. I think there some options here: 1. Discourage this kind of definition. Thread hooks should not add/remove other Thread hooks, or otherwise do so through other async methods, such as postponed jobs. 2. Find a way to make this work. Maybe inner calls to add/remove_event_hook() can share locks with the outer call, but I'm not sure if that's possible as I'm not familiar with pthread_rwlocks. ## Repro ```c #include "ruby.h" #include "ruby/thread.h" rb_internal_thread_event_hook_t *hook; void event_hook_callback(rb_event_flag_t flag, const rb_internal_thread_event_data_t *data, void *custom_data) { rb_internal_thread_remove_event_hook(hook); // hangs } RUBY_FUNC_EXPORTED void Init_mycext(void) { hook = rb_internal_thread_add_event_hook( event_hook_callback, RUBY_INTERNAL_THREAD_EVENT_RESUMED, NULL ); } ``` ``` ruby -rmycext -e 'Thread.new { loop { 1 + 1 } }' ``` -- https://bugs.ruby-lang.org/

1 0