January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120514] [Ruby master Misc#21009] Removed old archives from top-level of cache.ruby-lang.org.
by hsbt (Hiroshi SHIBATA) 10 Jan '25

10 Jan '25

Issue #21009 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #21009: Removed old archives from top-level of cache.ruby-lang.org. https://bugs.ruby-lang.org/issues/21009 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- https://cache.ruby-lang.org/pub/ruby/ has `ruby-1.8` to `ruby-2.6` and old versions of snapshot built by 2020. That archives also stored under like `1.8` directory. We can remove them because Ruby 2.6 was already EOL about 3 years ago. Motivation: https://cache.ruby-lang.org/pub/ruby/ shows `ruby-1.8`... list. I thought `ruby-3.4` also stored like `https://cache.ruby-lang.org/pub/ruby/ruby-3.4.1.tar.gz`. But it's nothing. We should avoid that situation. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120589] [Ruby master Feature#8751] Add offsets to method#source_location
by rocky (Rocky Bernstein) 09 Jan '25

09 Jan '25

Issue #8751 has been updated by rocky (Rocky Bernstein). Eregon (Benoit Daloze) wrote in #note-7: > In light of end line and column information being added in #6012 do you think there is still a need for byte offsets? Sure, this is fine. Feel free to close issue. ---------------------------------------- Feature #8751: Add offsets to method#source_location https://bugs.ruby-lang.org/issues/8751#change-111414 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Hello, I would like to have byte offsets returned on the source_location for methods. For example: def foo(&b) b.source_location # => [file_name, line_number, start_byte, end_byte] end If we had the start and end byte for a method or proc, then we could find the source for methods and procs in each file. There are some cases (like with heredocuments) where the "end of the method" could be after the `end` keyword. But I think if we just have offsets for the start of `def` and the end of `end`, I think it would cover 99% of usecases. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120581] [Ruby master Feature#6012] Proc#source_location also return the column
by Dan0042 (Daniel DeLorme) 09 Jan '25

09 Jan '25

Issue #6012 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-25: > Matz was negative neither on adding a new class like Ruby::CodeLocation for this purpose Any idea why? Because it seems like the "obviously correct" design so I'm curious why it was decided against. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111406 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120488] [Ruby master Feature#21005] Update the source location method to include line start/stop and column start/stop details
by bkuhlmann (Brooke Kuhlmann) 09 Jan '25

09 Jan '25

Issue #21005 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/

7 15

[ruby-core:120577] [Ruby master Feature#8751] Add offsets to method#source_location
by Eregon (Benoit Daloze) 09 Jan '25

09 Jan '25

Issue #8751 has been updated by Eregon (Benoit Daloze). In light of end line and column information being added in #6012 do you think there is still a need for byte offsets? ---------------------------------------- Feature #8751: Add offsets to method#source_location https://bugs.ruby-lang.org/issues/8751#change-111404 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Hello, I would like to have byte offsets returned on the source_location for methods. For example: def foo(&b) b.source_location # => [file_name, line_number, start_byte, end_byte] end If we had the start and end byte for a method or proc, then we could find the source for methods and procs in each file. There are some cases (like with heredocuments) where the "end of the method" could be after the `end` keyword. But I think if we just have offsets for the start of `def` and the end of `end`, I think it would cover 99% of usecases. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120576] [Ruby master Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 09 Jan '25

09 Jan '25

Issue #6012 has been updated by Eregon (Benoit Daloze). Great to see this was accepted and even already implemented! (thanks @nobu!) Byte offsets would be mostly for performance ("character" columns in multibyte files can be expensive to compute) and convenience (e.g. read the code at the given source_location from the file). They are not strictly necessary. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111403 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120073] [Ruby master Feature#20925] Allow boolean operators at beginning of line to continue previous line
by Dan0042 (Daniel DeLorme) 09 Jan '25

09 Jan '25

Issue #20925 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20925: Allow boolean operators at beginning of line to continue previous line https://bugs.ruby-lang.org/issues/20925 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- I would like for this to become accepted syntax: condition1 || condition2 condition1 && condition2 condition1 or condition2 condition1 and condition2 This is similar to how method chaining on the second line was added in Ruby 1.9 expr .method And it has the same advantage: when you have a multi-line expression, instead of hunting for the dot or boolean operator at the end of line1, it's right there at the beginning of line2, making the structure very obvious and readable. Please contrast: request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && request.encrypted_cookie_salt.present? && request.use_authenticated_cookie_encryption request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && request.encrypted_cookie_salt.present? && request.use_authenticated_cookie_encryption The first expression must rely on indentation to communicate the multi-line nature of the condition, and even then it's not as immediately obvious as the second expression, where we can see easily and immediately that this is a multi-line `&&` condition. This syntax is also similar to how a trailing comma is allowed in arrays and hashes (and method calls since Ruby 1.9), with the same advantage. It makes for a cleaner diff when you add an element to the array/hash/conditional. Taking the previous example, imagine we are adding the condition `&& request.use_authenticated_cookie_encryption`. Now contrast the diff between the two styles: request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && - request.encrypted_cookie_salt.present? + request.encrypted_cookie_salt.present? && + request.use_authenticated_cookie_encryption request.secret_key_base.present? && request.encrypted_signed_cookie_salt.present? && request.encrypted_cookie_salt.present? + && request.use_authenticated_cookie_encryption Based on the above I would say this syntax is natural and consistent with existing Ruby syntactical elements, and would greatly improve code readability. -- https://bugs.ruby-lang.org/

7 9

[ruby-core:120572] [Ruby master Feature#6012] Proc#source_location also return the column
by mame (Yusuke Endoh) 09 Jan '25

09 Jan '25

Issue #6012 has been updated by mame (Yusuke Endoh). This was discussed at the October 2024 dev meeting and @matz approved `source_location` to return `[path, start_line, start_column, end_line, end_column]`. https://github.com/ruby/dev-meeting-log/blob/28e0f45f334b31e60c7e07d25b6b6c… Matz was negative neither on adding a new class like Ruby::CodeLocation for this purpose, or adding offset information. We briefly re-asked matz about this at today's dev meeting, and he had not changed his mind. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111396 * Author: rogerdpack (Roger Pack) * Status: Assigned * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120397] [Ruby master Bug#20980] Range#size new TypeError vs semi-open ranges
by zverok (Victor Shepelev) 09 Jan '25

09 Jan '25

Issue #20980 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20980: Range#size new TypeError vs semi-open ranges https://bugs.ruby-lang.org/issues/20980 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-24T14:40:12Z master 07e89bde46) +PRISM [x86_64-linux] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- Since #18984, `Range#size` throws `TypeError` if the `begin` is not iterable (doesn't respond to `#succ`). It produces one small inconvenience compared to 3.3: ```ruby ('a'..).size #=> nil (..'a').size # 3.3: nil # 3.4: can't iterate from NilClass (TypeError) -- well, probably makes sense # BUT: (3..).size #=> Infinity -- cool! (..3).size # 3.3: Infinity -- reasonable? # 3.4: can't iterate from NilClass (TypeError) -- worse? ``` I believe that while 3.4's behavior is explainable, 3.3's one has better DX. (Obviously too late to change before the release, but maybe might be considered for some patch version or Ruby 3.5?..) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120350] [Ruby master Bug#20974] Required and optional anonymous parameter show differently in Proc#parameters
by alanwu (Alan Wu) 09 Jan '25

09 Jan '25

Issue #20974 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #20974: Required and optional anonymous parameter show differently in Proc#parameters https://bugs.ruby-lang.org/issues/20974 * Author: alanwu (Alan Wu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following has had the same output since Ruby 1.9, when Proc#parameters was [introduced]: ```ruby p(proc { |(_a)| }.parameters) # => [[:opt, nil]] p(lambda { |(_a)| }.parameters) # => [[:req]] ``` I think they should be `[[:opt]]` and `[[:req]]` or `[[:opt, nil]]` and `[[:req, nil]]`. I prefer the nil-free option since that feels more anonymous. [added]: https://docs.ruby-lang.org/en/master/NEWS/NEWS-1_9_2.html -- https://bugs.ruby-lang.org/

2 2