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

[ruby-core:119106] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by Dan0042 (Daniel DeLorme) 09 Sep '24

09 Sep '24

Issue #15554 has been updated by Dan0042 (Daniel DeLorme). This is a bit off-topic, but I've often thought it would be nice to have multiple "levels" of warnings. So we could have the fine-grained `Warning[:strict_unused_block]` which, if unset, defaults to the coarse-grained `Warning[:strict]` which, if unset, defaults to `$VERBOSE`. BTW "pedantic" might sound funny but it's both derogatory and undescriptive, and used here in a different sense to the -pedantic option of gcc. Maybe something like "potential_bug" would be better? ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-109695 * Author: ko1 (Koichi Sasada) * Status: Assigned * 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

[ruby-core:119105] to all devs! need help
by mikey 09 Sep '24

09 Sep '24

i have an interesting piece of androud hardware and i have a plan foe a fulk dep!oyment of its architechture but i want for it to be a controlled delloyment and for it to be released to only special people and also have ruby specifically embeded in its functionality. i am concerned over its release because its a build suplosedly from the underworld and its not a typical build . its not even sold on any market but its from another dimensional for of the same company. its really technical stuff and i want to keep it exclusive to ruby and matz because of his japan roots and the Yakuza background. i would like to establish a better relationship between Japan and the US. All devs will have access to this when a complete break down is completed. anyone specialized in android architecture i would exclusively be interested in your assistance. i also question if a debian type based build could be possible to integrate as its base build. i am not sure of its prob!em to associate witn ruby i would like to offer my designs as i said exclusively for ruby devs. i am in need of secure devices to further my work. i am afraid of insecure electronics and bad people trying to steal information. i never knew how difficult it was in the tech industry. god bless the beloved tech icons of our day and their struggles. please send support to my home address:Michae! Martinez (muerte) PO box 702 Aromas Ca 95004 i be!ieve there is a huge exploit, a huge bug bounty that is going to caus3 a disaster soon on behalf of apple if anyone is interested i collexting the reward i believe its in the AMDE files being deployed in the latest updates for mos telectronics so that apple users have backdoor exploits into everytning with spiritual assistance. their is no need for it and its a lawsuit really. i would like all the help i can get. i am sure kts the biggest bug bounty ever paid. file it and just sit back and enjoy. i am too unsecure to log in to my dev accounts. cant lose its just a small report. good luck ruby squad!!!

1 0

