Misc #17997
closed
DevelopersMeeting20210715Japan
Added by mame (Yusuke Endoh) over 3 years ago.
Updated over 3 years ago.
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 open — 0 closed)
- [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
?
- [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?)
- [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?
- [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.
- [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?
- [Misc #18025] rb_iterate is obsolete since 1.9 but is not marked as deprecated for C compilers (eregon)
- [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"
- [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%.
- [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?
- Description updated (diff)
- Status changed from Open to Closed
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0