ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2025 -----
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

April 2025

  • 3 participants
  • 138 discussions
[ruby-core:116085] [Ruby master Bug#20165] Ractors moving a Struct breaks beyond the first 3 fields
by codekitchen (Brian Palmer) 09 May '25

09 May '25
Issue #20165 has been reported by codekitchen (Brian Palmer). ---------------------------------------- Bug #20165: Ractors moving a Struct breaks beyond the first 3 fields https://bugs.ruby-lang.org/issues/20165 * Author: codekitchen (Brian Palmer) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Experimenting with Ractors on ruby 3.3.0, and I'm seeing a bug where if you move a struct between ractors, all but the first 3 fields are set to nil. ``` ruby Foo = Struct.new(:a,:b,:c,:d,:e,:f) r = Ractor.new { foo = Foo[0,0,0,0,0,0] p foo Ractor.yield(foo, move: true) } p r.take ``` ``` ❯ ruby -v ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] ❯ ruby rbug.rb rbug.rb:3: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<struct Foo a=0, b=0, c=0, d=0, e=0, f=0> #<struct Foo a=0, b=0, c=0, d=nil, e=nil, f=nil> ``` This seems specific to moving, if I set `move: false` the struct makes it across OK. -- https://bugs.ruby-lang.org/
3 2
0 0
[ruby-core:119941] [Ruby master Bug#20897] resolv: not usable across ractors
by chucke (Tiago Cardoso) 09 May '25

09 May '25
Issue #20897 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #20897: resolv: not usable across ractors https://bugs.ruby-lang.org/issues/20897 * Author: chucke (Tiago Cardoso) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Using the `resolv` library in a non-main ractor is impossible, due to DNS resources being memoized in a mutable class variable. [This patch](https://github.com/ruby/resolv/pull/62) fixes it by storing resource information in static variables. -- https://bugs.ruby-lang.org/
3 2
0 0
[ruby-core:120840] [Ruby master Misc#21100] DevMeeting before or after RubyKaigi2025
by ko1 (Koichi Sasada) 09 May '25

09 May '25
Issue #21100 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Misc #21100: DevMeeting before or after RubyKaigi2025 https://bugs.ruby-lang.org/issues/21100 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- RubyKaigi 2025 will be at Matsuyama, Japan, Apr 16th - 18th. We would like to try to hold a face-to-face dev meeting at Matsuyama. (@matz will also participate!) * Date: 2025/04/15 (Tue.) 16:00-19:00 (The day before RubyKaigi) * Location: Ehime-ken Sogo Shakai Fukushi Kaikan, 3F Training room (in Japanese) 愛媛県総合社会福祉会館3F 研修室 ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. Please sign up on the doorkeeper page: https://rubyassociation.doorkeeper.jp/events/181721 The meeting will be held in a hackathon event. Please enjoy Ruby hacking with friends if you want before the meeting. Note: Do not forget to register RubyKaigi ticket too (see "[ruby-core:120816] Invitation to RubyKaigi 2025" from Akira). ### Program * 10:00am door open and start the Hackathon event * 3:00pm(?) Matz will arrive * 4:00pm opening and self introduction * 4:30pm discuss topics * 6:00pm closing and free time (closing time is depends on topics) * 7:00pm door close ### 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 2025/04/10. I'll ask Matz which should be discussed on this meeting and reorder them. - 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/
6 8
0 0
[ruby-core:112091] [Ruby master Bug#19387] Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor
by luke-gru (Luke Gruber) 08 May '25

08 May '25
Issue #19387 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19387: Issue with ObjectSpace.each_objects not returning IO objects after starting a ractor https://bugs.ruby-lang.org/issues/19387 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do receive # block, the problem is not the termination of the ractor but the starting end ObjectSpace.each_object(IO) { |io| p io # we get no objects } ``` -- https://bugs.ruby-lang.org/
6 8
0 0
[ruby-core:121746] [Ruby Feature#21287] Remove SortedSet autoload and set/sorted_set
by jeremyevans0 (Jeremy Evans) 08 May '25

08 May '25
Issue #21287 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21287: Remove SortedSet autoload and set/sorted_set https://bugs.ruby-lang.org/issues/21287 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- When implementing core Set, I moved the `SortedSet` autoload from `lib/set.rb` to `prelude.rb`. However, since this autoload only works if the `sorted_set` gem is installed, I don't think it's a good idea to have in core. I would like to remove it. I've submitted a pull request that removes it: https://github.com/ruby/ruby/pull/13188 . I'm not sure whether people would prefer a deprecation warning before removal, to alert users who have the `sorted_set` gem installed and are relying on the autoload. Previously, the `SortedSet` autoload was only setup if you had already referenced `Set` to force loading `lib/set.rb`. So `Set; SortedSet` worked, but `SortedSet; Set` did not. If people would prefer a deprecation warning, I think it's fine to deprecate in 3.5 and remove in 3.6, and I can submit a separate pull request for that approach. -- https://bugs.ruby-lang.org/
2 1
0 0
[ruby-core:121686] [Ruby Feature#21274] Show performance warnings for easily avoidable unnecessary implicit splat allocations
by jeremyevans0 (Jeremy Evans) 08 May '25

08 May '25
Issue #21274 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21274: Show performance warnings for easily avoidable unnecessary implicit splat allocations https://bugs.ruby-lang.org/issues/21274 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- In Ruby 3.4, I made many changes to reduce implicit allocations (mostly in method calling). There are still a few cases where Ruby must allocate an array for a positional splat, or a hash for a keyword splat. Some of these allocations are unavoidable, but in other cases, while Ruby cannot avoid the allocation, it is easy for a user to make a small change to their code to avoid the allocation. One example of this is when Ruby allocates to avoid an evaluation order issue. For example: ```ruby def kw = nil ary = [] m(*ary, kw:) ``` Ruby allocates an array for `*ary`, even though it does not need to, because `kw` is a method call, and the method call could potentially modify `ary` (it doesn't in this example, but Ruby's compiler cannot assume that, as the method may be overridden later). It is simple to avoid the allocation by using a local variable: ```ruby def kw = nil ary = [] kw = self.kw m(*ary, kw:) ``` To make it easier for users to find and avoid these unnecessary implicit allocations, I would like to add a performance warning in cases where Ruby allocates solely to avoid an evaluation order issue. I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/13135 The current warning messages in the pull request are quite verbose: ``` $ ruby -W:performance -e 'def kw; {} end; a = []; p(*a, **kw)' -e: warning: This method call implicitly allocates a potentially unnecessary array for the positional splat, because a keyword, keyword splat, or block pass expression could cause an evaluation order issue if an array is not allocated for the positional splat. You can avoid this allocation by assigning the related keyword, keyword splat, or block pass expression to a local variable and using that local variable. $ ruby -W:performance -e 'def b; ->{} end; h = {}; p(**h, &b)' -e: warning: This method call implicitly allocates a potentially unnecessary hash for the keyword splat, because the block pass expression could cause an evaluation order issue if a hash is not allocated for the keyword splat. You can avoid this allocation by assigning the block pass expression to a local variable, and using that local variable. ``` It may be desirable to shorten these messages, so I would appreciate suggestions. -- https://bugs.ruby-lang.org/
3 5
0 0
[ruby-core:112207] [Ruby master Bug#19408] Object no longer frozen after moved from a ractor
by luke-gru (Luke Gruber) 08 May '25

08 May '25
Issue #19408 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19408: Object no longer frozen after moved from a ractor https://bugs.ruby-lang.org/issues/19408 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I think frozen objects should still be frozen after a move. ```ruby r = Ractor.new do obj = receive p obj.frozen? # should be true but is false p obj end obj = [Object.new].freeze r.send(obj, move: true) r.take ``` -- https://bugs.ruby-lang.org/
3 3
0 0
[ruby-core:120257] [Ruby master Bug#20957] RangeError on Array#values_at with negative ranges
by kyanagi (Kouhei Yanagita) 08 May '25

08 May '25
Issue #20957 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #20957: RangeError on Array#values_at with negative ranges https://bugs.ruby-lang.org/issues/20957 * Author: kyanagi (Kouhei Yanagita) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-13T10:19:31Z master 3cb79d4082) +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` [0, 1, 2, 3].values_at(10) #=> [nil] [0, 1, 2, 3].values_at(10..10) #=> [nil] [0, 1, 2, 3].values_at(-10) #=> [nil] [0, 1, 2, 3].values_at(-10..-10) #=> 'Array#values_at': -10..-10 out of range (RangeError) ``` Is this the intended behavior? I am aware that this behavior was recently added to the documentation, but I would like to confirm whether it is the intended behavior. -- https://bugs.ruby-lang.org/
3 2
0 0
[ruby-core:121755] [Ruby Misc#21290] Unable to build ruby extension on Fedora 42 due to possible GCC 15 issues
by lukef (Luke Freeman) 08 May '25

08 May '25
Issue #21290 has been reported by lukef (Luke Freeman). ---------------------------------------- Misc #21290: Unable to build ruby extension on Fedora 42 due to possible GCC 15 issues https://bugs.ruby-lang.org/issues/21290 * Author: lukef (Luke Freeman) * Status: Open ---------------------------------------- At least one Ruby extension (ed25519) fails to build due to incompatibilities(?) with the core library headers on Fedora 42. When trying to build the ed25519 extension that is required for Kamal (and I guess Rails by association) there are errors relating to `bool` types. I'm assuming this is related to the inclusion of GCC 15 by default in version 42. For example: ``` <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/core/rtypeddata.h:578:15: note: ‘bool’ is defined in header ‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’ In file included from <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/ruby.h:42: <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:420:5: error: unknown type name ‘bool’ 420 | bool left; /**< Whether overflow happened or not. */ | ^~~~ <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:65:1: note: ‘bool’ is defined in header ‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’ 64 | #include "ruby/internal/stdckdint.h" +++ |+#include <stdbool.h> 65 | #include "ruby/internal/xmalloc.h" <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h: In function ‘rbimpl_size_mul_overflow’: <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:574:49: error: ‘false’ undeclared (first use in this function) 574 | struct rbimpl_size_mul_overflow_tag ret = { false, 0, }; | ^~~~~ ``` I logged the relevant issue with Kamal and the ed25519 projects but figured the issue should be tracked here as anyone upgrading to Fedora 42 won't probably be able to use Rails if starting from scratch. Those issues are: - https://github.com/RubyCrypto/ed25519/issues/44 - https://github.com/basecamp/kamal/issues/1512 It's possible it is related to this issue also: https://bugs.ruby-lang.org/issues/21024. I have tried downgrading to Ruby 3.4.1 and even older, non-3.4 versions and the issue seems to be the same. I'm running: - Fedora 42 - Ruby 3.4+ Please let me know if you need additional information. -- https://bugs.ruby-lang.org/
7 7
0 0
[ruby-core:120710] [Ruby master Feature#21042] Add and expose Thread#memory_allocations memory allocation counters
by stanhu (Stan Hu) 08 May '25

08 May '25
Issue #21042 has been reported by stanhu (Stan Hu). ---------------------------------------- Feature #21042: Add and expose Thread#memory_allocations memory allocation counters https://bugs.ruby-lang.org/issues/21042 * Author: stanhu (Stan Hu) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- For the last 5 years, we've been patching our Ruby interpreter with https://github.com/ruby/ruby/pull/3978 in order to track memory allocations over time. This has been running in production at GitLab for a long time. I'd like to request approval for this patch to land upstream since we're getting tired of maintaining this patch, and this data seems like it would be generally useful. If this can be done via a C extension, let me know, and I can look at that. Copying from that pull request: ### Design This is designed to measure a memory allocations in a multi-threaded environments (concurrent requests processing) with an accurate information about allocated memory within a given execution context. The idea here is to provide as cheap as possible counter without an overhead of calling callbacks, and provide this information on a per-thread basis. ### Implementation This adds `Thread.current.memory_allocations`, which provides information about: * total_allocated_objects * total_malloc_bytes * total_mallocs This is based on a expectation, that allocation for a given thread always happens with a `rb_current_thread()` properly indicating a thread performing allocation. This measures total number of allocations as counters. Now, since the removal of objects is async and happening at random moment, the same cannot be said for deallocations, thus only allocations are tracked. -- https://bugs.ruby-lang.org/
5 5
0 0
  • ← Newer
  • 1
  • ...
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • ...
  • 14
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.