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

[ruby-core:121127] [Ruby master Bug#21150] Segfault in Ractor messes up libunwind (c backtrace info)
by luke-gru (Luke Gruber) 19 Feb '25

19 Feb '25

Issue #21150 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21150: Segfault in Ractor messes up libunwind (c backtrace info) https://bugs.ruby-lang.org/issues/21150 * Author: luke-gru (Luke Gruber) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Macos Arm64 with llvm18, libunwind fails with SEGV when called within a Ractor. So, the bug report fails with a SEGV and quits right before giving C backtrace information. It looks like: ``` -- Ruby level backtrace information ---------------------------------------- ../ruby/test.rb:49:in 'block in <main>' <internal:ractor>:902:in 'fail_assert' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- <internal:ractor>:902: [BUG] Segmentation fault at 0xfffffffffffffff8 ``` It tried to dereference the value -8, it looks like. ### To reproduce: `test.rb`: ```ruby r = Ractor.new do Ractor.fail_assert # to produce a bug report end r.take ``` `ractor.rb`: ```ruby def self.fail_assert __builtin_cexpr! %q{ VM_ASSERT(0), Qfalse } end ``` ### System info: `clang --version`: Homebrew clang version 18.1.8 Target: arm64-apple-darwin24.3.0 Thread model: posix `otool -L miniruby`: /opt/homebrew/opt/llvm(a)18/lib/libunwind.1.dylib (compatibility version 1.0.0, current version 1.0.0) I haven't tried to reproduce it on another system, but I did try with clang 16 and got the same results. ### Possible Causes This is just a guess, but I think the coroutine context switching is messing up libunwind's stack unwinding heuristic. ### Other issues that this causes Right now, if ruby receives a SEGV in a ractor, it tries to print the bug report and then receives another SEGV when running the libunwind code. This hangs the program because the sigaction for the SEGV signal was installed without SA_NODEFER, so that SEGV is blocked (masked) by the running handler. The program can't make any forward progress, so it hangs. The solution here is just to install the fatal handlers with SA_NODEFER. There is code already that checks if the bug report has already been called and it just aborts the process. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121121] [Ruby master Bug#21149] Strange behavior of ObjectSpace.each_object after Ractor.new
by wanabe (_ wanabe) 19 Feb '25

19 Feb '25

Issue #21149 has been reported by wanabe (_ wanabe). ---------------------------------------- Bug #21149: Strange behavior of ObjectSpace.each_object after Ractor.new https://bugs.ruby-lang.org/issues/21149 * Author: wanabe (_ wanabe) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I found the strange behavior of `ObjectSpace.each_object`. It misses some objects after `Ractor.new`. ``` $ ruby -ve 'class Foo; end; foo = Foo.new; Ractor.new do buz = Foo.new end.take; bar = Foo.new; p [ObjectSpace.each_object(Foo).to_a, foo.class, bar.class]' ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] -e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [[], Foo, Foo] ``` Of course it works well without `Ractor.new`. ``` $ ruby -ve 'class Foo; end; foo = Foo.new; bar = Foo.new; p [ObjectSpace.each_object(Foo).to_a, foo.class, bar.class]' ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] [[#<Foo:0x00007fa84f4b26d0>, #<Foo:0x00007fa84f4b27c0>], Foo, Foo] ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119142] [Ruby master Bug#20727] YJIT segmentation fault inside of invalidate_block_version
by jhawthorn (John Hawthorn) 18 Feb '25

18 Feb '25

Issue #20727 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20727: YJIT segmentation fault inside of invalidate_block_version https://bugs.ruby-lang.org/issues/20727 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For a while we've been seeing an occasional segfault in production inside of YJIT's invalidation code. It seems to happen most often when a invalidation on a widely used CME. ``` [BUG] Segmentation fault at 0x0000000000000014" "ruby 3.3.5 (2024-09-04 revision 4f143c3038) +YJIT [x86_64-linux]" null "-- Control frame information -----------------------------------------------" "c:0174 p:---- s:1247 e:001246 CFUNC :extend_object" "c:0173 p:---- s:1244 e:001243 CFUNC :extend" "c:0172 p:0049 s:1239 e:001238 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/activerecord-8.0.0.alpha.6395186/lib/active_record/relation/query_methods.rb:1467" "c:0171 p:0024 s:1233 e:001232 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/activerecord-8.0.0.alpha.6395186/lib/active_record/relation/query_methods.rb:1456" "c:0170 p:0055 s:1227 e:001226 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/will_paginate-4.0.1/lib/will_paginate/active_record.rb:170" "c:0169 p:0076 s:1219 e:001218 METHOD /build/vendor/gems/3.3.5/ruby/3.3.0/gems/will_paginate-4.0.1/lib/will_paginate/active_record.rb:154" -----8<----- null "-- Threading information ---------------------------------------------------" "Total ractor count: 1" "Ruby thread count for this ractor: 19" null "-- Machine register context ------------------------------------------------" " RIP: 0x0000563c0aaccef7 RBP: 0x00007f481524f5f0 RSP: 0x00007fffe8631d70" " RAX: 0x0000000000000014 RBX: 0x0000000000000010 RCX: 0x000000000000000e" " RDX: 0x0000000002ff9bab RDI: 0x00007f4839357520 RSI: 0x0000000000000008" " R8: 0x00007f480cc0f5e0 R9: 0x0000000000000800 R10: 0x00007f48af4008c0" " R11: 0x0000000000000060 R12: 0x0000563c0ad93108 R13: 0x00007f4816abe260" " R14: 0x000000000000000e R15: 0x0000000002f9d50f EFL: 0x0000000000010206" null "-- C level backtrace information -------------------------------------------" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_print_backtrace+0x11) [0x563c0a9ff8df] vm_dump.c:820" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_vm_bugreport) vm_dump.c:1151" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x563c0abc2a1c] error.c:1065" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(sigsegv+0x4d) [0x563c0a94e02d] signal.c:926" "/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f48afba1420]" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(0x563c0aaccef7) [0x563c0aaccef7]" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby({closure#0}) yjit/src/core.rs:718" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(invalidate_block_version) yjit/src/core.rs:3237" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby({closure#0}+0xe6) [0x563c0aaf1586] yjit/src/invariants.rs:246" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(do_call<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>) /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(try<(), yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}>) /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(catch_unwind<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>+0x8) [0x563c0aae2d68] /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/s> "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(with_vm_lock<yjit::invariants::rb_yjit_cme_invalidate::{closure_env#0}, ()>) yjit/src/cruby.rs:646" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_yjit_cme_invalidate+0x5c) [0x563c0aae6e0c] yjit/src/invariants.rs:243" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(vm_cme_invalidate+0x12) [0x563c0a9d78bd] vm_method.c:126" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(clear_method_cache_by_id_in_class) vm_method.c:240" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(clear_module_cache_i+0x13) [0x563c0ab2d263] class.c:1234" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(rb_id_table_foreach+0x84) [0x563c0a9891c4] id_table.c:278" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(do_include_modules_at+0x16a) [0x563c0ab31a0a] class.c:1314" "/build/vendor/ruby/4f143c30380724f14341665b622148b0646138fe/bin/ruby(include_modules_at+0x1a) [0x563c0ab31f61] class.c:1370" -----8<----- ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120743] [Ruby master Bug#21049] Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables`
by mame (Yusuke Endoh) 18 Feb '25

18 Feb '25

Issue #21049 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21049: Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables` https://bugs.ruby-lang.org/issues/21049 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: matz (Yukihiro Matsumoto) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, `Binding#local_variable*` APIs wrongly handles the numbered parameters. ```ruby # Binding#local_variables includes numbered parameters that should not be visible "foo".tap do _1 "bar".tap do p binding.local_variables #=> expected: [], actual: [:_1] end end # Binding#local_variable_get can read numbered parameters that should not be readable "foo".tap do _1 "bar".tap do p binding.local_variable_get(:_1) #=> expected: NameError, actual: "foo" end end # Binding#local_variable_set can update numbered parameter "foo".tap do p _1 #=> "foo" binding.local_variable_set(:_1, "bar") # expected: NameError, actual: updates _1 p _1 #=> "bar" end ``` My proposal is to stop handling numbered parameters and "it" parameter in `Binding#local_variable*` APIs. ```ruby "foo".tap do _1 binding.local_variables #=> proposed: [] binding.local_variable_get(:_1) #=> proposed: NameError end ``` Here is a proof-of-concept patch. https://github.com/ruby/ruby/pull/12601 It would be theoretically possible to fix `Binding#local_variable*` APIs to handle numbered parameters while maintaining compatibility as much as possible. However, I think the implicit “it” parameter introduced in Ruby 3.4 poses a spec-level problem. This is because there is no way to distinguish between the implicit “it” parameter and a true local variable named "it". Also, I don't think numbered parameters are local variables, so I feel uncomfortable handling them by `Binding#local_variable*` APIs. If it is absolutely necessary to access numbered parameters or "it" parameter via binding, it would be good to introduce dedicated APIs for the purpose, as: * Binding#numbered_parameters #=> [:_1, :_2, :_3, ...] * Binding#numbered_parameter_get(:_1) #=> obj * Binding#numbered_parameter_defined?(:_1) #=> true or false * Binding#it_get #=> obj * Binding#it_defined? #=> true or false Personally, however, I do not see the need for these APIs currently. I implemented them as proof-of-concept in PR, but I am okay that they are not introduced. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120660] [Ruby master Bug#21036] Somewhat confusing behaviour between warning "block passed may be ignored", versus the responsible method triggering this warning already being faulty and can never be run successfully due to errors such as "wrong number of arguments" and/or recursive cal
by rubyFeedback (robert heiler) 17 Feb '25

17 Feb '25

Issue #21036 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Bug #21036: Somewhat confusing behaviour between warning "block passed may be ignored", versus the responsible method triggering this warning already being faulty and can never be run successfully due to errors such as "wrong number of arguments" and/or recursive cal https://bugs.ruby-lang.org/issues/21036 * Author: rubyFeedback (robert heiler) * Status: Open * ruby -v: ruby 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Today I was updating / porting some legacy code, to ruby 3.4.1. Ruby 3.4.1 changed a few things, including some warnings, which is actually quite useful in the long run, in my opinion - although right now requiring some changes, which takes time. One new warning or notification is this: warning: the block passed to 'Object#xyz' defined at bla.rb:5 may be ignored So ruby now warns the developer that a block argument may be ignored. This is new information, which is useful. However had, while it takes the brain to adjust to this slowly, I actually encountered a small situation where the ruby warning reported here is a little bit awkward. Let me show a minimal script that reproduces this issue, so you can copy / paste it quickly: #!/usr/bin/ruby -w # Encoding: UTF-8 # frozen_string_literal: true # =========================================================================== # def is_recursive_but_wrong abc = is_recursive_but_wrong(abc) { :automatic } return '' end is_recursive_but_wrong Don't worry about this example being nonsensical, I actually had two bugs in one go. :D When you run the above ruby code, from a .rb file, it will report something like this: huh.rb:6: warning: the block passed to 'Object#is_recursive_but_wrong' defined at huh.rb:5 may be ignored huh.rb:5:in 'is_recursive_but_wrong': wrong number of arguments (given 1, expected 0) (ArgumentError) from huh.rb:6:in 'Object#is_recursive_but_wrong' from huh.rb:10:in '<main>' In this aptly named file called huh.rb (capturing my surprise as filename), you can see two things: 1) the warning about the block being ignored, and 2) the wrong number of arguments given I actually accidentally copy/pasted code, and in another .rb file I had a method called "created_scrolled_window" to return a scrolled-window widget from ruby-gtk3, but I first focused on the block warning given. So the first focus I made was on the "ignored block parameter", as I tend to fix these quickly, first, due to them being fairly simple. I then realised I recursively called that method. So why do I think that behaviour is strange? Well - the to me surprising part has been that I get BOTH the warning AND the issue of a wrong number of arguments. In such a situation I would prefer the wrong number of arguments reported, but not the warning about "ignored block parameter given", as that latter is less problematic (which is ok as a warning, but it still takes my attention to it, since it is reported first). Only after the "wrong number of arguments" would I think is that warning ok, as ruby can not know whether the intent truly was to ignore the block, or whether prior to that, the method is already wrong. Interestingly when I changed the above code to this variant: #!/usr/bin/ruby -w # Encoding: UTF-8 # frozen_string_literal: true # =========================================================================== # def is_recursive_but_wrong abc = is_recursive_but_wrong(def) { :automatic } return '' end is_recursive_but_wrong Aka changing the second "abc" to "def", all not defined, I get a totally different error, which is even more confusing: huh.rb:6: warning: assigned but unused variable - abc huh.rb: --> huh.rb Unmatched keyword, missing `end' ? 5 def is_recursive_but_wrong > 6 abc = is_recursive_but_wrong(def) { :automatic } > 7 return '' 8 end huh.rb:6: syntax errors found (SyntaxError) 4 | # =========================================================================== # 5 | def is_recursive_but_wrong > 6 | ... ) { :automatic } | ^ unexpected ')', ignoring it | ^ expected a delimiter to close the parameters | ^ unexpected ')'; expected a method name | ^ expected a `=>` between the hash key and value | ^ unexpected '}'; expected a value in the hash literal 7 | return '' 8 | end 9 | > 10 | is_recursive_but_wrong | ^~~~~~~~~~~~~~~~~~~~~~ unexpected local variable or method, expecting end-of-input | ^~~~~~~~~~~~~~~~~~~~~~ unexpected local variable or method; expected a `)` to close the arguments | ^ expected an `end` to close the `def` statement | ^ unexpected end-of-input, assuming it is closing the parent top level context By the way I like the change to use a red arrows there, that is quite helpful. Now, the above error makes sense I suppose because the ruby parser has to be kept in a "flexible" state, to evaluate ruby code (the old parse versus prism), but to me all of the above is a bit confusing nonetheless. Or perhaps the priorities are different. It may be difficult for ruby and the parsers to evaluate the intent of the programmer, I get it, and people may write odd code and also odd-but-valid code, but at the least in example 1, I would reason that the "ignored block warning" should not be shown if the underlying error, within that same method, means it can never be truly evaluated. I think in such a case, perhaps say 99% of the situations, whether the block is evaluated or not, is irrelevant, because the method itself is faulty and can never be correct (in my case, both as recursive call to itself, and also wrong arguments actually). I have no good suggestion to fix this as perhaps this may be intended behaviour, but perhaps I am not the only one who may be confused about the above, so I'll report it just in case. Please feel free to close this issue at any moment in time; it may not be a bug, but I found it better to file it under "Bug" rather than issue request or misc. (Perhaps in the long run we may improve on the warnings-versus-error issue a little bit. I also don't have a good suggestion here, but I remember from issues in the past that warnings can be both helpful but also confusing or spammy to some users. Any simple but effective solution here in the long run may be useful for ruby developers in general.) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120992] [Ruby master Feature#21135] Feature request: Enumerable.compare_count
by Student (Nathan Zook) 17 Feb '25

17 Feb '25

Issue #21135 has been reported by Student (Nathan Zook). ---------------------------------------- Feature #21135: Feature request: Enumerable.compare_count https://bugs.ruby-lang.org/issues/21135 * Author: Student (Nathan Zook) * Status: Open ---------------------------------------- Enumerables at times can be quite expensive to complete expand. If all is desired is to compare the count, we can terminate the enumeration once the result is known. The functionality that I envision, if implemented in ruby, might look like this: ```ruby module Enumerable def compare_count(operation, standard, &blk) case operation when :< compare_count_lt(standard, &blk) when :>= !compare_count_lt(standard, &blk) when :> compare_count_spaceship(standard, &blk) == 1 when :<= compare_count_spaceship(standard, &blk) != 1 when :== compare_count_spaceship(standard, &blk) == 0 when :!= compare_count_spaceship(standard, &blk) != 0 end end def compare_count_lt(standard, &blk) truncate_count(standard - 1, &blk) < standard end def compare_count_spaceship(standard, &blk) truncate_count(standard, &blk) <=> standard end def truncate_count(limit, &blk) return 0 if limit < 0 found = 0 each do |ele| found += 1 unless blk && !yield(ele) break if found > limit end found end end class Demo include Enumerable attr_reader :capacity attr_reader :cnt def initialize(capacity) @capacity = capacity end def each @cnt = 0 while cnt < capacity @cnt += 1 yield cnt end end end %i{< <= >= > == !=}.each do |op| d = Demo.new(3) (-1..5).each do |x| puts [op, x, d.compare_count(op, x), d].inspect end end require 'prime' %i{< <= >= > == !=}.each do |op| d = Demo.new(6) (-1..5).each do |x| puts [op, x, d.compare_count(op, x){|p| Prime.prime?(p)} , d].inspect end end ``` ``` [:<, -1, false, #<Demo:0x034d567c @capacity=3>] [:<, 0, false, #<Demo:0x034d567c @capacity=3>] [:<, 1, false, #<Demo:0x034d567c @capacity=3, @cnt=1>] [:<, 2, false, #<Demo:0x034d567c @capacity=3, @cnt=2>] [:<, 3, false, #<Demo:0x034d567c @capacity=3, @cnt=3>] [:<, 4, true, #<Demo:0x034d567c @capacity=3, @cnt=3>] [:<, 5, true, #<Demo:0x034d567c @capacity=3, @cnt=3>] [:<=, -1, false, #<Demo:0x034d512c @capacity=3>] [:<=, 0, false, #<Demo:0x034d512c @capacity=3, @cnt=1>] [:<=, 1, false, #<Demo:0x034d512c @capacity=3, @cnt=2>] [:<=, 2, false, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:<=, 3, true, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:<=, 4, true, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:<=, 5, true, #<Demo:0x034d512c @capacity=3, @cnt=3>] [:>=, -1, true, #<Demo:0x034d4d44 @capacity=3>] [:>=, 0, true, #<Demo:0x034d4d44 @capacity=3>] [:>=, 1, true, #<Demo:0x034d4d44 @capacity=3, @cnt=1>] [:>=, 2, true, #<Demo:0x034d4d44 @capacity=3, @cnt=2>] [:>=, 3, true, #<Demo:0x034d4d44 @capacity=3, @cnt=3>] [:>=, 4, false, #<Demo:0x034d4d44 @capacity=3, @cnt=3>] [:>=, 5, false, #<Demo:0x034d4d44 @capacity=3, @cnt=3>] [:>, -1, true, #<Demo:0x034d4998 @capacity=3>] [:>, 0, true, #<Demo:0x034d4998 @capacity=3, @cnt=1>] [:>, 1, true, #<Demo:0x034d4998 @capacity=3, @cnt=2>] [:>, 2, true, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:>, 3, false, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:>, 4, false, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:>, 5, false, #<Demo:0x034d4998 @capacity=3, @cnt=3>] [:==, -1, false, #<Demo:0x034d4600 @capacity=3>] [:==, 0, false, #<Demo:0x034d4600 @capacity=3, @cnt=1>] [:==, 1, false, #<Demo:0x034d4600 @capacity=3, @cnt=2>] [:==, 2, false, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:==, 3, true, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:==, 4, false, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:==, 5, false, #<Demo:0x034d4600 @capacity=3, @cnt=3>] [:!=, -1, true, #<Demo:0x034d4268 @capacity=3>] [:!=, 0, true, #<Demo:0x034d4268 @capacity=3, @cnt=1>] [:!=, 1, true, #<Demo:0x034d4268 @capacity=3, @cnt=2>] [:!=, 2, true, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:!=, 3, false, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:!=, 4, true, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:!=, 5, true, #<Demo:0x034d4268 @capacity=3, @cnt=3>] [:<, -1, false, #<Demo:0x00007f64147c37e0 @capacity=6>] [:<, 0, false, #<Demo:0x00007f64147c37e0 @capacity=6>] [:<, 1, false, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=2>] [:<, 2, false, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=3>] [:<, 3, false, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=5>] [:<, 4, true, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=6>] [:<, 5, true, #<Demo:0x00007f64147c37e0 @capacity=6, @cnt=6>] [:<=, -1, false, #<Demo:0x00007f64147c21d8 @capacity=6>] [:<=, 0, false, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=2>] [:<=, 1, false, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=3>] [:<=, 2, false, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=5>] [:<=, 3, true, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=6>] [:<=, 4, true, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=6>] [:<=, 5, true, #<Demo:0x00007f64147c21d8 @capacity=6, @cnt=6>] [:>=, -1, true, #<Demo:0x00007f64147c0860 @capacity=6>] [:>=, 0, true, #<Demo:0x00007f64147c0860 @capacity=6>] [:>=, 1, true, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=2>] [:>=, 2, true, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=3>] [:>=, 3, true, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=5>] [:>=, 4, false, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=6>] [:>=, 5, false, #<Demo:0x00007f64147c0860 @capacity=6, @cnt=6>] [:>, -1, true, #<Demo:0x00007f64147df260 @capacity=6>] [:>, 0, true, #<Demo:0x00007f64147df260 @capacity=6, @cnt=2>] [:>, 1, true, #<Demo:0x00007f64147df260 @capacity=6, @cnt=3>] [:>, 2, true, #<Demo:0x00007f64147df260 @capacity=6, @cnt=5>] [:>, 3, false, #<Demo:0x00007f64147df260 @capacity=6, @cnt=6>] [:>, 4, false, #<Demo:0x00007f64147df260 @capacity=6, @cnt=6>] [:>, 5, false, #<Demo:0x00007f64147df260 @capacity=6, @cnt=6>] [:==, -1, false, #<Demo:0x00007f64147dd898 @capacity=6>] [:==, 0, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=2>] [:==, 1, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=3>] [:==, 2, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=5>] [:==, 3, true, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=6>] [:==, 4, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=6>] [:==, 5, false, #<Demo:0x00007f64147dd898 @capacity=6, @cnt=6>] [:!=, -1, true, #<Demo:0x00007f64147dbf20 @capacity=6>] [:!=, 0, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=2>] [:!=, 1, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=3>] [:!=, 2, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=5>] [:!=, 3, false, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=6>] [:!=, 4, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=6>] [:!=, 5, true, #<Demo:0x00007f64147dbf20 @capacity=6, @cnt=6>] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121072] [Ruby master Feature#16993] Sets: from hash keys using Hash#key_set
by greggzst (Grzegorz Jakubiak) 15 Feb '25

15 Feb '25

Issue #16993 has been updated by greggzst (Grzegorz Jakubiak). nobu (Nobuyoshi Nakada) wrote in #note-5: > This kind of extensions should be done in the corresponding library side, set.rb. Thanks for pointing that out. Here's the PR https://github.com/ruby/set/pull/40 Dan0042 (Daniel DeLorme) wrote in #note-6: > I like the concept but I'm going to bikeshed the naming: by itself "key_set" is unclear if you don't already know what it does. It sounds like the purpose is to set a key (like instance_variable_set). I'd prefer something a bit more descriptive like "keys_to_set" Good point I addressed that ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-111989 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121068] [Ruby master Feature#16993] Sets: from hash keys using Hash#key_set
by Dan0042 (Daniel DeLorme) 15 Feb '25

15 Feb '25

Issue #16993 has been updated by Dan0042 (Daniel DeLorme). I like the concept but I'm going to bikeshed the naming: by itself "key_set" is unclear if you don't already know what it does. It sounds like the purpose is to set a key (like instance_variable_set). I'd prefer something a bit more descriptive like "keys_to_set" ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-111984 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121071] Your private information has been stolen because of suspicious events.
by ruby-core＠ruby-lang.org 15 Feb '25

15 Feb '25

Greetings!Would like to introduce myself - I am a specialized hacker, and have succeeded in hacking your operating system.At this moment, I have obtained a complete access to account of yours.On top of that, I was also unnoticeably observing all your activities and spying on you for few past months.It was possible because your computer was infected with malicious spyware, which infiltrated your computer while you were visiting a website containing adult videos.Give me a few minutes to clarify how that affects you. Because of Trojan viruses, I am now able to have an unrestricted access to your computer as well as any other devices owned by you.In other words, I can see without any restrictions everything in your screen and even activate the camera together with microphone anytime I want, and you won't even know about that.Moreover, I have complete access to confidential data of yours including emails, chat history etc.You may be rightfully puzzled how come your antivirus is not able to detect the harmful software of mine.I don't mind explaining that at all: my malicious software is driver-based; hence it refreshes its signatures every 4 hours, which makes it impossible for your antivirus to identify it.I have come up with a video exposing the scenes of your passionate masturbation sessions on the left side, whereas on the right side it shows the dirty videos you were watching during that time .^.Trust me, it takes several mouse clicks to distribute this video to your entire email addresses list as well as messenger contacts on your PC or other devices.Additionally, I can easily share all your emails as well as chat history to public too.I honestly think you would certainly like to abstain from letting that happen.There is a solution for you in this case - perform 950 USD transfer in Bitcoin equivalent to Bitcoin account of mine (it is really not difficult to do, and you can find online the step-by-step guide, if you have no idea about it).My bitcoin account details are below as follows (Bitcoin wallet):1GTVwiR2Y9FdbduBwVjnRB1yEmBM34BKMkOnce the aforementioned amount gets transferred to my account, I will straight away erase all those kinky videos and vanish from your life completely.Please, settle this payment within 50 hours (2 days).A notification will be sent to me right after this email gets opened, which will trigger the countdown.Believe me, I am very cautious, professional and never fail.If I get to know about you sharing this message with anyone else, I will right away distribute your private videos to public.Best of luck!

1 0

[ruby-core:121065] [Ruby master Feature#16993] Sets: from hash keys using Hash#key_set
by nobu (Nobuyoshi Nakada) 14 Feb '25

14 Feb '25

Issue #16993 has been updated by nobu (Nobuyoshi Nakada). This kind of extensions should be done in the corresponding library side, set.rb. ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-111978 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0