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

[ruby-core:115030] [Ruby master Bug#18903] Stack overflow signal handling seems to be triggered once and then not working after
by mame (Yusuke Endoh) 13 Oct '23

13 Oct '23

Issue #18903 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. @nobu said he would investigate if he could fix it with M2. Recovering from a stack overflow in C is not portable and complete, but it is a fact that they work almost well in Linux, which is the main production environment. If we make it a fatal error that cannot be rescued normally, it might impact on users of Rails apps, job queues like Sidekiq, etc. ---------------------------------------- Bug #18903: Stack overflow signal handling seems to be triggered once and then not working after https://bugs.ruby-lang.org/issues/18903#change-104901 * Author: chrisseaton (Chris Seaton) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- This program creates a recursive object graph and then tries to convert it to JSON with no max depth, so it stack overflows in C code that does no co-operative stack overflow checks, as the bytecode interpreter would. This therefore triggers a segmentation fault and the stack overflow detection there. It works the first time, but the second time around it doesn't and the program hard crashes on M1. Is there something like a guard page permission that is switched during the handling, and needs to switched back for the guard page to work again? Note that it isn't JSON specific - I think any stack overflow within C code would do it. ```ruby require 'json' a = [] a << a begin JSON.dump(a) rescue Exception puts 'rescued' end JSON.dump(a) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114661] [Ruby master Bug#19866] Future of `readline.rb`
by vo.x (Vit Ondruch) 13 Oct '23

13 Oct '23

Issue #19866 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19866: Future of `readline.rb` https://bugs.ruby-lang.org/issues/19866 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-05 master 7c8932365f) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I wonder what is the future of readline.rb? It still tries to load `readline.so` by default. Is this intended behavior? I'd say that instead, it should rather fire a deprecation warning and load reline. Or maybe the whole readline gem should be completely removed? -- https://bugs.ruby-lang.org/

5 5

[ruby-core:115012] [Ruby master Feature#13933] Add Range#empty?
by matz (Yukihiro Matsumoto) 12 Oct '23

12 Oct '23

Issue #13933 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected One drawback of `Range#empty?` is that we have several corner cases that cannot determine emptiness correctly (e.g., regarding exclude_end ranges or infinity). Upon the fact we don't see the real-world use-case yet, we reject the proposal for the moment. FYI, `Range#overlap?` has similar corner cases, it's better to document clearly somewhere. Matz. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104882 * Author: ted (Ted Johansson) * Status: Rejected * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115011] [Ruby master Feature#18515] Add Range#reverse_each implementation
by matz (Yukihiro Matsumoto) 12 Oct '23

12 Oct '23

Issue #18515 has been updated by matz (Yukihiro Matsumoto). I accept this as a performance improvement. Matz. ---------------------------------------- Feature #18515: Add Range#reverse_each implementation https://bugs.ruby-lang.org/issues/18515#change-104881 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- PR is ~~https://github.com/ruby/ruby/pull/5489~~ https://github.com/ruby/ruby/pull/8525 Current `Range#reverse_each` uses `Enumerable#reverse_each` which is implemented with `#to_a`. So we are virtually not able to use `reverse_each` for a very large or beginless range, even if few elements are iterated on actually. ``` (1..2**100).reverse_each { |x| p x; break if x.odd? } (..5).reverse_each { |x| p x; break if x == 0 } (1..2**32).reverse_each.lazy.select { |x| Prime.prime?(x) }.take(3).to_a ``` This patch, implements `Range#reverse_each` for Integer elements, enables these examples. I think `#reverse_each` for an endless range should raise an exception. This is a different issue, so I'll create another ticket later. -> posted: https://bugs.ruby-lang.org/issues/18551 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115010] [Ruby master Bug#16927] String#tr won't return the expected result for some sign with diacritics
by naruse (Yui NARUSE) 12 Oct '23

12 Oct '23

Issue #16927 has been updated by naruse (Yui NARUSE). As nobu says, since String#tr is for codepoints, so this proposal is rejected. Maybe though a dedicated method for this use case can be reasonable, the current use case is not enough to design it. ---------------------------------------- Bug #16927: String#tr won't return the expected result for some sign with diacritics https://bugs.ruby-lang.org/issues/16927#change-104878 * Author: psychoslave (mathieu lovato stumpf guntz) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- # Context Not much interest for the bug here, but I always appreciate to be given more context. So, as part of a larger project, I needed to utter every number from zero to 255 with a single syllable written as a consonant-vowel-consonant (CVC) in IPA. To avoid ambiguity, the nomenclature should not collide with existing numerical terms like "six" and "ten" in any language for which the documentation was found. As it was not enough nerdy, I came with the idea to mark with diacritics primes and congruence with 2, 8, 12, 16 (optionally and without intended phonological alteration though). If you are curious about it, you can look at [the algorithm](https://gitlab.com/psychoslave/isotopy/-/blob/master/tool/combin… I used to build the nomenclature matching [the specification](https://gitlab.com/psychoslave/isotopy/-/issues/4). # Code to reproduce the bug ``` ruby #!/bin/env ruby translated = 'aeiou'.tr('aeiou', 'ą̂ę̂į̂ǫ̂ų̂') substitued = 'aeiou'.sub(/aeiou/, 'ą̂ę̂į̂ǫ̂ų̂') puts `ruby -v`, translated == substitued, translated, substitued # Actual result ``` On my box, this outputs: ``` ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux] false ą̂ę̂į ą̂ę̂į̂ǫ̂ų̂ ``` # Expected result `tr` should return a congruent result: either it should fail for all signs with similar diacritics, or (preferably) return the specified Unicode glyph. That is, in the code above, `translated == substitued` should be `true`. # Remarks I am not a Unicode Guru: maybe the missing signs generating the difference comes from the way they are encoded. I am aware that some glyphs come in duplicates: as solo code points vs. combined code point sequences. However I'm cannot tell if the above code uses a mixture of both. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115003] [Ruby master Bug#19919] Variable assignments in condition are warned however class variable assignment and constant declaration are not warned
by yui-knk (Kaneko Yuichiro) 12 Oct '23

12 Oct '23

Issue #19919 has been reported by yui-knk (Kaneko Yuichiro). ---------------------------------------- Bug #19919: Variable assignments in condition are warned however class variable assignment and constant declaration are not warned https://bugs.ruby-lang.org/issues/19919 * Author: yui-knk (Kaneko Yuichiro) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Is it better to warn for class variable assignment and constant declaration in condition? ```ruby (x, y = 1, 2) ? x : y # test.rb:1: warning: found `= literal' in conditional, should be == if a = 1 # test.rb:3: warning: found `= literal' in conditional, should be == end b = 1 1.times do if b = 2 # test.rb:8: warning: found `= literal' in conditional, should be == end end if $a = 1 # test.rb:12: warning: found `= literal' in conditional, should be == end if @a = 1 # test.rb:15: warning: found `= literal' in conditional, should be == end class A if @@a = 1 # no warning end end if B = 1 # no warning end ``` I use `ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7)`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115008] [Ruby master Feature#5825] Sweet instance var assignment in the object initializer
by matheusrich (Matheus Richard) 12 Oct '23

12 Oct '23

Issue #5825 has been updated by matheusrich (Matheus Richard). Maybe a different proposal, but if the `def initialize(@a, @b)` is ugly, how about a new method similar to `attr_{reader,writter}` like ```rb class User init_with :name, :age # or maybe attributes :name, :age end User.new("Matz", 21) ``` We could even have an option like `keyword_init: true` for keyword args. On the other hand, a simple alternative is using the new `Data` class, which already provides this nicety: ```rb User = Data.define(:name, :age) User.new("matz", 21) # or User.new(name: "matz", age: 21) ``` ---------------------------------------- Feature #5825: Sweet instance var assignment in the object initializer https://bugs.ruby-lang.org/issues/5825#change-104875 * Author: goshakkk (Gosha Arinich) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- I'm very excited about this feature in CoffeeScript, and think it might be a nice-to-have thing in Ruby 2.0. That's how I think it would look like: ~~~ruby class Me def initialize(@name, @age, @location); end end ~~~ So we can declare `@variable`s in the initializer method parameters definition to avoid assigning instance variables from method arguments by hand, like: ~~~ruby class Me def initialize(name, age, location) @name = name @age = age @location = location end end ~~~ Want to hear what do you guys think, does that feature worth being included in 2.0? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114773] [Ruby master Misc#19883] DevMeeting-2023-10-12
by mame (Yusuke Endoh) 11 Oct '23

11 Oct '23

Issue #19883 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19883: DevMeeting-2023-10-12 https://bugs.ruby-lang.org/issues/19883 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/10/12 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/10/09. 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/

6 5

[ruby-core:115002] [Ruby master Feature#16294] Make MatchData frozen and forbid MatchData.allocate
by Eregon (Benoit Daloze) 11 Oct '23

11 Oct '23

Issue #16294 has been updated by Eregon (Benoit Daloze). Looks good, I think we should merge it. (and this is already the case on TruffleRuby) ---------------------------------------- Feature #16294: Make MatchData frozen and forbid MatchData.allocate https://bugs.ruby-lang.org/issues/16294#change-104870 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal ---------------------------------------- Currently, `MatchData.allocate` is allowed, but almost every MatchData method called on it `raise TypeError, 'uninitialized Match'`. I think MatchData should be frozen, none of its internal fields are mutable and I don't see any use case for storing instance variables on it. Once frozen, we can implement MatchData#dup and #clone as just `return self`, and we don't need to check for the uninitialized case. And Marshal can have special treatment to create an initialized MatchData directly. My main motivation is looking at the code in TruffleRuby required to implement `MatchData.allocate` and check if it's initialized in so many places: https://github.com/oracle/truffleruby/pull/1792/files Thoughts? Anyone against? cc @alanwu -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115000] [Ruby master Feature#16294] Make MatchData frozen and forbid MatchData.allocate
by nobu (Nobuyoshi Nakada) 11 Oct '23

11 Oct '23

Issue #16294 has been updated by nobu (Nobuyoshi Nakada). I've forgot this for years, and just happened to discover this branch. https://github.com/ruby/ruby/pull/8624 ---------------------------------------- Feature #16294: Make MatchData frozen and forbid MatchData.allocate https://bugs.ruby-lang.org/issues/16294#change-104868 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal ---------------------------------------- Currently, `MatchData.allocate` is allowed, but almost every MatchData method called on it `raise TypeError, 'uninitialized Match'`. I think MatchData should be frozen, none of its internal fields are mutable and I don't see any use case for storing instance variables on it. Once frozen, we can implement MatchData#dup and #clone as just `return self`, and we don't need to check for the uninitialized case. And Marshal can have special treatment to create an initialized MatchData directly. My main motivation is looking at the code in TruffleRuby required to implement `MatchData.allocate` and check if it's initialized in so many places: https://github.com/oracle/truffleruby/pull/1792/files Thoughts? Anyone against? cc @alanwu -- https://bugs.ruby-lang.org/

1 0