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

[ruby-core:111144] [Ruby master Feature#19171] Update Unicode data to Unicode Version 15.1
by duerst 20 Sep '24

20 Sep '24

Issue #19171 has been reported by duerst (Martin Dürst). ---------------------------------------- Feature #19171: Update Unicode data to Unicode Version 15.1 https://bugs.ruby-lang.org/issues/19171 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) ---------------------------------------- According to http://blog.unicode.org/2022/11/the-unicode-standard-2023-release.html, Unicode plans to release Version 15.1 in September 2023. According to https://www.unicode.org/versions/beta.html, public alpha review starts Feb. 7, 2023, and ends April 4, 2023. Because alpha review may not include all the files we use, it may be difficult for us to participate. Public beta review is planned to start May 23, 2023, ending July 4, 2023. At this point, we should be able to test things. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116581] [Ruby master Bug#20237] Unable to unshare(CLONE_NEWUSER) in Linux because of timer thread
by hanazuki (Kasumi Hanazuki) 16 Sep '24

16 Sep '24

Issue #20237 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #20237: Unable to unshare(CLONE_NEWUSER) in Linux because of timer thread https://bugs.ruby-lang.org/issues/20237 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2024-02-04T16:05:02Z master 8bc6fff322) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ## Backgrounds [unshare(2)](https://man7.org/linux/man-pages/man2/unshare.2.html) is a syscall in Linux to move the calling process into a fresh execution context. With `unshare(CLONE_NEWUSER)` you can move a process into a new [user_namespace(7)](https://man7.org/linux/man-pages/man7/user_namespaces.7.…, where the process gains the full capability on the resources within the namespace. This is fundamental for Linux containers to achieve privilege separation. `unshare(CLONE_NEWUSER)` requires the calling process to be single-threaded (or no background threads are running). So, it is often invoked after `fork(2)` as forking propagates only the calling thread to the child process. ## Problem It becomes a problem that Ruby 3.3 on Linux uses timer threads even for a single-`Thread`ed application. Because `Kernel#fork` spawns a thread in the child process before the control returns to the user code, there is no chance to call `unshare(CLONE_NEWUSER)` in Ruby. The following snippet is a reproducer of this problem. This program first forks and then shows the user namespace to which the process belongs before and after calling unshare(2). It also shows the threads of the child process after forking. ```ruby p(RUBY_DESCRIPTION:) require 'fiddle/import' module C extend Fiddle::Importer dlload 'libc.so.6' extern 'int unshare(int flags)' CLONE_NEWUSER = 0x10000000 def self.raise_system_call_error raise SystemCallError.new(Fiddle.last_error) end end pid = fork do system("ps -O tid -T -p #$$") system("ls -l /proc/self/ns/user") if C.unshare(C::CLONE_NEWUSER) != 0 C.raise_system_call_error # => EINVAL with Ruby 3.3 end system("ls -l /proc/self/ns/user") end p Process.wait2(pid) ``` The program successfully changes the user namespace with Ruby 3.2, but it raises EINVAL with Ruby 3.3. You can see Ruby 3.3 has two threads running after forking. ``` % rbenv shell 3.2 && ruby ./test.rb {:RUBY_DESCRIPTION=>"ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux]"} PID TID S TTY TIME COMMAND 1585787 1585787 S pts/12 00:00:00 ruby ./test.rb lrwxrwxrwx 1 kasumi kasumi 0 Feb 5 02:25 /proc/self/ns/user -> 'user:[4026531837]' lrwxrwxrwx 1 nobody nogroup 0 Feb 5 02:25 /proc/self/ns/user -> 'user:[4026532675]' [1585787, #<Process::Status: pid 1585787 exit 0>] % rbenv shell 3.3 && ruby ./test.rb {:RUBY_DESCRIPTION=>"ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux]"} PID TID S TTY TIME COMMAND 1585849 1585849 S pts/12 00:00:00 ruby ./test.rb 1585849 1585851 S pts/12 00:00:00 ruby ./test.rb lrwxrwxrwx 1 kasumi kasumi 0 Feb 5 02:25 /proc/self/ns/user -> 'user:[4026531837]' ./test.rb:10:in `raise_system_call_error': Invalid argument (Errno::EINVAL) from ./test.rb:24:in `block in <main>' from ./test.rb:19:in `fork' from ./test.rb:19:in `<main>' [1585849, #<Process::Status: pid 1585849 exit 1>] % rbenv shell master && ruby ./test.rb {:RUBY_DESCRIPTION=>"ruby 3.4.0dev (2024-02-04T16:05:02Z master 8bc6fff322) [x86_64-linux]"} PID TID S TTY TIME COMMAND 1585965 1585965 S pts/12 00:00:00 ruby ./test.rb 1585965 1585967 S pts/12 00:00:00 ruby ./test.rb lrwxrwxrwx 1 kasumi kasumi 0 Feb 5 02:25 /proc/self/ns/user -> 'user:[4026531837]' ./test.rb:10:in `raise_system_call_error': Invalid argument (Errno::EINVAL) from ./test.rb:24:in `block in <main>' from ./test.rb:19:in `fork' from ./test.rb:19:in `<main>' [1585965, #<Process::Status: pid 1585965 exit 1>] ``` ## Workaround My workaround is to rebuild ruby with `rb_thread_stop_timer_thread` and `rb_thread_start_timer_thread` exported, and use a C-ext that stops the timer thread before calling `unshare`. This seems not robust because the process cannot know when the terminated thread is reclaimed by the kernel, after which the process is considered single-threaded. ```c #define _GNU_SOURCE 1 #include <sched.h> #include <ruby/ruby.h> static VALUE Unshare_s_unshare(VALUE _self, VALUE rflags) { int const flags = NUM2INT(rflags); rb_thread_stop_timer_thread(); usleep(1000); // FIXME: It takes some time for the kernel to remove the stopped thread? int const ret = unshare(flags); rb_thread_start_timer_thread(); if(ret != 0) rb_sys_fail_str(rb_sprintf("unshare(%#x)", flags)); return Qnil; } RUBY_FUNC_EXPORTED void Init_unshare(void) { VALUE rb_mUnshare = rb_define_module("Unshare"); rb_define_singleton_method(rb_mUnshare, "unshare", Unshare_s_unshare, 1); rb_define_const(rb_mUnshare, "CLONE_NEWUSER", INT2FIX(CLONE_NEWUSER)); } ``` ## Questions - Is this a limitation of Ruby? - Is it safe (or even possible) to stop the timer thread during execution? - If so, can we export it as the public API? - But it may not so useful for this problem as explained in the workaround. - Is it guaranteed that no other threads are running after forks? - Are there any better ways to solve this issue? - Can we somehow delay the start of the timer thread after forking, or hook into `fork` to run some code in the child process immediately after it spawns. - Can they be Ruby API instead of C API? -- https://bugs.ruby-lang.org/

4 9

[ruby-core:117783] [Ruby master Bug#20473] Ractor array/hash literals
by kddnewton (Kevin Newton) 13 Sep '24

13 Sep '24

Issue #20473 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20473: Ractor array/hash literals https://bugs.ruby-lang.org/issues/20473 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- There are many optimizations in place in the compiler to ensure Ruby doesn't overflow the stack when an array or hash literal has many values. For example: ```ruby puts RubyVM::InstructionSequence.compile(<<~RUBY).disasm [#{Array.new(512) { |index| index % 128 == 0 ? "\"\#{nil}\"" : "1" }.join(", ")}] RUBY ``` gives the instructions: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,1564)> 0000 putobject "" ( 1)[Li] 0002 putnil 0003 dup 0004 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0006 anytostring 0007 concatstrings 2 0009 newarray 1 0011 putobject [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] 0013 concatarray 0014 putobject "" 0016 putnil 0017 dup 0018 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0020 anytostring 0021 concatstrings 2 0023 newarray 1 0025 concatarray 0026 putobject [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] 0028 concatarray 0029 putobject "" 0031 putnil 0032 dup 0033 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0035 anytostring 0036 concatstrings 2 0038 newarray 1 0040 concatarray 0041 putobject [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] 0043 concatarray 0044 putobject "" 0046 putnil 0047 dup 0048 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0050 anytostring 0051 concatstrings 2 0053 newarray 1 0055 concatarray 0056 putobject [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] 0058 concatarray 0059 leave ``` because it is smart enough to group the static elements together and use concatarray. This ensures we never have too many values on the stack. In Ruby 3.3, this worked for ractors as well. (Adding `# shareable_constant_value: literal` and `A =` to the example above doesn't change anything about the instructions above except adding a couple of `-@` calls and one call to `make_shareable`. On HEAD, all of these optimizations are now gone. With this: ```ruby puts RubyVM::InstructionSequence.compile(<<~RUBY).disasm # shareable_constant_value: literal A = [#{Array.new(512) { |index| index % 128 == 0 ? "\"\#{nil}\"" : "1" }.join(", ")}] RUBY ``` code on master, we get: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(2,1568)> 0000 putobject RubyVM::FrozenCore ( 2)[Li] 0002 putobject "" 0004 putnil 0005 dup 0006 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0008 anytostring 0009 concatstrings 2 0011 opt_send_without_block <calldata!mid:-@, argc:0, ARGS_SIMPLE> 0013 putobject_INT2FIX_1_ ~~~~ 0139 putobject_INT2FIX_1_ 0140 putobject "" 0142 putnil 0143 dup 0144 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0146 anytostring 0147 concatstrings 2 0149 opt_send_without_block <calldata!mid:-@, argc:0, ARGS_SIMPLE> 0151 putobject_INT2FIX_1_ ~~~~ 0277 putobject_INT2FIX_1_ 0278 putobject "" 0280 putnil 0281 dup 0282 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0284 anytostring 0285 concatstrings 2 0287 opt_send_without_block <calldata!mid:-@, argc:0, ARGS_SIMPLE> 0289 putobject_INT2FIX_1_ ~~~~ 0415 putobject_INT2FIX_1_ 0416 putobject "" 0418 putnil 0419 dup 0420 objtostring <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE> 0422 anytostring 0423 concatstrings 2 0425 opt_send_without_block <calldata!mid:-@, argc:0, ARGS_SIMPLE> 0427 putobject_INT2FIX_1_ ~~~~ 0553 putobject_INT2FIX_1_ 0554 newarray 512 0556 opt_send_without_block <calldata!mid:make_shareable, argc:1, ARGS_SIMPLE> 0558 dup 0559 putspecialobject 3 0561 setconstant :A 0563 leave ``` where the `~~~~` represents another 128 `putobject_INT2FIX_1_` instructions. I assume this was done because it used to modify the AST and that got removed. However, I also assume it was not intentional to lose all of these optimizations, as it now means if Ractors are being used that large literals are vulnerable to stack overflows. Please let me know how to proceed, as I am trying to exactly match behavior in the prism compiler. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:118388] [Ruby master Feature#20594] A new String method to append bytes while preserving encoding
by byroot (Jean Boussier) 11 Sep '24

11 Sep '24

Issue #20594 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20594: A new String method to append bytes while preserving encoding https://bugs.ruby-lang.org/issues/20594 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context When working with binary protocols such as `protobuf` or `MessagePack`, you may often need to assemble multiple strings of different encoding: ```ruby Post = Struct.new(:title, :body) do def serialize(buf) buf << 255 << title.bytesize << title << 255 << body.bytesize << body end end Post.new("Hello", "World").serialize("somedata".b) # => "somedata\xFF\x05Hello\xFF\x05World" #<Encoding:ASCII-8BIT> ``` The problem in the above case, is that because `Encoding::ASCII_8BIT` is declared as ASCII compatible, if one of the appended string contains bytes outside the ASCII range, string is automatically promoted to another encoding, which then leads to encoding issues: ```ruby Post.new("H€llo", "Wôrld").serialize("somedata".b) # => incompatible character encodings: ASCII-8BIT and UTF-8 (Encoding::CompatibilityError) ``` In many cases, you want to append to a String without changing the receiver's encoding. The issue isn't exclusive to binary protocols and formats, it also happen with ASCII protocols that accept arbitrary bytes inline, like Redis's RESP protocol or even HTTP/1.1. ### Previous discussion There was a similar feature request a while ago, but it was abandoned: https://bugs.ruby-lang.org/issues/14975 ### Existing solutions You can of course always cast the strings you append to avoid this problem: ```ruby Post = Struct.new(:title, :body) do def serialize(buf) buf << 255 << title.bytesize << title.b << 255 << body.bytesize << body.b end end ``` But this cause a lot of needless allocations. You'd think you could also use `bytesplice`, but it actually has the same issue: ```ruby Post = Struct.new(:title, :body) do def serialize(buf) buf << 255 << title.bytesize buf.bytesplice(buf.bytesize, title.bytesize, title) buf << 255 << body.bytesize buf.bytesplice(buf.bytesize, body.bytesize, title) end end Post.new("H€llo", "Wôrld").serialize("somedata".b) # => 'String#bytesplice': incompatible character encodings: BINARY (ASCII-8BIT) and UTF-8 (Encoding::CompatibilityError) ``` And even if it worked, it would be very unergonomic. ### Proposal: a `byteconcat` method A solution to this would be to add a new `byteconcat` method, that could be shimed as: ```ruby class String def byteconcat(*strings) strings.map! do |s| if s.is_a?(String) && s.encoding != encoding s.dup.force_encoding(encoding) else s end end concat(*strings) end end Post = Struct.new(:title, :body) do def serialize(buf) buf.byteconcat( 255, title.bytesize, title, 255, body.bytesize, body, ) end end Post.new("H€llo", "Wôrld").serialize("somedata".b) # => "somedata\xFF\aH\xE2\x82\xACllo\xFF\x06W\xC3\xB4rld" #<Encoding:ASCII-8BIT> ``` But of course a builtin implementation wouldn't need to dup the arguments. Like other `byte*` methods, it's the responsibility of the caller to ensure the resulting string has a valid encoding, or to deal with it if not. ### Method name and signature #### Name This proposal suggests `String#byteconcat`, to mirror `String#concat`, but other names are possible: - `byteappend` (like `Array#append`) - `bytepush` (like `Array#push`) #### Signature This proposal makes `byteconcat` accept either `String` or `Integer` (in char range) arguments like `concat`. I believe it makes sense for consistency and also because it's not uncommon for protocols to have some byte based segments, and Integers are more convenient there. The proposed method also accept variable arguments for consistency with `String#concat`, `Array#push`, `Array#append`. The proposed method returns self, like `concat` and others. ### YJIT consideration I consulted @maximecb about this proposal, and according to her, accepting variable arguments makes it harder for YJIT to optimize. I suspect consistency with other APIs trumps the performance consideration, but I think it's worth mentioning. -- https://bugs.ruby-lang.org/

12 31

[ruby-core:118796] [Ruby master Bug#20667] Backport ReXML CVE fixes
by vo.x (Vit Ondruch) 10 Sep '24

10 Sep '24

Issue #20667 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20667: Backport ReXML CVE fixes https://bugs.ruby-lang.org/issues/20667 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It would be nice to have the recent ReXML CVE fixes backported everywhere. BTW it is surprising that ReXML was recently bumped in 3.1 / 3.2 branches, but 3.3 brach stays with older ReXML 3.2. -- https://bugs.ruby-lang.org/

4 4

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

06 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) 06 Sep '24

06 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) 06 Sep '24

06 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: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

[ruby-core:118970] [Ruby master Feature#20703] Alias StringIO#string to StringIO#to_s
by sebyx07 (Sebastian Buza) 05 Sep '24

05 Sep '24

Issue #20703 has been reported by sebyx07 (Sebastian Buza). ---------------------------------------- Feature #20703: Alias StringIO#string to StringIO#to_s https://bugs.ruby-lang.org/issues/20703 * Author: sebyx07 (Sebastian Buza) * Status: Open ---------------------------------------- # Description Allow to use `StringIO.new('my string').to_s` to be the same as `StringIO.new('my string').string` IMO nobody really uses the current StringIO#to_s, so I don't think it will break other apps. That way you can also do interpolation easily ```ruby my_sio = StringIO.new('my string') puts "value: #{my_sio}" # value: my string ``` - issue: https://github.com/ruby/stringio/issues - pr: https://github.com/ruby/stringio/pull/103 -- https://bugs.ruby-lang.org/

4 4