Misc #19766: DevMeeting-2023-08-24

• Status: Closed
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2023/08/24 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeeting-2023-08-24.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 2023/08/21. 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.

[mame (Yusuke Endoh)]

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

[byroot (Jean Boussier)]

• [Bug #19784] Inconsistency between String#start_with? and String#delete_prefix for strings with broken encodings.
  • "\xFF\xFE".start_with?("\xFF") # => true
  • "\xFF\xFE".delete_prefix("\xFF") # => "\xFF\xFE"
  • If Ruby considers \xFF is indeed the prefix, it's unclear why it refuses to delete that prefix.
  • Should String#delete_prefix stop validating the encoding, or should String#start_with? start validating it?

[peterzhu2118 (Peter Zhu)]

• [Feature #19783] Weak References in the GC (peterzhu2118)
  • Native support for weak references in the GC. Overwrites dead objects with Qundef.
  • Implemented for CME of CC, ObjectSpace::WeakMap and ObjectSpace::WeakKeyMap. Makes the implementation of ObjectSpace::WeakMap and ObjectSpace::WeakKeyMap simpler.
  • No performance impact in yjit-bench. Microbenchmarks show that ObjectSpace::WeakMap#[]= is 3x faster.
• [Feature #19785] Deprecate RUBY_GC_HEAP_INIT_SLOTS (peterzhu2118)
  • This environment variable only made sense when we only have one heap.
  • It's replaced by the RUBY_GC_HEAP_INIT_SIZE_%d_SLOT environment variables.
  • Should we deprecate it? Or can we just remove it? It's an implementation internal environment variable, so maybe we can just remove it?

[jemmai (Jemma Issroff)]

• [Misc #19772] API Naming for YARP compiler
  • How should we expose the public API for YARP's compile method?
  • Potential options: YARP.compile, RubyVM::InstructionSequence.compile(yarp: true), RubyVM::InstructionSequence.compile_yarp, any of these with a name other than YARP (please suggest)

[byroot (Jean Boussier)]

• [Feature #19790] Optionally write Ruby crash reports into a file rather than STDERR (byroot)
  • STDERR is often hard to exploit in production, as it's often shared by multiple process causing interwined logs.
  • Being able to write bug report in predictable location allow for easier automated reporting of crashes in production.
  • The JVM has a similar feature with -XX:ErrorFile=
  • I suggest RUBY_BUGREPORT_PATH as an environment variable to control where the bug reports are written.

[alanwu (Alan Wu)]

• [Misc #19777] Make Kernel#lambda raise when called without a literal block
  • There are two code paths for detecting whether a literal block was passed, best to have just one
  • The way f_lambda_warn() does it allows block_code to be left uninitialized on calls, which is helpful for YJIT
  • Three years feels long enough for users to respond to the deprecation warning

[jeremyevans0 (Jeremy Evans)]

• [Bug #19779] eval "return" at top level raises LocalJumpError (jeremyevans0)
  • Do we want to allow eval "return" at top level with the same sematics as return?
• [Bug #19749] Confirm correct behaviour when attaching private method with #define_method (jeremyevans0)
  • This was discussed last month, but discussion focused on the general semantics and not the specific bug I want to fix.
  • Please see comments #13 and #15 for examples of the bug I want to fix. Can we fix that specific bug?
• [Bug #19829] Enumerator.product called with keyword arguments raises exception with not precise message (jeremyevans0)
  • Can we add rb_no_keywords_accepted to the C-API, so that C functions can implement the equivalent of **nil?
• [Misc #19740] Block taking methods can't differentiate between a non-local return and a throw (jeremyevans0)
  • The underlying issue is no longer a problem after a fix to timeout to always use raise instead of throw.
  • However, do we want to add a feature for ensure blocks to know if they were called via throw?
  • I'm against such a feature, as I don't think we want libraries treating throw differently than other non-local return.

[ko1 (Koichi Sasada)]

• [Feature #19842] Introduce M:N threads (ko1)
  • Do you have any questions about it?

[hsbt (Hiroshi SHIBATA)]

• [Bug #19843] Promote bigdecimal as bundled gems at Ruby 3.4
  • mrkn: Is it okay?

[mame (Yusuke Endoh)]

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