February 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112295] [Ruby master Feature#17753] Add Module#namespace
by shioyama (Chris Salzberg) 09 Feb '23

09 Feb '23

Issue #17753 has been updated by shioyama (Chris Salzberg). > When you assign an integer to a constant, it's just storage. If you assign a class or module object with a name, it's just storage. However, assigning an anonymous class or module object changes the state, it has a side-effect that is only programmed for these objects. That's a very interesting way to put it, I hadn't thought of it that way. And indeed those side-effects scale with the number of other classes and modules rooted in the thing that was named. ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101730 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal ---------------------------------------- Given code like this: ```ruby module A module B class C; end class D; end end end ``` We can get from `C` to `B` like `C.outer_scope`, or to `A` like `C.outer_scope.outer_scope`. I want to use this in cases where I don't know the outer scope, but I want to find constants that are "siblings" of a constant. For example, I can do `A::B::C.outer_scope.constants` to find the list of "sibling" constants to `C`. I want to use this feature when walking objects and introspecting. For example: ```ruby ObjectSpace.each_object(Class) do |k| p siblings: k.outer_scope.constants end ``` I've attached a patch that implements this feature, and there is a pull request on GitHub [here](https://github.com/ruby/ruby/pull/4326). ---Files-------------------------------- 0001-Add-Module-outer_scope.patch (5.93 KB) 0001-Add-Module-namespace.patch (5.89 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111501] [Ruby master Bug#19283] Regex error on ruby 3.2
by Sho (Shohei Nakano) 09 Feb '23

09 Feb '23

Issue #19283 has been reported by Sho (Shohei Nakano). ---------------------------------------- Bug #19283: Regex error on ruby 3.2 https://bugs.ruby-lang.org/issues/19283 * Author: Sho (Shohei Nakano) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is an regex error pattern on ruby 3.2.0. This pattern is success on ruby 3.1.3. Is this a bug? Or, is ruby 3.2.0 correct? - ruby 3.2.0 ``` # ruby -v ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') nil ``` - ruby 3.1.3 ``` # ruby -v ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> ``` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:111461] [Ruby master Feature#19272] Hash#merge: smarter protocol depending on passed block arity
by zverok (Victor Shepelev) 09 Feb '23

09 Feb '23

Issue #19272 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19272: Hash#merge: smarter protocol depending on passed block arity https://bugs.ruby-lang.org/issues/19272 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Usage of `Hash#merge` with a "conflict resolution block" is almost always clumsy: due to the fact that the block accepts `|key, old_val, new_val|` arguments, and many trivial usages just somehow sum up old and new keys, the thing that should be "intuitively trivial" becomes longer than it should be: ```ruby # I just want a sum! {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |_, o, n| o + n } # I just want a group! {words: %w[I just]}.merge(words: %w[want a group]) { |_, o, n| [*o, *n] } # I just want to unify flags! {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE) { |_, o, n| o | n } # ...or, vice versa: {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE) { |_, o, n| o & n } ``` It is especially noticeable in the last two examples, but the _usual_ problem is there are too many "unnecessary" punctuation, where the essential might be lost. There are proposals like #19148, which struggle to define _another_ method (what would be the name? isn't it just merging?) But I've been thinking, can't the implementation be chosen based on the arity of the passed block?.. Prototype: ```ruby class Hash alias old_merge merge def merge(other, &block) return old_merge(other) unless block if block.arity.abs != 2 old_merge(other, &block) else old_merge(other) { |_, o, n| block.call(o, n) } end end end {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5, &:+) #=> {:apples=>4, :oranges=>2, :bananas=>5} {words: %w[I just]}.merge(words: %w[want a group], &:concat) => {:words=>["I", "just", "want", "a", "group"]} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, &:|) # => {"file1"=>5, "file2"=>5} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE, &:&) # => {"file1"=>0, "file2"=>4} # If necessary, old protocol still works: {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |k, o, n| k == :apples ? 0 : o + n } # => {:apples=>0, :oranges=>2, :bananas=>5} ``` As far as I can remember, Ruby core doesn't have methods like this (that change implementation depending on arity of passed callable), but I think I saw this approach in other languages. Can't remember particular examples, but always found this idea appealing. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:112290] [Ruby master Feature#19061] Proposal: make a concept of "consuming enumerator" explicit
by matz (Yukihiro Matsumoto) 09 Feb '23

09 Feb '23

Issue #19061 has been updated by matz (Yukihiro Matsumoto). Regarding the concrete proposals: 1. Introduce an `Enumerator#consuming?` method The consuming information is not reliable especially with I/O (some IO may not be rewindable, but lseek(2) may not return error for the IO, e.g. on MacOS). Thus we cannot implement trust-worthy `consuming?` method 2. Introduce `consuming: true` parameter for Enumerator.new Since `consuming?` state of the enumerators are unreliable, this keyword argument is useless 3. Introduce Enumerator#consuming method to produce a consuming enumerator from a non-consuming one The original PoC code modifies the original, the modified one raising error for duping internal fiber. It's not acceptable behavior (but former may be). In theory, we can overhaul the implementation of enumerators, but I don't think it's worth the cost. The final decision may be up to the actual use-case. But I doubt the benefit. Matz. ---------------------------------------- Feature #19061: Proposal: make a concept of "consuming enumerator" explicit https://bugs.ruby-lang.org/issues/19061#change-101722 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- **The problem** Let's imagine this synthetic data: ```ruby lines = [ "--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators", "", "Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..." ] ``` The logic of parsing it is more or less clear: * skip the first line * take lines until meet empty, to read the header * take the rest of the lines to read the body It can be easily translated into Ruby code, almost literally: ```ruby def parse(enumerator) puts "Testing: #{enumerator.inspect}" enumerator.next p enumerator.take_while { !_1.empty? } p enumerator.to_a end ``` Now, let's try this code with two different enumerators on those lines: ```ruby require 'stringio' enumerator1 = lines.each enumerator2 = StringIO.new(lines.join("\n")).each_line(chomp: true) puts "Array#each" parse(enumerator1) puts puts "StringIO#each_line" parse(enumerator2) ``` Output (as you probably already guessed): ``` Array#each Testing: #<Enumerator: [...]:each> ["--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators", "", "Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] StringIO#each_line Testing: #<Enumerator: #<StringIO:0x00005581018c50a0>:each_line(chomp: true)> ["From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] ``` Only the second enumerator behaves the way we wanted it to. Things to notice here: 1. Both enumerators are of the same class, "just enumerator," but they behave differently: one of them is **consuming** data on each iteration method, the other does not; but there is no programmatic way to tell whether some enumerator instance is consuming 2. There is no easy way to **make a non-consuming enumerator behave in a consuming way**, to open a possibility of a sequence of processing "skip this, take that, take the rest" **Concrete proposal** 1. Introduce an `Enumerator#consuming?` method that will allow telling one of the other (and make core enumerators like `#each_line` properly report they are consuming). 2. Introduce `consuming: true` parameter for `Enumerator.new` so it would be easy for user's code to specify the flag 3. Introduce `Enumerator#consuming` method to produce a consuming enumerator from a non-consuming one: ```ruby # reference implementation is trivial: class Enumerator def consuming source = self Enumerator.new { |y| loop { y << source.next } } end end enumerator3 = lines.each.consuming parse(enumerator3) ``` Output: ``` ["From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112289] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by matz (Yukihiro Matsumoto) 09 Feb '23

09 Feb '23

Issue #18368 has been updated by matz (Yukihiro Matsumoto). I accept solution 2, which someone may specify an array or a set for the range edge, and get an unnatural result. I consider it is the responsibility of the user. Matz. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-101721 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112286] Ruby 3.2.1 Released
by NARUSE, Yui 08 Feb '23

08 Feb '23

Ruby 3.2.1 has been released. This is the first TEENY version release of the stable 3.2 series. See the [commit logs](https://github.com/ruby/ruby/compare/v3_2_0...v3_2_1) for further details. ## Download * <https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.1.tar.gz> SIZE: 20448976 SHA1: aa570c9c89dc19090f623dc31083a4fa4e2b8a7b SHA256: 13d67901660ee3217dbd9dd56059346bd4212ce64a69c306ef52df64935f8dbd SHA512: f8bbff5e237b501f4042ddc70a19ac1ce74f72f147c90daf7f3007a940136abde37c12a0f7444f713ede09ba847c2cc2897a1742823832e3dc8cce80073164e1 * <https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.1.tar.xz> SIZE: 15094384 SHA1: eab9eaa05c6f572032e8c8f6108c9a4fe229ddd3 SHA256: 746c8661ae25449cbdc5297d1092702e93e66f365a75fecb740d4f292ced630c SHA512: 69caadab9be6b56905ea4fc92fa0e36704f9fa6a0e7e7f4c6bdb79e9cbe8dc57c524f96d9c18802d61aa1ca578fed2e9758692f9d701bf0dba938f0206b721b3 * <https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.1.zip> SIZE: 24595108 SHA1: fa35be65563b8d989ecf529b938e391b5d595ac4 SHA256: b6e132b65ec1a821067a5a1ca281936aa6f8967d3f758c623a9f4f22e711a317 SHA512: 795e1b74f70552d756c0a75c12ff9f3150866546643dd86afbbe8c0bcaa4df53ae928004e3632e703e14bb76d671c4627dfd01eb453d039067186200ea058d74 ## Release Comment Many committers, developers, and users who provided bug reports helped us make this release. Thanks for their contributions.

1 0

[ruby-core:112285] [Ruby master Feature#17753] Add Module#namespace
by fxn (Xavier Noria) 08 Feb '23

08 Feb '23

Issue #17753 has been updated by fxn (Xavier Noria). Let me reword that last remark about "the Ruby model suffers just a little bit". Ruby objects and variables behave the same. But constants are not as orthogonal and generic: 1. When you assign an integer to a constant, it's just storage. If you assign a class or module object with a name, it's just storage. However, assigning an anonymous class or module object changes the state, it has a side-effect that is only programmed for these objects. 2. The `class` and `module` keywords perform constant assignments. So, "suffer" is not an exact word for what I have in mind. I'd say this change would accentuate an already existing asimmetry, and in a way that is consitent with `Module#name`. This is not bad, it goes in a consistent direction. ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101717 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal ---------------------------------------- Given code like this: ```ruby module A module B class C; end class D; end end end ``` We can get from `C` to `B` like `C.outer_scope`, or to `A` like `C.outer_scope.outer_scope`. I want to use this in cases where I don't know the outer scope, but I want to find constants that are "siblings" of a constant. For example, I can do `A::B::C.outer_scope.constants` to find the list of "sibling" constants to `C`. I want to use this feature when walking objects and introspecting. For example: ```ruby ObjectSpace.each_object(Class) do |k| p siblings: k.outer_scope.constants end ``` I've attached a patch that implements this feature, and there is a pull request on GitHub [here](https://github.com/ruby/ruby/pull/4326). ---Files-------------------------------- 0001-Add-Module-outer_scope.patch (5.93 KB) 0001-Add-Module-namespace.patch (5.89 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112281] [Ruby master Feature#19423] IXDTF (Internet Extended Date/Time format) support
by nobu (Nobuyoshi Nakada) 08 Feb '23

08 Feb '23

Issue #19423 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #19423: IXDTF (Internet Extended Date/Time format) support https://bugs.ruby-lang.org/issues/19423 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- This is a reminder ticket. duerst (Martin Dürst) wrote in [Misc #19096#note-10]: > I'm not sure whether and how much this is relevant, but please note that the Sedate WG in the IETF has a draft (https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html, close to final) that updates RFC 3339 (https://www.rfc-editor.org/rfc/rfc3339) It seems a format that allows UTF offsets and time zone names to be written in parallel, as far as I understand. I'm going to implement it by the time it is finally adopted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112280] [Ruby master Misc#19096] [Question] Time with `-00:00` offset is in UTC
by nobu (Nobuyoshi Nakada) 08 Feb '23

08 Feb '23

Issue #19096 has been updated by nobu (Nobuyoshi Nakada). duerst (Martin Dürst) wrote in #note-10: > I'm not sure whether and how much this is relevant, but please note that the Sedate WG in the IETF has a draft (https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html, close to final) that updates RFC 3339 (https://www.rfc-editor.org/rfc/rfc3339) For details, please check https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html…. Thank you for the interesting information. Although that draft seems not recommending use of `-00:00`, but it also says > the present specification however does not formally deprecate this syntax. at https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html… ---------------------------------------- Misc #19096: [Question] Time with `-00:00` offset is in UTC https://bugs.ruby-lang.org/issues/19096#change-101713 * Author: andrykonchin (Andrew Konchin) * Status: Closed * Priority: Normal ---------------------------------------- It's a bit unexpected but ```ruby Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc? # => true ``` But time with `+00:00` or `0` offset is treated as not UTC time: ```ruby Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc? # => false Time.new(2022, 1, 1, 0, 0, 0, 0).utc? # => false ``` Is it an intentional behaviour? In this case could you please clarify the reason why it works this way? --- ``` ruby -v ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111926] [Ruby master Misc#19357] DevMeeting-2023-02-09
by mame (Yusuke Endoh) 08 Feb '23

08 Feb '23

Issue #19357 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19357: DevMeeting-2023-02-09 https://bugs.ruby-lang.org/issues/19357 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/02/09 13:00-17:00** (JST) 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 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/02/06. 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/

7 6