Project

General

Profile

Actions

Misc #22394

closed

DevMeeting-2026-10-07

Misc #22394: DevMeeting-2026-10-07

Added by hsbt (Hiroshi SHIBATA) 23 days ago. Updated 15 days ago.

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

Description

The next dev meeting

Date: 2026/10/07 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-10-07.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 2026/10/04. 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 open — 0 closed)

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

Updated by hsbt (Hiroshi SHIBATA) 23 days ago Actions #1

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

Updated by byroot (Jean Boussier) 23 days ago Actions #2 [ruby-core:126891]

  • [Feature #22395] RubyVM::InstructionSequence.load_from_binary to optionally accept file and path arguments like compile (byroot)
    • ISeq caching has a long live problem that ISeqs contain the source file path and realpath, making Iseq "non-portable". See [Feature #17593].
    • To solve this, I think we need to be able to provide the new path and realpath when loading an ISeq from binary. Which means extending some APIs.
    • Proposed: load_from_binary(binary [, file[, path]]), similar to the existing compile(source[, file[, path[, line[, options]]]]).
    • Also C API: VALUE rb_iseq_load_from_binary(const char *ptr, size_t len, VALUE file, VALUE path). The later argument can be set to nil.

Updated by jeremyevans0 (Jeremy Evans) 23 days ago Actions #3 [ruby-core:126898]

  • [Feature #22309] Allow super in a module method to work if method was called by refinement method super (jeremyevans0)
    • From Ruby 2.4-4.0, super has been allowed, but used the wrong method lookup, so it generally resulted in a NoMethodError.
    • I changed it to always raise a NoMethodError instead of doing method lookup a few months ago (#22071).
    • However, I think it's better to actually remove the limitation and allow super to work correctly.
    • This also fixes defined?(super) and {Method,UnboundMethod}#super_method in these methods.
    • Can we remove this limitation? @shugo (Shugo Maeda) has already reviewed the pull request.

Updated by hasumikin (hitoshi hasumi) 22 days ago ยท Edited Actions #4 [ruby-core:126899]

  • [Feature #22399] Iterator Methods for String Bit Operations (hasumikin)
    • Proposed new methods each_bit, bits, each_bit_offset and bit_offsets for String
    • They are the iterator forms of the single-bit read methods merged in #22118
    • Please discuss whether the method names and the API conventions are suitable for Ruby
  • [Feature #22405] Run-Length Methods for String Bit Operations (hasumikin)
    • Proposed new methods bit_run_length, each_bit_run and bit_runs
    • Likewise, please consider the method names and the API conventions

Updated by hsbt (Hiroshi SHIBATA) 22 days ago Actions #5 [ruby-core:126901]

  • [Feature #22400] Use rb_long_t for lengths so that String and Array can exceed 2GiB on mswin (hsbt)
    • The first step (PR #18862) replaces long with rb_long_t, which stays typedef long, and changes nothing. The second step makes it 64 bits on mswin and breaks a few extensions there. I would like to know whether we go this way, whether rb_long_t is a good name, and whether both steps can land in 4.1.

Updated by shugo (Shugo Maeda) 21 days ago Actions #6 [ruby-core:126907]

  • [Feature #22392] Allow refinements to define && and || (shugo)
    • I propose to allow && and || to be defined in refinements, so that DSLs can write where { name == "x" && age > 20 } instead of where { (name == "x") & (age > 20) }.
    • The right-hand side is evaluated before the hook is called, so a hook never short-circuits; code outside using or Proc#refined keeps the current behavior, and defining them outside refinements raises NameError.
    • &&= and ||=, conditions such as if a && b, and statements that discard the value keep the current behavior.
    • PoC: https://github.com/ruby/ruby/pull/19133
    • Objections on the ticket: the cost for non-users (alanwu) and that &/| with parentheses is readable enough (matheusrich). With conditions excluded, code that doesn't use the hooks pays +2..3 instructions per &&/|| whose value is used and about +0.4% of iseq memory. Is the feature worth that?

Updated by hsbt (Hiroshi SHIBATA) 21 days ago Actions #7 [ruby-core:126911]

  • [Feature #22402] Drop support for Darwin on PowerPC (hsbt)
    • PowerPC Macs stopped at Mac OS X 10.5 in 2007 and no CI covers them, but coroutine/ppc, coroutine/ppc64 and the PowerPC branches under __APPLE__ remain and still get occasional patches. I would like to drop Darwin on PowerPC only, not PowerPC in general (ppc64le and AIX stay), and raise the minimum Mac OS X version to 10.6 along with it (https://github.com/ruby/ruby/pull/19183). Can we drop it?

Updated by jhawthorn (John Hawthorn) 18 days ago Actions #8 [ruby-core:126928]

  • [Feature #22376] Undefine the allocator for Class (jhawthorn)
    • Makes Class.allocate raise. Same as ex. Proc.allocate
    • Class can't be subclassed, and I didn't find any legitimate uses in gem-codesearch. I don't think there will be compatibility issues.
    • Okay to merge? https://github.com/ruby/ruby/pull/18964

Updated by mame (Yusuke Endoh) 15 days ago Actions #9

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

Updated by mame (Yusuke Endoh) 15 days ago Actions #10

  • Description updated (diff)
Actions

Also available in: PDF Atom