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

[ruby-core:120279] [Ruby master Feature#20959] Add a way to get codepage of console.
by YO4 (Yoshinao Muramatsu) 12 Dec '25

12 Dec '25

Issue #20959 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #20959: Add a way to get codepage of console. https://bugs.ruby-lang.org/issues/20959 * Author: YO4 (Yoshinao Muramatsu) * Status: Open ---------------------------------------- # Abstract Add a way to retrieve code pages of console. On Windows, Encoding.find("locale") returns the console codepage. To prepare for future changes, specify ```console``` instead of ```locale``` to get the encoding when a console code page is needed. # Background On Windows, Encoding.find("locale") returns the console codepage. This is different from locale in other environments. Also the name and content do not seem to match. In the future, if we change the locale_encoding of the Windows port to the locale codepage of the C runtime library, we need to get the encoding for the console. Strings received via pipe from cmd.exe or powershell are encoded in the console codepage. This would be necessary when communicating with other programs via pipes. # Proposal Make Encoding.find("console") return the encoding that represents the console codepage. # Background(continued) Since Windows 10, UTF-8 support seems to be enhanced in the commandline environment. * build 17134 ucrt supports UTF-8 locale codepage ```setlocale(LC_CTYPE, ".utf8")``` Windows support UTF-8 ANSI Codepage(experimental) ```Beta: Use Unicode UTF-8 for worldwide language support``` * build 18362 support ```Set a process code page to UTF-8``` via manifest. * build 19041 Time zone name holds in wchar_t internaly, so proper tzname can be obtained regardless of the Windows language setting. This should not be all. Through these, I feel that the Microsoft team recommends the use of utf-8. It also seems that Microsoft, which has previously depricated the ANSI version of the API, is treating it as a valid alternative to use in UTF-8. If it becomes widespread on Windows for libraries to respect the C runtime library locale, ruby would do better to follow it. Of course, it is good to be able to get the encoding of the console by specifying a console. # Future plan By reducing differences from other platforms, bugs and extra code are hoped to be reduced. * Do ```setlocale(LC_CTYPE, ".utf8");``` in main.c (or refer LC_* environment variables). * ```Encoding.find("locale")``` returns C runtime library locale. Since strings obtained from the Windows system have a Unicode code range, the API to obtain fixed UTF-8 encoding remains unchanged. # Discussion The code page we can get from Windows also has ACP and OEMCP, but are these necessary? Is it reasonable to get locale_encoding if Encoding.find("console") is called on other platforms? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:117003] [Ruby master Bug#20314] Simultaneous Timeout expires may raise an exception after the block
by mame (Yusuke Endoh) 11 Dec '25

11 Dec '25

Issue #20314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20314: Simultaneous Timeout expires may raise an exception after the block https://bugs.ruby-lang.org/issues/20314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Launchable reports `TestTimeout#test_nested_timeout` as a flaky test, and I reproduced it as follows. ```ruby require "timeout" class A < Exception end class B < Exception end begin Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do nil while true end end rescue A, B p $! #=> #<A: execution expired> # Exception B is raised after the above call returns #=> test.rb:16:in `p': execution expired (B) p :end # not reach end ``` This is because the timer thread performs two consecutive `Thread#raise` to the target thread. I have discussed this with @ko1 and have come up with three solutions. ### Solution 1 When multiple nested Timeouts expire simultaneously, raise an exception for the outer-most Timeout and let the inner Timeouts expire without throwing an exception. In the above example, it would only raise A. The problem with this approach is that if you are rescuing A in the inner block, it may never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue A sleep # The exception A is caught. The inner Timeout is already expired, so the code (may) never end. end end end ``` Note that, if A and B did not occur at the same time, it would raise B. This is a race condition. ### Solution 2 When multiple nested Timeouts expire simultaneously, raise an exception for the inner-most Timeout and let the outer Timeouts wait until the inner-most Timeout returns. In the above example, it would raise either A or B, not both. The problem with this approach is that if you are rescuing B in the inner block, it never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue B sleep # The outer Timeout waits for the inner timeout, and the inner Timeout never return. So this code never ends. end end end ``` ### Solution 3 Make thread interrupt queue one length. If the target thread has already been `Thread#raise(A)`, the new `Thread#raise(B)` blocks until the target thread processes A. Since there will be no more simultaneous Thread#raise, there will be no more exceptions after the end of the block. The timeout timer thread should be changed in consideration that `Thread#raise` may block. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122240] [Ruby Bug#21363] `Namespace.current` should always return the Namespace in which it was defined
by tenderlovemaking (Aaron Patterson) 09 Dec '25

09 Dec '25

Issue #21363 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21363: `Namespace.current` should always return the Namespace in which it was defined https://bugs.ruby-lang.org/issues/21363 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-22T23:07:21Z rm-assertion 17e71c7a24) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I think `Namespace.current` should always return the namespace in which it was defined. Here is an example to demonstrate what I mean: ```ruby File.binwrite("ns.rb", <<-RUBY) # namespace 3 module M def self.test p Namespace.current end TEST = -> { p Namespace.current } end RUBY ns = Namespace.new ns.load "./ns.rb" p Namespace.current ns::M.test ns::M::TEST.call ``` I expect the output of `ns::M.test` and `ns::M::TEST.call` to be the same. Instead the output is like this: ``` #<Namespace:2,user,main> #<Namespace:3,user,optional> #<Namespace:2,user,main> ``` I think a method and lambda defined in the same namespace should return the same value for `Namespace.current` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122114] [Ruby Bug#21341] `Namespace is not a module (TypeError)` without enabling the namespace
by yahonda (Yasuo Honda) 09 Dec '25

09 Dec '25

Issue #21341 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21341: `Namespace is not a module (TypeError)` without enabling the namespace https://bugs.ruby-lang.org/issues/21341 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby on Rails test case has the `module Namespace`. https://github.com/rails/rails/blob/main/activemodel/test/validators/namesp… ```ruby module Namespace class EmailValidator < ::EmailValidator end end ``` This code fails against Ruby 3.5.0dev without enabling the namespace feature. ### Steps to reproduce ```ruby $ ruby -ve 'module Namespace; end' ``` ### Expected behavior It should run without errors. ### Actual behavior It raises the TypeError. ```ruby $ ruby -ve 'module Namespace; end' ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] -e:1:in '<main>': Namespace is not a module (TypeError) ruby:0: previous definition of Namespace was here ``` Raising this TypeError with RUBY_NAMESPACE=1 looks expected to me. ```ruby $ RUBY_NAMESPACE=1 ruby -ve 'module Namespace; end' ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. -e:1:in '<main>': Namespace is not a module (TypeError) ruby:0: previous definition of Namespace was here ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:121955] [Ruby Bug#21320] Namespaces leak with constant lookup
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21320 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21320: Namespaces leak with constant lookup https://bugs.ruby-lang.org/issues/21320 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program ```ruby X = :top class C X = :super end class D < C p X end ``` prints `:super` normally, and `:top` if running under a namespace. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121952] [Ruby Bug#21318] Namespaces leak with permanent names
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21318 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21318: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21318 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program: ```ruby Module.nesting ``` The nesting is empty or not depending on whether it is being executed under a namespace. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121950] [Ruby Bug#21316] Namespaces leak with permanent names
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21316 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21316: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21316 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program ```ruby C = Class.new C.name == 'C' ``` because under a non-main user namespace, the name of `C` has the namespace as a prefix. -- https://bugs.ruby-lang.org/

7 12

[ruby-core:122132] [Ruby Bug#21343] Namespace: singleton classes of root namespace leak between namespaces
by jhawthorn (John Hawthorn) 09 Dec '25

09 Dec '25

Issue #21343 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21343: Namespace: singleton classes of root namespace leak between namespaces https://bugs.ruby-lang.org/issues/21343 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby classes all have singleton classes, those singleton classes have singleton classes, and so on with infinite nesting. Since we don't have infinite resources, we create these lazily. Because of this, only a certain number of singleton classes exist in the root namespace. At a certain depth, mutable singleton classes end up shared between namespaces. ``` ruby File.write("/tmp/ntest.rb", <<~'RUBY') p String.singleton_class.singleton_class::Foo String.singleton_class.singleton_class::Bar = 456 RUBY String.singleton_class.singleton_class::Foo = 123 ns = Namespace.new ns.require("/tmp/ntest.rb") p String.singleton_class.singleton_class::Bar ``` ``` RUBY_NAMESPACE=1 ruby nstest2.rb ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. 123 456 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122070] [Ruby Feature#21335] Namespaces should be present in the backtrace
by tenderlovemaking (Aaron Patterson) 09 Dec '25

09 Dec '25

Issue #21335 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21335: Namespaces should be present in the backtrace https://bugs.ruby-lang.org/issues/21335 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Namespaces can call in to other name spaces. I think it might be helpful if namespace information is in the backtrace. For example: ```ruby File.binwrite "foo.rb", <<-eorb class Foo def self.test(ns1, ns2, count) if count == 0 puts caller else if count % 2 == 0 ns1::Foo.test(ns1, ns2, count - 1) else ns2::Foo.test(ns1, ns2, count - 1) end end end end eorb ns1 = Namespace.new ns1.load "foo.rb" ns2 = Namespace.new ns2.load "foo.rb" ns1::Foo.test(ns1, ns2, 10) ``` The output is like this: ``` See doc/namespace.md for known issues, etc. /Users/aaron/git/ruby/exe/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' ./test.rb:23:in '<main>' ``` `Foo.test` alternates between namespaces when calling a method, but you can't tell from the backtrace. I think we should include namespaces in the backtrace. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:121973] [Ruby Bug#21322] Namespaces and builtin classes as arguments and return values
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21322 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21322: Namespaces and builtin classes as arguments and return values https://bugs.ruby-lang.org/issues/21322 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- @tagomoris thanks for the docs under `doc/namespace.md`. Unless I missed it, I believe there is an edge case related to builtin classes (using the vocabulary there). Consider: ```ruby # test.rb ns = Namespace.new ns.require_relative 'foo' X = 1 ns::C.x(Object) # foo.rb class C def self.x(obj) obj::X end end ``` `obj::X` raises. I believe this is consistent with the feature, but maybe would deserve docs, because from the point of view of the Ruby programmer I am passing an object, no constant name resolution is happening in `foo.rb`. See what I mean? I believe, from my tests, that something analogous happens if `ns::C.x` returns (the namespaced) `Object`. In the main namespace, you don't get the object passed up as-is. I am also curious about how is this implemented (maybe to comment here, not necessarily in the docs). -- https://bugs.ruby-lang.org/

3 8