Misc #17299
closed
DevelopersMeeting20201120Japan
Added by mame (Yusuke Endoh) almost 4 years ago.
Updated over 3 years ago.
Description
The next dev meeting¶
Date: 2020/11/20 13:00-17:00
Place/Sign-up/Agenda/Log: https://github.com/ruby/dev-meeting-log/blob/master/DevelopersMeeting20201120Japan.md
- Dev meeting IS NOT a decision-making place. All decisions should be made on the bug tracker.
- Dev meeting is a place we can ask Matz, nobu, nurse, and other developers directly.
- Matz is a very busy person. Take this opportunity to ask him. If you cannot attend, a different attendee can ask instead of you (if the attendee can understand your issue).
- We will write a log about the discussion in a file or on each ticket in English.
- All activities are best-effort (keep in mind that most of us are volunteer developers).
- The date, time, and place are scheduled according to when/where we can reserve Matz' time.
-
DO NOT discuss them on this ticket, please.
Call for agenda items¶
If you have a ticket that you want Matz and other committers to discuss, please post it on this ticket in the following format:
* [Ticket ref] Ticket title (your name)
* Comment (A summary of the ticket, why you put this ticket here, what points should be discussed, etc.)
Example:
* [Feature #14609] `Kernel#p` without args shows the receiver (ko1)
* I feel this feature is very useful and some people say :+1:, so let's discuss this feature.
- Comment deadline: 2020/11/13 (one week before the meeting)
- The format is strict. We'll use this script to automatically create a markdown-style agenda. We may ignore comments that do not follow the format.
- Your comment is mandatory. We cannot read the entire discussion of the ticket within a limited time.
Related issues
1 (1 open — 0 closed)
- Description updated (diff)
- [Feature #17303] Make webrick to bundled gems or remove from stdlib
- [Feature #17143] Improve support for warning categories (jeremyevans0)
- I researched the Python warning categories, and provided some analysis.
- Can we decide on warning categories so they can be implemented in time for Ruby 3?
- [Bug #10845] Subclassing String (jeremyevans0)
- In #6087, matz decided that in Ruby 3.0, methods for Array subclasses should return arrays and not subclass instances.
- The same issues that apply to Array subclasses also apply to String subclasses.
- Do we want to make String subclass methods return strings instead of subclass instances?
- If so, is the pull request OK?
- Note that changing the behavior of String methods will require changes in Rails.
- [Bug #11022] opening an eigenclass does not change the class variable definition context (jeremyevans0)
- This was discussed in the December 2019 meeting, but a decision was not made.
- Considering #14012 was rejected last meeting, can we also reject this?
- [Bug #7844] include/prepend satisfiable module dependencies are not satisfied (jeremyevans0)
- This was discussed in the December 2019 meeting, but a decision was not made.
- Considering the other improvements to include/prepend in 3.0, it would be a good time to fix this.
- [Bug #11213] defined?(super) ignores respond_to_missing? (jeremyevans0)
- I agree with Koichi that it is best to accept the current behavior as spec.
- Can we reject this?
- [Feature #13381] Expose rb_fstring and its family to C extensions (byroot)
- The feature itself was approved, however we're still waiting on an agreement on the naming of one function (https://github.com/ruby/ruby/pull/3586)
- Both
json
and msgpack
now call String#-@
, and could benefit from large allocation reduction if they could call rb_fstring_cstr
instead.
- [Bug #17197] Yielding arity for
Hash
methods (marcandre)
-
Hash#each
with arity 1: confirmed?
-
#select
, #keep_if
, #delete_if
, #reject
and to_h
should also be changed, right?
-
#map
: should only accept arity 1, right?
- [Feature #17291] Optimize
__send__
call
- Improve the performance of
__send__
call by the following ways
- Omit emitting
__send__
calls for literal method name cases
- Introduce a new instruction
sendsym
to skip __send__
call for dynamic method name cases
- I guess it is no problem to skip
__send__
call because the following warning says "redefining __send__
may cause serious problems" for a long time
- I want to know Matz's reaction to this
- [Feature #16043]
$LOAD_PATH.resolve_feature_path
should not raise (eregon)
- Seems good to me, OK to merge?
- [Feature #17100] Ractor naming (eregon)
- What should be the method name to send a message?
send
seems problematic as many have reported. We should decide soon. Many good other names are listed in the issue (notably in https://bugs.ruby-lang.org/issues/17100#note-19 and https://bugs.ruby-lang.org/issues/17100#note-43).
- Specifically,
Ractor#send
conflicts with Kernel#send
, which is a violation of the Liskov substitution principle.
- There has been (AFAIK) no official deprecation of
Kernel#send
, so it seems inadvisable to use the name for other semantics for Ractor. Deprecating Kernel#send
seems a way to require 100 000s of changes in gems for for very little reasons, so it seems unfeasible in practice anyway.
- When should
send
and __send__
be used? It seems gems prefer to use send
(>10x more used than __send__
), and only use __send__
when required. IMHO __send__
feels like Python's __add__
, which I find unpretty, and feels like C's poor way of namespacing things.
- [Feature #17307] A way to mark C extensions as thread-safe, Ractor-safe, or unsafe (eregon)
- I'd like feedback on this. Any idea for a good way to mark C extensions?
- How about defining symbols like
foo_is_thread_safe
/foo_is_ractor_safe
to mark C extensions?
- [Feature #16786] Light-weight scheduler for improved concurrency (eregon)
- [Feature #17312] New methods in Enumerable and Enumerator::Lazy: flatten, product, compact (zverok)
- If there would be no objections, I'd prepare a PR
- Description updated (diff)
- Status changed from Open to Closed
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0