ruby-core

Issue #18039 has been updated by jeremyevans0 (Jeremy Evans).


* [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#<=>` and `Range#succ` such that a range of ranges could be useful.
* [Bug #15428] Refactor Proc#>> and #<< (jeremyevans0)
  * Do we want `Proc#<<` and `Proc#>>` to call `to_proc` on the argument given?
  * Doing so would allow usage of symbols and other things that implement `to_proc` but not `call`.
  * Doing so always would break usage with arguments that respond to `call` but do not respond to `to_proc`.
  * Doing so only if the argument responds to `to_proc` and not `call` 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 to `call`.
* [Bug #14744] Refinements modules have a superclass (jeremyevans0)
  * Should we hide the superclass of a refinement module from reflection APIs such as `ancestors`?

----------------------------------------
Misc #18039: DevelopersMeeting20210819Japan
https://bugs.ruby-lang.org/issues/18039#change-93202

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
# The next dev meeting

**Date: 2021/08/19 13:00-17:00**
Place/Sign-up/Agenda/Log: *TBD*

- 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](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86).  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.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

Thread

Prev Next

In This Thread

Prev Next