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

[ruby-core:112832] [Ruby master Feature#17684] Remove `--disable-gems` from release version of Ruby
by hsbt (Hiroshi SHIBATA) 10 Mar '23

10 Mar '23

Issue #17684 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Feature #17684: Remove `--disable-gems` from release version of Ruby https://bugs.ruby-lang.org/issues/17684#change-102339 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- In my understand, `--disable-gems` is only debugging feature for ruby-core team. But some users enabled its option in test environment for performance or etc. So, `--disable-gems` option is wrong usage for some users. * https://github.com/rubygems/bundler/issues/7487#issuecomment-569901549 * https://github.com/rubygems/rubygems/pull/4440#issue-587031184 We should remove it from package version of ruby. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112831] [Ruby master Bug#18789] make test-bundled-gems failed after make install
by hsbt (Hiroshi SHIBATA) 10 Mar '23

10 Mar '23

Issue #18789 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Bug #18789: make test-bundled-gems failed after make install https://bugs.ruby-lang.org/issues/18789#change-102338 * Author: znz (Kazuhiro NISHIYAMA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.2.0dev (2022-05-17T22:12:44Z master e2bad65eab) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- On snapshot-master CI, `make test-bundled-gems` failed. https://github.com/ruby/actions/runs/6476724416?check_suite_focus=true#step… ``` ./tool/test-bundled-gems.rb:10:in `realpath': No such file or directory @ realpath_rec - /home/runner/work/actions/actions/snapshot-master/.bundle/bin/rake (Errno::ENOENT) from ./tool/test-bundled-gems.rb:10:in `<main>' make: *** [uncommon.mk:1410: test-bundled-gems-run] Error 1 ``` I investigated it, it causes after `make install`. How to reproduce: 1. Run configure 2. `make install` 3. `make test-bundled-gems` or In already built directory 1. `rm -rf path/to/srcdir/.bundle` 2. `make install` 3. `make test-bundled-gems` If I run `rm -rf path/to/srcdir/.bundle` and `make test-bundled-gems` without `make install`, `.bundle/bin/rake` exists. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112794] [Ruby master Bug#19524] Garbage Collector is not working as expected.
by hjimenez89rb 10 Mar '23

10 Mar '23

Issue #19524 has been reported by hjimenez89rb (Hugo Alberto Jiménez Santos). ---------------------------------------- Bug #19524: Garbage Collector is not working as expected. https://bugs.ruby-lang.org/issues/19524 * Author: hjimenez89rb (Hugo Alberto Jiménez Santos) * Status: Open * Priority: Normal * ruby -v: 3.1.2 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- We are currently developing a Ruby based web application which connects to a DB2 Database . WE have been using ibm_db-5.4.0 to establish a connection. We are currently following the IBM and Ruby documentation but the application crashes by garbage collector Ruby error. We have checked the issue with IBM_team to make sure that It was not a IBM_GEM problem but as a result of their tests, IBM_GEM is working in different cases but for us we face up with those errors even with those versions (2.7.6, 3.1.2, 3.2.1): */usr/local/rvm/gems/ruby-3.2.1/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:3104: warning: undefining the allocator of T_DATA class IBM_DB::Statement /usr/local/rvm/rubies/ruby-3.2.1/lib/ruby/3.2.0/rubygems/specification.rb:1048: [BUG] object allocation during garbage collection phase *0x0/usr/local/rvm/gems/ruby-3.1.2/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:760: [BUG] object allocation during garbage collection phase ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] *Exception occurred on Step thread ID #SID:34117;RSEQ:911723; wrong instance allocation; backtrace: /usr/local/rvm/gems/ruby-3.1.2/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:760:in `server_info' (RuntimeError) /usr/local/rvm/gems/ruby-3.1.2/gems/ibm_db-5.4.0/lib/active_record/connection_adapters/ibm_db_adapter.rb:760:in `initialize'. (all trace is attached in this ticket) OS name: "CentOS" version: "8" architecture: "x86_64" rvm: version: "1.29.12 (latest)" As an extra error, we're not sure if Warning! PATH is not properly set up, /usr/local/rvm/gems/ruby-3.2.1/bin is not at first place. Usually this is caused by shell initialization files. Search for PATH=... entries. You can also re-add RVM to your profile by running: rvm get stable --auto-dotfiles To fix it temporarily in this shell session run: rvm use ruby-3.2.1 To ignore this error add rvm_silence_path_mismatch_check_flag=1 to your ~/.rvmrc file. Garbage collector leack test this code we have been running manually garbage collector, if you can see in this example:T_STRING. is not deceasing the stings in live memory, Even executig GC manualy. (log is attached) GC.disable # Only run GC when manually called an_array = [] loop do 1000.times { an_array << "A" + "B" + "C" } puts "Array is #{an_array.size} items long" GC.start # Run a major GC - use full_mark: false for minor GC pp ObjectSpace.count_objects sleep 1 end ---Files-------------------------------- LOGS3.txt (12.5 KB) LOGS4.txt (127 KB) LOGS2.txt (9.62 KB) LOGS1.txt (123 KB) leacky.txt (3.64 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112821] [Ruby master Feature#19094] `sleep(nil)` vs `sleep()` and replicating the default implementation.
by ioquatix (Samuel Williams) 10 Mar '23

10 Mar '23

Issue #19094 has been updated by ioquatix (Samuel Williams). Status changed from Open to Closed Merged. ---------------------------------------- Feature #19094: `sleep(nil)` vs `sleep()` and replicating the default implementation. https://bugs.ruby-lang.org/issues/19094#change-102328 * Author: ioquatix (Samuel Williams) * Status: Closed * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- ``` > sleep(nil) (irb):1:in `sleep': can't convert NilClass into time interval (TypeError) ``` However, I feel that this makes implementing a compatible sleep method a little difficult. ```ruby def sleep(time = nil) if time sleep_some(time) else sleep_forever end end ``` Can we consider allowing `sleep(nil)` and `sleep(false)` to be the same as `sleep()` to simplify this behaviour? Otherwise, it's hard to proxy (e.g. fiber scheduler, or even just a plain old variable argument). e.g. ```ruby class Sleeper def initialize(time = nil) @time = time end def sleep Kernel::sleep(@time) # Hard to get the behaviour of `sleep()` here without explicitly handling/checking. end end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112820] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by matz (Yukihiro Matsumoto) 10 Mar '23

10 Mar '23

Issue #18743 has been updated by matz (Yukihiro Matsumoto). It should be fixed. But I think the proposed change https://github.com/ruby/ruby/pull/6201 is not enough, we should link the old exception with the new one (via `cause`). Matz. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-102327 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112815] [Ruby master Feature#10343] Postfix notations for `when` and `else` inside `case` statement
by mame (Yusuke Endoh) 10 Mar '23

10 Mar '23

Issue #10343 has been updated by mame (Yusuke Endoh). Status changed from Open to Rejected Discussed at the dev meeting. @matz rejected this proposal because he didn't think it was easy to understand. ---------------------------------------- Feature #10343: Postfix notations for `when` and `else` inside `case` statement https://bugs.ruby-lang.org/issues/10343#change-102318 * Author: sawa (Tsuyoshi Sawada) * Status: Rejected * Priority: Normal ---------------------------------------- In a `case` statement, the condition part (`when ...`) in the branches do not have the same length in general, and especially, `else` is much shorter than the conditions. So when we write the condition and the return value in a single line, they are not aligned, and are hard to read. ```ruby case foo when some_very_long_proc then "a" when short_regex then "bbb" when some_long_regex then "cc" else "dddd" end ``` I propose to allow postfix notations with `when` and `else` (or `otherwise`) inside `case` statement as below: ```ruby case foo "a" when some_very_long_proc "bbb" when short_regex "cc" when some_long_regex "dddd" else end ``` Pros are: 1) Postfix notation does not require `then` or `;`, so it is concise. 2) The return values from the branches (e.g., `"a"`, `"bb"`, `"ccc"`, `"dddd"`) tend to be shorter and more uniformly lengthened than the conditions, hence they are somewhat close to being aligned naturally, making this easier to read. 3) We are usually more interested in the return value than the condition of a branch, especially when we are reading someone's code and are trying to grasp what the `case` statement does or returns. 4) This notation is closer to case-like conditional notations regularly used in mathematics: ``` ┌ 1 (x = 0) x! = ┤ └ x (x - 1)! (otherwise) ``` So it would be easier to read for those who are familiar with mathematics. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112536] [Ruby master Feature#19457] Some improvements to test-all suite
by luke-gru (Luke Gruber) 09 Mar '23

09 Mar '23

Issue #19457 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #19457: Some improvements to test-all suite https://bugs.ruby-lang.org/issues/19457 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal ---------------------------------------- Hi, I've been making some improvements to this suite in a branch of my own and came up with a list of changes I think are good but I would like input from developers. 1) Currently test-all with -j option does not show errors/failures immediately, it waits until end. Additionaly it doesn't really show them at end, it only shows after it retries the tests in current process. I made changes to make it show immediately and have a summary before the retry. 2) If timeout occurs in -j mode (default 180 sec), the worker process is terminated but no new worker is added to replace it. I added this. 3) If a timeout occurs in -j mode, it is not reported immediately. I made it do so. 4) I added -no-leakchecker flag. I use this often when I don't want any output of DRB tests because I get lots of leakchecker reports from this for some reason. 5) when filtering test name with --name option, you can give regexp like /test_hash/ but it can also match class name like !/DRbTest/. You can't give //i flag so you need to get case exactly right for the class names. I added //i flag functionality for positive and negative regexps. 6) Fixed colorization of failures/skips. 7) I added test suite (test class) GC in serial (no -j) mode. After a test class finishes the constant is removed and references deleted. It saves quite a bit of memory in my tests so far. Motivation to reduce memory and reduce full GC pause time. I have all these changes in a single branch. If any of these changes interest you, let me know and I will try to isolate them in a single commit and make a PR. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112681] [Ruby master Misc#19475] Propose Matthew Valentine-House (@eightbitraptor) as a core committer
by k0kubun (Takashi Kokubun) 09 Mar '23

09 Mar '23

Issue #19475 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #19475: Propose Matthew Valentine-House (@eightbitraptor) as a core committer https://bugs.ruby-lang.org/issues/19475 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- I'd like to propose Matthew Valentine-House (@eightbitraptor) as a committer. He has been [an active contributor to Ruby](https://github.com/ruby/ruby/pulls?q=author%3Aeightbitraptor) in the following areas: * **Variable Width Allocation** - He worked on the VWA (RVARGC) project to increase performance by improving the spatial locality of objects [https://bugs.ruby-lang.org/issues/17816](https://bugs.ruby-lang.org/issues/… * **Compaction movement refactor** - He re-worked the GC's compaction algorithm to facilitate object movement between the size pools to ensure VWA uses memory efficiently: [https://bugs.ruby-lang.org/issues/18619](https://bugs.ruby-lang.org/issues/… (He spoke about this at [Ruby Kaigi 2022 in 津](https://rubykaigi.org/2022/presentations/eightbitraptor.html#day2)) * **LLDB refactor & Developer experience** - He is also passionate about the developer experience of working on the Ruby codebase. He has been refactoring the LLDB helpers to give them some more structure and make debugging Ruby easier: [https://github.com/ruby/ruby/pull/6129](https://github.com/ruby/ruby/pull/6… He's really passionate about making Ruby's GC better. He wants to implement novel GC algorithms and techniques in CRuby, and I want to make it easier for him to push changes required for it. This is a proposal from @tenderlovemaking and myself. If approved, we'll help him onboard as a Ruby committer. I already heard that @matz and @mame are in favor of the idea, but let me formally propose this here. -- https://bugs.ruby-lang.org/

7 10

[ruby-core:112746] [Ruby master Bug#19518] Recent Source Releases Do Not Compile on CentOS 7 Due to configure Script Error Generated By autoconf >= 2.70
by eviljoel (evil joel) 09 Mar '23

09 Mar '23

Issue #19518 has been reported by eviljoel (evil joel). ---------------------------------------- Bug #19518: Recent Source Releases Do Not Compile on CentOS 7 Due to configure Script Error Generated By autoconf >= 2.70 https://bugs.ruby-lang.org/issues/19518 * Author: eviljoel (evil joel) * Status: Open * Priority: Normal * ruby -v: 3.2.1, 3.2.0, 3.1.3, 3.0.5 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Source releases where the 'configure' script was generated by autoconf 2.70 or greater results in a failed Ruby compilation on CentOS 7. This is because autoconf 2.70 and 2.71 adds some code that attempts to detect C11 support resulting in a compilation with the -std11 flag instead of the -std99 flag. The gcc bundled with CentOS 7 is version 4.8.5 which only has experimental C11 support. This experimental C11 support appears to not handle 'extern' appropriately. I've included a Dockerfile that reproduces the problem: ``` FROM centos:7 RUN yum -y install autoconf gcc libyaml-devel make RUN curl -O https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.1.tar.xz # Verify the SHA256SUM as listed here: https://www.ruby-lang.org/en/news/2023/02/08/ruby-3-2-1-released/ RUN [ "$(sha256sum ruby-3.2.1.tar.xz | sed -n 's/^$[^\s]*$\s.*/\1/p' | tr -d "\n" | tr -d ' ')" = '746c8661ae25449cbdc5297d1092702e93e66f365a75fecb740d4f292ced630c' ] RUN tar -xf ruby-3.2.1.tar.xz RUN cd ruby-3.2.1 && ./configure RUN cd ruby-3.2.1 && make RUN /ruby-3.2.1/ruby --version ``` I've also included a Dockerfile that works around the problem simply by regenerating the configure script with autoconf 2.69: ``` FROM centos:7 RUN yum -y install autoconf gcc libyaml-devel make RUN curl -O https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.1.tar.xz # Verify the SHA256SUM as listed here: https://www.ruby-lang.org/en/news/2023/02/08/ruby-3-2-1-released/ RUN [ "$(sha256sum ruby-3.2.1.tar.xz | sed -n 's/^$[^\s]*$\s.*/\1/p' | tr -d "\n" | tr -d ' ')" = '746c8661ae25449cbdc5297d1092702e93e66f365a75fecb740d4f292ced630c' ] RUN tar -xf ruby-3.2.1.tar.xz RUN cd ruby-3.2.1 && autoconf configure.ac > configure RUN cd ruby-3.2.1 && ./configure RUN cd ruby-3.2.1 && make RUN /ruby-3.2.1/ruby --version ``` This 'configure' bug affects the following releases of Ruby: ruby-3.2.1 ruby-3.2.0 ruby-3.1.3 ruby-3.0.5 Ruby 2.7.7's 'configure' script was generated with autoconf 2.71 but appears to be unaffected. My experience working with autoconf is very limited, but I believe this is mostly due to an error in autoconf itself. I believe autoconf should be smart enough to not attempt to leverage gcc's experimental C11 support. Regardless, Ruby should still compile correctly on CentOS 7 especially when prior bugfix releases of 3.0 and 3.1 did so successfully. At a minimum, future releases of 3.0 and 3.1 should generate their 'configure' scripts with autoconf 2.69 to maintain backwards compatibility and to address this regression. Ruby developers should also consider supporting compilation of Ruby 3.2 and 3.3 on CentOS 7 until CentOS 7 support ends next year. If you agree this is also an autoconf error, I'll file a bug upstream. Thank you. ---Files-------------------------------- ruby321BuildFailure-20230308.Dockerfile (531 Bytes) ruby321BuildWorkAround-20230308.Dockerfile (586 Bytes) -- https://bugs.ruby-lang.org/

3 6

[ruby-core:112788] [Ruby master Misc#19523] Replace tabs in parse.y with spaces
by kddeisz (Kevin Newton) 09 Mar '23

09 Mar '23

Issue #19523 has been reported by kddeisz (Kevin Newton). ---------------------------------------- Misc #19523: Replace tabs in parse.y with spaces https://bugs.ruby-lang.org/issues/19523 * Author: kddeisz (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- Since the tabs have been replaced in C files, could we do the same for parse.y? -- https://bugs.ruby-lang.org/

1 0