[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:91247] [Ruby trunk Feature#5653] "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead)
From:
fxn@...
Date:
2019-01-24 10:19:40 UTC
List:
ruby-core #91247
Issue #5653 has been updated by fxn (Xavier Noria). Let me add a couple of things. In case const_missing is discussed, these are the reasons why implementing autoloading based on const_missing doesn't fly (from memory): 1) The nesting is unknown. 2) Whether the missing constant was relative is unknown. 3) Since const_missing is the last resort in the constant resolution algorithms, you may miss an autoload if some class/module up in the nesting or the ancestor chain happens to have a constant with the same name. 4) It is not thread-safe. On the other hand, Zeitwerk is based on these techniques (some are not portable as of this writing, but would hope they are in the future for compatibility with CRuby): 1) Kernel#autoload, related API, and the fact that it is thread-safe. 2) Constants API. 3) Kernel#autoload calls Kernel#require (Zeitwerk decorates it). 4) TracePoint for the :class event if there is at least one explicit namespace (hotel.rb & hotel/pricing.rb), to support the very common edge case in which Hotel includes Hotel::Pricing and you need to set an autoload on Hotel for :Pricing before that line is reached. (I am aware of https://bugs.ruby-lang.org/issues/14104 and this week I have made some changes in that line, as in https://github.com/fxn/zeitwerk/commit/a1bd83b10521f41f7f74e921602839a1813d11e4). Additionally, Zeitwerk by design uses internally absolute paths only, there are no lookups in $LOAD_PATH or autoload paths, gems using Zeitwerk should load a tad faster. Even more, a code base managed by Zeitwerk does not even need to be in $LOAD_PATH. Any other information that you'd like to know please just tell me! ---------------------------------------- Feature #5653: "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead) https://bugs.ruby-lang.org/issues/5653#change-76493 * Author: matz (Yukihiro Matsumoto) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: Next Major ---------------------------------------- Hi, Today, I talked with NaHi about enhancing const_missing to enable autoload-like feature with nested modules. But autoload itself has fundamental flaw under multi-thread environment. I should have remove autoload when I added threads to the language (threads came a few months after autoload). So I hereby declare the future deprecation of autoload. Ruby will keep autoload for a while, since 2.0 should keep compatibility to 1.9. But you don't expect it will survive further future, e.g. 3.0. I strongly discourage the use of autoload in any standard libraries. matz. ---Files-------------------------------- noname (500 Bytes) 5653.pdf (38.3 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>