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

[ruby-core:112277] [Ruby master Feature#17753] Add Module#namespace
by fxn (Xavier Noria) 08 Feb '23

08 Feb '23

Issue #17753 has been updated by fxn (Xavier Noria). Yeah, I believe the feature makes sense and can be useful, and the proposed implementation that keeps a pointer is well-defined (vs what AS does). Also consistent with `Module#name`, as you said. My observations above were more related to the name `namespace` I think, because we are defining "the class or module object that holded the constant to which I was initially assigned, if any". That is weaker. Regarding your proposal, in English would be `parent_module` right? Let me add something, this is practical, but the Ruby model suffers just a little bit in my view. Let me explain. To me: ```ruby module M X = String.new end module N X = Module.new end ``` are essentially the same, Ruby objects stored in places. As we all know, the Ruby model is quite unconstrained, which makes it beautiful, but also weaker in a logical sense. So, there is a part of me that believes for consistency the string object should also respond to `parent_module`, which is a weird derivation. (I am playing reductio at absurdum here, no proposing that!). However, maybe in this case practicality can win over a pure and spherical language model, I don't know :). ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101709 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal ---------------------------------------- Given code like this: ```ruby module A module B class C; end class D; end end end ``` We can get from `C` to `B` like `C.outer_scope`, or to `A` like `C.outer_scope.outer_scope`. I want to use this in cases where I don't know the outer scope, but I want to find constants that are "siblings" of a constant. For example, I can do `A::B::C.outer_scope.constants` to find the list of "sibling" constants to `C`. I want to use this feature when walking objects and introspecting. For example: ```ruby ObjectSpace.each_object(Class) do |k| p siblings: k.outer_scope.constants end ``` I've attached a patch that implements this feature, and there is a pull request on GitHub [here](https://github.com/ruby/ruby/pull/4326). ---Files-------------------------------- 0001-Add-Module-outer_scope.patch (5.93 KB) 0001-Add-Module-namespace.patch (5.89 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112276] [Ruby master Bug#18169] Local copies of gemified libraries are being released out of sync with their gems
by hsbt (Hiroshi SHIBATA) 08 Feb '23

08 Feb '23

Issue #18169 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed In Ruby 3.2, I completely sync default gems and ruby release code. But Ruby 3.1 and 3.0 are still work in progress. I'll working to fix out-of-sync statuses with @headius on each repository. ---------------------------------------- Bug #18169: Local copies of gemified libraries are being released out of sync with their gems https://bugs.ruby-lang.org/issues/18169#change-101706 * Author: headius (Charles Nutter) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The CRuby codebase includes a number of libraries that have been gemified, more and more with each release. Unfortunately, these libraries are continually out of sync with both their home repositories and their released gems. The problem lies in the fact that CRuby keeps a local copy of these libraries within the CRuby git repository, and allows committers to make changes either in the CRuby repository or in the gem's home repository. This has led to many releases of Ruby shipping code that **does not correspond to any released version of the related gem**. I have filed several issues about this but the root cause has not been addressed: * https://github.com/ruby/ostruct/issues/11 * https://github.com/ruby/matrix/issues/12 * https://github.com/ruby/prime/issues/11 * https://github.com/ruby/webrick/issues/48 * https://github.com/ruby/rdoc/issues/835 * https://github.com/ruby/rexml/issues/79 * https://github.com/ruby/fileutils/issues/59 * https://github.com/ruby/ostruct/issues/31 If these gems are to live on their own as standalone libraries/gems then one of two things must happen: * All changes to them must go into their repositories. This would be the cleanest option. CRuby would, like JRuby, source these libraries directly from released gems, and no copies of their sources would be versioned in the CRuby git repository. OR * CRuby-local changes to these libraries must be prohibited from being released unless there is a corresponding gem release. This would require automated or manual auditing at release time, to ensure that the claimed gem version actually corresponds to the sources being shipped. In addition to making it impossible for external users of these gems to match CRuby releases, there are more serious implications: * These hybrid intra-version changes to these libraries cannot be audited to a specific gem release. This could affect stability and security when users attempt to sync their local gem sets to the ones that shipped in a given version of Ruby. * Security fixes have gone out in CRuby releases but no corresponding x.x.y or x.x.x.y security release of the gem was released. This prevents users from fixing the security issue locally without either upgrading CRuby or also including new functionality changes (which may or may not work on the current version of Ruby). See the rexml issue above for one example of the security problem. Until the gem was released, it was not possible to install any gem version with the security fix without upgrading functionality elsewhere in rexml. I believe it is time for CRuby to stop making changes to gemified libraries directly in the CRuby repository. These libraries have their own gems, repositories, and issue trackers, and that is where they should be maintained. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112273] [Ruby master Feature#17753] Add Module#namespace
by shioyama (Chris Salzberg) 08 Feb '23

08 Feb '23

Issue #17753 has been updated by shioyama (Chris Salzberg). This has been quiet for a while, but despite the reservations expressed I'd really like to see it implemented. I don't personally really like `namespace` as a name either, because of its usage in other places. It's been mentioned, but what exactly is wrong with `module_parents`, the same method ActiveSupport uses? @fxn > Yes, c.name is "X::C", but as I said above, that is just a string. It's a string, yes, but it also includes some rules about _what_ to return _when_ that I think are relevant to your concerns about edge cases. I think any implementation of this method should be fully consistent with `Module#name`. That means also encompassing names that are temporary (where the root is anonymous). Just so we're all on the same page: ```ruby mod = Module.new mod.name #=> nil mod::Foo = Module.new mod::Foo.name #=> "#<Module:0x0000000106471d80>::Foo" ``` `"#<Module:0x0000000106471d80>::Foo"` is `mod::Foo`'s "temporary name". We can assign another module under an anonymous root to it and it will not change: ```ruby other_mod = Module.new other_mod::Bar = mod::Foo other_mod::Bar #=> "#<Module:0x0000000106471d80>::Foo" ``` So temporary names are "sticky" as long as the module doesn't have a permanent name. Once it has a permanent name, that name does not change regardless of assignment to other toplevel-rooted constants. So we have some rules for how `Module#name` can and cannot change: 1. A module's permanent name, once assigned, cannot be re-assigned. So although you can nest the same constant in many places in many ways, the `name`, once attached to a permanent root, will not change. 2. A module's temporary name, once assigned, cannot be re-assigned except to a permanent name. So you can assign another name from an anonymous namespace, the module's original temporary name sticks and only changes when/if it gets a permanent name. I think these rules give us everything we need to define a method that returns the set of module objects in `name` as an array, and I think this would be a very useful method to have. Extended to anonymous roots, I would expect this (I'm using `namespace` here because that's the current name we're talking about, I don't love it but just to avoid confusion): ```ruby mod = Module.new mod::Foo = Module.new mod::Foo.name #=> "#<Module:0x0000000106471d80>::Foo" mod::Foo.namespace #=> [<Module:0x0000000106471d80>::Foo, <Module:0x0000000106471d80>] other_mod = Module.new other_mod::Bar = mod::Foo other_mod::Bar.namespace #=> [<Module:0x0000000106471d80>::Foo, <Module:0x0000000106471d80>] Bar = mod mod::Foo.namespace #=> [Bar::Foo, Foo] Baz = mod Baz::Foo.namespace #=> [Bar::Foo, Foo] ``` This is entirely consistent with how `name` works, and I think is in fact a very natural complement to it. Since conventions are exactly the same, there is no need for any additional "rules" to cover the edge cases above. As an implementation, this is fully determined, consistent with an existing pattern (`Module#name`) and works as expected for most common use cases. @mame > the use case is not clear to him It's been mentioned above, but [ActiveSupport](https://github.com/rails/rails/blob/dcd8f37bc63d46f28aa55e68… and other libraries use `mod.name.split("::")` all over the place to go from something they can _see_ (`Module#name`) to something they can _use_ (actual module objects). This has always seemed extremely clumsy to me; Ruby generated the `name` from the module objects, but it will only give you the "trace" of them, not the actual living things. Personally, I've been recently working with anonymous-rooted namespaces (like `mod` and `mod::Foo` above) and the inability to get the root of a module is yet more problematic, because `name.split("::")` and `constantize` don't work in that context. I'd love to see this happen, under any name that seems appropriate. ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101703 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal ---------------------------------------- Given code like this: ```ruby module A module B class C; end class D; end end end ``` We can get from `C` to `B` like `C.outer_scope`, or to `A` like `C.outer_scope.outer_scope`. I want to use this in cases where I don't know the outer scope, but I want to find constants that are "siblings" of a constant. For example, I can do `A::B::C.outer_scope.constants` to find the list of "sibling" constants to `C`. I want to use this feature when walking objects and introspecting. For example: ```ruby ObjectSpace.each_object(Class) do |k| p siblings: k.outer_scope.constants end ``` I've attached a patch that implements this feature, and there is a pull request on GitHub [here](https://github.com/ruby/ruby/pull/4326). ---Files-------------------------------- 0001-Add-Module-outer_scope.patch (5.93 KB) 0001-Add-Module-namespace.patch (5.89 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112173] [Ruby master Bug#19399] Ripper::Lexer.parse throws NoMethodError error for some input
by tompng (tomoya ishida) 07 Feb '23

07 Feb '23

Issue #19399 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19399: Ripper::Lexer.parse throws NoMethodError error for some input https://bugs.ruby-lang.org/issues/19399 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ripper::Lexer.paser throws ``undefined method `flatten!' for nil:NilClass (NoMethodError)`` for this input ~~~ruby require 'ripper' code = <<~CODE a do |b # closing "|" is missing <<~C C end CODE Ripper::Lexer.parse code ~~~ ~~~ /Users/tomoya/.rbenv/versions/3.2.0/lib/ruby/3.2.0/ripper/lexer.rb:183:in `parse': undefined method `flatten!' for nil:NilClass (NoMethodError) result.concat(@buf) until (@buf = []; super(); @buf.flatten!; @buf.empty?) ^^^^^^^^^ from /Users/tomoya/.rbenv/versions/3.2.0/lib/ruby/3.2.0/ripper/core.rb:19:in `parse' from -:8:in `<main>' ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:111992] [Ruby master Bug#19372] Proc objects are not traversed for shareable check during Ractor.make_shareable(prok)
by luke-gru (Luke Gruber) 07 Feb '23

07 Feb '23

Issue #19372 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19372: Proc objects are not traversed for shareable check during Ractor.make_shareable(prok) https://bugs.ruby-lang.org/issues/19372 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby class Proc attr_accessor :obj1 def initialize @obj1 = Object.new end end p = true.instance_eval { Proc.new { puts "hi" } } Ractor.make_shareable(p) p "Obj1 frozen?", Ractor.shareable?(p.obj1) P = p r = Ractor.new do pp = P p pp.obj1 # gives error in debug builds (rb_ractor_confirm_belonging rb_bug() call) end ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:112206] [Ruby master Bug#19407] 2 threads taking from current ractor will hang forever
by luke-gru (Luke Gruber) 07 Feb '23

07 Feb '23

Issue #19407 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19407: 2 threads taking from current ractor will hang forever https://bugs.ruby-lang.org/issues/19407 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the current implementation of Ractors, it's possible to `take` from the current ractor. This could be useful when co-ordinating threads: ```ruby t = Thread.new do obj = Ractor.current.take p obj # do some work with obj end t0 = Thread.new do obj = Ractor.current.take p obj # do some work with obj end Ractor.yield :go ``` However it hangs forever: ```ruby t = Thread.new do obj = Ractor.current.take p obj end t0 = Thread.new do obj = Ractor.current.take p obj end sleep 0.5 ``` Should "self-take" be disabled, or was it designed to allow it but this is just a bug? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112210] [Ruby master Bug#19410] If move from ractor fails with error, some objects are left in broken state
by luke-gru (Luke Gruber) 07 Feb '23

07 Feb '23

Issue #19410 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19410: If move from ractor fails with error, some objects are left in broken state https://bugs.ruby-lang.org/issues/19410 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do obj = receive end a = Object.new obj = [a, proc { }] begin r.send(obj, move: true) rescue => e puts "couldn't move" end p a # a is moved, this errors out. But it's not really moved because the other ractor can't access it. It's in limbo :) r << :end r.take ``` This might be tricky to fix, as it requires some sort of commit function for moving objects after every object is checked for ability to move. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112243] [Ruby master Bug#17664] Behavior of sockets changed in Ruby 3.0 to non-blocking
by ioquatix (Samuel Williams) 07 Feb '23

07 Feb '23

Issue #17664 has been updated by ioquatix (Samuel Williams). > I could probably use the 'events' form of IO#wait however. Yes, you should do that. `IO.select` for a single file descriptor is hard to implement efficiently into the event loop. ---------------------------------------- Bug #17664: Behavior of sockets changed in Ruby 3.0 to non-blocking https://bugs.ruby-lang.org/issues/17664#change-101669 * Author: ciconia (Sharon Rosner) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * ruby -v: 3.0.0 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I'm not sure this is a bug, but apparently a change was introduced in Ruby 3.0 that makes sockets non-blocking by default. This change was apparently introduced as part of the work on the [FiberScheduler interface](https://github.com/ruby/ruby/blame/78f188524f551c97b1a7a44ae1351…. This change of behaviour is not discussed in the Ruby 3.0.0 release notes. This change complicates the implementation of an io_uring-based fiber scheduler, since io_uring SQE's on fd's with `O_NONBLOCK` can return `EAGAIN` just like normal syscalls. Using io_uring with non-blocking fd's defeats the whole purpose of using io_uring in the first place. A workaround I have put in place in the Polyphony [io_uring backend](https://github.com/digital-fabric/polyphony/blob/d3c9cf3ddc1f41438… is to make sure `O_NONBLOCK` is not set before attempting I/O operations on any fd. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112232] [Ruby master Bug#19418] Checking if a date in an open date range times out when the range starts after the test date
by wilhelmsen (Hallgeir Wilhelmsen) 06 Feb '23

06 Feb '23

Issue #19418 has been reported by wilhelmsen (Hallgeir Wilhelmsen). ---------------------------------------- Bug #19418: Checking if a date in an open date range times out when the range starts after the test date https://bugs.ruby-lang.org/issues/19418 * Author: wilhelmsen (Hallgeir Wilhelmsen) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ` require 'date' ((Date.today + 1)..).include?(Date.today) ` is expected to return `false`. It never return a value, as like it is in a never ending loop. `((Date.today)..).include?(Date.today)` however, returns `true` right away. `(2..).include?(1)` also returns false, as expected. I.e. this seems to be a date issue and not a range issue, and it seem to happen when the start date comes after the date to check for. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112189] [Ruby master Bug#19404] Backport request for 3b83b265f11965582d4b9b439eff8a501792ab68
by alanwu (Alan Wu) 06 Feb '23

06 Feb '23

Issue #19404 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #19404: Backport request for 3b83b265f11965582d4b9b439eff8a501792ab68 https://bugs.ruby-lang.org/issues/19404 * Author: alanwu (Alan Wu) * Status: Closed * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED ---------------------------------------- It would be nice to have this in a release to make it easier for people to send good crash diagnostics. ``` commit 3b83b265f11965582d4b9b439eff8a501792ab68 YJIT: Crash with rb_bug() when panicking Helps with getting good bug reports in the wild. Intended to be backported to the 3.2.x series. yjit/bindgen/src/main.rs | 3 +++ yjit/src/cruby_bindings.inc.rs | 1 + yjit/src/yjit.rs | 29 +++++++++++++++++++++++++++-- ``` -- https://bugs.ruby-lang.org/

2 1