Project

General

Profile

Actions

Misc #19074

closed

DevMeeting-2022-12-01 (postponed from 11-17)

Added by mame (Yusuke Endoh) about 2 years ago. Updated about 2 years ago.

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

Description

The next dev meeting

Date: 2022/11/17 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/DevMeeting-2022-12-01.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 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.)

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 2022/11/14. 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 2 years ago

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

Updated by ioquatix (Samuel Williams) about 2 years ago

  • [Feature #19078] Introduce Fiber#storage for inherited fiber-scoped variables.
    • Updated based on feedback, is it acceptable?

Updated by byroot (Jean Boussier) about 2 years ago

Updated by Eregon (Benoit Daloze) about 2 years ago

  • [Bug #18899] Inconsistent argument handling in IO#set_encoding (@Eregon (Benoit Daloze))
    • Could someone review Jeremy's fix and merge it?
    • The logic for IO set_encoding is really complicated (also following the C code for it is hard), I wish we could simplify it.

Updated by tenderlovemaking (Aaron Patterson) about 2 years ago

Updated by mame (Yusuke Endoh) about 2 years ago

  • [Feature #19104] Introduce the cache-based optimization for Regexp matching (mame)
    • This optimization to onigmo makes most Regexp matching linear time. In short, it will solve ReDoS.
    • There are two notable limitations: (1) there are some unoptimizable Regexp patterns (e.g., back-references. About 10% Regexp objects are not optimizable according to measurement with some real-world libraries), and (2) it comsumes memory proportional to the input string (According to measurement, at worst, about 10 times to the length of the input string)
    • We want you to discuss: (1) can we merge this change (into preview3 if possible), and (2) should we provide a way to tell users if a given regexp is optimizable or not (e.g., a warning at unoptimizable regexp creation, a new API like Regexp#optimizable?, or a new opt-in Regexp flag /foo/r to raise a SyntaxError when it is not optimizable, etc.)

Updated by Eregon (Benoit Daloze) about 2 years ago

  • [Feature #11689] Add methods allow us to get visibility from Method and UnboundMethod object. (eregon)
    • {Method,UnboundMethod}#{private?,protected?,public?} exist in 3.1 but are currently not defined in 3.2
    • I think we should add them back, I think there is no reason to remove them anymore, since the behavior is intuitive now. Of course we need to store and return the visibility of the original method found by .method/.instance_method, not the zsuper-resolved method (same as for owner).
    • I think it is unnecessary to wait for someone to open a ticket "private?,protected?,public? methods missing in 3.2".

Updated by jeremyevans0 (Jeremy Evans) about 2 years ago

  • [Bug #19012] BasicSocket#recv* methods return an empty packet instead of nil on closed connections (jeremyevans0)
    • It seems like a good idea to be able to differentiate an empty packet versus a closed connection.
    • Is it OK to change the behavior to return nil for closed connections?
  • [Bug #19003] TracePoint behavior inconsistency in 3.2.0-preview2 (jeremyevans0)
    • Behavior has changed for this case since Ruby 3.1 to fix other TracePoint bugs.
    • Do we consider the new behavior a bug, or an implementation detail?

Updated by st0012 (Stan Lo) about 2 years ago

  • [Feature #18996] Proposal: Introduce new APIs to reline for changing dialog UI colours
    • After discussing with @k0kubun (Takashi Kokubun), we've decided to use iTerm2's settings as colour options' naming reference.
    • We also think it's better to accept colour configs at both DialogRenderInfo and completion level (which builds on top of DialogRenderInfo but doesn't expose its APIs). This will give us enough flexibility for future extension.
    • Do we think it's ready for implementation?

Updated by jeremyevans0 (Jeremy Evans) about 2 years ago

  • [Bug #19113] Inconsistency in retention of compare_by_identity flag in Hash methods (jeremyevans0)
    • Is it OK to change Hash.[] to never return a compare_by_identity hash?
    • Is it OK to change Hash.ruby2_keywords_hash to not drop the compare_by_identity flag for empty hash arguments?
    • Is it OK to change Hash#compact to copy the default value/proc and compare_by_identity flag?

Updated by byroot (Jean Boussier) about 2 years ago

  • [Feature #19107] Allow trailing comma in method signature (byroot)
    • I would like to make def foo(a,), def foo(a:,) and def foo(&block,) valid syntax.
    • Trailing commas are popular when breaking up a very long statement into multiple lines.
    • Method calls, array literals, hash literals, all accept trailing commas, but method definitions don't.
    • This would seem more consistent to me.
  • [Feature #18951] Object#with to set and restore attributes around a block (byroot)
    • It's not clear to me what was decided when this was first discussed in a previous meeting.
    • I kinda understand that with is seen as too generic, if so would with_attr be acceptable?
    • I added a handful of real world code snippets that would be simplified by this method.
    • Any other concerns?
  • [Feature #19117] Include the method owner in backtraces, not just the method name (byroot)
    • from /tmp/foo.rb:4:in 'Foo::Bar#inspect' instead of just from /tmp/foo.rb:4:in 'inspect'.
    • Would make backtrace much easier to understand just by reading them without jumping to the definition every time.
    • @Dan0042 (Daniel DeLorme) suggested to display the receiver rather than the owner.

Updated by bdewater (Bart de Water) about 2 years ago

  • [Feature #19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] (bdewater)
    • There seems to be consensus for the need of the feature, but not on what the method name should be. The proposals are with (C#, Java, Sorbet, value_semantics gem) and dup (with arguments, similar to Sequel datasets).
    • I think it would be valuable to have this decided and shipped with 3.2 to make Data objects ergonomic to work with.

Updated by shugo (Shugo Maeda) about 2 years ago

  • [Bug #19132] ** with other keyword parameters causes "no anonymous keyword rest parameter" (shugo)
    • RBS expects no name for keyword rest parameters while test_method.rb etc expects :**. Can we choose :** for consistency?

Updated by mame (Yusuke Endoh) about 2 years ago

This dev meeting has been postponed to 1st Dec. for various reasons.

If you have any topics you really want us to discuss, you can add them by 30th Nov. (But we already have a lot on the agenda, so I would appreciate your consideration.)

Actions #15

Updated by duerst (Martin Dürst) about 2 years ago

  • Subject changed from DevMeeting-2022-11-17 to DevMeeting-2022-12-01 (postponed from 11-17)

Updated by shugo (Shugo Maeda) about 2 years ago

  • [Feature #19134] ** is not allowed in def foo(...)
    • I believe ** should be allowed, or both * and & should be prohibited.

Updated by Eregon (Benoit Daloze) about 2 years ago

  • [Bug #19108] Format routines like pack blindly treat a string as ASCII-encoded (@Eregon (Benoit Daloze))
    • Is it OK to make unknown pack directive an ArgumentError?
    • If not is it OK to make it a non-verbose warning (i.e., shown with default $VERBOSE=false)?

Updated by Eregon (Benoit Daloze) about 2 years ago

  • [Bug #19150] pack/unpack silently ignores unknown directives (eregon)
    • Similar to #19108 just above.
    • I believe unknown directive should be ArgumentError, not silent unless VERBOSE is true.
Actions #19

Updated by mame (Yusuke Endoh) about 2 years ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0