Please comment on your favorite ticket numbers you want to ask to discuss with your SHORT comment or summary.
(your summary/comment will help us because we don't need to read all of the ticket comments)
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.
Please comment on your favorite ticket we need to discuss with the following format.
* [Ticket ref] Ticket title (your name)
* your comment why you want to put this ticket here if you want to add.
Your comment is very important if you are no attendee because we can not ask why you want to discuss it.
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.
We don't guarantee to put tickets in agenda if the comment violate the format (because it is hard to copy&paste).
Could the pattern matching be made available as a first-class citizen to be used as a filter when searching in data structures and to be able to implement Actor receive method
Consider contractions log_messages.find in [:error, message] { puts message }
Non-symbol matching of Hashes would be very desirable
[Feature #15797] Use realpath(3) instead of custom realpath implementation if available (jeremyevans0)
Is this OK to commit? It may cause regressions on less common Unix not tested by Travis (e.g. FreeBSD, NetBSD, AIX, Solaris), though we could just fallback to current implementation in that case.
Do we want to add workarounds for Mac OS <=10.5 (10.5 was released in October 2007)?
[Feature #15903] Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path
matz: Could you decide between Kernel.resolve_feature_path and $LOAD_PATH.resolve_feature_path?
[Feature #15897] it as a default block parameter and [Misc #15723] Reconsider numbered parameters
Could committers continue the discussion from last meeting? Are most people OK with just one implicit argument vs many? I think that could be the first thing to settle.
I think a comment from matz sharing his thoughts on either ticket would be helpful.
[Bug #15708] Implicit numbered argument decomposes an array
What's the reason of current behavior? Please explain on the ticket.
matz: Can you judge whether that behavior is worth the inconsistency with { |x| and making #map, etc not work with unknown element types (if elements can or not be arrays)?
[Feature #15966] Introducing experimental features behind a flag, disabled by default
Could you read the description and reply what you think? Do you think it's a good idea? I think it would be a much better way to introduce experimental features.
[Feature #15865] <expr> in <pattern> expression (mame)
We have some opinions: scoping, matching strictness, the keyword in, and the word order. But all are not specific to the one-line matching. I think it is acceptable if case/in matching is acceptable. May I experimentally commit it as well as case/in?
[Misc #15806] Explicitly initialise encodings on init to remove branches on encoding lookup
Currently rb_enc_from_index and related methods explicitly check for encoding table init on each call - I think this should be initialised at boot time instead as even the simple case of loading the interpreter requires the encoding table to be loaded anyways (symbol.c)