Misc #18399



Added by mame (Yusuke Endoh) 12 months ago. Updated 10 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) 12 months ago

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

Updated by zverok (Victor Shepelev) 12 months 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) 12 months 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) 11 months ago

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

Updated by duerst (Martin Dürst) 11 months 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) 11 months 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) 11 months 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) 11 months 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) 11 months 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) 11 months 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) 11 months 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) 10 months ago

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

Also available in: Atom PDF