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

[ruby-core:116269] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by zverok (Victor Shepelev) 17 Jan '24

17 Jan '24

Issue #18576 has been updated by zverok (Victor Shepelev). > Such incompatibility is not acceptable. In all honesty, a selective application of this dogma doesn’t always look justified. For better or worse, we break compatibility constantly. One of the recent telling examples was the removal of `File.exists?` (an alias of `.exist?`), which, while "deprecated a long time ago," actually * broke a lot of gems/other software (because even with the "typically we have bare words as predicates" rule, it was more natural for people to write `exists?`, so while it was available, a _lot_ of code was using it); * improved absolutely nothing in Ruby’s friendliness and learnability save for "removed a reason to ask for `String#starts_with?` and similar methods" (while, say, Rails continues to prefer third-person verbs in its core extensions, like `String#starts_with?` or `Range#overlaps?`) OTOH, renaming the unfortunately named encoding: * makes Ruby friendlier (as a mentor, I saw a _lot_ of people confused with `ASCII-8BIT`), * breaks not a lot of code: while fixing gems wouldn't fix _all_ of its usages, the (minuscule) amount of gems to fix gives a good estimation of how frequently this might be a problem, * breaks code that mostly written in the "unexpected" way, so rethinking it might be a good idea anyway. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106291 * 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:116268] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by byroot (Jean Boussier) 17 Jan '24

17 Jan '24

Issue #18576 has been updated by byroot (Jean Boussier). @naruse no one is denying that there is private code out there that will be broken by such change. The question is how much and how hard it would be to detect and fix, and how much the change improve Ruby for its users. We regularly make changes with much more breaking potential. So that alone isn't a reason to refuse the change in my opinion. But if there is consensus that the cost/benefit isn't positive, then I'd like to propose again: > We could keep Encoding#name as "ASCII-8BIT", but change Encoding#inspect and make sure EncodingError use the BINARY name in its error messages. But slightly modified: I'd like to change `Encoding::BINARY.inspect` from `"#<Encoding:ASCII-8BIT>"` to `"#<Encoding:ASCII-8BIT (BINARY)>"`. Would that be acceptable? ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106290 * 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:116266] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by naruse (Yui NARUSE) 17 Jan '24

17 Jan '24

Issue #18576 has been updated by naruse (Yui NARUSE). Even if you "fix" gems, the number of affected gems insists there are as many as private rails applications. Such incompatibility is not acceptable. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106288 * 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:116190] [Ruby master Feature#20182] Rewrite Array#each in Ruby
by k0kubun (Takashi Kokubun) 16 Jan '24

16 Jan '24

Issue #20182 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Feature #20182: Rewrite Array#each in Ruby https://bugs.ruby-lang.org/issues/20182 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- ## Proposal Rewrite Array#each in Ruby https://github.com/ruby/ruby/pull/6687. ```rb class Array def each unless block_given? return to_enum(:each) { self.length } end i = 0 while i < self.length yield self[i] i = i.succ end self end end ``` ## Purpose Make it possible for YJIT to optimize ISEQs across `Array#each`. ## Background Whether JIT-compiled or not, calling Ruby from C is more expensive than calling Ruby from Ruby. It also prevents YJIT from making cross-ISEQ optimizations. This is problematic especially for loop methods written in C like `Array#each` since the overhead is repeated at every iteration. ## Discussions There are a couple of things I'd like to discuss in this ticket: 1. @Eregon has pointed out that there's a race condition in the above implementation. `self[i]` would yield `nil` if the element was removed by another thread or TracePoint after `i < self.length`. Is it `Array#each`'s responsibility to atomically operate on elements, or are users supposed to avoid mutating the array in the middle of its loop? 2. If `Integer#<`, `Integer#length`, `Integer#succ`, or `Array#[]` is overridden in an incompatible way, the Ruby implementation may not work correctly. May I assume it's acceptable? -- https://bugs.ruby-lang.org/

4 4

