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

[ruby-core:115304] [Ruby master Feature#19993] Optionally Free all memory at exit
by HParker (Adam Hess) 07 Dec '23

07 Dec '23

Issue #19993 has been reported by HParker (Adam Hess). ---------------------------------------- Feature #19993: Optionally Free all memory at exit https://bugs.ruby-lang.org/issues/19993 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal ---------------------------------------- Add a runtime option allowing Ruby to optionally free all memory at shutdown. # why Today, memory sanitizers are difficult to use with Ruby, since not all memory is freed at shutdown. it is difficult to detect memory leaks or errors in Ruby or in Ruby C extensions when these tools are not available. While implementing this feature, we were able to identify and fix a number of memory leaks and errors. https://github.com/ruby/ruby/pull/8556 https://github.com/ruby/ruby/pull/8512 https://github.com/ruby/ruby/pull/8503 https://github.com/ruby/ruby/pull/8487 https://github.com/ruby/ruby/pull/8452 https://github.com/ruby/ruby/pull/8501 https://github.com/ruby/ruby/pull/8481 https://github.com/ruby/ruby/pull/8555 This shows that having access to tools like this can make finding and fixing memory bugs easier. # current progress Today we can allow ruby developers to enable freeing memory at shutdown via the `free-at-shutdown` runtime option. PR: https://github.com/ruby/ruby/pull/8868 running, without `--free-on-shutdown`: ``` valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby basictest/test.rb ``` ``` ==573270== LEAK SUMMARY: ==573270== definitely lost: 658,324 bytes in 5,387 blocks ==573270== indirectly lost: 955,708 bytes in 11,957 blocks ==573270== possibly lost: 2,071,096 bytes in 12 blocks ==573270== still reachable: 161,881 bytes in 275 blocks ==573270== suppressed: 0 bytes in 0 blocks ==573270== Reachable blocks (those to which a pointer was found) are not shown. ==573270== To see them, rerun with: --leak-check=full --show-leak-kinds=all ``` with `--free-on-shutdown` ``` valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby --free-on-shutdown basictest/test.rb ``` ``` ==573306== HEAP SUMMARY: ==573306== in use at exit: 0 bytes in 0 blocks ==573306== total heap usage: 43,643 allocs, 43,643 frees, 29,222,534 bytes allocated ==573306== ==573306== All heap blocks were freed -- no leaks are possible ``` # future plans * Continue improving memory safety * add `valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby --free-on-shutdown basictest/test.rb` to CI * Allow C extensions to do a "optional destruct for memory safety" so they can leverage the same memory sanitizer tools. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:115333] [Ruby master Misc#19997] DevMeeting-2023-11-30
by mame (Yusuke Endoh) 06 Dec '23

06 Dec '23

Issue #19997 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19997: DevMeeting-2023-11-30 https://bugs.ruby-lang.org/issues/19997 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/11/30 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/11/27. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

10 14

[ruby-core:115593] [Ruby master Bug#20041] Array destructuring and default values in parameters
by tenderlovemaking (Aaron Patterson) 06 Dec '23

06 Dec '23

Issue #20041 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20041: Array destructuring and default values in parameters https://bugs.ruby-lang.org/issues/20041 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It's possible to set the default value of a parameter to a previous parameter. For example: ```ruby def foo(a, b = a) b end foo([1, 2]) # => [1, 2] ``` However, if the parameters are destructured, the destructring happens _after_ default parameter assignment. For example: ```ruby def foo((x, y), b = x) [x, y, b] end foo([1, 2]) # => [1, 2, nil] ``` Is this expected behavior? I would have expected the parameters to be "evaluated" from left to right, and the array destructuring to happen _before_ the default parameter assignment. Thanks! -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115604] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 06 Dec '23

06 Dec '23

Issue #18576 has been updated by Eregon (Benoit Daloze). Target version set to 3.4 @matz Could we try this again for 3.4, soon after the 3.3 release? Then there is plenty of time to discover any issue related to it (probably very few as gems have been patched, and applications using encoding names instead of encoding constants are likely very old and unlikely to use a recent Ruby). ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-105535 * 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:114785] [Ruby master Bug#19886] "default->bundled gem" warning is not shown under "bundle exec"
by mame (Yusuke Endoh) 06 Dec '23

06 Dec '23

Issue #19886 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19886: "default->bundled gem" warning is not shown under "bundle exec" https://bugs.ruby-lang.org/issues/19886 * Author: mame (Yusuke Endoh) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ cat Gemfile source "https://rubygems.org" $ cat test.rb require "base64" $ bundle exec ruby test.rb $ ``` In this situation, `bundle exec ruby test.rb` should print a warning: base64 which will be not part of the default gems since Ruby 3.4.0. Note that `ruby test.rb` shows the warning, which is not needed (see #19885). ``` $ ruby test.rb test.rb:1: warning: base64 which will be not part of the default gems since Ruby 3.4.0 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115602] [Ruby master Bug#19147] `TestFileExhaustive#test_expand_path_for_existent_username` and `TestDir#test_home` fails on i686
by vo.x (Vit Ondruch) 06 Dec '23

06 Dec '23

Issue #19147 has been updated by vo.x (Vit Ondruch). Testing further, there might be issue in some other places. While I can't reproduce the issue on Fedora Rawhide, it still fails on Fedora 38. I was not expecting this. Might the culprit be e.g. glibc? Or is it FS type related? ---------------------------------------- Bug #19147: `TestFileExhaustive#test_expand_path_for_existent_username` and `TestDir#test_home` fails on i686 https://bugs.ruby-lang.org/issues/19147#change-105533 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-11-24 master 66e5200ba4) [i386-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Testing with commit:git|66e5200ba4 on Fedora Rawhide, I observe following error just on i686 (other platforms are passing just fine): ~~~ 1) Error: TestFileExhaustive#test_expand_path_for_existent_username: RuntimeError: can't set length of shared string /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_file_exhaustive.rb:1122:in `expand_path' /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_file_exhaustive.rb:1122:in `test_expand_path_for_existent_username' 2) Error: TestDir#test_home: RuntimeError: can't set length of shared string /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_dir.rb:537:in `expand_path' /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_dir.rb:537:in `block in test_home' ~~~ Previously testing with commit:git|4b1504ae0a, the tests were passing just fine. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115596] [Ruby master Feature#20040] Make Hash respond do deconstruct to allow matchting key/value pairs
by matz (Yukihiro Matsumoto) 06 Dec '23

06 Dec '23

Issue #20040 has been updated by matz (Yukihiro Matsumoto). Theoretically possible, but could you show us a specific use case, please? Matz. ---------------------------------------- Feature #20040: Make Hash respond do deconstruct to allow matchting key/value pairs https://bugs.ruby-lang.org/issues/20040#change-105527 * Author: Anonymous * Status: Open * Priority: Normal ---------------------------------------- It would be nice to allow pattern matching to work on key/value pairs of a Hash to e.g. find the first entry, or entries where the key is not known. Example: ``` class Hash; def deconstruct = to_a; end {a: 1, b: 2} => [[k, v], *] puts "k=#{k}" # :a puts "v=#{v}" # 1 {a: 1, b: 2} => [*, [k, 2], *] puts "k=#{k}" # :b ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115592] [Ruby master Feature#20040] Make Hash respond do deconstruct to allow matchting key/value pairs
by jochen＠seeber.me (Jochen Seeber) 05 Dec '23

05 Dec '23

Issue #20040 has been reported by jochen(a)seeber.me (Jochen Seeber). ---------------------------------------- Feature #20040: Make Hash respond do deconstruct to allow matchting key/value pairs https://bugs.ruby-lang.org/issues/20040 * Author: jochen(a)seeber.me (Jochen Seeber) * Status: Open * Priority: Normal ---------------------------------------- It would be nice to allow pattern matching to work on key/value pairs of a Hash to e.g. find the first entry, or entries where the key is not known. Example: ``` class Hash; def deconstruct = to_a; end {a: 1, b: 2} => [[k, v], *] puts "k=#{k}" # :a puts "v=#{v}" # 1 {a: 1, b: 2} => [*, [k, 2], *] puts "k=#{k}" # :b ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115591] [Ruby master Bug#19147] `TestFileExhaustive#test_expand_path_for_existent_username` and `TestDir#test_home` fails on i686
by vo.x (Vit Ondruch) 05 Dec '23

05 Dec '23

Issue #19147 has been updated by vo.x (Vit Ondruch). This was already fixed at 3.2.0 release it seems. Nevertheless, I am still unsure, what was cause and fix for this. ---------------------------------------- Bug #19147: `TestFileExhaustive#test_expand_path_for_existent_username` and `TestDir#test_home` fails on i686 https://bugs.ruby-lang.org/issues/19147#change-105524 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-11-24 master 66e5200ba4) [i386-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Testing with commit:git|66e5200ba4 on Fedora Rawhide, I observe following error just on i686 (other platforms are passing just fine): ~~~ 1) Error: TestFileExhaustive#test_expand_path_for_existent_username: RuntimeError: can't set length of shared string /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_file_exhaustive.rb:1122:in `expand_path' /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_file_exhaustive.rb:1122:in `test_expand_path_for_existent_username' 2) Error: TestDir#test_home: RuntimeError: can't set length of shared string /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_dir.rb:537:in `expand_path' /builddir/build/BUILD/ruby-3.2.0-66e5200ba4/test/ruby/test_dir.rb:537:in `block in test_home' ~~~ Previously testing with commit:git|4b1504ae0a, the tests were passing just fine. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115588] [Ruby master Bug#20039] Matching US-ASCII string to copied UTF-8 Regexp causes invalid multibyte character error
by dbrown9＠gmail.com (Dustin Brown) 04 Dec '23

04 Dec '23

Issue #20039 has been reported by dbrown9(a)gmail.com (Dustin Brown). ---------------------------------------- Bug #20039: Matching US-ASCII string to copied UTF-8 Regexp causes invalid multibyte character error https://bugs.ruby-lang.org/issues/20039 * Author: dbrown9(a)gmail.com (Dustin Brown) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-03 master 85bc80a) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Matching a US-ASCII string to a UTF-8 encoded regexp with multibyte characters works as expected. ```ruby re = Regexp.new("\u2018".encode("UTF-8")) "".encode("US-ASCII").match?(re) => false ``` However, if that regexp is used to initialize a new regexp, the comparison fails with a Invalid mutibyte character error. ```ruby re = Regexp.new("\u2018".encode("UTF-8")) "".encode("US-ASCII").match?(Regexp.new(re)) => ArgumentError: regexp preprocess failed: invalid multibyte character ``` -- https://bugs.ruby-lang.org/

1 0