[#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:119236] [Ruby master Feature#20309] Bundled gems for Ruby 3.5
From:
"Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date:
2024-09-17 12:37:03 UTC
List:
ruby-core #119236
Issue #20309 has been updated by Eregon (Benoit Daloze).
vo.x (Vit Ondruch) wrote in #note-35:
> I don't think it is bad idea to start using `bundle install --local`, i.e. use gems which are already available on the system. And on top of that, stop using Bundler in containers for runtime in production use.
Do you mean `--prefer-local`? I don't think `--local` would work in general since that does not attempt to connect to rubygems.org at all.
>>From the docs it's not clear if either of them would reuse bundled gems:
```
--local
Do not attempt to connect to rubygems.org. Instead, Bundler will use the gems already present in Rubygems' cache or in vendor/cache. Note that if an
appropriate platform-specific gem exists on rubygems.org it will not be found.
--prefer-local
Force using locally installed gems, or gems already present in Rubygems' cache or in vendor/cache, when resolving, even if newer versions are available
remotely. Only attempt to connect to rubygems.org for gems that are not present locally.
```
+ the version would need to match the bundled gem version in the Gemfile.lock, which I'm not sure there is any easy way to do that.
But it would be nice, yeah, for Bundler to have a way to reuse bundled & default gems when possible, at resolution (`bundle lock`) and install time.
----------------------------------------
Feature #20309: Bundled gems for Ruby 3.5
https://bugs.ruby-lang.org/issues/20309#change-109819
* Author: hsbt (Hiroshi SHIBATA)
* Status: Assigned
* Assignee: hsbt (Hiroshi SHIBATA)
----------------------------------------
I propose migrate the following default gems to bundled gems at Ruby 3.5. So, It means users will get warnings if users try to load them.
(Update with 2024/03/14, 2024/06/05, 2024/09/06)
* rdoc(done)
* We need to change build task like download rdoc gem before document generation.
* extract `make doc` from `make all` and invoke `make doc` before `make install`.
* done for Ruby 3.4
* or We make document generation is optional from Ruby 3.5
* We explicitly separate `make install` and `make install-doc`
* ostruct(done)
* I make ostruct as optional on json at https://github.com/flori/json/pull/565
* pstore(done)
* win32ole(done)
* logger(done)
* activesupport needs to add logger to its dependency same as bigdecimal, drb or etc.
* fiddle(done)
* benchmark
* irb
* We need to consider how works `binding.irb` after Ruby 3.5.
* I consider to use `irb` without Gemfile.
* reline
* readline (wrapper file for readline-ext and reline)
I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them.
* io-console
* rubygems uses that. Should we make optional that?
* open-uri
* yaml (wrapper file for psych)
* syck is retired today. I'm not sure what people uses `psych` directly, not `yaml`.
* un
* `ruby -run` is one of cool feature of Ruby. Should we avoid uninstalling `un` gem?
* mkmf uses `ruby -run` for that. I need to investigate that.
* singleton
* This is famous design pattern. Should we enforce users add them to their Gemfile?
* forwadable
* `reline` needs to add forwardable their `runtime_dependency` after migration.
* weakref
* I'm not sure how impact after migrating bundled gems.
* fcntl
* Should we integrate these constants into ruby core?
I would like to migrate `ipaddr` and `uri` too. But these are used by webrick that is mock server for our test suite. We need to rewrite `webrick` with `TCPSocker` or extract `ipaddr` and `uri` dependency from `webrick`
Other default gems depend on our build process or other libraries deeply. I will update this proposal if I could extract them from default gems.
--
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/