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

[ruby-core:115634] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 07 Dec '23

07 Dec '23

Issue #18368 has been updated by zverok (Victor Shepelev). @naruse Is there a chance for this change to be included in 3.3? ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-105569 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115632] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by tbsprs (Tobias Preuss) 07 Dec '23

07 Dec '23

Issue #11322 has been updated by tbsprs (Tobias Preuss). Thanks for following up. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105566 * Author: tbsprs (Tobias Preuss) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115629] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
by k0kubun (Takashi Kokubun) 07 Dec '23

07 Dec '23

Issue #18980 has been updated by k0kubun (Takashi Kokubun). Description updated Status changed from Open to Assigned Assignee set to k0kubun (Takashi Kokubun) Target version set to 3.4 In today's Developers Meeting, @matz accepted to warn `it` in Ruby 3.3 and add `it` in Ruby 3.4. Quote from the meeting notes: > * matz: accept `it` on Ruby 3.4. > * ruby 3.3 will warn and ruby 3.4 will use the new semantics I also copied the discussed specification to the ticket description. In Ruby 3.3, `it` should be warned only when `it` will behave like `_1` in Ruby 3.4. ---------------------------------------- Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter https://bugs.ruby-lang.org/issues/18980#change-105563 * Author: k0kubun (Takashi Kokubun) * Status: Assigned * Priority: Normal * Assignee: k0kubun (Takashi Kokubun) * Target version: 3.4 ---------------------------------------- ## Problem Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`. ```rb [1, 2, 3].each { puts _1 } ``` I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB. <details> <summary>Why I don't use <code>_1</code></summary> I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`. </details> ## Proposal * Ruby 3.3: Warn `it` method calls without a receiver, arguments, or a block. * Ruby 3.4: Introduce `it` as follows. ### Specification ```rb [1, 2, 3].each { puts it } ``` `it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments. <details> <summary>Full specification</summary> ```ruby # Ruby 3.4 def foo it #=> method call _1 #=> method call 1.times do p it #=> 0 it = "foo" p it #=> "foo" p _1 #=> 0 _1 = "foo" # Syntax Error p _1 #=> N/A p foo #=> method call foo = 1 p foo #=> local var it "foo" do # method call (rspec) end end 1.times do || p _1 # Syntax Error it # method call end 1.times do ["Foo"].any? {|| it } # method call end yield_1_and_2 do # yield 1, 2 p _1 #=> 1 p it #=> 1 end yield_ary do # yield [1, 2] p _1 #=> [1, 2] p it #=> [1, 2] end 1.times do p [_1, it] # Syntax Error p [_2, it] # Syntax Error end end ``` </details> ## Past discussions * [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`. * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-… * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8… * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118) * [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`. * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c… * [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged. * [Feature #18980] Re-reconsider numbered parameters: (this ticket) * 2022/09/08: [Ruby Committers vs the World](https://youtu.be/ajm3lr6Y9yE?si=yyWGiZHoUWqZiTaS&t=2920) ### Compatibility `it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`? The following cases have been discussed: * `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)) * `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined. With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them. Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years. ### Confusion We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points: * RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end` * `it` could be a local variable or `_1`, depending on the situation My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument. I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115628] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by hsbt (Hiroshi SHIBATA) 07 Dec '23

07 Dec '23

Issue #11322 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed I merged https://github.com/ruby/open-uri/pull/18. Thanks all. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105562 * Author: tbsprs (Tobias Preuss) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115627] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by akr (Akira Tanaka) 07 Dec '23

07 Dec '23

Issue #11322 has been updated by akr (Akira Tanaka). I agree with `max_redirects` option. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105561 * Author: tbsprs (Tobias Preuss) * Status: Assigned * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115428] [Ruby master Feature#20011] Reduce implicit array allocations on caller side of method calling
by jeremyevans0 (Jeremy Evans) 07 Dec '23

07 Dec '23

