Actions
Misc #19766
closedDevMeeting-2023-08-24
Status:
Closed
Assignee:
-
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.
Updated by mame (Yusuke Endoh) over 1 year ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by byroot (Jean Boussier) over 1 year ago
- [Bug #19784] Inconsistency between
String#start_with?
andString#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 shouldString#start_with?
start validating it?
Updated by peterzhu2118 (Peter Zhu) over 1 year 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
andObjectSpace::WeakKeyMap
. Makes the implementation ofObjectSpace::WeakMap
andObjectSpace::WeakKeyMap
simpler. - No performance impact in yjit-bench. Microbenchmarks show that
ObjectSpace::WeakMap#[]=
is 3x faster.
- Native support for weak references in the GC. Overwrites dead objects with
- [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) over 1 year 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) about 1 year 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) about 1 year 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 allowsblock_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) about 1 year ago
- [Bug #19779]
eval "return"
at top level raisesLocalJumpError
(jeremyevans0)- Do we want to allow
eval "return"
at top level with the same sematics asreturn
?
- Do we want to allow
- [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) about 1 year ago
- [Feature #19842] Introduce M:N threads (ko1)
- Do you have any questions about it?
Updated by hsbt (Hiroshi SHIBATA) about 1 year ago
- [Bug #19843] Promote bigdecimal as bundled gems at Ruby 3.4
- mrkn: Is it okay?
Updated by mame (Yusuke Endoh) about 1 year ago
- Description updated (diff)
- Status changed from Open to Closed
Actions
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0