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

[ruby-core:112281] [Ruby master Feature#19423] IXDTF (Internet Extended Date/Time format) support

by nobu (Nobuyoshi Nakada)

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 year, 3 months

1
0
0 0

[ruby-core:112280] [Ruby master Misc#19096] [Question] Time with `-00:00` offset is in UTC

by nobu (Nobuyoshi Nakada)

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 year, 3 months

1
0
0 0

[ruby-core:111926] [Ruby master Misc#19357] DevMeeting-2023-02-09

by mame (Yusuke Endoh)

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/

1 year, 3 months

7
6
0 0

[ruby-core:112277] [Ruby master Feature#17753] Add Module#namespace

by fxn (Xavier Noria)

Issue #17753 has been updated by fxn (Xavier Noria). Yeah, I believe the feature makes sense and can be useful, and the proposed implementation that keeps a pointer is well-defined (vs what AS does). Also consistent with `Module#name`, as you said. My observations above were more related to the name `namespace` I think, because we are defining "the class or module object that holded the constant to which I was initially assigned, if any". That is weaker. Regarding your proposal, in English would be `parent_module` right? Let me add something, this is practical, but the Ruby model suffers just a little bit in my view. Let me explain. To me: ```ruby module M X = String.new end module N X = Module.new end ``` are essentially the same, Ruby objects stored in places. As we all know, the Ruby model is quite unconstrained, which makes it beautiful, but also weaker in a logical sense. So, there is a part of me that believes for consistency the string object should also respond to `parent_module`, which is a weird derivation. (I am playing reductio at absurdum here, no proposing that!). However, maybe in this case practicality can win over a pure and spherical language model, I don't know :). ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101709 * 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 year, 3 months

1
0
0 0

[ruby-core:112276] [Ruby master Bug#18169] Local copies of gemified libraries are being released out of sync with their gems

by hsbt (Hiroshi SHIBATA)

Issue #18169 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed In Ruby 3.2, I completely sync default gems and ruby release code. But Ruby 3.1 and 3.0 are still work in progress. I'll working to fix out-of-sync statuses with @headius on each repository. ---------------------------------------- Bug #18169: Local copies of gemified libraries are being released out of sync with their gems https://bugs.ruby-lang.org/issues/18169#change-101706 * Author: headius (Charles Nutter) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The CRuby codebase includes a number of libraries that have been gemified, more and more with each release. Unfortunately, these libraries are continually out of sync with both their home repositories and their released gems. The problem lies in the fact that CRuby keeps a local copy of these libraries within the CRuby git repository, and allows committers to make changes either in the CRuby repository or in the gem's home repository. This has led to many releases of Ruby shipping code that **does not correspond to any released version of the related gem**. I have filed several issues about this but the root cause has not been addressed: * https://github.com/ruby/ostruct/issues/11 * https://github.com/ruby/matrix/issues/12 * https://github.com/ruby/prime/issues/11 * https://github.com/ruby/webrick/issues/48 * https://github.com/ruby/rdoc/issues/835 * https://github.com/ruby/rexml/issues/79 * https://github.com/ruby/fileutils/issues/59 * https://github.com/ruby/ostruct/issues/31 If these gems are to live on their own as standalone libraries/gems then one of two things must happen: * All changes to them must go into their repositories. This would be the cleanest option. CRuby would, like JRuby, source these libraries directly from released gems, and no copies of their sources would be versioned in the CRuby git repository. OR * CRuby-local changes to these libraries must be prohibited from being released unless there is a corresponding gem release. This would require automated or manual auditing at release time, to ensure that the claimed gem version actually corresponds to the sources being shipped. In addition to making it impossible for external users of these gems to match CRuby releases, there are more serious implications: * These hybrid intra-version changes to these libraries cannot be audited to a specific gem release. This could affect stability and security when users attempt to sync their local gem sets to the ones that shipped in a given version of Ruby. * Security fixes have gone out in CRuby releases but no corresponding x.x.y or x.x.x.y security release of the gem was released. This prevents users from fixing the security issue locally without either upgrading CRuby or also including new functionality changes (which may or may not work on the current version of Ruby). See the rexml issue above for one example of the security problem. Until the gem was released, it was not possible to install any gem version with the security fix without upgrading functionality elsewhere in rexml. I believe it is time for CRuby to stop making changes to gemified libraries directly in the CRuby repository. These libraries have their own gems, repositories, and issue trackers, and that is where they should be maintained. -- https://bugs.ruby-lang.org/

1 year, 3 months

1
0
0 0

[ruby-core:112273] [Ruby master Feature#17753] Add Module#namespace

by shioyama (Chris Salzberg)

Issue #17753 has been updated by shioyama (Chris Salzberg). This has been quiet for a while, but despite the reservations expressed I'd really like to see it implemented. I don't personally really like `namespace` as a name either, because of its usage in other places. It's been mentioned, but what exactly is wrong with `module_parents`, the same method ActiveSupport uses? @fxn > Yes, c.name is "X::C", but as I said above, that is just a string. It's a string, yes, but it also includes some rules about _what_ to return _when_ that I think are relevant to your concerns about edge cases. I think any implementation of this method should be fully consistent with `Module#name`. That means also encompassing names that are temporary (where the root is anonymous). Just so we're all on the same page: ```ruby mod = Module.new mod.name #=> nil mod::Foo = Module.new mod::Foo.name #=> "#<Module:0x0000000106471d80>::Foo" ``` `"#<Module:0x0000000106471d80>::Foo"` is `mod::Foo`'s "temporary name". We can assign another module under an anonymous root to it and it will not change: ```ruby other_mod = Module.new other_mod::Bar = mod::Foo other_mod::Bar #=> "#<Module:0x0000000106471d80>::Foo" ``` So temporary names are "sticky" as long as the module doesn't have a permanent name. Once it has a permanent name, that name does not change regardless of assignment to other toplevel-rooted constants. So we have some rules for how `Module#name` can and cannot change: 1. A module's permanent name, once assigned, cannot be re-assigned. So although you can nest the same constant in many places in many ways, the `name`, once attached to a permanent root, will not change. 2. A module's temporary name, once assigned, cannot be re-assigned except to a permanent name. So you can assign another name from an anonymous namespace, the module's original temporary name sticks and only changes when/if it gets a permanent name. I think these rules give us everything we need to define a method that returns the set of module objects in `name` as an array, and I think this would be a very useful method to have. Extended to anonymous roots, I would expect this (I'm using `namespace` here because that's the current name we're talking about, I don't love it but just to avoid confusion): ```ruby mod = Module.new mod::Foo = Module.new mod::Foo.name #=> "#<Module:0x0000000106471d80>::Foo" mod::Foo.namespace #=> [<Module:0x0000000106471d80>::Foo, <Module:0x0000000106471d80>] other_mod = Module.new other_mod::Bar = mod::Foo other_mod::Bar.namespace #=> [<Module:0x0000000106471d80>::Foo, <Module:0x0000000106471d80>] Bar = mod mod::Foo.namespace #=> [Bar::Foo, Foo] Baz = mod Baz::Foo.namespace #=> [Bar::Foo, Foo] ``` This is entirely consistent with how `name` works, and I think is in fact a very natural complement to it. Since conventions are exactly the same, there is no need for any additional "rules" to cover the edge cases above. As an implementation, this is fully determined, consistent with an existing pattern (`Module#name`) and works as expected for most common use cases. @mame > the use case is not clear to him It's been mentioned above, but [ActiveSupport](https://github.com/rails/rails/blob/dcd8f37bc63d46f28aa55e68… and other libraries use `mod.name.split("::")` all over the place to go from something they can _see_ (`Module#name`) to something they can _use_ (actual module objects). This has always seemed extremely clumsy to me; Ruby generated the `name` from the module objects, but it will only give you the "trace" of them, not the actual living things. Personally, I've been recently working with anonymous-rooted namespaces (like `mod` and `mod::Foo` above) and the inability to get the root of a module is yet more problematic, because `name.split("::")` and `constantize` don't work in that context. I'd love to see this happen, under any name that seems appropriate. ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101703 * 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 year, 3 months

1
0
0 0

[ruby-core:112173] [Ruby master Bug#19399] Ripper::Lexer.parse throws NoMethodError error for some input

by tompng (tomoya ishida)

Issue #19399 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19399: Ripper::Lexer.parse throws NoMethodError error for some input https://bugs.ruby-lang.org/issues/19399 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ripper::Lexer.paser throws ``undefined method `flatten!' for nil:NilClass (NoMethodError)`` for this input ~~~ruby require 'ripper' code = <<~CODE a do |b # closing "|" is missing <<~C C end CODE Ripper::Lexer.parse code ~~~ ~~~ /Users/tomoya/.rbenv/versions/3.2.0/lib/ruby/3.2.0/ripper/lexer.rb:183:in `parse': undefined method `flatten!' for nil:NilClass (NoMethodError) result.concat(@buf) until (@buf = []; super(); @buf.flatten!; @buf.empty?) ^^^^^^^^^ from /Users/tomoya/.rbenv/versions/3.2.0/lib/ruby/3.2.0/ripper/core.rb:19:in `parse' from -:8:in `<main>' ~~~ -- https://bugs.ruby-lang.org/

1 year, 3 months

3
2
0 0

[ruby-core:111992] [Ruby master Bug#19372] Proc objects are not traversed for shareable check during Ractor.make_shareable(prok)

by luke-gru (Luke Gruber)

Issue #19372 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19372: Proc objects are not traversed for shareable check during Ractor.make_shareable(prok) https://bugs.ruby-lang.org/issues/19372 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby class Proc attr_accessor :obj1 def initialize @obj1 = Object.new end end p = true.instance_eval { Proc.new { puts "hi" } } Ractor.make_shareable(p) p "Obj1 frozen?", Ractor.shareable?(p.obj1) P = p r = Ractor.new do pp = P p pp.obj1 # gives error in debug builds (rb_ractor_confirm_belonging rb_bug() call) end ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

3
5
0 0

[ruby-core:112206] [Ruby master Bug#19407] 2 threads taking from current ractor will hang forever

by luke-gru (Luke Gruber)

Issue #19407 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19407: 2 threads taking from current ractor will hang forever https://bugs.ruby-lang.org/issues/19407 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the current implementation of Ractors, it's possible to `take` from the current ractor. This could be useful when co-ordinating threads: ```ruby t = Thread.new do obj = Ractor.current.take p obj # do some work with obj end t0 = Thread.new do obj = Ractor.current.take p obj # do some work with obj end Ractor.yield :go ``` However it hangs forever: ```ruby t = Thread.new do obj = Ractor.current.take p obj end t0 = Thread.new do obj = Ractor.current.take p obj end sleep 0.5 ``` Should "self-take" be disabled, or was it designed to allow it but this is just a bug? -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:112210] [Ruby master Bug#19410] If move from ractor fails with error, some objects are left in broken state

by luke-gru (Luke Gruber)

Issue #19410 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19410: If move from ractor fails with error, some objects are left in broken state https://bugs.ruby-lang.org/issues/19410 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby r = Ractor.new do obj = receive end a = Object.new obj = [a, proc { }] begin r.send(obj, move: true) rescue => e puts "couldn't move" end p a # a is moved, this errors out. But it's not really moved because the other ractor can't access it. It's in limbo :) r << :end r.take ``` This might be tricky to fix, as it requires some sort of commit function for moving objects after every object is checked for ability to move. -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

2024

2023

2022

ruby-core February 2023