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

[ruby-core:111386] [Ruby master Bug#19252] IO::Buffer.pread last argument is always ignored?
by zverok (Victor Shepelev) 24 Dec '22

24 Dec '22

Issue #19252 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19252: IO::Buffer.pread last argument is always ignored? https://bugs.ruby-lang.org/issues/19252 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I am trying to document new `IO::Buffer#pread` and `#pwrite` methods. According to what I can guess from code and tests, this code: ```ruby IO::Buffer.for('teststring') do |buffer| buffer.pread(File.open('/dev/urandom', 'rb'), 0, 2, 3) p buffer.get_string end ``` ...is expected to read **2** chars from `/dev/urandom`, starting from **0**th char, and write it to buffer starting from its **3**rd byte. Actual output: ``` "F\x94ststring" ``` E.g. two first chars of the buffer are replaced. Am I missing something, or is it a legitimate bug?.. UPD: Seems the same for `pwrite`: ```ruby IO::Buffer.for('1234567').pwrite(File.open('tmp/buf.txt', 'wb'), 0, 2, 3) # expected to write "45" to file `cat tmp/buf.txt` # => "12" ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:111415] [Ruby master Feature#18181] Introduce Enumerable#min_with_value, max_with_value, and minmax_with_value
by sawa (Tsuyoshi Sawada) 24 Dec '22

24 Dec '22

Issue #18181 has been updated by sawa (Tsuyoshi Sawada). Related to #17097 ---------------------------------------- Feature #18181: Introduce Enumerable#min_with_value, max_with_value, and minmax_with_value https://bugs.ruby-lang.org/issues/18181#change-100787 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- PR is https://github.com/ruby/ruby/pull/4874 I propose `Enumerable#min_with_value`, `max_with_value` and `minmax_with_value`. These methods work like this: ``` ruby %w(abcde fg hijk).min_with_value { |e| e.size } # => ['fg', 2] %w(abcde fg hijk).max_with_value { |e| e.size } # => ['abcde', 5] %w(abcde fg hijk).minmax_with_value { |e| e.size } # => [['fg', 2], ['abcde', 5]] ``` Corresponding to `#min(n)`, an integer argument can be passed to `#min_with_value` or `#max_with_value`. ``` ruby %w(abcde fg hijk).min_with_value(2) { |e| e.size } # => [['fg', 2], ['hijk', 4]] %w(abcde fg hijk).max_with_value(2) { |e| e.size } # => [['abcde', 5], ['hijk', 4]] ``` ## Motivation When I use `Enumerable#min_by`, I sometimes want to get not only the minimum element but also the value from the given block. (e.g.: There are many points. Find the nearest point and get distance to it.) ``` ruby elem = enum.min_by { |e| foo(e) } value = foo(elem) ``` This works, but I'd like to avoid writing foo() twice. (Consider a more complex case.) This can be written without repeated foo() like belows, but it is slightly complicated and needs extra arrays. ``` ruby value, elem = enum.map { |e| [foo(e), e] }.min_by(&:first) ``` If the size of enum is enormous, it is hard to use intermediate arrays. `Enumerable#min_with_value` solves this problem. I think `min_with_value` is the best name I could think of, but any suggestions for better names would be appreciated. ## Benchmark https://bugs.ruby-lang.org/issues/18181#note-2 ## Example Solving a traveling salesman problem in nearest neighbor algorithm. ``` ruby require 'set' Point = Struct.new(:x, :y) points = Set.new([Point.new(1, 1), Point.new(2, 4), Point.new(3, 3), Point.new(2, 2), Point.new(0, 1)]) total = 0 current = points.first points.delete(current) path = [current] until points.empty? current, distance = points.min_with_value do |point| Math.hypot(current.x - point.x, current.y - point.y) end total += distance points.delete(current) path << current end p path p total ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111406] [Ruby master Feature#17097] `map_min`, `map_max`
by Eregon (Benoit Daloze) 23 Dec '22

23 Dec '22

Issue #17097 has been updated by Eregon (Benoit Daloze). IMHO we should just add `max_of` and `min_of`, like Crystal has. `map` in the name feels out of place here because this method does not return a new array, it's just execute the block and remember the max/min value returned by the block for all elements. ---------------------------------------- Feature #17097: `map_min`, `map_max` https://bugs.ruby-lang.org/issues/17097#change-100778 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- `min`, `min_by`, `max`, `max_by` return the element that leads to the minimum or the maximum value, but I think it is as, or even more, frequent that we are interested in the minimum or the maximum value itself rather than the element. For example, to get the length of the longest string in an array, we do: ```ruby %w[aa b cccc dd].max_by(&:length).length # => 4 %w[aa b cccc dd].map(&:length).max # => 4 ``` I propose to have methods that return the minimum or the maximum value. Temporarily calling them `map_min`, `map_max`, they should work like this: ```ruby %w[aa b cccc dd].map_max(&:length) # => 4 ``` `map_min`, `map_max` are implementation-centered names, so perhaps better names should replace them, just like `yield_self` was replaced by `then`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111391] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array
by sawa (Tsuyoshi Sawada) 23 Dec '22

23 Dec '22

Issue #11064 has been updated by sawa (Tsuyoshi Sawada). Thank you, Matz for answering my question. > Singleton classes are in principle only accessed using the singleton_class method or the singleton class notation. Since we already have the following results, ```ruby nil.singleton_class # => NilClass class << nil; self; end # => NilClass ``` the crucial part is that they should be the **only** way to access, if `NilClass` were to be a singleton class. So in short, the fact that it can be accessed directly through the name `NilClass` seems to be what is avoiding it from being a singleton class. > Implementation wise, FL_SINGLETON is set for singleton classes. Thank you for letting me know about it. But I do not think Ruby users should need to worry too much about its implementation details. From the point of view of a user, that should be irrelevant for whether calling a class a singleton class or not. To summarize, it seems that just because `NiClass` has its name as a constant, it cannot be regarded as a singleton class. I now understand how the distinction is made currently, but I do not think it makes sense. I might make a feature request to get rid of this distinction. ---------------------------------------- Bug #11064: #singleton_methods for objects with special singleton_class returns an empty array https://bugs.ruby-lang.org/issues/11064#change-100766 * Author: rbjl (Jan Lelis) * Status: Open * Priority: Normal * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- ~~~ def nil.bla 42 end # works nil.bla #=> 42 nil.singleton_method(:bla) #=> #<Method: NilClass#bla> NilClass.instance_methods.include? :bla #=> true # does not work nil.singleton_methods #=> [] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111390] [Ruby master Feature#17097] `map_min`, `map_max`
by baweaver (Brandon Weaver) 23 Dec '22

23 Dec '22

Issue #17097 has been updated by baweaver (Brandon Weaver). For the sake of naming conventions I would personally lean towards `map_max` to match methods like `filter_map`, and while this does not necessarily extend to _all_ Enumerable methods I would wonder if there's another conversation later to be had about composite Enumerable methods. On this particular ticket though I believe that the use-case is common enough, and in many cases may be what the developer intends. ---------------------------------------- Feature #17097: `map_min`, `map_max` https://bugs.ruby-lang.org/issues/17097#change-100765 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- `min`, `min_by`, `max`, `max_by` return the element that leads to the minimum or the maximum value, but I think it is as, or even more, frequent that we are interested in the minimum or the maximum value itself rather than the element. For example, to get the length of the longest string in an array, we do: ```ruby %w[aa b cccc dd].max_by(&:length).length # => 4 %w[aa b cccc dd].map(&:length).max # => 4 ``` I propose to have methods that return the minimum or the maximum value. Temporarily calling them `map_min`, `map_max`, they should work like this: ```ruby %w[aa b cccc dd].map_max(&:length) # => 4 ``` `map_min`, `map_max` are implementation-centered names, so perhaps better names should replace them, just like `yield_self` was replaced by `then`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111389] [Ruby master Bug#19113] Inconsistency in retention of compare_by_identity flag in Hash methods
by matz (Yukihiro Matsumoto) 23 Dec '22

23 Dec '22

Issue #19113 has been updated by matz (Yukihiro Matsumoto). I agree with @jeremyevans0 too. Matz. ---------------------------------------- Bug #19113: Inconsistency in retention of compare_by_identity flag in Hash methods https://bugs.ruby-lang.org/issues/19113#change-100764 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-11-07T17:29:28Z master 9001e53e68) [x86_64-openbsd7.2] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- `Hash.[]` and `Hash.ruby2_keywords_hash` retain the compare_by_identity flag for non-empty hashes, but do not retain it for empty hashes: ```ruby hs = [{}.compare_by_identity, {:a=>1}.compare_by_identity] hs.map{|h| Hash[h].compare_by_identity?} # => [false, true] hs.map{|h| Hash.ruby2_keywords_hash(h).compare_by_identity?} # => [false, true] ``` This inconsistency seems like a bug. `Hash#compact` always drops the compare_by_identity flag, but it is documented as returning a copy of self, implying the compare_by_identity flag is kept (since #dup and #clone retain the flag). ```ruby {}.compare_by_identity.compact.compare_by_identity? # => false ``` I'm not sure whether is a bug, because it is consistent, but I think retaining the flag makes more sense. I'll try to work on a fix for both of these issues tomorrow. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111388] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array
by matz (Yukihiro Matsumoto) 23 Dec '22

23 Dec '22

Issue #11064 has been updated by matz (Yukihiro Matsumoto). @sawa Singleton classes are in principle only accessed using the `singleton_class` method or the singleton class notation. Implementation wise, FL_SINGLETON is set for singleton classes. Neither is true for NilClass (nor FalseClass nor TrueClass). Matz. ---------------------------------------- Bug #11064: #singleton_methods for objects with special singleton_class returns an empty array https://bugs.ruby-lang.org/issues/11064#change-100763 * Author: rbjl (Jan Lelis) * Status: Open * Priority: Normal * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- ~~~ def nil.bla 42 end # works nil.bla #=> 42 nil.singleton_method(:bla) #=> #<Method: NilClass#bla> NilClass.instance_methods.include? :bla #=> true # does not work nil.singleton_methods #=> [] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111387] [Ruby master Feature#17097] `map_min`, `map_max`
by jnchito (Junichi Ito) 23 Dec '22

23 Dec '22

Issue #17097 has been updated by jnchito (Junichi Ito). `max_of` method is very elegant! I really want the Ruby version of this method. For example, I need to write `column_width = @ls_files.map { |ls_file| ls_file.name.size }.max` to determine column width according to the longest file name (in the image below, it would be 19 because "credentials.yml.enc" is the longest, and see also [this](https://github.com/JunichiIto/ruby-practices/pull/2/files#diff-50ea26…) ![sample](https://user-images.githubusercontent.com/1148320/209256935-e849003a-1ac1-4244-a4c8-d21cb53aa5c5.png) I'd be pretty if I could write `column_width = @ls_files.max_of { |ls_file| ls_file.name.size }` . ---------------------------------------- Feature #17097: `map_min`, `map_max` https://bugs.ruby-lang.org/issues/17097#change-100762 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- `min`, `min_by`, `max`, `max_by` return the element that leads to the minimum or the maximum value, but I think it is as, or even more, frequent that we are interested in the minimum or the maximum value itself rather than the element. For example, to get the length of the longest string in an array, we do: ```ruby %w[aa b cccc dd].max_by(&:length).length # => 4 %w[aa b cccc dd].map(&:length).max # => 4 ``` I propose to have methods that return the minimum or the maximum value. Temporarily calling them `map_min`, `map_max`, they should work like this: ```ruby %w[aa b cccc dd].map_max(&:length) # => 4 ``` `map_min`, `map_max` are implementation-centered names, so perhaps better names should replace them, just like `yield_self` was replaced by `then`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111220] [Ruby master Bug#19187] Ruby 3.1.3 testsuite fails after timezone 2022g update is applied
by coolo (Stephan Kulow) 22 Dec '22

22 Dec '22

Issue #19187 has been reported by coolo (Stephan Kulow). ---------------------------------------- Bug #19187: Ruby 3.1.3 testsuite fails after timezone 2022g update is applied https://bugs.ruby-lang.org/issues/19187 * Author: coolo (Stephan Kulow) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux-gnu] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The timezone database changed incompatible to what ruby's testsuite expects. See the announcement here: http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html and note the little detail Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Problem is that test/ruby/test_time_tz.rb tests this very detail in 3 places - and breaks. 1) Failure: TestTimeTZ#test_asia_singapore [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:143]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 2) Failure: TestTimeTZ#test_gen_Asia_Singapore_22 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:382]: TZ=Asia/Singapore Time.utc(1981, 12, 31, 16, 29, 59).localtime. <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. 3) Failure: TestTimeTZ#test_gen_Asia_Singapore_45 [/home/abuild/rpmbuild/BUILD/ruby-3.1.3/test/ruby/test_time_tz.rb:400]: TZ=Asia/Singapore Time.local(1981, 12, 31, 23, 59, 59). <"1981-12-31 23:59:59 +0730"> expected but was <"1982-01-01 00:29:59 +0800">. I can see no other option than not to test this detail - because relying on correct timezone data (either way) is barely possible. -- https://bugs.ruby-lang.org/

7 10

[ruby-core:111381] [Ruby master Bug#19251] Limit amount of test failures due to updates of tzdata
by vo.x (Vit Ondruch) 22 Dec '22

22 Dec '22

Issue #19251 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19251: Limit amount of test failures due to updates of tzdata https://bugs.ruby-lang.org/issues/19251 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- It seems that recently, Ruby test suite is broken ~ twice a year due to changes in tzdata. I am not sure how detailed the test suite needs to be to have the right amount of test coverage, but it would be nice if Ruby developers had more control above this changes then this changes being forced upon us via OS update. This is followup to #19187. BTW with my Fedora / RHEL maintainer hat on, this is a bit annoying, because: 1) It tends to hide other issues 2) In Fedora, it might block other development 3) Especially in RHEL, where there is not so big churn, it is unpleasant to start work on fixing CVE just to discover one needs to fix the tzdata test failures first -- https://bugs.ruby-lang.org/

1 0