Actions
Misc #18039
closedDevelopersMeeting20210819Japan
Status:
Closed
Assignee:
-
Description
The next dev meeting¶
Date: 2021/08/19 13:00-17:00
Place/Sign-up/Agenda/Log: https://github.com/ruby/dev-meeting-log/blob/master/DevelopersMeeting20210819Japan.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 log about the discussion to a 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 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 2021/08/16. 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 3 years ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by nobu (Nobuyoshi Nakada) over 3 years ago
- [Misc #18059] Which
FL_USER
x are open to extension libraries? (nobu)- (need comment)
Updated by nobu (Nobuyoshi Nakada) over 3 years ago
- [Feature #18051] Move symbols exported under internal (nobu)
-
Some symbols exported in headers under
internal
are declared and used in some extension libraries.
These seem OK to be moved to public headers.-
ruby_scan_digits
,ruby_hexdigits
,ruby_digit36_to_number_table
rb_int_positive_pow
rb_deprecate_constant
-
-
Updated by alanwu (Alan Wu) over 3 years ago
- [Bug #13392] TracePoint return event location is incorrect for methods defined with define_method (alanwu)
- There are two PRs available, one more complex but opens the possibility for future optimizations. Which do you prefer?
- [Bug #18060] Fix infinite loop when b_return TracePoint throws (alanwu)
- Does the fix make sense?
- [Bug #18031] Nested TracePoint#enable with define_method target crashes (alanwu)
- Does my fix look good? It assumes that multiple TracePoints targeting the same bmethod should work similar to other targets.
Updated by duerst (Martin Dürst) over 3 years ago
- [Feature #18045] Variable Width Allocation Phase II (peterzhu2118)
- Variable Width Allocation is a major change to Ruby internals and therefore should be discussed seriously.
Updated by byroot (Jean Boussier) about 3 years ago
- [Feature #10917] Add GC.stat[:total_time] (byroot)
- Time spent in GC is a very important metric for application performance monitoring.
- Right now only
GC::Profiler
can be used, but it is ill suited when there are multiple callers because it is stateful. It also need to be gated by a Mutex. - A single monotonically increasing time metric would be much more usable.
- If the
getrusage_time
overhead is dimmed to big, it could be a an opt-in metrics through a flag on::GC
. - I don't ask to merge that particular patch, but wether the general idea is acceptable.
- @Eregon (Benoit Daloze) suggested
GC.stat[:time]
in milliseconds, as that's what JRuby and TruffleRuby already expose.
Updated by jeremyevans0 (Jeremy Evans) about 3 years ago
- [Bug #18036] Pthread fibers become invalid on fork - different from normal fibers. (jeremyevans0)
-
fork
terminates other threads. - When using pthread coroutine, all fibers are threads, therefore
fork
terminates all other fibers. - Are we OK with this runtime difference with pthread coroutine? (I am.)
- Do we want to terminate other fibers when forking always, or just when using the pthread coroutine?
- Do we want to raise an exception if calling
fork
from a non-main fiber?
-
- [Feature #16889] TracePoint.enable { ... } also activates the TracePoint for other threads, even outside the block (jeremyevans0)
- I think this behavior is currently expected. At least the tests expect it, and the behavior seems reasonable.
- Ruby could benefit from a nicer way to pass a block and only allow tracing for the block.
- I implemented this nicer way by supporting a
target: :block
option. - Is the current behavior of
TracePoint.enable
with a block expected? - Is it OK to add support for a
target: :block
option using the patch?
- [Bug #15404] Endless range has inconsistent chaining behaviour (jeremyevans0)
- Do we want to make ranges of ranges a parse error (e.g.
(1..2)..(1..3)
)? - I think we shouldn't. It's possible to define
Range#<=>
andRange#succ
such that a range of ranges could be useful.
- Do we want to make ranges of ranges a parse error (e.g.
- [Bug #15428] Refactor Proc#>> and #<< (jeremyevans0)
- Do we want
Proc#<<
andProc#>>
to callto_proc
on the argument given? - Doing so would allow usage of symbols and other things that implement
to_proc
but notcall
. - Doing so always would break usage with arguments that respond to
call
but do not respond toto_proc
. - Doing so only if the argument responds to
to_proc
and notcall
may result in inconsistent behavior. - I see no problem with the current situation, but I'm not opposed to calling
to_proc
if the object does not respond tocall
.
- Do we want
- [Bug #14744] Refinements modules have a superclass (jeremyevans0)
- Should we hide the superclass of a refinement module from reflection APIs such as
ancestors
?
- Should we hide the superclass of a refinement module from reflection APIs such as
Updated by ktsj (Kazuki Tsujimoto) about 3 years ago
- [Feature #16182] Should
expr in a, b, c
be allowed or not? (ktsj)- How about allowing brackets/braces to be omitted in one-line pattern matching?
Updated by tenderlovemaking (Aaron Patterson) about 3 years ago
- [Feature #18007] C extension "allocation function" check
- Should we add a config option and put in 3.1, or just wait for 3.2?
Updated by ioquatix (Samuel Williams) about 3 years ago
- [Feature #18083] Capture error in ensure block.
- Is it acceptable?
Updated by nobu (Nobuyoshi Nakada) about 3 years ago
- [Bug #18077]
Marshal.dump(closed_io)
raisesIOError
instead ofTypeError
(nobu)-
Marshal.dump
is expected to raise aTypeError
for unmarshallable objects. But closed streams raise anIOError
-
Updated by hsbt (Hiroshi SHIBATA) almost 3 years ago
- Status changed from Open to Closed
Actions
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0