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
  • 144 discussions
[ruby-core:121465] [Ruby Bug#21204] `TestEtc#test_ractor_parallel` is still flaky result
by hsbt (Hiroshi SHIBATA) 02 Apr '25

02 Apr '25
Issue #21204 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21204: `TestEtc#test_ractor_parallel` is still flaky result https://bugs.ruby-lang.org/issues/21204 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- https://github.com/ruby/ruby/actions/runs/14121185441/job/39561623937?pr=13… ``` 1) Failure: TestEtc#test_ractor_parallel [/home/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: pid 150540 killed by SIGABRT (signal 6) (core dumped) | [BUG] pthread_mutex_lock: Owner died (EOWNERDEAD) | ruby 3.5.0dev (2025-03-28T03:13:46Z pull/13004/merge 4cfbc634ea) +PRISM +GC[mmtk] [x86_64-linux] | | -- Control frame information ----------------------------------------------- | | malloc_consolidate(): unaligned fastbin chunk detected | | -- Threading information --------------------------------------------------- | Total ractor count: 1 ``` -- https://bugs.ruby-lang.org/
2 2
0 0
[ruby-core:121510] [Ruby Feature#14565] Simpler, one-liner, failsafe require in ruby? [Suggested names: require_failsafe, require_safe, require_try, require_add)
by jeromedalbert (Jerome Dalbert) 02 Apr '25

02 Apr '25
Issue #14565 has been updated by jeromedalbert (Jerome Dalbert). I like this feature request, a non-failing require would be great for gems that optionally depend on another gem. For example: ```ruby begin require 'rubocop-rspec' rescue LoadError end if defined?(RuboCop::RSpec) # ... end ``` could be turned into something like this ```ruby if require('rubocop-rspec', exception: false) # ... end ``` ---------------------------------------- Feature #14565: Simpler, one-liner, failsafe require in ruby? [Suggested names: require_failsafe, require_safe, require_try, require_add) https://bugs.ruby-lang.org/issues/14565#change-112532 * Author: shevegen (Robert A. Heiler) * Status: Open ---------------------------------------- I have quite a bit of code like this: ```ruby begin require 'x/tools/cdrskin.rb' rescue LoadError; end ``` I also use the longer variant, e.g., ```ruby begin require 'foobar' rescue LoadError puts 'project foobar is not available - consider '\ 'installing it via gem install foobar' end ``` Often, I do not need to inform the user about missing gems/projects that are tiny and not very important. In my larger ruby projects, I handle cases where a smaller project is not available or available, so I can proceed either way. It is a bit pointless to notify the user when that is me; that is why I would like to have a one-liner. I am thinking of an API such as any of the following: require_failsafe require_safe require_try require_add This is for loading with a rescue LoadError without notification. If I need to notify a user then I am fine with the longer variant. If anyone has better names, feel free to add them! I think people are more likely to remember the require-family, e. g. require 'foo.rb' or require_relative 'bar.rb' and so forth. --- I also wanted to propose a stronger `require`/`import`, including the possibility to refer to `.rb` files without a hardcoded path (if the .rb file is moved, all explicit requires to it, in particular from external projects, would have to change; and my vague idea is to replace this with some kind of project-specific way to "label" files and load these files based on these "labels", but that is for another suggestion; I only want to mention it because Hiroshi Shibata made some suggestion as extension to require, and I think the use case he mentioned may also be useful to see whether ruby may get a stronger "load code in files" functionality for ruby 3.x eventually). -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-core:121508] [Ruby Bug#21213] [BUG] heap_idx_for_size: allocation size too large (size=145u, heap_idx=146u)
by jjs008 02 Apr '25

02 Apr '25
Issue #21213 has been reported by jjs008 (小龙 江). ---------------------------------------- Bug #21213: [BUG] heap_idx_for_size: allocation size too large (size=145u, heap_idx=146u) https://bugs.ruby-lang.org/issues/21213 * Author: jjs008 (小龙 江) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Failed to build ruby 3.4.2 after upgrade Visual C++ build Tools from 17.2 to 17.3.5. The logging file is as attachment. Use this build script https://github.com/jiangjianshan/msvc-pkg/blob/main/packages/ruby/build.bat and it work before upgrade Visual C++ toolsets. ---Files-------------------------------- ruby.txt (3.84 KB) -- https://bugs.ruby-lang.org/
2 1
0 0
[ruby-core:121490] [Ruby Bug#21208] `Ractor#send(move: true)` allow moving objects that are on the stack, and used by C code.
by byroot (Jean Boussier) 01 Apr '25

01 Apr '25
Issue #21208 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21208: `Ractor#send(move: true)` allow moving objects that are on the stack, and used by C code. https://bugs.ruby-lang.org/issues/21208 * Author: byroot (Jean Boussier) * Status: Open * Assignee: ractor * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following script causes a crash: ```ruby rac = Ractor.new do Ractor.receive end hash = Hash[*50.times] hash.merge!(12 => 0, 14 => 0) do |key, old_val, new_val| if key == 12 rac.send(hash, move: true) end new_val end p rac.take ``` Contrary to previous crashes related to `send(move: true)`, I'm afraid this one is with the design of the feature itself, not just the implementation. If we allow objects to be moved, any C code that calls `rb_yield()` may cause memory corruption if one of the objects it uses is moved. I personally can't see any realistic solution to this. -- https://bugs.ruby-lang.org/
2 2
0 0
  • ← Newer
  • 1
  • ...
  • 12
  • 13
  • 14
  • 15
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.