[#119132] Segfault using ruby C on MacOS (Intel Catalina and M2 Sonoma) — "martin.kufner--- via ruby-core" <ruby-core@...>
Hey guys,
4 messages
2024/09/12
[#119133] Re: Segfault using ruby C on MacOS (Intel Catalina and M2 Sonoma)
— "martin.kufner--- via ruby-core" <ruby-core@...>
2024/09/12
I just saw, that the #includes dont show up in the c file ...
[#119145] [Ruby master Misc#20728] Propose Eileen Uchitelle as a core committer — "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>
Issue #20728 has been reported by kddnewton (Kevin Newton).
14 messages
2024/09/12
[#119312] [Ruby master Bug#20762] `make test-basic` with -DRGENGC_FORCE_MAJOR_GC is always failure — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>
Issue #20762 has been reported by hsbt (Hiroshi SHIBATA).
6 messages
2024/09/27
[ruby-core:119044] [Ruby master Bug#20714] Handle optional dependencies in `bundled_gems.rb`
From:
"Earlopain (A S) via ruby-core" <ruby-core@...>
Date:
2024-09-04 16:20:10 UTC
List:
ruby-core #119044
Issue #20714 has been updated by Earlopain (A S). Thanks for you reply, I was about to write something similar about the older rubies. At first I was writing about how I don't think a new api is really necessary since the compatibility code can simply be dropped once `required_ruby_version` is at or above the ruby version that would error but I don't think that is entirely true. For example, on ruby 3.4 the following script produces this output: ```rb begin require "webrick" rescue LoadError end if defined?(Webrick) puts "Do some things" end # test.rb:2: warning: webrick was loaded from the standard library, but is not part of the default gems starting from Ruby 3.0.0. # You can add webrick to your Gemfile or gemspec to silence this warning. ``` So even though webrick is gone since Ruby 3.0, I'd still have to do some trickery to optionally enhance it without triggering the warning. I see two solutions: * `require "foo", optional: true` like you suggested * Drop warnings when ruby would throw an error [here]. When the require will raise, it doesn't need to warn. This is how I already imagined it works. I guess it doesn't for visibility? [here]: https://github.com/ruby/ruby/blob/294dad22d7ac5f307d567cff897507b9fd9d05e9/lib/bundled_gems.rb#L6-L36 ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109622 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've encountered a few places around bundled gems where the library doesn't care if the gem is available, but will still provide some functionallity if it is. The way to accomplish that right now seems to be by setting `$VERBOSE = nil` and resetting it later again to not bother the user with the warning about the gem. However, this has the effect of silencing the warning about other gems as well, that may not be prepared about the bundling. >>From `ruby/reline` for example: https://github.com/ruby/reline/blob/c90f08f7e308d2f1cdd7cfaf9939fe45ce546fd2/lib/reline/terminfo.rb#L1-L15 Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c65098cd3c3316677ef1f3784/lib/logging.rb#L9-L15 I propose to simply delay the warning to the next require. GitHub PR at https://github.com/ruby/ruby/pull/11545 -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/