Project

General

Profile

Actions

Misc #17997

closed

DevelopersMeeting20210715Japan

Added by mame (Yusuke Endoh) over 3 years ago. Updated over 3 years ago.

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

Description

The next dev meeting

Date: 2021/07/15 13:00-17:00
Place/Sign-up/Agenda/Log: https://github.com/ruby/dev-meeting-log/blob/master/DevelopersMeeting20210715Japan.md

  • Dev meeting IS NOT a decision-making place. All decisions should be done at 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 can not attend, other attendees can ask instead of you (if attendees can understand your issue).
  • We will write a log about the discussion to a file or to 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's time.
  • DO NOT discuss then on this ticket, please.

Call for agenda items

If you have a ticket that you want matz and committers to discuss, please post it into 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 point 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 discuss this feature.
  • It is recommended to add a comment by 2021/07/12. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
  • The format is strict. We'll use this script to automatically create an markdown-style agenda. We may ignore a comment that does not follow the format.
  • Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion.

Related issues 1 (1 open0 closed)

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

Updated by mame (Yusuke Endoh) over 3 years ago

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

Updated by mame (Yusuke Endoh) over 3 years ago

  • [Feature #17994] Clarify IO.read behavior and add File.read method (mame)
    • Jeremy pointed that Socket.read is callable but does not make sense. Should we deprecate the use of IO.read against a receiver different than IO and File?

Updated by matheusrich (Matheus Richard) over 3 years ago

  • [Feature #17938] Keyword alternative for boolean positional arguments (MatheusRich)
    • I think we should address this in the whole std lib (incrementally). Matz seemed positive about it.
    • What should we do if both positional and keyword args are given?
    • Should we deprecate/warn the positional version? (even in a minor release?)

Updated by jeremyevans0 (Jeremy Evans) over 3 years ago

  • [Feature #15856] Performance of redundant Kernel.require is slow when many gems are activated (jeremyevans0)
    • Repeated require of native library without extension is very slow.
    • Repeated require of pure ruby library without extension is fast.
    • Making search_required use the same logic for both native and pure ruby libraries makes repeated require of native library without extension fast.
    • In addition to dramatically increasing the performance, this also makes the behavior consistent for native and pure ruby libraries.
    • This breaks backwards compatibility, in that require 'foo.so'; require 'foo' will not load foo.rb if it exists.
    • Is such breakage acceptable for the dramatically increased performance and increased consistency?
  • [Feature #17724] Make the pin operator support instance/class/global variables (jeremyevans0)
    • Is it OK to allow the pattern matching pin operator to directly support instance/class/global variables?
  • [Bug #17757] Hash#slice does not keep compare_by_identity on the results (jeremyevans0)
    • Some hash methods do not consistently return hashes with compare by identity flag if receiver has compare by identity flag.
    • Some of these are definitely bugs, as they treat the empty receiver differently than non empty receiver.
    • However, do we want change the behavior for slice and/or transform_keys to return compare by identity hash if receiver has compare by identity flag?
  • [Bug #17737] Array#permutation does not immediately check the arity when no block is given (jeremyevans0)
    • If we think this is a bug, we'll have to move all argument checking before enumerator creation in all of the methods that return enumerator.
    • I don't think it is a bug.
    • If this isn't a bug, can this be closed?
  • [Bug #17719] Irregular evaluation order in hash literals (jeremyevans0)
    • Should we fix the evaluation order for duplicate hash keys using @nobu's patch (my preference)?
    • Or should we change duplicate hash keys from a warning to an error?

Updated by Eregon (Benoit Daloze) over 3 years ago

  • [Bug #18011] Method#parameters is incorrect for forwarded arguments (eregon)
    • How about @jeremyevans0's suggestion to add [:keyrest, :**] for ruby2_keywords methods and for (...)? It sounds good to me.

Updated by larskanis (Lars Kanis) over 3 years ago

  • [Bug #15357] Proc#parameters returns incomplete type information (larskanis)
    • Either change proc{}.parameters to return the same information as lambda{}.parameters
    • or add keyword parameters(lambda: true) to enable this in a backward compatible way (@jeremyevans0's patch)
    • or keep everything as is?

Updated by Eregon (Benoit Daloze) over 3 years ago

Updated by Dan0042 (Daniel DeLorme) over 3 years ago

  • [Feature #17795] Around Process.fork callbacks API (dan0042)
    • After a few meetings without a decision, can we at least reach a compromise with Process._fork_ ?
    • For certain uses cases that would improve the statu quo from "impossible to write fork-safe code" to "unobvious but possible"

Updated by duerst (Martin Dürst) over 3 years ago

  • [Feature #17837] Add support for Regexp timeouts (Sam Saffron)
    • I support looking more closely at Nobu's patch. I have done some experiments which show worst-case slowdowns of ~5%.

Updated by Eregon (Benoit Daloze) over 3 years ago

  • [Bug #13671] Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters (eregon)
    • Can we update to latest Onigmo to fix this? Who knows how to do that/who to assign?
Actions #11

Updated by mame (Yusuke Endoh) over 3 years ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0