Project

General

Profile

Actions

Misc #19766

closed

DevMeeting-2023-08-24

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

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

Updated by byroot (Jean Boussier) 11 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) 11 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) 11 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) 10 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) 10 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) 10 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) 10 months ago

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

Updated by hsbt (Hiroshi SHIBATA) 10 months ago

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

Updated by mame (Yusuke Endoh) 10 months ago

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

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0