[ruby-core:119104] [Ruby master Feature#13820] Add a nil coalescing operator
by TylerRick (Tyler Rick) 09 Sep '24

09 Sep '24

Issue #13820 has been updated by TylerRick (Tyler Rick). Ruby already has the safe navigation operator `?.`, added back in Ruby 2.3, which was definitely a step in the right direction with regards to first-class `nil`-aware operations. Now we just need a null coalescing operator like most other popular languages have and our support for null-aware operators will be complete! I would jump for joy. Please add this. Adding this operator would make it elegantly concise and trivially simple to just write what you mean the *first* time: "if LHS is **nil** , then use (`??`) / initialize using (`??=`) this default value" — instead of being tempted to use the *almost*-correct but subtly different-meaning ("if LHS is **falsy** , then...") alternative that we've all ended up using instead, `something || default`. And then having to "upgrade"/fix the logic to something more complicated/verbose when you inevitably realize that `false` values were inadvertently *also* using the logic path you intended only for `nil` values. As akim (Akim Demaille) summed up perfectly in #note-10: > > In practice when people use `||`, they [really] mean `??` It should be easier to do the right thing here, and *not* so easy (by virtue of it being the *only* obvious/easy solution provided by the syntax) to shoot yourself in the foot by inadvertently allowing `false` values to use the same logic path that you only *wanted* to be used for `nil`... If we *had* the syntax to allow it, it would be a lot easier / more common to allow `false` values as *distinct* values from `nil` — and allow them (without any extra effort) to arrive all the way inside your method/etc. instead of getting mistakenly lumped together with `nil` values (and accidentally triggering the "default value" path). As Michael Harrington [put it](https://github.com/kibiz0r/coalesce)... :) > Ruby, as a community, unfairly discriminates against `false` [...] > `false` is a perfectly non-nil object, and you're excluding it out of convenience! --- I would prefer spelling it `??` since that seems the most consistent with the existing `?.` operator, and seems like the most popular spelling (used by C#, JavaScript, PHP, PowerShell, and Swift). (`?:` as in [Kotlin](https://kotlinlang.org/docs/null-safety.html#elvis-operator) would be a fun spelling, but IMHO it look too much like the ternary operator `? :`, which of course is different since it checks for *truthy* values rather than *nullish* values, so that similarity could be surprising.) Shoot, even ***JavaScript*** has [had this operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference… since ECMAScript 2020. Are we really going to let JavaScript and PHP be more developer-friendly than Ruby on this point??? Say it ain't so. ---------------------------------------- Feature #13820: Add a nil coalescing operator https://bugs.ruby-lang.org/issues/13820#change-109694 * Author: williamn (William Newbery) * Status: Open ---------------------------------------- It would be nice if Ruby had an operator that only considered `nil` as false, like the null coalescing operators or "Logical Defined-Or operator" (Perl) found in some other languages. Ive seen things like `//` and `//=`m `??` and `??=`, or `?:` used for this. This would work like `||` and `||=` for short circuiting etc. except that only `nil` is considered a false condition. While Ruby considers only "false" and "nil" as false, with everything else true ("", [], {}, etc.) I still find occasionally people trip up when using logical or, `||` and `||=` when the value may be false. ```ruby a = 0 || 55 # = 0 Ruby already considers 0, "", etc. as true (oter languages do differ a lot here) a = 0 ?? 55 # = 0 So no change here a = nil || 55 # = 55, nil is false so right side is evaulated. a = nil ?? 55 # = 55, again no change a = false || 55 # = 55, however false is false for logical or a = false ?? 55 # = false, but its still a non-nil value ``` For example when doing things like: ```ruby def lazy @lazy ||= compute_this end def fetch(id, **opts) host = opts[:host] || default_host https = opts[:https] || true port = opts[:port] || (https ? 443 : 80) ... ``` Normally the intention is to use a default value or compute an action if no value is provided, which if the value may be false then requires special handling, or sometimes is missed and results in a bug. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119000] [Ruby master Bug#20710] Reducing Hash allocation introduces large performance degradation (probably related to VWA)
by pocke (Masataka Kuwabara) 09 Sep '24

09 Sep '24

Issue #20710 has been reported by pocke (Masataka Kuwabara). ---------------------------------------- Bug #20710: Reducing Hash allocation introduces large performance degradation (probably related to VWA) https://bugs.ruby-lang.org/issues/20710 * Author: pocke (Masataka Kuwabara) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin21] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a surprising performance degradation while developing RBS. In short, I tried to remove unnecessary Hash allocations for RBS. Then, it made the execution time 2x slower. VWA for Hash probably causes this degradation. I'd be happy if we could mitigate the impact by updating the memory management strategy. ## Reproduce You can reproduce this problem on a PR in pocke/rbs repository. https://github.com/pocke/rbs/pull/2 This PR dedups empty Hash objects. 1. `git clone` and checkout 1. `bundle install` 1. `bundle exec rake compile` for C-ext 1. `bundle ruby benchmark/benchmark_new_env.rb` The "before" commit is https://github.com/pocke/rbs/commit/2c356c060286429cfdb034f88a74a6f94420fd21. The "after" commit is https://github.com/pocke/rbs/commit/bfb2c367c7d3b7f93720392252d3a3980d7bf335. The benchmark results are the following: ``` # Before $ bundle exec ruby benchmark/benchmark_new_env.rb (snip) new_env 6.426 (±15.6%) i/s - 64.000 in 10.125442s new_rails_env 0.968 (± 0.0%) i/s - 10.000 in 10.355738s # After $ bundle exec ruby benchmark/benchmark_new_env.rb (snip) new_env 4.371 (±22.9%) i/s - 43.000 in 10.150192s new_rails_env 0.360 (± 0.0%) i/s - 4.000 in 11.313158s ``` The IPS decreased 1.47x for `new_env` case (parsing small RBS env), and 2.69x for `new_rails_env` (parsing large RBS env). ## Investigation ### GC.stat `GC.stat` indicates the number of minor GCs increases. ```ruby # In the RBS repository require_relative './benchmark/utils' tmpdir = prepare_collection! new_rails_env(tmpdir) pp GC.stat ``` ``` # before {:count=>126, :time=>541, :marking_time=>496, :sweeping_time=>45, :heap_allocated_pages=>702, :heap_sorted_length=>984, :heap_allocatable_pages=>282, :heap_available_slots=>793270, :heap_live_slots=>787407, :heap_free_slots=>5863, :heap_final_slots=>0, :heap_marked_slots=>757744, :heap_eden_pages=>702, :heap_tomb_pages=>0, :total_allocated_pages=>702, :total_freed_pages=>0, :total_allocated_objects=>2220605, :total_freed_objects=>1433198, :malloc_increase_bytes=>5872, :malloc_increase_bytes_limit=>16777216, :minor_gc_count=>112, :major_gc_count=>14, :compact_count=>0, :read_barrier_faults=>0, :total_moved_objects=>0, :remembered_wb_unprotected_objects=>0, :remembered_wb_unprotected_objects_limit=>4779, :old_objects=>615704, :old_objects_limit=>955872, :oldmalloc_increase_bytes=>210912, :oldmalloc_increase_bytes_limit=>16777216} # after {:count=>255, :time=>1551, :marking_time=>1496, :sweeping_time=>55, :heap_allocated_pages=>570, :heap_sorted_length=>1038, :heap_allocatable_pages=>468, :heap_available_slots=>735520, :heap_live_slots=>731712, :heap_free_slots=>3808, :heap_final_slots=>0, :heap_marked_slots=>728727, :heap_eden_pages=>570, :heap_tomb_pages=>0, :total_allocated_pages=>570, :total_freed_pages=>0, :total_allocated_objects=>2183278, :total_freed_objects=>1451566, :malloc_increase_bytes=>1200, :malloc_increase_bytes_limit=>16777216, :minor_gc_count=>242, :major_gc_count=>13, :compact_count=>0, :read_barrier_faults=>0, :total_moved_objects=>0, :remembered_wb_unprotected_objects=>0, :remembered_wb_unprotected_objects_limit=>5915, :old_objects=>600594, :old_objects_limit=>1183070, :oldmalloc_increase_bytes=>8128, :oldmalloc_increase_bytes_limit=>16777216} ``` ### Warming up Hashes The following patch, which creates unnecessary Hash objects before the benchmark, improves the execution time. ```diff diff --git a/benchmark/benchmark_new_env.rb b/benchmark/benchmark_new_env.rb index 6dd2b73f..a8da61c6 100644 --- a/benchmark/benchmark_new_env.rb +++ b/benchmark/benchmark_new_env.rb @@ -4,6 +4,8 @@ require 'benchmark/ips' tmpdir = prepare_collection! +(0..30_000_000).map { {} } + Benchmark.ips do |x| x.time = 10 ``` The results are the following: ``` # Before Calculating ------------------------------------- new_env 10.354 (± 9.7%) i/s - 103.000 in 10.013834s new_rails_env 1.661 (± 0.0%) i/s - 17.000 in 10.282490s # After Calculating ------------------------------------- new_env 10.771 (± 9.3%) i/s - 107.000 in 10.010446s new_rails_env 1.584 (± 0.0%) i/s - 16.000 in 10.178984s ``` ### `RUBY_GC_HEAP_FREE_SLOTS_MIN_RATIO` The `RUBY_GC_HEAP_FREE_SLOTS_MIN_RATIO` env var also mitigates the performance impact. In this example, I set `RUBY_GC_HEAP_FREE_SLOTS_MIN_RATIO=0.6` (default: 0.20) ```console # Before Calculating ------------------------------------- new_env 10.271 (± 9.7%) i/s - 102.000 in 10.087191s new_rails_env 1.529 (± 0.0%) i/s - 16.000 in 10.538043s # After $ env RUBY_GC_HEAP_FREE_SLOTS_MIN_RATIO=0.6 bundle exec ruby benchmark/benchmark_new_env.rb Calculating ------------------------------------- new_env 11.003 (± 9.1%) i/s - 110.000 in 10.068428s new_rails_env 1.347 (± 0.0%) i/s - 14.000 in 11.117665s ``` ## Additional Information * I applied the same change to Array. But it does not cause this problem. * I guess the cause is the difference of the Size Pool. An empty Array uses 40 bytes like the ordinal Ruby object, but an empty Hash uses 160 bytes. * The Size Pool for 160 bytes objects has fewer objects than the 40 bytes one. So, reducing allocation affects the performance sensitively. * I tried it on Ruby 3.2. This change on Ruby 3.2 does not degrade the execution time. * VWA for Hash is introduced since Ruby 3.3. https://github.com/ruby/ruby/blob/73c39a5f93d3ad4514a06158e2bb7622496372b9/… ## Acknowledgement @mame, @ko1, and @soutaro helped the investigation. I would like to thank them. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:119096] [Ruby master Bug#20720] prism incorrectly marks SuperNode as forwarding in some cases
by luke-gru (Luke Gruber) 07 Sep '24

07 Sep '24

Issue #20720 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20720: prism incorrectly marks SuperNode as forwarding in some cases https://bugs.ruby-lang.org/issues/20720 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.0dev * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby class A def foo(*b, &block) end end class B < A def foo(...) super() puts "2" end end ``` results in: ``` ./ruby --parser=prism -I../ruby/lib -I. -I.ext/x86_64-linux -I.ext/common -r./x86_64-linux-fake ../ruby/test.rb -- raw disasm-------- trace: 8 trace: 1 <L000> [sp: 0, unremovable: 0, refcnt: 0] 0000 putself ( 284) 0001 invokesuperforward <calldata:, 0>, nil ( 284) * 0004 pop ( 284) trace: 1 0005 putself ( 285) 0006 putchilledstring "2" ( 285) 0008 opt_send_without_block <calldata:puts, 1> ( 285) trace: 10 0010 leave ( 286) --------------------- ../ruby/test.rb: ../ruby/test.rb:284: argument stack underflow (-1) (SyntaxError) ``` It should differentiate between ZSUPER type nodes and super nodes in this case. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118831] [Ruby master Feature#20673] Enable native SOCKS support by default
by MatzFan (Brian Cohen) 05 Sep '24

05 Sep '24

Issue #20673 has been reported by MatzFan (Brian Cohen). ---------------------------------------- Feature #20673: Enable native SOCKS support by default https://bugs.ruby-lang.org/issues/20673 * Author: MatzFan (Brian Cohen) * Status: Open ---------------------------------------- I'd like to see future Rubies have native SOCKS support enabled by default. Currently Rubies must be compiled with the `--enable-socks=true` option in order to provide access to the `SOCKSSocket` class, through which network connections may be made via the SOCKS protocol. My proposal is simply to deprecate the `--enable-socks` option IFO of SOCKS support being enabled by default. Use cases: To the best of my knowledge, the most commonly used SOCKS proxies are [Dante](https://www.inet.no/dante/) and [Tor](https://torproject.org). I know little of the former, but the latter is used as an anonymity tool. For example, the Tor Browser (based on Firefox) is built on the `tor` SOCKS proxy. Users wishing to make requests through the SOCKS protocol (through one of these proxies or otherwise) must compile their own Ruby with SOCKS enabled, or install Dante/Tor and make requests through these via another tool - e.g. a Selenium-driven browser, suitably configured. Alternatively, a lower level library like `cURL` can be utilized. Discussion: Most users do not build their own Rubies, but instead use the standard Rubies available from Ruby managers like `rvm` or `rbenv` (in both production and CI environments). Users needing to use the SOCKS protocol natively with one of these Rubies are presently reliant on the [socksify](https://rubygems.org/gems/socksify) Ruby gem (> 60M downloads). Declaration: I am the gem's current maintainer. The gem was originally built to provide native SOCKS support to users of these 'standard' Rubies via patches to the `Net/HTTP` and other Ruby core libraries. The current gem patches the private method `Net::HTTP#connect` in order to achieve this. This is a brittle and highly undesirable state of affairs and all code built using `socksify` is of course subject to breakage with each new Ruby release. It is difficult to gauge the exact nature and extent of the user need, but of the 60M Socksify downloads 20M have taken place is the last few years since I became maintainer. I consider this a significant user base. Many other languages provide native SOCKS support - e.g. Python has [PySocks](https://pypi.org/project/PySocks/). Fundamentally, is there any reason NOT to enable SOCKS support - would it break anything? I'd dearly like to retire the Socksify 'hack' in due course and see Ruby join the list of languages that offer SOCKS support by default - in all future Rubies. Many thanks for your consideration. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:118930] [Ruby master Feature#20692] Rewrite Array#bsearch in Ruby
by sebyx07 (Sebastian Buza) 05 Sep '24

05 Sep '24

Issue #20692 has been reported by sebyx07 (Sebastian Buza). ---------------------------------------- Feature #20692: Rewrite Array#bsearch in Ruby https://bugs.ruby-lang.org/issues/20692 * Author: sebyx07 (Sebastian Buza) * Status: Open ---------------------------------------- inspired by https://bugs.ruby-lang.org/issues/20182 Benchmark results (average over 10000000 iterations): user system total real Original bsearch: 7.011691 0.000038 7.011729 ( 7.013117) Native bsearch: 2.809711 0.001000 2.810711 ( 2.812067) https://github.com/sebyx07/native_ruby/blob/master/lib/native_ruby/array/bs… I also created this gem: https://github.com/sebyx07/native_ruby/ - to load patches w/o depending on the ruby/master -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118745] [Ruby master Misc#20658] Dropping the "Arm Neoverse (Ubuntu) server on RubyCI
by jaruga (Jun Aruga) 05 Sep '24

05 Sep '24

Issue #20658 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20658: Dropping the "Arm Neoverse (Ubuntu) server on RubyCI https://bugs.ruby-lang.org/issues/20658 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Context On July 26 2024, 4 days ago, the person at Arm sponsoring a SSH-accessing Arm server via Works on Arm program told me that they could no longer sponsor the server **after 10th August 2024**. We have been using Equinix's Arm-based virtual machine on their cloud infrastructure[2] for the server right now. The person at Arm told me that Arm is actually scaling down their servers at Equinix within the Works on Arm program. While the person at Arm suggested using their cloud offerings listed on the [1] for paid or free tier, I need to take time to investigate how to continue to use Arm-based SSH-accessing servers continuously within the Works on Arm program if we want to continue to use it. At least we need to drop the Arm-based server that is named as "Arm Neoverse (Ubuntu)" on RubyCI until 10th August 2024.[3] ## Note for Ruby project commiters using the "Arm Neoverse (Ubuntu)" server Dear commiters, Please back up your files on the "Arm Neoverse (Ubuntu)" server if you have the files. After 10th August 2024, we cannot access to the server by SSH any more. ## Steps to drop the "Arm Neoverse (Ubuntu)" I plan to do the following tasks to drop the "Arm Neoverse (Ubuntu)". * Drop the "Arm Neoverse (Ubuntu)" on RubyCI. * Remove the content about the "Ubuntu arm neoverse" on [our Wiki page](https://github.com/ruby/ruby/wiki/CI-Servers). * Drop the content about Works on Arm on www.ruby-lang.org, which I added by the pull-request <https://github.com/ruby/www.ruby-lang.org/pull/3183>. Please let me know if you find any other task about this topic. [1] Works on Arm: https://www.arm.com/markets/computing-infrastructure/works-on-arm [2] Equinix: https://www.equinix.com/ [3] RubyCI: https://rubyci.org/ -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119022] [Ruby master Bug#20711] readline/reline duplicate display of prompt
by yogo1212 (Leon Busch-George) 05 Sep '24

05 Sep '24

Issue #20711 has been reported by yogo1212 (Leon Busch-George). ---------------------------------------- Bug #20711: readline/reline duplicate display of prompt https://bugs.ruby-lang.org/issues/20711 * Author: yogo1212 (Leon Busch-George) * Status: Open * ruby -v: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby #!/usr/bin/env ruby require 'readline' prompt = "asdf: " default = "true" Readline.pre_input_hook = -> do Readline.insert_text "#{default}" Readline.redisplay Readline.pre_input_hook = nil end Readline.readline(prompt) ``` ``` prompt: trueprompt: ``` the cursor sits at the right place (behind the 'e' in 'true'). inserting a backslash causes the line to be cleared and fixes the display. expected display, correct in previous versions: ``` prompt: true ``` affected: ``` ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux] # from rbenv ``` unaffected: ``` ruby 3.0.7p220 (2024-04-23 revision 724a071175) [x86_64-linux] # RHEL 9 ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x86_64-linux] # Arch Linux package ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118969] [Ruby master Feature#20702] Add `Array#fetch_values`
by toy (Ivan Kuchin) 05 Sep '24

05 Sep '24

Issue #20702 has been reported by toy (Ivan Kuchin). ---------------------------------------- Feature #20702: Add `Array#fetch_values` https://bugs.ruby-lang.org/issues/20702 * Author: toy (Ivan Kuchin) * Status: Open ---------------------------------------- `Array` and `Hash` have matching methods to fetch: * One value using `[]` (`Array` also allows fetching multiple with range or two arguments) * One value with default or exception using `fetch` method * Multiple values using `values_at` method But only `Hash` has method `fetch_values` to fetch multiple values with fallback or raising an exception (see #10017). ```ruby hash = {a: 1, b: 2, c: 3} array = [1, 2, 3] hash[:b] # => 2 hash[:d] # => nil array[1] # => 2 array[4] # => nil hash.fetch(:b) # => 2 hash.fetch(:d) # => IndexError hash.fetch(:d){ 42 } # => 42 array.fetch(1) # => 2 array.fetch(4) # => IndexError array.fetch(4){ 42 } # => 42 hash.values_at(:b, :c) # => [2, 3] hash.values_at(:b, :d) # => [2, nil] array.values_at(1, 2) # => [2, 3] array.values_at(1, 4) # => [2, nil] hash.fetch_values(:b, :c) # => [2, 3] hash.fetch_values(:b, :d) # => IndexError hash.fetch_values(:b, :d){ 42 } # => [2, 42] # missing array.fetch_values(1, 2) # => [2, 3] array.fetch_values(1, 4) # => IndexError array.fetch_values(1, 4){ 42 } # => [2, 42] ``` -- https://bugs.ruby-lang.org/

3 2