[#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:119297] [Ruby master Bug#20714] Handle optional dependencies in `bundled_gems.rb`
From:
deivid via ruby-core <ruby-core@...>
Date:
2024-09-26 10:26:36 UTC
List:
ruby-core #119297
Issue #20714 has been updated by deivid (David Rodr=EDguez). @hsbt found an issue with the simpler approach. It will no longer show info= rmation about bundled gem extraction "after the fact". So, it for example k= eeps warning that `csv` will no longer be part of Ruby starting from Ruby 3= .4 when using Ruby 3.3, but once users upgrade to Ruby 3.4, they will start= getting an standard load error instead of the current message "csv is not = part of the default gems starting from Ruby 3.4.0". I _think_ the more complicated approach proposed here does not have that is= sue, but it does happen the thread safety concerns raised. I think the issue found by @hsbt may be an acceptable compromise, but I'm n= ot sure. ---------------------------------------- Bug #20714: Handle optional dependencies in `bundled_gems.rb` https://bugs.ruby-lang.org/issues/20714#change-109909 * Author: Earlopain (A S) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * 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 i= f it is. The way to accomplish that right now seems to be by setting `$VERBOSE =3D n= il` and resetting it later again to not bother the user with the warning ab= out the gem. However, this has the effect of silencing the warning about ot= her gems as well, that may not be prepared about the bundling.=20 >>From `ruby/reline` for example: https://github.com/ruby/reline/blob/c90f08f= 7e308d2f1cdd7cfaf9939fe45ce546fd2/lib/reline/terminfo.rb#L1-L15 Or the `logging` gem: https://github.com/TwP/logging/blob/df41715364f7eb8c6= 5098cd3c3316677ef1f3784/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 --=20 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.rub= y-lang.org/