Issue #20011 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #20011: Reduce implicit array allocations on caller side of method calling https://bugs.ruby-lang.org/issues/20011 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I would like to use the peephole optimizer to eliminate caller-side array allocations for the following cases, by switching `splatarray true` to `splatarray false`: ```ruby f(1, *a) f(1, *a, &lvar) f(1, *a, &@ivar) f(*a, **lvar) f(*a, **@ivar) f(*a, **lvar, &lvar) f(*a, **@ivar, &@ivar) f(*a, kw: 1) f(*a, kw:1, &lvar) f(*a, kw:1, &@ivar) ``` In terms of safety, currently, `f(*a, &lvar)` and `f(*a, &@ivar)` both avoid array allocations (`splatarray false`), and all of the above are as safe as those in terms of safety. Note that since at least Ruby 1.8, in pathlogical cases, `lvar.to_proc` can modify `a`, which results in behavior contrary to expected evaluation order: ```ruby ary = [1,2] kwd = Object.new kwd.define_singleton_method(:to_proc) {ary << 4; lambda{}} p(*ary, &kwd) # 4 included in output ``` I think that for both the current `f(*a, &lvar)` and `f(*a, &@ivar)` cases and all of the above cases, the benefit of avoiding the allocation is higher than the costs, considering that only pathologic cases fail. If we do not want the above optimization, for consistency, we should remove the optimization of `f(*a, &lvar)` and `f(*a, &@ivar)` (or update the optimization so that it is only used if `lvar` or `@ivar` is already a proc), which will slow Ruby down. I have submitted a pull request for these changes: https://github.com/ruby/ruby/pull/8853 To make sure these cases are worth optimizing, I did some analysis: For ruby -e '' (just loads rubygems): ``` 5 : f(1, *a) 2 : f(1, *a, &lvar) | f(1, *a, &@ivar) ``` Current stdlib: ``` 139 : f(1, *a) 3 : f(1, *a, &lvar) | f(1, *a, &@ivar) 4 : f(*a, **lvar) | f(*a, **@ivar) ``` Rails master: ``` 77 : f(1, *a) 5 : f(1, *a, &lvar) | f(1, *a, &@ivar) 26 : f(*a, **lvar) | f(*a, **@ivar) 5 : f(*a, kw: 1) ``` minitest 5.20 (bundled gem): ``` 4 : f(1, *a) 1 : f(1, *a, &lvar) | f(1, *a, &@ivar) 2 : f(*a, **lvar) | f(*a, **@ivar) 2 : f(*a, **lvar, &lvar) | f(*a, **@ivar, &@ivar) ``` capybara 3.39.2: ``` 15 : f(1, *a) 2 : f(1, *a, &lvar) | f(1, *a, &@ivar) 19 : f(*a, **lvar) | f(*a, **@ivar) 4 : f(*a, **lvar, &lvar) | f(*a, **@ivar, &@ivar) ``` This shows that all cases optimized except `f(*a, kw:1, &lvar)` and `f(*a, kw:1, &@ivar)` are used in common gems. Those cases could be removed if people think they are not worth optimizing. Code backing the above analysis can be found at https://github.com/ruby/ruby/pull/8853#issuecomment-1817656139 -- https://bugs.ruby-lang.org/

3 7

[ruby-core:115625] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by ko1 (Koichi Sasada) 07 Dec '23

07 Dec '23

Issue #18886 has been updated by ko1 (Koichi Sasada). Please merge it. > I don't think this will affect performance unless TracePoint is used, because the same method caching is done in both cases. Showing benchmarking result will help IMO to confirm there is no penalty. ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105557 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115388] [Ruby master Feature#20005] Add C API to return symbols of native extensions resolved from features
by tagomoris (Satoshi Tagomori) 07 Dec '23

07 Dec '23

