Misc #18399



Added by mame (Yusuke Endoh) about 1 year ago. Updated 12 months ago.



The next dev meeting

Date: 2022/01/13 13:00-17:00 (JST)

  • 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 record of the discussion in the 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 of the meeting 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.)


* [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 2022/01/10. 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) about 1 year ago

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

Updated by zverok (Victor Shepelev) about 1 year ago

  • [Feature #18368] Range#step semantics for non-Numeric ranges (zverok)
    • Is there a reason why (timestamp1...timestamp2).step(3.hours) is not what #step supports?
    • If there is, can there be a new method introduced with this semantic?
  • [Feature #18136] Enumerable#take_while_after (zverok)
    • Many real-life use-cases provided
    • Two alternative names provided: take_while_after and drop_after
    • Is there any way this can be moved forward?

Updated by mame (Yusuke Endoh) about 1 year ago

  • [Feature #18367] Stop the interpreter from escaping error messages (mame)
    • At the previous dev-meeting, we decided to survey the current status of how modern terminal emulators handle untrusted escape sequences.
    • I surveyed rxvt, Eterm, xterm, VTE (gnome-terminal), Windows Terminal, and iterm2, and all of them have addressed known vulnerabilities.
    • Also, according to some comments in source code, terminal authors are completely aware that this kind of vulnerabilities should be addressed on terminal emulator side.
    • I believe there is already a concensus that this kind of security issues should be handled by terminal emulators, not Ruby.
    • So, let's remove the escape!

Updated by mame (Yusuke Endoh) about 1 year ago

Notes on issues found during the release process: (Sorry for Japanese)

Updated by duerst (Martin Dürst) about 1 year ago

  • [Bug #18294] error when parsing regexp comment (Martin Dürst)
    • We should decide whether this is spec, or to make parsing easier, or a bug.

Updated by jeremyevans0 (Jeremy Evans) about 1 year ago

  • [Bug #15928] Constant declaration does not conform to JIS 3017:2013 (jeremyevans0)
    • This was discussed at the May 2021 developer meeting, and it was decided to wait until after 3.1.
    • This makes constant assignment consistent with attribute assignment, so evaluation occurs left-to-right.
    • Is this OK to commit now?
  • [Bug #17545] Calling dup on a subclass of Proc returns a Proc and not the subclass (jeremyevans0)
    • Is this OK to commit this now?
  • [Bug #16908] Strange behaviour of Hash#shift when used with default_proc. (jeremyevans0)
    • This was discussed in the March 2021 developer meeting, and it was decided to wait until after 3.1.
    • I've added a pull request to make Hash#shift return nil if the hash is empty.
    • Is this OK to commit this now?
  • [Bug #16663] Add block or filtered forms of Kernel#caller to allow early bail-out (jeremyevans0)
    • @headius (Charles Nutter) prefers iteration over search, and recommends Thread.each_backtrace as the method name.
    • @headius (Charles Nutter) also has an idea for a block form that returns an enumerable, but I think that would greatly increase complexity.
    • I don't think each_backtrace is a good name for a method that yields individual caller locations.
    • I would like to go forward with Thread.each_caller_location or Kernel.each_caller_location (singleton method only), yielding Thread::Backtrace::Location objects. Is that acceptable?
  • [Bug #11064] #singleton_methods for objects with special singleton_class returns an empty array (jeremyevans0)
    • It is a bit inconsistent that singleton_method for nil/true/false returns a Method, but singleton_methods does not include the method.
    • Is this a bug, or expected behavior?

Updated by mame (Yusuke Endoh) about 1 year ago

  • [Feature #18438] Add Exception#additional_message to show additional error information (mame)
    • I'd like to apply error_highlight more exceptions than NameError, but it will break some existing tests that check the return value of Exception#message.
    • This feature allows did_you_mean and error_highlight to add their suggestions without modifying the return value of Exception#message.
    • To be honest, I'm unsure if this is a right way. I'd like to hear opinions from committers.
    • I'll explain some details in the meeting (prefix, needed cooperation, the API style between additional_message and description, etc.)

Updated by zverok (Victor Shepelev) about 1 year ago

  • [Feature #16122] Struct::Value: simple immutable value object (zverok)
    • the concept was somewhat favorably discussed a long time ago, but since then no reiterations were made.
    • I provided the extended description and rationales and answered the questions that were raised.
    • Is it possible to move forward with the idea?

Updated by Dan0042 (Daniel DeLorme) about 1 year ago

  • [Feature #18408] Allow pattern match to set instance variables
    • Currently, expr => @var is not supported.
    • It doesn't seem like there's a specific reason for that limitation; rescue => @var works fine.
    • I think ivars should be supported, it would be one less gotcha to learn.
    • The same might apply to @@var and $var ?

Updated by mame (Yusuke Endoh) about 1 year ago

  • [Feature #18462] Proposal to merge WASI based WebAssembly support (mame)
    • Let's support wasm. This will allow MRI to work on browsers and edge computing platforms.

Updated by mame (Yusuke Endoh) about 1 year ago

We were not able to discuss all of the agenda items. We will continue discussion on 28th Jan.

Actions #12

Updated by mame (Yusuke Endoh) 12 months ago

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

Also available in: Atom PDF