[ruby-core:115460] [Ruby master Misc#19997] DevMeeting-2023-11-30

Issue #19997 has been updated by jeremyevans0 (Jeremy Evans).


* [Bug #20008] f(**kw, &block) calls block.to_proc before kw.to_hash (jeremyevans0)
  * I think this is a bug as it goes against expected evaluation order.
  * Is fixing this using a new VM instruction and the peephole optimizer acceptable?
* [Bug #20012] Fix keyword splat passing as regular argument (jeremyevans0)
  * Should we fix this for Ruby 3.3, or wait until Ruby 3.4 (my preference would be 3.3)?
  * Should we backport this fix to Ruby 3.2 or 3.1 (my preference would be both)?
* [Bug #18886] Struct aref and aset don't trigger any tracepoints. (jeremyevans0)
  * I implemented support using the same approach used for attr_{reader,writer}.
  * Is the pull request acceptable?
* [Bug #19779] `eval "return"` at top level raises `LocalJumpError` (jeremyevans0)
  * I developed a pull request to fix this.
  * Is the pull request acceptable?
* [Feature #20011] Reduce implicit array allocations on caller side of method calling (jeremyevans0)
  * Some of these optimizations have the same theoretical issues as `f(*a, &lvar)` and `f(*a, &@ivar)` currently.
  * I think the benefit of the optimizations exceeds the costs (unexpected behavior in pathological cases).
  * Are these optimizations acceptable?
  * If not acceptable, should we fix the theoretical issues with `f(*a, &lvar)` and `f(*a, &@ivar)`, at the cost of performance?

----------------------------------------
Misc #19997: DevMeeting-2023-11-30
https://bugs.ruby-lang.org/issues/19997#change-105389

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
# The next dev meeting

**Date: 2023/11/30 13:00-17:00** (JST)
Log: *TBD*

- 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 2023/11/27. 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](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86).  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.




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/