- ruby-core - ml.ruby-lang.org

[ruby-core:115188] [Ruby master Bug#19977] (nil..nil) === x can raise an exception, differing from Range#cover?

by kyanagi (Kouhei Yanagita)

Issue #19977 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19977: (nil..nil) === x can raise an exception, differing from Range#cover? https://bugs.ruby-lang.org/issues/19977 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I investigated Range#=== and Range#cover?, and found that the only difference in behavior between them would be that `(nil..nil) === x` could throw an exception. ``` % ~/tmp/ruby-master/bin/ruby -v ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22] ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil) === "a"' -e:1:in `===': cannot determine inclusion in beginless/endless ranges (TypeError) p (nil..nil) === "a" ^^^ from -e:1:in `<main>' ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil).cover?("a")' true ``` Is this difference intended? According to NEWS, `Range#===` uses `cover?` since Ruby 2.6 (For `String`, since Ruby 2.7). Following this, `(nil..nil) === x` should not throw an exception in the same way as `(nil..nil).cover?(x)`. history: `(nil..nil) === "a"` throws an exception since https://github.com/ruby/ruby/commit/04a92a6. For "linear objects" (`Integer`, `Float`, `Numeric`, `Time`), it has beed fixed not to throw an exception on https://github.com/ruby/ruby/commit/fb17c83. related issues: * [Bug #15449] Range#=== is not using cover in Ruby 2.6 * [Bug #18580] Range#include? inconsistency for beginless String ranges * [Bug #19533] Behavior of ===/include? on a beginless/endless range (nil..nil) changed in ruby 3.2 -- https://bugs.ruby-lang.org/

16 minutes

2
4
0 0

[ruby-core:115333] [Ruby master Misc#19997] DevMeeting-2023-11-30

by mame (Yusuke Endoh)

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/

4 hours, 30 minutes

10
14
0 0

[ruby-core:115593] [Ruby master Bug#20041] Array destructuring and default values in parameters

by tenderlovemaking (Aaron Patterson)

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/

5 hours, 41 minutes

2
3
0 0

[ruby-core:115598] [Ruby master Bug#20044] Add runtime flag and environment variable for prism

by HParker (Adam Hess)

Issue #20044 has been reported by HParker (Adam Hess). ---------------------------------------- Bug #20044: Add runtime flag and environment variable for prism https://bugs.ruby-lang.org/issues/20044 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- To enable prism to be used as the parser when running Ruby code, I would like to add a runtime flag and environment variable that allow it to be enabled. The flags could be, ``` ruby --prism test.rb ``` and the environment variable could be, ``` RUBY_PRISM=1 ruby test.rb ``` Previously implemented here: https://github.com/ruby/ruby/pull/9115, but merged before discussion could happen. Things to be sure to discuss mentioned by @mame, > * What to do with the command-line option when prism becomes the default parser in the future. > ** Just remove it, or leave it as a "do nothing" option? > * What are the appropriate names. > ** In Ruby, not absolutely but the names of features for professional use tend to be long and verbose, while those used by ordinary users tend to be short. > * Whether to print a warning when this mode is used. -- https://bugs.ruby-lang.org/

5 hours, 54 minutes

4
4
0 0

[ruby-core:115595] [Ruby master Bug#20043] `defined?` checks for method existence but only sometimes

by tenderlovemaking (Aaron Patterson)

Issue #20043 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20043: `defined?` checks for method existence but only sometimes https://bugs.ruby-lang.org/issues/20043 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-05T21:25:34Z master 56eccb350b) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When an expression is passed to `defined?`, it will _sometimes_ check if a method in a sub-expression is defined and sometimes it won't. For example: ``` $ ./miniruby -e'p defined?(a)' nil $ ./miniruby -e'p defined?([a])' nil ``` In the above case, Ruby will check whether or not the method `a` is defined, and it returns `nil`. However, if you use a splat, it will not check: ``` $ ./miniruby -e'p defined?([*a])' "expression" ``` The same thing seems to happen with method parameters: ``` $ ./miniruby -e'p defined?(itself)' "method" $ ./miniruby -e'p defined?(itself(a))' nil $ ./miniruby -e'p defined?(itself(*a))' "method" ``` Oddly, `defined?` will check contents of arrays, but _won't_ check contents of hashes: ``` $ ./miniruby -e'p defined?([[[[a]]]])' nil $ ./miniruby -e'p defined?({ a => a })' "expression" ``` I think all of the cases that refer to `a` should check whether or not `a` is defined regardless of splats or hashes. -- https://bugs.ruby-lang.org/

11 hours, 17 minutes

3
2
0 0

[ruby-core:115604] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`

by Eregon (Benoit Daloze)

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/

14 hours, 14 minutes

1
0
0 0

[ruby-core:114785] [Ruby master Bug#19886] "default->bundled gem" warning is not shown under "bundle exec"

by mame (Yusuke Endoh)

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/

16 hours, 37 minutes

2
2
0 0

[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)

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/

17 hours, 28 minutes

1
0
0 0

[ruby-core:115594] [Ruby master Bug#20042] ObjectSpace finalizer can cause segfault

by ioquatix (Samuel Williams)

Issue #20042 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20042: ObjectSpace finalizer can cause segfault https://bugs.ruby-lang.org/issues/20042 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby class Finalizer def call # <- missing (id) argument end end object = Object.new ObjectSpace.define_finalizer(object, Finalizer.new) object = nil GC.start # segfaults here ``` -- https://bugs.ruby-lang.org/

18 hours, 48 minutes

2
2
0 0

[ruby-core:115525] [Ruby master Feature#20027] Range Deconstruction

by stuyam (Stuart Yamartino)

Issue #20027 has been reported by stuyam (Stuart Yamartino). ---------------------------------------- Feature #20027: Range Deconstruction https://bugs.ruby-lang.org/issues/20027 * Author: stuyam (Stuart Yamartino) * Status: Open * Priority: Normal ---------------------------------------- Ranges are a powerful tool in ruby. A common range I use is a date range such as `(Date.yesterday..Date.tomorrow)`. A range will often be passed around to methods because the dates hold meaning together such as a timeframe for a table filter. Often I want to grab the original values out of a range like: ```ruby timeframe = (Date.yesterday..Date.tomorrow) start_date = timeframe.begin end_date = timeframe.end #=> start_date = yesterday #=> end_date = today ``` Similar to array and hash deconstruction I thought it would be useful to support range deconstruction like this: ```ruby start_date, end_date = (Date.yesterday..Date.tomorrow) #=> start_date = yesterday #=> end_date = today ``` This would also work for endless or beginless ranges since the beginning and end are just nil in those cases: ```ruby start_date, end_day = ..Date.tomorrow #=> start_date = nil #=> end_date = tomorrow ``` You could do this now using `to_a` like: ```ruby start_date, *middle_dates, end_date = (Date.new(2000,1,1)..Date.new(2023,1,1).to_a ``` However this has unnecessary performance issues by converting the range to an array especially if the range spans a large period, `middle_dates` would hold a very large array. Also if the range resulted in an array with 2 values, `end_date` would be nil and this wouldn't actually work to get the begin and end values. I think this provides a simple interface for a common pattern of deconstructing ranges into their beginning and end values. It would be useful for ranges regardless of date ranges or other types of ranges since they are essentially tuples. Would love to know what others think about this <3 -- https://bugs.ruby-lang.org/

1 day, 2 hours

2
2
0 0

2023

2022

ruby-core ----- 2023 ----- December 2023 November 2023 October 2023 September 2023 August 2023 July 2023 June 2023 May 2023 April 2023 March 2023 February 2023 January 2023 ----- 2022 ----- December 2022 November 2022

ruby-core