Actions
Misc #17299
closedDevelopersMeeting20201120Japan
Status:
Closed
Assignee:
-
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.
Updated by mame (Yusuke Endoh) about 4 years ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by hsbt (Hiroshi SHIBATA) about 4 years ago
- [Feature #17303] Make webrick to bundled gems or remove from stdlib
- Any objection?
Updated by jeremyevans0 (Jeremy Evans) about 4 years ago
- [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?
Updated by byroot (Jean Boussier) about 4 years ago
- [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
andmsgpack
now callString#-@
, and could benefit from large allocation reduction if they could callrb_fstring_cstr
instead.
Updated by marcandre (Marc-Andre Lafortune) about 4 years ago
- [Bug #17197] Yielding arity for
Hash
methods (marcandre)-
Hash#each
with arity 1: confirmed? -
#select
,#keep_if
,#delete_if
,#reject
andto_h
should also be changed, right? -
#map
: should only accept arity 1, right?
-
Updated by mrkn (Kenta Murata) about 4 years ago
- [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
- Omit emitting
- 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
- Improve the performance of
Updated by Eregon (Benoit Daloze) about 4 years ago
- [Feature #16043]
$LOAD_PATH.resolve_feature_path
should not raise (eregon)- Seems good to me, OK to merge?
Updated by Eregon (Benoit Daloze) almost 4 years ago
- [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 withKernel#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. DeprecatingKernel#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 usesend
(>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.
- What should be the method name to send a message?
Updated by Eregon (Benoit Daloze) almost 4 years ago
- [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?
Updated by Eregon (Benoit Daloze) almost 4 years ago
- [Feature #16786] Light-weight scheduler for improved concurrency (eregon)
- @matz (Yukihiro Matsumoto): The
Fiber.set_scheduler(value)
API doesn't make any sense to me and is very confusing, please see my comments there (summary: https://bugs.ruby-lang.org/issues/16786#note-70). - Anything wrong with the obvious and clear
Thread.current.scheduler = value
orThread.current.fiber_scheduler = value
?
- @matz (Yukihiro Matsumoto): The
Updated by zverok (Victor Shepelev) almost 4 years ago
- [Feature #17312] New methods in Enumerable and Enumerator::Lazy: flatten, product, compact (zverok)
- If there would be no objections, I'd prepare a PR
Updated by mame (Yusuke Endoh) almost 4 years ago
- Description updated (diff)
- Status changed from Open to Closed
Actions
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0