[#120855] [Ruby master Bug#21104] Net::HTTP connections failing in Ruby >= 3.4.0 on macOS with Happy Eyeballs enabled — "mjt58 (Mike Thompson) via ruby-core" <ruby-core@...>

Issue #21104 has been reported by mjt58 (Mike Thompson).

14 messages 2025/02/01

[#120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs — "stanhu (Stan Hu) via ruby-core" <ruby-core@...>

Issue #21111 has been reported by stanhu (Stan Hu).

10 messages 2025/02/03

[#120884] [Ruby master Bug#21115] Etc.getgrgid is not Ractor-safe but is marked as such — "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>

Issue #21115 has been reported by Eregon (Benoit Daloze).

7 messages 2025/02/05

[#120897] [Ruby master Bug#21119] Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly. — "genya0407 (Yusuke Sangenya) via ruby-core" <ruby-core@...>

Issue #21119 has been reported by genya0407 (Yusuke Sangenya).

6 messages 2025/02/06

[#121054] [Ruby master Bug#21139] Prism and parse.y parses `it = it` differently — "tompng (tomoya ishida) via ruby-core" <ruby-core@...>

Issue #21139 has been reported by tompng (tomoya ishida).

19 messages 2025/02/14

[#121060] [Ruby master Feature#21140] Add a method to get the address of certain JIT related functions — "tenderlovemaking (Aaron Patterson) via ruby-core" <ruby-core@...>

Issue #21140 has been reported by tenderlovemaking (Aaron Patterson).

23 messages 2025/02/14

[#121077] [Ruby master Misc#21143] Speficy order of execution const_added vs inherited — "fxn (Xavier Noria) via ruby-core" <ruby-core@...>

Issue #21143 has been reported by fxn (Xavier Noria).

15 messages 2025/02/17

[#121142] [Ruby master Misc#21154] Document or change Module#autoload? — "fxn (Xavier Noria) via ruby-core" <ruby-core@...>

Issue #21154 has been reported by fxn (Xavier Noria).

32 messages 2025/02/23

[#121172] [Ruby master Feature#21157] Comparison operator <> — lpogic via ruby-core <ruby-core@...>

SXNzdWUgIzIxMTU3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGxwb2dpYyAoxYF1a2FzeiBQb21pZXTF

11 messages 2025/02/26

[ruby-core:121170] [Ruby master Misc#21154] Document or change Module#autoload?

From: "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>
Date: 2025-02-26 04:02:39 UTC
List: ruby-core #121170
Issue #21154 has been updated by mame (Yusuke Endoh).


> Why I don't show source code? Because this is not a ticket motivated by a need I have.

I see, you really do not have a use case. I finally understand.
I had misunderstood that you were hiding your use cases and somewhat challenging us.
(I am not sure if my English wording is appropriate here, sorry if it makes a wrong sense.)
Sorry for the frustration.

Let me explain why I am eager to hear the use cases.

In principle, all proposed changes to Ruby are considered based on the use cases that would require the change.
Even if it is just an inconsistency, we force ourselves to assume use cases that could be affected by the inconsistency and then consider how (and whether) to fix it.

Therefore, ticket discussions at the dev meetings begin with an understanding of the use case.
Without a background explanation in the ticket, a great deal of time is spent to try identifying use cases.
Still, it is impossible to cover all the use cases in a limited amount of time, so we could reach incomplete conclusions.
We sometimes end up finding a different use case than the one the proposer has in mind, leading to a conclusion that the users, including the proposer, do not want.
If a reasonable use case cannot be found, we need to ask the proposer to clarify, which takes time.
Or we may choose WONTFIX, or make a random choice based on matz's intuition, which is also often not the result desired by the proposer.

You may think that Ruby committers has the "answer" to the question you have and you want to just get it out of us.
In fact, we have no "answer". At least I do not have. I believe matz does not have it either for your question yet.
We need to decide how (and whether) to fix it by using the use cases.
If there is no particular use case that is troubling you, then we tend to choose "don't touch it" or just rely on matz's intuition.

As for autoload, there is a long history of subtle and repeated fine-tuning based on problems encountered in real-workd use cases.
Therefore, I feel strong resistance to changing something based on intuition alone.
I am afraid that by making a bad change, Zeitwerk stops working, which will affect many people.

This is the reason why I insisted on asking you, the author of Zeitwerk, for background on this issue.

----------------------------------------
Misc #21154: Document or change Module#autoload?
https://bugs.ruby-lang.org/issues/21154#change-112109

* Author: fxn (Xavier Noria)
* Status: Open
----------------------------------------
The documentation of `Module#autoload?` says

> Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors.

Cool, but in the following snippet

```ruby
autoload :Foo, 'foo'
autoload?(:Foo)
```

the second line could evaluate to `nil`, and this does not seem to agree. I just registered an autoload, therefore (according to the documentation) I should get "foo" back in line 2.

I'd like to ask for clarification from the Ruby team:

1. Is the documentation complete? Should that second line always return "foo"?
2. If the answer is no, which is the logic missing in the docs?

Thank you!



-- 
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/


In This Thread