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
  • ----- 2026 -----
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • 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

May 2024

  • 3 participants
  • 225 discussions
[ruby-core:117047] [Ruby master Bug#20324] `(1..).overlap?('foo'..)` returns true
by kyanagi (Kouhei Yanagita) 29 May '24

29 May '24
Issue #20324 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #20324: `(1..).overlap?('foo'..)` returns true https://bugs.ruby-lang.org/issues/20324 * Author: kyanagi (Kouhei Yanagita) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While thinking about finding the intersection of two ranges, I found that `(1..).overlap?('foo'..)` returns true. In the current implementation, it seems that `(a..).overlap?(b..)` or `(..a).overlap?(..b)` returns true regardless of what `a` or `b` are. However, I think it should return true if and only if `a` and `b` are comparable. (What is the intersection of `1..` and `'foo'..`?) -- https://bugs.ruby-lang.org/
2 1
0 0
[ruby-core:118061] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Dan0042 (Daniel DeLorme) 29 May '24

29 May '24
Issue #6648 has been updated by Dan0042 (Daniel DeLorme). > * change `RbConfig.ruby` to be the current ruby interpreter (because TBH I'm not sure what's the use of this current `RbConfig.ruby`) @nobu what are your thoughts on the above? For example in the test suite, in `test/set/test_sorted_set.rb` we can see `r = system(RbConfig.ruby, *options, '-e', ruby)` and it seems to me like that's wrong; the system call is executing the installed ruby rather than the compiled ruby that is supposedly under test. If you think this is correct and it's fine that `RbConfig.ruby` returns a static path, we need a different place for `ruby_args` Or if you're not ok with relaxing the semantics of RbConfig then we also need a different place, maybe `Process.ruby_args` ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-108488 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-core:116888] [Ruby master Bug#20285] Stale inline method caches when refinement modules are reloaded
by jhawthorn (John Hawthorn) 29 May '24

29 May '24
Issue #20285 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20285: Stale inline method caches when refinement modules are reloaded https://bugs.ruby-lang.org/issues/20285 * Author: jhawthorn (John Hawthorn) * Status: Assigned * Priority: Normal * Assignee: jhawthorn (John Hawthorn) * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: UNKNOWN ---------------------------------------- This is essentially the same issue as #11672, but for inline method caches rather than class caches. In Ruby 3.3 we started using inline caches for refinements. However, we weren't clearing inline caches when defined on a reopened refinement module. ``` ruby class C end module R refine C do def m :foo end end end using R def m C.new.m end raise unless :foo == m() module R refine C do alias m m def m :bar end end end v = m() raise "expected :bar, got #{v.inspect}" unless :bar == v ``` This will raise in Ruby 3.3 as the inline cache finds a stale refinement, but passes in previous versions. -- https://bugs.ruby-lang.org/
2 2
0 0
[ruby-core:116344] [Ruby master Bug#20195] 3.3.0 YJIT mishandles splat into methods taking a rest parameter
by alanwu (Alan Wu) 29 May '24

29 May '24
Issue #20195 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #20195: 3.3.0 YJIT mishandles splat into methods taking a rest parameter https://bugs.ruby-lang.org/issues/20195 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- Check with: ```ruby ruby2_keywords def foo(*args) = args def bar(*args, **kw) = [args, kw] def pass_bar(*args) = bar(*args) def body args = foo(a: 1) pass_bar(*args) end p body ``` ```shell $ ruby ../test.rb [[{:a=>1}], {}] $ ruby --yjit-call-threshold=1 ../test.rb [[], {:a=>1}] ``` -- https://bugs.ruby-lang.org/
2 1
0 0
[ruby-core:116374] [Ruby master Bug#20204] 3.3.0 YJIT rises TypeError instead of ArgumentError with some incorrect calls
by alanwu (Alan Wu) 28 May '24

28 May '24
Issue #20204 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #20204: 3.3.0 YJIT rises TypeError instead of ArgumentError with some incorrect calls https://bugs.ruby-lang.org/issues/20204 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- Test with: ```ruby def foo(a, *) = a def call(args, &) foo(1) foo(*args, &) end call([1, 2]) call([]) ``` ``` $ ruby ../test.rb ../test.rb:1:in `foo': wrong number of arguments (given 0, expected 1+) (ArgumentError) $ ruby --yjit-call-threshold=1 ../test.rb ../test.rb:5:in `call': wrong argument type Array (expected Proc) (TypeError) ``` -- https://bugs.ruby-lang.org/
2 1
0 0
[ruby-core:118020] [Ruby master Bug#20511] Update bundled reline gem version to v0.5.7
by Revolt (Iulian Onofrei) 28 May '24

28 May '24
Issue #20511 has been reported by Revolt (Iulian Onofrei). ---------------------------------------- Bug #20511: Update bundled reline gem version to v0.5.7 https://bugs.ruby-lang.org/issues/20511 * Author: Revolt (Iulian Onofrei) * Status: Open * ruby -v: 3.3.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The bundled reline gem should be updated to v0.5.7 (https://github.com/ruby/reline/releases/tag/v0.5.7) because the current latest Ruby version is unusable in some situations due to an exception being thrown (https://github.com/ruby/reline/issues/690) -- https://bugs.ruby-lang.org/
3 2
0 0
[ruby-core:116311] [Ruby master Bug#20192] YJIT in 3.3.0 miscompiles `yield` with keyword splats
by alanwu (Alan Wu) 28 May '24

28 May '24
Issue #20192 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #20192: YJIT in 3.3.0 miscompiles `yield` with keyword splats https://bugs.ruby-lang.org/issues/20192 * Author: alanwu (Alan Wu) * Status: Closed * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- Test with: ```ruby def splat_kw(kwargs) = yield(**kwargs) p splat_kw({}) { _1 } ``` ```shell % ruby --yjit-call-threshold=1 test.rb {} % ruby test.rb nil ``` -- https://bugs.ruby-lang.org/
2 1
0 0
[ruby-core:116911] [Ruby master Bug#20294] Parser no longer warns on some duplicated keys
by kddnewton (Kevin Newton) 28 May '24

28 May '24
Issue #20294 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20294: Parser no longer warns on some duplicated keys https://bugs.ruby-lang.org/issues/20294 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Previously, the parser would warn on all duplicated keys. Now some cases are not handled: ```ruby { 100.0 => 1, 1e2 => 1 } { 100.0 => 1, 1E2 => 1 } { 100.0 => 1, 100.00 => 1 } { 100.0r => 1, 100.00r => 1 } { 100.0i => 1, 100.00i => 1 } ``` -- https://bugs.ruby-lang.org/
1 2
0 0
[ruby-core:117813] [Ruby master Bug#20479] Ensure line number in begin...end in method
by kddnewton (Kevin Newton) 28 May '24

28 May '24
Issue #20479 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20479: Ensure line number in begin...end in method https://bugs.ruby-lang.org/issues/20479 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In the following example: ```ruby def foo begin rescue p :rescue ensure p :ensure end end ``` the ISEQ has the label: `#<ISeq:ensure in foo@test.rb:6 (6,4)-(6,13)>`, but tracepoint reports that `first_lineno` is 1. This is coming straight from the AST, which says `@ NODE_ENSURE (id: 12, line: 1, location: (2,7)-(6,13))`. This seems incorrect. The `rescue` knows that its line starts on line 3, but `ensure` says it starts on line 1. Could we change that to reflect the actual line it's on? -- https://bugs.ruby-lang.org/
2 4
0 0
[ruby-core:117984] [Ruby master Misc#20503] Dedenting heredoc line continuation
by kddnewton (Kevin Newton) 28 May '24

28 May '24
Issue #20503 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20503: Dedenting heredoc line continuation https://bugs.ruby-lang.org/issues/20503 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- When there is a line continuation inside a dedenting heredoc, occasionally it will impact the dedent calculation in interesting ways. I'm not sure if it's a bug, or if my understanding is incorrect. ```ruby <<~eos TEXT eos ``` In this case the string is `"TEXT\n", because the common whitespace is 2 and it's removed from the only line. However if there is a line continuation: ```ruby <<~eos \ TEXT eos ``` then the results is `" TEXT\n"`. To me this seems incorrect, because the second line is supposed to be considered as part of the first, which would mean it should have the same result as the first one. So either my understanding is incorrect or this is a bug. Could someone clarify? Thanks! -- https://bugs.ruby-lang.org/
3 6
0 0
  • ← Newer
  • 1
  • ...
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • ...
  • 23
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.