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

[ruby-core:115300] [Ruby master Feature#14602] Version of dig that raises error if a key is not present
by mame (Yusuke Endoh) 08 Nov '23

08 Nov '23

Issue #14602 has been updated by mame (Yusuke Endoh). We discussed at the dev meeting but did not reach a conclusion. But there has been some progress. * @akr said we shouldn't add new vocabulary, and Matz agreed. * There is `Array#fetch` which throws an exception when it is not found, so we want to use this vocabulary: `fetch_*` or `*_fetch` * Matz didn't like any of the proposed `fetch_each` `fetch_all` `fetch_tail` `fetch_end` * Matz prefers `dig` or `recursive` to `deep` to represent this behavior. * `deep` sounds to be an operation on the entire data structure, due to the influence of deep_copy. * Matz was interested in how `dig_fetch` or `fetch_dig` would sound to English native speakers. * Matz also mentioned `recursive_fetch`, but said it seemed a bit long. ---------------------------------------- Feature #14602: Version of dig that raises error if a key is not present https://bugs.ruby-lang.org/issues/14602#change-105218 * Author: amcaplan (Ariel Caplan) * Status: Open * Priority: Normal ---------------------------------------- Currently, if I have a hash like this: ~~~ ruby { :name => { :first => "Ariel", :last => "Caplan" } } ~~~ and I want to navigate confidently and raise a KeyError if something is missing, I can do: ~~~ ruby hash.fetch(:name).fetch(:first) ~~~ Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this: ~~~ ruby hash[:name][:first] ~~~ which leads to many unexpected errors. The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this: ~~~ ruby hash = { :name => { :first => "Ariel", :last => "Caplan" } } hash.dig!(:name, :first) # => Ariel hash.dig!(:name, :middle) # raises KeyError (key not found: :middle) hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method) ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115297] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by mame (Yusuke Endoh) 08 Nov '23

08 Nov '23

Issue #18915 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. This is tentative, but @matz said: * I don't want to change the documentation of `NotImplementedError`. * `NotImplementedYetError` is too confusing with `NotImplementedError`. * `ToBeDefinedError` or something would be better. * I will reply to the ticket. Please wait for matz's answer. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105215 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115296] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by ccaviness (Clay Caviness) 07 Nov '23

07 Nov '23

Issue #18286 has been updated by ccaviness (Clay Caviness). @nobu Yes, at least in initial tests. A universal ruby built on an x86 Mac with that patch seems to work on an Apple Silicon Mac. ---------------------------------------- Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64 https://bugs.ruby-lang.org/issues/18286#change-105214 * Author: ccaviness (Clay Caviness) * Status: Open * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine. To reproduce: * On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)` * Copy the built `./ruby` binary to an Apple Silicon machine * Attempt to execute it Expected: The universal `ruby` binary works correctly on both devices Actual: The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`). Details: I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines. It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]` This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines. Intel: ``` $ ./ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21] ``` Apple Silicon: ``` $ ./ruby -v Segmentation fault: 11 $ lldb ./ruby (lldb) target create "./ruby" Current executable set to '/Users/crc/ruby' (arm64). (lldb) run Process 77071 launched: '/Users/crc/ruby' (arm64) Process 77071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16 ruby`ruby_vm_special_exception_copy: -> 0x1002176b8 <+16>: ldr x0, [x0, #0x8] 0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real 0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc 0x1002176c4 <+28>: mov x20, x0 Target 0: (ruby) stopped. (lldb) ^D ``` I also attempted the same thing with ruby 2.7.4 source, with the same result. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115251] [Ruby master Bug#19989] Fix refinement refine performance
by bkuhlmann (Brooke Kuhlmann) 07 Nov '23

07 Nov '23

Issue #19989 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Bug #19989: Fix refinement refine performance https://bugs.ruby-lang.org/issues/19989 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [arm64-darwin22.4.0] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Why Hello. 👋 Would it be possible to improve the performance of refining an object as I'm seeing a significant performance cost? I know some of this is already known but, when searching through existing issues, I couldn't find any issue that specifically mentioned or called attention to `refine` performance. My C skills are not that great but it seems that `rb_mod_refine` ([source](https://github.com/ruby/ruby/blob/master/eval.c#L1412-L1459)) might be the primary source of complexity and performance degradation? By fixing this, we could improve refinement performance and encourage more adoption since refinements are a powerful way to make small adjustments to the language without resorting to more complicated solutions -- or worse -- using monkey patches. ## How Here's the benchmark I'm using: ``` #! /usr/bin/env ruby # frozen_string_literal: true require "bundler/inline" gemfile true do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |benchmark| benchmark.config time: 5, warmup: 2 benchmark.report "With" do Module.new do refine String do def dud = true end end end benchmark.report "Without" do Module.new do def dud = true end end benchmark.compare! end ``` When running the above, I'm getting the following results (this is a random sample): **Ruby 2.6.6** (ruby 2.6.6p146 (2020-03-31 revision 67876) [-darwin22]) *ℹ️ Temporarily refactored the benchmark to not use endless methods for this version.* ``` Warming up -------------------------------------- With 745.000 i/100ms Without 67.593k i/100ms Calculating ------------------------------------- With 10.849k (±168.6%) i/s - 18.625k in 5.359230s Without 680.199k (± 5.8%) i/s - 3.447M in 5.085558s Comparison: Without: 680198.8 i/s With: 10849.1 i/s - 62.70x slower ``` **Ruby 3.2.2** (ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [arm64-darwin22.4.0]) ``` Warming up -------------------------------------- With 959.000 i/100ms Without 297.091k i/100ms Calculating ------------------------------------- With 21.856k (±198.5%) i/s - 30.688k in 5.509103s Without 3.281M (± 5.8%) i/s - 16.637M in 5.082246s Comparison: Without: 3281310.6 i/s With: 21856.1 i/s - 150.13x slower ``` **Ruby 3.3.3 Preview 2** (ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) +YJIT [arm64-darwin22.6.0]) ``` Warming up -------------------------------------- With 1.044k i/100ms Without 288.264k i/100ms Calculating ------------------------------------- With 24.044k (±192.0%) i/s - 29.232k in 5.305651s Without 3.096M (± 8.0%) i/s - 15.566M in 5.059470s Comparison: Without: 3095640.6 i/s With: 24043.8 i/s - 128.75x slower ``` ## Notes Here's the environment I'm using: - **macOS**: 13.6.1, Apple M1 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:115291] [Ruby master Feature#14602] Version of dig that raises error if a key is not present
by Eregon (Benoit Daloze) 07 Nov '23

07 Nov '23

Issue #14602 has been updated by Eregon (Benoit Daloze). I like `deep_fetch` too. ---------------------------------------- Feature #14602: Version of dig that raises error if a key is not present https://bugs.ruby-lang.org/issues/14602#change-105209 * Author: amcaplan (Ariel Caplan) * Status: Open * Priority: Normal ---------------------------------------- Currently, if I have a hash like this: ~~~ ruby { :name => { :first => "Ariel", :last => "Caplan" } } ~~~ and I want to navigate confidently and raise a KeyError if something is missing, I can do: ~~~ ruby hash.fetch(:name).fetch(:first) ~~~ Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this: ~~~ ruby hash[:name][:first] ~~~ which leads to many unexpected errors. The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this: ~~~ ruby hash = { :name => { :first => "Ariel", :last => "Caplan" } } hash.dig!(:name, :first) # => Ariel hash.dig!(:name, :middle) # raises KeyError (key not found: :middle) hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method) ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115060] [Ruby master Bug#19928] IPV6 nameserver issues: "Protocol not supported - socket(2) - udp"
by brendans-bits (Brendan Bits) 07 Nov '23

07 Nov '23

Issue #19928 has been reported by brendans-bits (Brendan Bits). ---------------------------------------- Bug #19928: IPV6 nameserver issues: "Protocol not supported - socket(2) - udp" https://bugs.ruby-lang.org/issues/19928 * Author: brendans-bits (Brendan Bits) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [amd64-freebsd13] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I get a similar error message to https://bugs.ruby-lang.org/issues/9477 The error message I see: ``` Errno::EPROTONOSUPPORT: Protocol not supported - socket(2) - udp ``` Similarly: ``` $ ruby -rresolv -e 'puts Resolv::DNS.new.getresource("_rubygems._tcp.rubygems.org", Resolv::DNS::Resource::IN::SRV).target' /usr/local/lib/ruby/3.1/resolv.rb:750:in `initialize': Protocol not supported - socket(2) - udp (Errno::EPROTONOSUPPORT) from /usr/local/lib/ruby/3.1/resolv.rb:750:in `new' from /usr/local/lib/ruby/3.1/resolv.rb:750:in `block (2 levels) in lazy_initialize' from /usr/local/lib/ruby/3.1/resolv.rb:740:in `each' from /usr/local/lib/ruby/3.1/resolv.rb:740:in `block in lazy_initialize' from /usr/local/lib/ruby/3.1/resolv.rb:735:in `synchronize' from /usr/local/lib/ruby/3.1/resolv.rb:735:in `lazy_initialize' from /usr/local/lib/ruby/3.1/resolv.rb:771:in `sender' from /usr/local/lib/ruby/3.1/resolv.rb:527:in `block in fetch_resource' from /usr/local/lib/ruby/3.1/resolv.rb:1125:in `block (3 levels) in resolv' from /usr/local/lib/ruby/3.1/resolv.rb:1123:in `each' from /usr/local/lib/ruby/3.1/resolv.rb:1123:in `block (2 levels) in resolv' from /usr/local/lib/ruby/3.1/resolv.rb:1122:in `each' from /usr/local/lib/ruby/3.1/resolv.rb:1122:in `block in resolv' from /usr/local/lib/ruby/3.1/resolv.rb:1120:in `each' from /usr/local/lib/ruby/3.1/resolv.rb:1120:in `resolv' from /usr/local/lib/ruby/3.1/resolv.rb:521:in `fetch_resource' from /usr/local/lib/ruby/3.1/resolv.rb:507:in `each_resource' from /usr/local/lib/ruby/3.1/resolv.rb:488:in `getresource' from -e:1:in `<main>' ``` I am running this in a FreeBSD jail (created by Bastille) that does not have IPV6 connectivity, on a host that does have IPV6 connectivity. Similar to the previous issue, the problem is successfully resolved by commenting out the IPV6 nameserver lines. Longer output for reference: ``` rake aborted! Errno::EPROTONOSUPPORT: Protocol not supported - socket(2) - udp /usr/local/www/mastodon/app/validators/email_mx_validator.rb:49:in `block in resolve_mx' /usr/local/www/mastodon/app/validators/email_mx_validator.rb:46:in `resolve_mx' /usr/local/www/mastodon/app/validators/email_mx_validator.rb:14:in `validate' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:423:in `block in make_lambda' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:180:in `block (2 levels) in halting_and_conditional' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:687:in `block (2 levels) in default_terminator' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:686:in `catch' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:686:in `block in default_terminator' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:181:in `block in halting_and_conditional' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:595:in `block in invoke_before' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:595:in `each' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:595:in `invoke_before' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:106:in `run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:929:in `_run_validate_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activemodel-7.0.8/lib/active_model/validations.rb:406:in `run_validations!' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activemodel-7.0.8/lib/active_model/validations/callbacks.rb:115:in `block in run_validations!' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:107:in `run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:929:in `_run_validation_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activemodel-7.0.8/lib/active_model/validations/callbacks.rb:115:in `run_validations!' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activemodel-7.0.8/lib/active_model/validations.rb:337:in `valid?' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/validations.rb:68:in `valid?' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/validations.rb:84:in `perform_validations' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/validations.rb:47:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:298:in `block in save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/connection_adapters/abstract/database_statements.rb:314:in `transaction' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:350:in `with_transaction_returning_status' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:298:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/suppressor.rb:50:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:455:in `save_has_one_association' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:198:in `block in add_autosave_association_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:166:in `instance_eval' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:166:in `block in define_non_cyclic_method' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:400:in `block in make_lambda' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:236:in `block in halting_and_conditional' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:599:in `block in invoke_after' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:599:in `each' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:599:in `invoke_after' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:108:in `run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:929:in `_run_create_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/callbacks.rb:459:in `_create_record' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/timestamp.rb:108:in `_create_record' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/persistence.rb:1069:in `create_or_update' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/callbacks.rb:455:in `block in create_or_update' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:118:in `block in run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:370:in `around_save_collection_association' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:127:in `block in run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:138:in `run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:929:in `_run_save_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/callbacks.rb:455:in `create_or_update' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/timestamp.rb:126:in `create_or_update' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/persistence.rb:615:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/validations.rb:47:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:298:in `block in save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/connection_adapters/abstract/database_statements.rb:314:in `transaction' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:350:in `with_transaction_returning_status' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:298:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/suppressor.rb:50:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:491:in `save_belongs_to_association' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:210:in `block in add_autosave_association_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:166:in `instance_eval' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/autosave_association.rb:166:in `block in define_non_cyclic_method' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:400:in `block in make_lambda' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:199:in `block (2 levels) in halting' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:687:in `block (2 levels) in default_terminator' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:686:in `catch' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:686:in `block in default_terminator' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:200:in `block in halting' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:595:in `block in invoke_before' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:595:in `each' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:595:in `invoke_before' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:116:in `block in run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:138:in `run_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/callbacks.rb:929:in `_run_save_callbacks' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/callbacks.rb:455:in `create_or_update' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/timestamp.rb:126:in `create_or_update' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/persistence.rb:615:in `save' # Generated by resolvconf /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/validations.rb:47:in `save' # Generated by resolvconf /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:298:in `block in save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activesupport-7.0.8/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:350:in `with_transaction_returning_status' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/transactions.rb:298:in `save' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/activerecord-7.0.8/lib/active_record/suppressor.rb:50:in `save' /usr/local/www/mastodon/lib/tasks/mastodon.rake:517:in `block (2 levels) in <main>' /usr/local/www/mastodon/vendor/bundle/ruby/3.1/gems/rake-13.0.6/exe/rake:27:in `<top (required)>' Tasks: TOP => mastodon:setup (See full trace by running task with --trace) ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115259] [Ruby master Bug#19990] Could we reconsider the second argument to Kernel#load?
by fxn (Xavier Noria) 07 Nov '23

07 Nov '23

Issue #19990 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #19990: Could we reconsider the second argument to Kernel#load? https://bugs.ruby-lang.org/issues/19990 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation of `Kernel#load` says: > If the optional wrap parameter is true, the loaded script will be executed under an anonymous module, protecting the calling program’s global namespace. If the optional wrap parameter is a module, the loaded script will be executed under the given module. In no circumstance will any local variables in the loaded file be propagated to the loading environment. I'd like to ask you to reconsider this feature. First of all, "protecting the calling program" is not really accomplished because the loaded file may still do this ```ruby class ::C # defines ::C regardless of the second argument end ``` Another example, if the caller defines a module `M`, then the loaded program can also define things in `M`: ```ruby class M::C # defines ::M::C regardless of the second argument end ``` It does not even need a leading `::`. So, the "protection" is not really there. In addition to that, this is not transparent for the code being loaded either. For example, let's take this program: ```ruby class A end module X ::A # could be needed if your own lookup had an A somewhere you want to skip end ``` the Ruby programmer expects that to work. But with this feature, on paper, nobody knows if it wil work. How can you ship code confidently? So, the documentation should say: > It kind of protects, but not really. Also, the loaded file may not work as expected, or may not even be laodable at all. That hypothetical documentation suggests to me it would be worth revisiting this feature. In Ruby, as it is today, things are global. The language does not have features to really isolate code as containers do, for example. I believe the 2nd argument to `Kernel#load` steers the API in a direction that is not consistent with the language, and provides a feature that is only partial and cannot satisfy what it promises. I'd be in favor of deprecating and eventually remove this API. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:115033] [Ruby master Misc#19925] DevMeeting-2023-11-07
by mame (Yusuke Endoh) 06 Nov '23

06 Nov '23

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

10 11

[ruby-core:115273] [Ruby master Feature#14602] Version of dig that raises error if a key is not present
by sinsoku (Takumi Shotoku) 06 Nov '23

06 Nov '23

Issue #14602 has been updated by sinsoku (Takumi Shotoku). I agree with [#14602#note-23](https://bugs.ruby-lang.org/issues/14602#note-23). I think a fetch-based or dig-based name would be better, since the function can be inferred from the method name. Personally, I feel that **deep_fetch** is a simple and nice name. I often use [deep_dup](https://api.rubyonrails.org/classes/Object.html#method-i-deep_dup) and [deep_merge](https://api.rubyonrails.org/classes/Hash.html#method-i-deep_mer… in Rails apps and are familiar with the method name `deep_*`. I found `fetch_dig` and `dig_fetch` to be a little strange in that they have verbs lined up. I think `dig_strict` is a good name, but I prefer **deep_fetch** because `deep` has fewer characters and is simpler than `strict`. ---------------------------------------- Feature #14602: Version of dig that raises error if a key is not present https://bugs.ruby-lang.org/issues/14602#change-105189 * Author: amcaplan (Ariel Caplan) * Status: Open * Priority: Normal ---------------------------------------- Currently, if I have a hash like this: ~~~ ruby { :name => { :first => "Ariel", :last => "Caplan" } } ~~~ and I want to navigate confidently and raise a KeyError if something is missing, I can do: ~~~ ruby hash.fetch(:name).fetch(:first) ~~~ Unfortunately, the length of the name, combined with the need to repeat the method name every time, means most programmers are more likely to do this: ~~~ ruby hash[:name][:first] ~~~ which leads to many unexpected errors. The Hash#dig method made it easy to access methods safely from a nested hash; I'd like to have something similar for access without error protection, and I'd think the most natural name would be Hash#dig!. It would work like this: ~~~ ruby hash = { :name => { :first => "Ariel", :last => "Caplan" } } hash.dig!(:name, :first) # => Ariel hash.dig!(:name, :middle) # raises KeyError (key not found: :middle) hash.dig!(:name, :first, :foo) # raises TypeError (String does not have #dig! method) ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115272] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by Dan0042 (Daniel DeLorme) 06 Nov '23

06 Nov '23

Issue #15554 has been updated by Dan0042 (Daniel DeLorme). I think this was closed by mistake and should be re-opened. ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-105188 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0