Project

General

Profile

Actions

Misc #19766

closed

DevMeeting-2023-08-24

Added by mame (Yusuke Endoh) 8 months ago. Updated 6 months ago.

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

Description

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.

Related issues 1 (1 open0 closed)

Related to Ruby master - Misc #14770: [META] DevelopersMeetingOpenActions
Actions #1

Updated by mame (Yusuke Endoh) 8 months ago

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

Updated by byroot (Jean Boussier) 7 months ago

  • [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?

Updated by peterzhu2118 (Peter Zhu) 7 months ago

  • [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?

Updated by jemmai (Jemma Issroff) 7 months ago

  • [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)

Updated by byroot (Jean Boussier) 7 months ago

  • [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.

Updated by alanwu (Alan Wu) 6 months ago

  • [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

Updated by jeremyevans0 (Jeremy Evans) 6 months ago

  • [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.

Updated by ko1 (Koichi Sasada) 6 months ago

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

Updated by hsbt (Hiroshi SHIBATA) 6 months ago

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

Updated by mame (Yusuke Endoh) 6 months ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0