Issue #20005 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #20005: Add C API to return symbols of native extensions resolved from features https://bugs.ruby-lang.org/issues/20005 * Author: tagomoris (Satoshi Tagomori) * Status: Open * Priority: Normal ---------------------------------------- I want an API to resolve symbols of other native extensions by a feature name and a symbol name (just like `dlsym`). (`rb_dln_resolve_symbol` is an example function name of this feature in the example below) ```c // "a_client_open" is a function defined in "/..../a_client.so", that should be loaded in Ruby beforehand. // in the extension to be "a.so" VALUE (*a_client_open)(VALUE); void Init_a(void) { a_client_open = (VALUE(*)(VALUE))rb_dln_resolve_symbol("a_client", "a_client_open"); // the return value may be NULL if the symbols is not found } ``` This API is to replace direct reference of external symbols. Currently, native extensions have to just call the function of other extensions directly on the assumption of: * The dependency native extension is already loaded * The symbol is defined correctly in the dependency (the version of dependency is correct&expected) Otherwise, it crashes. This API provides a way for developers to raise exceptions if the resolved symbol is `NULL`, and these exceptions can display meaningful messages and instructions to the users of extensions. -- https://bugs.ruby-lang.org/

4 13

[ruby-core:115619] [Ruby master Feature#16431] Optionally load did_you_mean (and RubyGems)
by hsbt (Hiroshi SHIBATA) 07 Dec '23

07 Dec '23

Issue #16431 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed https://github.com/ruby/ruby/pull/2764 has been merged. ---------------------------------------- Feature #16431: Optionally load did_you_mean (and RubyGems) https://bugs.ruby-lang.org/issues/16431#change-105551 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I just have opened PR [1], which allows Ruby to run when did_you_mean is not available. As I previously discussed in #16427, there are cases when speed, memory, disk or network bandwidth is a concern and did_you_mean is not useful for runtime. This is especially useful when Ruby is installed via packaging systems of (Linux) distributions. The PR is split into 4 commits, because since I was there, I prepared similar changes to RubyGems. [1]: https://github.com/ruby/ruby/pull/2764 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115304] [Ruby master Feature#19993] Optionally Free all memory at exit
by HParker (Adam Hess) 07 Dec '23

07 Dec '23

Issue #19993 has been reported by HParker (Adam Hess). ---------------------------------------- Feature #19993: Optionally Free all memory at exit https://bugs.ruby-lang.org/issues/19993 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal ---------------------------------------- Add a runtime option allowing Ruby to optionally free all memory at shutdown. # why Today, memory sanitizers are difficult to use with Ruby, since not all memory is freed at shutdown. it is difficult to detect memory leaks or errors in Ruby or in Ruby C extensions when these tools are not available. While implementing this feature, we were able to identify and fix a number of memory leaks and errors. https://github.com/ruby/ruby/pull/8556 https://github.com/ruby/ruby/pull/8512 https://github.com/ruby/ruby/pull/8503 https://github.com/ruby/ruby/pull/8487 https://github.com/ruby/ruby/pull/8452 https://github.com/ruby/ruby/pull/8501 https://github.com/ruby/ruby/pull/8481 https://github.com/ruby/ruby/pull/8555 This shows that having access to tools like this can make finding and fixing memory bugs easier. # current progress Today we can allow ruby developers to enable freeing memory at shutdown via the `free-at-shutdown` runtime option. PR: https://github.com/ruby/ruby/pull/8868 running, without `--free-on-shutdown`: ``` valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby basictest/test.rb ``` ``` ==573270== LEAK SUMMARY: ==573270== definitely lost: 658,324 bytes in 5,387 blocks ==573270== indirectly lost: 955,708 bytes in 11,957 blocks ==573270== possibly lost: 2,071,096 bytes in 12 blocks ==573270== still reachable: 161,881 bytes in 275 blocks ==573270== suppressed: 0 bytes in 0 blocks ==573270== Reachable blocks (those to which a pointer was found) are not shown. ==573270== To see them, rerun with: --leak-check=full --show-leak-kinds=all ``` with `--free-on-shutdown` ``` valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby --free-on-shutdown basictest/test.rb ``` ``` ==573306== HEAP SUMMARY: ==573306== in use at exit: 0 bytes in 0 blocks ==573306== total heap usage: 43,643 allocs, 43,643 frees, 29,222,534 bytes allocated ==573306== ==573306== All heap blocks were freed -- no leaks are possible ``` # future plans * Continue improving memory safety * add `valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby --free-on-shutdown basictest/test.rb` to CI * Allow C extensions to do a "optional destruct for memory safety" so they can leverage the same memory sanitizer tools. -- https://bugs.ruby-lang.org/

4 7