Project

General

Profile

Actions

Misc #17299

closed

DevelopersMeeting20201120Japan

Added by mame (Yusuke Endoh) about 4 years ago. Updated almost 4 years ago.

Status:
Closed
Assignee:
-
[ruby-core:100675]

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 open0 closed)

Related to Ruby master - Misc #14770: [META] DevelopersMeetingOpenActions
Actions #1

Updated by mame (Yusuke Endoh) about 4 years ago

  • Related to Misc #14770: [META] DevelopersMeeting added
Actions #2

Updated by sawa (Tsuyoshi Sawada) about 4 years ago

  • Description updated (diff)

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 and msgpack now call String#-@, and could benefit from large allocation reduction if they could call rb_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 and to_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
      1. Omit emitting __send__ calls for literal method name cases
      2. 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

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

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)

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
Actions #13

Updated by mame (Yusuke Endoh) almost 4 years ago

  • Description updated (diff)
  • Status changed from Open to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0