[ruby-core:116203] [Ruby master Bug#20185] String#ascii_only? buggy in ruby 3.3
by chucke (Tiago Cardoso) 16 Jan '24

16 Jan '24

Issue #20185 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #20185: String#ascii_only? buggy in ruby 3.3 https://bugs.ruby-lang.org/issues/20185 * Author: chucke (Tiago Cardoso) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This was the smallest reduction of the bug I could come up with: require "stringio" puts StringIO::VERSION def is_ascii(buffer) str = buffer.string puts "\"#{str}\" is ascii: #{str.ascii_only?}" end buffer = StringIO.new("".b) buffer.write("a=b&c=d") buffer.rewind is_ascii(buffer) buffer.write "богус" is_ascii(buffer) # in ruby 3.3 #=> 3.1.0 #=> "a=b&c=d" is ascii: true #=> "богус" is ascii: true # in ruby 3.2 #=> 3.0.4 #=> "a=b&c=d" is ascii: true #=> "богус" is ascii: true # in ruby 3.1 #=> 3.0.1 #=> "a=b&c=d" is ascii: true #=> "богус" is ascii: false I believe that only the 3.1 result is correct, as "богус" first character is not ascii. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:116226] [Ruby master Bug#20189] `rb_str_resize` does not clear coderange when expanding
by tompng (tomoya ishida) 16 Jan '24

16 Jan '24

Issue #20189 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20189: `rb_str_resize` does not clear coderange when expanding https://bugs.ruby-lang.org/issues/20189 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2024-01-09T07:07:19Z master db476cc71c) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Expanding string in some encoding (utf16 utf32) can change coderange to either valid or broken, but rb_str_resize does not clear coderange. This will cause a bug in c-extension libraries that use rb_str_resize. ~~~ruby # Example for stringio s = StringIO.new("\0".encode('UTF-16LE')) s.truncate(1); s.truncate(2); s.string.valid_encoding? #=> true s.truncate(1); s.string.valid_encoding?; s.truncate(2); s.string.valid_encoding? #=> false (expect to be true) ~~~ -- https://bugs.ruby-lang.org/

4 5

[ruby-core:116236] [Ruby master Feature#18057] Introduce Array#mean
by matheusrich (Matheus Richard) 16 Jan '24

16 Jan '24

Issue #18057 has been updated by matheusrich (Matheus Richard). Was this proposal rejected? ---------------------------------------- Feature #18057: Introduce Array#mean https://bugs.ruby-lang.org/issues/18057#change-106257 * Author: ggmichaelgo (Michael Go) * Status: Open * Priority: Normal ---------------------------------------- Introduce Array#average to calculate the average value of an array. ```ruby array = [1, 2, 3] array.mean # 2 array = [1.5, 2.2, 3.1] array.mean(&:round) # 2.3333333333333335 array = [-3, -2, -1] array.mean { |e| e.abs } # 2 ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116233] [Ruby master Bug#14607] Fix use of the rb_profile_frames start parameter
by dylants (Dylan Thacker-Smith) 16 Jan '24

16 Jan '24

Issue #14607 has been updated by dylants (Dylan Thacker-Smith). > The original patch has a merge conflict. However, I have opened a pull request with the fix for this issue (https://github.com/ruby/ruby/pull/2713) that has been rebased to resolve the merge conflict. The github PR has been merged, so this issue can be closed now. It doesn't look like I have permission to change its status though. ---------------------------------------- Bug #14607: Fix use of the rb_profile_frames start parameter https://bugs.ruby-lang.org/issues/14607#change-106253 * Author: dylants (Dylan Thacker-Smith) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- rb_profile_frames was always behaving as if the value given for the start parameter was 0. The reason for this was that it would check `if (start > 0) {` then `continue` without updating the control frame pointer or anything other than decrementing `start`. This bug applies to all branches under normal maintenance, from ruby 2.3 to trunk. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116232] [Ruby master Bug#5179] Complex#rationalize and to_r with approximate zeros
by mrkn (Kenta Murata) 16 Jan '24

16 Jan '24

Issue #5179 has been updated by mrkn (Kenta Murata). `Complex(re, im.to_r).to_r` looks good to me if `im` is not `0` or `0r`. `Complex(re, im.to_i).to_i` is also OK for me in the same manner. `Complex(re, im.to_f).to_f` cannot resolve the problem the current `to_f` holds. I don't have other ideas to resolve this right now. I don't think we can discuss `**` along with `to_r` because `**` is not type conversion. ---------------------------------------- Bug #5179: Complex#rationalize and to_r with approximate zeros https://bugs.ruby-lang.org/issues/5179#change-106251 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) * ruby -v: r32354 ---------------------------------------- Currently, Complex#rationalize and Complex#to_r raise a RangeError if the imaginary part is nonzero *or is a Float*. Note that a BigDecimal(0) is accepted, though: Complex(1, 0).to_r # => Rational(1,1) Complex(1, BigDecimal("0.0")).to_r # => Rational(1,1) Complex(1, 0.0).to_r # => RangeError This is inconsistent. I recommend not raising an error for 0.0 (Float or BigDecimal). Any objection? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116084] [Ruby master Feature#20164] Add Exception#deconstruct_keys
by Dan0042 (Daniel DeLorme) 15 Jan '24

15 Jan '24

Issue #20164 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20164: Add Exception#deconstruct_keys https://bugs.ruby-lang.org/issues/20164 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- It would be convenient to perform pattern matching with exception classes. So `Exception#deconstruct_keys` should return a hash with `:message` (original_message) as well as any other keys specific to the exception subclass. Examples: ``` begin #code rescue => err case err in StandardError(message: /Permission denied/) abort "please select a different file" in NameError(name: :foo) retry if require "foo_helper else raise end end ``` -- https://bugs.ruby-lang.org/

2 2