Actions
Misc #20781
closedDevMeeting-2024-11-07
Status:
Closed
Assignee:
-
Description
The next dev meeting¶
Date: 2024/11/07 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2024/DevMeeting-2024-11-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 2024/11/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.
Updated by mame (Yusuke Endoh) about 2 months ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by eightbitraptor (Matt V-H) about 1 month ago
- [Feature #20794] Expose information about the currently running GC Module (@eightbitraptor (Matt V-H))
- This adds a dynamic component to
RUBY_DESCRIPTION
, when a modular GC is loaded. Is this acceptable? - This adds a method
GC.active_gc_name
- Is the name OK?
- Are the semantics OK? (
nil
unless a GC module is actively being used).
- This adds a dynamic component to
Updated by mame (Yusuke Endoh) 25 days ago
- [Feature #20811]
warning: in a**b, b may be too big
is really helpful? (mame)- I think the warning is not useful. Can we remove the warning?
Updated by hsbt (Hiroshi SHIBATA) 21 days ago
- [Feature #20782] Introduction of Happy Eyeballs Version 2 (RFC8305) in TCPSocket.new
- Propose shioimm as a Ruby committer
- How about it?
- Propose shioimm as a Ruby committer
Updated by hsbt (Hiroshi SHIBATA) 20 days ago
- [Feature #20859] Make Base64 to core class
- It's useful and helpful for gemification.
Updated by peterzhu2118 (Peter Zhu) 20 days ago
- [Feature #20860] Merge Optional Experimental Feature MMTk into Ruby
- We are proposing to merge MMTk into the
ruby/mmtk
repository, which will be mirrored intoruby/ruby
. - This implementation uses the GC API (introduced in [Feature #20470]).
- Supports the NoGC and mark-sweep algorithms.
- We do not ever anticipate replacing Ruby's default GC with MMTk but instead offer it as an alternative implementation.
- We have our roadmap proposed in the ticket, which includes supporting generations, improving parallelism, and support moving, faster algorithms such as Immix.
- We are proposing to merge MMTk into the
Updated by furunkel (Julian Aron Prenner) 20 days ago
- [Feature #20818] Allow passing a block to Hash#store to update current value (furunkel)
- currently, to update a value in a hash we have to call
#[]
followed by#[]=
- this calls
#hash
twice (on key), and requires two lookups; this also happens for shortcuts such ash[k] += c
- this calls
- the problem could be solved by introducing a block form for
Hash#store
(Hash#update
is already taken)- the block is called with the current value or the default value if the key does not exist; return value = new value
- inverse of
Hash#fetch
, which also can take block
-
h[k] = some_method(h[k])
could be written ash.store(k) { some_method(_1) }
, more efficient and more elegant in some cases (e.g., ifk
is complex, no repetition) - exists in other languages: e.g.,
Map#computeIfAbsent|Present
(Java) orand_modify
(Rust) - existing implementation: GH PR#11956
- currently, to update a value in a hash we have to call
Updated by AlexandreMagro (Alexandre Magro) 18 days ago · Edited
- [Feature #20770] (Re)Introduce pipe operator (AlexandreMagro)
- Initially proposed as syntactic sugar for
.then
, and later refined after discussion to work as a statement separator (like;
) with a variable carrying the LHS expression result to the RHS in #note-34. - This approach aligns with how pipes work in other languages, adapted for Ruby.
- Improves readability by transforming
p(q(r))
into a more naturalr |> q |> p
, matching how we think.
- Initially proposed as syntactic sugar for
Updated by mame (Yusuke Endoh) 17 days ago
AlexandreMagro (Alexandre Magro) wrote in #note-8:
- Improves readability by transforming
p(q(r))
into a more naturalr |> q |> p
, matching how we think.
Do you mean r |> q(_) |> p(_)
?
Updated by ioquatix (Samuel Williams) 16 days ago · Edited
- [Bug #20863]
zlib.c
callsrb_str_set_len
andrb_str_modify_expand
(and others) without holding the GVL (ioquatix)- Is the PR (https://github.com/ruby/zlib/pull/88) to zlib acceptable?
- [Feature #20877] Introduce (public) debug assertion for holding the GVL (ioquatix)
- Is the PR (https://github.com/ruby/ruby/pull/11975 - ignore the changes to
zlib.c
) to introduce these checks internally acceptable? - Can we add more checks to other functions in CRuby?
- Can we introduce a public macro so that other native extensions can also implement this check?
- Can we agree on a name for this macro and any related public functions?
- Is the PR (https://github.com/ruby/ruby/pull/11975 - ignore the changes to
- [Feature #20876] Introduce
Fiber::Scheduler#blocking_operation_wait
to avoid stalling the event loop (ioquatix)- Is the proposed scheduler hook acceptable?
- [Feature #20864] Allow
Kernel#warn
to accept**options
and pass these toWarning.warn
(ioquatix)- Is such an interface acceptable?
- If we introduce the updated interface, do we need to provide C function too?
Updated by byroot (Jean Boussier) 15 days ago
- [Bug #20869] IO buffer handling is inconsistent when seeking (byroot)
- The ticket show multiple weirdness around
IO#ungetbyte / IO#ungetc
and#IO#seek
. - This is very clearly a bug, but what the right behavior should be isn't very clear. Clarification would be welcome.
- The ticket show multiple weirdness around
Updated by mame (Yusuke Endoh) 14 days ago
- Description updated (diff)
- Status changed from Open to Closed
Actions
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0