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

[ruby-core:118976] [Ruby master Bug#20704] Windows: `-C` option does not work for multibyte path name
by nobu (Nobuyoshi Nakada) 08 Nov '24

08 Nov '24

Issue #20704 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20704: Windows: `-C` option does not work for multibyte path name https://bugs.ruby-lang.org/issues/20704 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Related to [Bug #20699]. ``` C:> \Ruby33-x64\bin\ruby.exe -C xテスト_test -ep \Ruby33-x64\bin\ruby.exe: Can't chdir to xテスト_test (fatal) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:119495] [Ruby master Feature#20792] String#forcible_encoding?
by kddnewton (Kevin Newton) 08 Nov '24

08 Nov '24

Issue #20792 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20792: String#forcible_encoding? https://bugs.ruby-lang.org/issues/20792 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to add a method to String called `forcible_encoding?(encoding)`. This would return true or false depending on whether the receiver can be forced into the given encoding without breaking the string. It would effectively be an alias for: ```ruby def forcible_encoding?(enc) original = encoding result = force_encoding(enc).valid_encoding? force_encoding(original) result end ``` I would like this method because there are extremely rare but possible circumstances where source files are marked as binary but contain UTF-8-encoded characters. In that case I would like to check if it's possible to cleanly force UTF-8 before actually doing it. The code I'm trying to replace is here: https://github.com/ruby/prism/blob/d6e9b8de36b4d18debfe36e4545116539964ceeb…. The pull request for the code is here: https://github.com/ruby/ruby/pull/11851. -- https://bugs.ruby-lang.org/

7 15

[ruby-core:119602] [Ruby master Feature#20811] `warning: in a**b, b may be too big` is really helpful?
by mame (Yusuke Endoh) 08 Nov '24

08 Nov '24

Issue #20811 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #20811: `warning: in a**b, b may be too big` is really helpful? https://bugs.ruby-lang.org/issues/20811 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I tried to calculate the largest prime number recently discovered. However, it did not work. I was a bit disappointed. ``` $ ruby -e 'p 2**136279841-1' -e:1: warning: in a**b, b may be too big Infinity ``` I know this is not a realistic case, but I checked my past chat logs and found a record of the same thing six years ago and the same disappointment. ``` $ ruby -e 'p 2**77232917-1' -e:1: warning: in a**b, b may be too big Infinity ``` So I would like to ask, has anyone experienced that this behavior has actually been helpful? I think that this limit is to prevent a program from unintentionally spending too much time and memory trying to compute a power that is too large. However, is it helpful to return Infinity in such a situation? I think raising an exception would be safer, if this limit is really needed. Also, is this limit appropriate? On my machine, `2 ** 32537661` is calculated normally and `2 ** 32537662` returns Infinity. This calculation took about 100 ms and 400 kB. I think this is short enough for a single computation time. Incidentally, `2 ** 32537661` in decimal notation is 9,794,814 digits, which may be too loose a limit considering the display. Note that this limit only applies when calculating the power directly. `(2 ** 32537661) * 2` returns an Integer, not Infinity. Even `1 << 32537662` gives an Integer. From the above, I suspect that this limit is not particularly useful and only spoils the fun of mathematics. What do you think? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119575] [Ruby master Bug#20808] Cannot override Data#inspect
by maicolben (Maicol Bentancor) 07 Nov '24

07 Nov '24

Issue #20808 has been reported by maicolben (Maicol Bentancor). ---------------------------------------- Bug #20808: Cannot override Data#inspect https://bugs.ruby-lang.org/issues/20808 * Author: maicolben (Maicol Bentancor) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Given the next code: ``` Dog = Data.define(:name) do def inspect "Hello!" end private attr_reader :name end Dog.new(name: "Fido") ``` It throws an error: - An error occurred when inspecting the object: #<NoMethodError: private method `name' called for an instance of Dog> And isn't using my `inspect` function -- https://bugs.ruby-lang.org/

3 7

[ruby-core:119650] [Ruby master Bug#20857] Don't change `Hash#inspect formatting`
by vo.x (Vit Ondruch) 07 Nov '24

07 Nov '24

Issue #20857 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20857: Don't change `Hash#inspect formatting` https://bugs.ruby-lang.org/issues/20857 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-15 master 3da3cabf98) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Testing Ruby 3.4 in Fedora, I just hit issue like this in AsciiDoctor test suite: ~~~ 1) Failure: Minitest::Test::TestExtensions::TestIntegration#test_should_assign_captures_correctly_for_inline_macros [test/extensions_test.rb:1382]: --- expected +++ actual @@ -1,9 +1,9 @@ "target=\"\", attributes={} -target=\"value,key=val\", attributes={1=>\"value\", \"key\"=>\"val\", \"name\"=>\"value\"} -target=\"\", attributes={\"text\"=>\"\"} -target=\"[text]\", attributes={\"text\"=>\"[text]\"} +target=\"value,key=val\", attributes={1 => \"value\", \"key\" => \"val\", \"name\" => \"value\"} +target=\"\", attributes={\"text\" => \"\"} +target=\"[text]\", attributes={\"text\" => \"[text]\"} target=\"target\", attributes={} -target=\"target\", attributes={1=>\"value\", \"key\"=>\"val\", \"name\"=>\"value\"} -target=\"target\", attributes={\"text\"=>\"\"} -target=\"target\", attributes={\"text\"=>\"[text]\"} +target=\"target\", attributes={1 => \"value\", \"key\" => \"val\", \"name\" => \"value\"} +target=\"target\", attributes={\"text\" => \"\"} +target=\"target\", attributes={\"text\" => \"[text]\"} target=\"target\", attributes={}" ~~~ This suggest that `Hash#inspect` formatting was changed and there are additional spaces around hash rocket. Is the space really worth of the troubles? BTW [here](https://github.com/asciidoctor/asciidoctor/issues/4634#issuecomment-2… is AsciiDoctor upstream reaction and I share the sentiment. -- https://bugs.ruby-lang.org/

8 16

[ruby-core:119636] [Ruby master Feature#20852] Anonymous HEREDOC blocks
by bradgessler (Brad Gessler) 07 Nov '24

07 Nov '24

Issue #20852 has been reported by bradgessler (Brad Gessler). ---------------------------------------- Feature #20852: Anonymous HEREDOC blocks https://bugs.ruby-lang.org/issues/20852 * Author: bradgessler (Brad Gessler) * Status: Open ---------------------------------------- Consider the following code. ```ruby # Consider the following code. Markdown.render <<~MARKDOWN # Hello there This is a Markdown file. See? 1. This is a list 2. With items 3. And more items MARKDOWN ``` There's a lot of "Markdown" that's repeated. ```ruby # Or this SQL.execute <<~SQL SELECT * FROM users WHERE id = 1; SQL ``` It's fine. It works. The key feature is that it understands the text in that block is indented. Not requiring the name could make the syntax less redundant and free developers up from having to name the string. Here's what that could look like: ```ruby # Now with 75% less markdown! Markdown.render <<~ # Hello there This is a Markdown file. See? 1. This is a list 2. With items 3. And more items ~>> # We can't sell SQL symbols fast enough! SQL.execute <<~ SELECT * FROM users WHERE id = 1; ~>> ``` I implement a lot of my application UI in Phlex. The dream is that I can build pages out that look like this: ```ruby class Form < ApplicationForm def view_template input(type: "text", name: "name", placeholder: "Name") fieldset{ h2 { "Agreement" } article(class: "prose"){ markdown <<~ ## Terms and Conditions By submitting this form, you agree to the terms and conditions of this website. # Privacy Policy We will not share your information with anyone. ... ~>> } } button{ "Submit" } end end ``` The closest I can get to that today is if I do this: ```ruby SQL.execute <<~_ SELECT * FROM users WHERE id = 1; _ ``` I've proposed a similar feature a while back and chimed in on similar proposals, but after thinking about it for a bit I realized "Anonymous HEREDOC blocks" is a slightly different approach that could be a different possible path forward. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119502] [Ruby master Feature#20793] Allow Multiple Arguments for the .is_a? Method
by artemb (Artem Borodkin) 07 Nov '24

07 Nov '24

Issue #20793 has been reported by artemb (Artem Borodkin). ---------------------------------------- Feature #20793: Allow Multiple Arguments for the .is_a? Method https://bugs.ruby-lang.org/issues/20793 * Author: artemb (Artem Borodkin) * Status: Open ---------------------------------------- I propose allowing multiple arguments to be passed to the .is_a? Method imply "OR" semantics: ``` ruby name.is_a? String, Symbol ``` Currently, we need to write the following to achieve the same functionality: ``` ruby [String, Symbol].include?(name.class) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:119469] [Ruby master Feature#20786] Flow chaining with "then" keyword
by lpogic 07 Nov '24

07 Nov '24

Issue #20786 has been reported by lpogic (Łukasz Pomietło). ---------------------------------------- Feature #20786: Flow chaining with "then" keyword https://bugs.ruby-lang.org/issues/20786 * Author: lpogic (Łukasz Pomietło) * Status: Open ---------------------------------------- Hi, I would like to propose using the *"then"* keyword to create chained flows. ### Background: Original idea: https://bugs.ruby-lang.org/issues/20770#change-110056 However, the concept has changed slightly since then. I now assume that rhs is only calculated when lhs is true, which seems more compatible with the current usage of *"then"* keyword. I would also like to move the discussion here as it may cause unnecessary chaos there. ### Basics: In the canonical version, *"then"* is used in a *"begin..end"* block to split it into steps. When the result of the last expression before *"then"* is not *"false"* or *"nil"*, it is passed as an argument to the next step. Otherwise, all subsequent steps are skipped. The result of the *"begin..end"* block is the result of the last expression, or *"false"*/*"nil"* if any step was skipped. ### Example: ``` ruby # original code source: https://github.com/ruby/ruby/blob/a6383fbe1628bdaa9ec6a30b3baa60dd7430b461/… def include?(other) other = coerce_other(other) return false unless other.family == family begin_addr <= other.begin_addr && end_addr >= other.end_addr end # with chained flow def include?(other) begin coerce_other(other) then => coerced # then => name is my proposition of argument naming syntax return false unless coerced.family == family coerced then => it begin_addr <= it.begin_addr && end_addr >= it.end_addr end end ``` Please treat the canonical form as a starting point. As further improvements I would see: - implicit block argument name - implicit begin - beginless *"then"*, when lhs is just expression ### Example with futher improvements: ``` ruby def include?(other) coerce_other(other) then it.family == family ? it : false then begin_addr <= it.begin_addr && end_addr >= it.end_addr end # or def include?(other) coerce_other other then return false unless it.family == family begin_addr <= it.begin_addr && end_addr >= it.end_addr end end ``` ### *"then"* keyword as the pipeline operator: Under certain conditions, "then" could offer similar capabilities to the pipeline operator of functional languages: ``` ruby # assuming that "foo" and "bar" never return "false" or "nil" # instead of writing this: baz("string", bar(foo(), 2), 5) # you could write this: begin foo() then bar(it, 2) then baz("string", it, 5) end ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119050] [Ruby master Feature#20715] `Ractor.[]` and `Ractor.[]=` to access Ractor local storage
by ko1 (Koichi Sasada) 07 Nov '24

07 Nov '24

Issue #20715 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #20715: `Ractor.[]` and `Ractor.[]=` to access Ractor local storage https://bugs.ruby-lang.org/issues/20715 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Trivial proposal. Now `Ractor#[]/#[]=` is supported to access current ractor local storage. However, it doesn't allow to access local storage of other ractors. ```ruby Ractor.current[:foo] = 1 Ractor.new{ p Ractor.main[:foo] #=> nil }.take ``` So providing `Ractor.[]/[]=` is more reasonable. Further more, we don't need to use `Ractor#current` and it is slightly faster. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:119646] [Ruby master Feature#20855] Introduce `Fiber::Scheduler#blocking_region` to avoid stalling the event loop.
by ioquatix (Samuel Williams) 06 Nov '24

06 Nov '24

Issue #20855 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20855: Introduce `Fiber::Scheduler#blocking_region` to avoid stalling the event loop. https://bugs.ruby-lang.org/issues/20855 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- The fiber scheduler performance can be negatively affected when performing blocking operations that cannot be deferred to the event loopThe current Fiber Scheduler performance can be significantly impacted by blocking operations that cannot be deferred to the event loop, particularly in high-concurrency environments where Fibers rely on non-blocking IO for efficient task execution. ## Problem Description Fibers in Ruby are designed to improve performance and responsiveness by allowing concurrent tasks to proceed without blocking one another. However, certain operations inherently block the Fiber Scheduler, leading to delayed execution across other Fibers. When blocking operations are inevitable, such as system or CPU bound operations without event-loop support, they create bottlenecks that degrade the Scheduler's performance. ## Proposed Solution The proposed solution in PR #11963 introduces a blocking_region hook in the Fiber Scheduler to improve handling of blocking operations. This addition allows code that releases the GVL (Global VM Lock) code to be lifted out of the event loop, reducing the performance impact on the Scheduler during blocking calls. By isolating these operations from the primary event loop, this enhancement aims to improve Fiber-based concurrency, especially in cases where non-deferrable blocking operations would otherwise delay the Fiber Scheduler. The new Fiber Scheduler hook blocking_region is designed to accept an opaque callable object, which encapsulates work that can be offloaded to a thread pool for execution. By isolating these blocking tasks from the main event loop, this hook allows the Scheduler to maintain better responsiveness. This addition offers an efficient way to handle tasks that cannot run asynchronously within the event loop itself, leveraging multi-threading where necessary to keep Fibers running smoothly and minimize blocking impact. -- https://bugs.ruby-lang.org/

5 9