[#100309] How to use backport custom field — Jun Aruga <jaruga@...>
Please allow my ignorance.
9 messages
2020/10/06
[#100310] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
"Backport custom field" is only available for tickets whose tracker is "Bug".
[#100311] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/06
On Tue, Oct 6, 2020 at 4:44 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100314] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
Thank you for confirmation.
[#100322] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Tue, Oct 6, 2020 at 7:25 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100326] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/07
I added you to "Reporter" role in the project
[#100327] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Wed, Oct 7, 2020 at 1:42 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100358] [BUG] ruby 2.6.6 warning with encdb.so — shiftag <shiftag@...>
Hello,
1 message
2020/10/10
[ruby-core:100444] [Ruby master Feature#17145] Ractor-aware `Object#deep_freeze`
From:
marcandre-ruby-core@...
Date:
2020-10-20 10:00:24 UTC
List:
ruby-core #100444
Issue #17145 has been updated by marcandre (Marc-Andre Lafortune).
ko1 (Koichi Sasada) wrote in #note-17:
> I never realized that so many `freeze` redefinition are used. Checking the code, some of them freeze attribute objects, which they are frozen with `deep_freeze`. I can find some cases to calculate lazy (?).
Indeed, I imagine that the majority are used to do a deep-freeze, so calling `#freeze` or not will not make a difference.
An example of lazy computation I can remember writing is a [generic memoization module in DeepCover](https://github.com/deep-cover/deep-cover/blob/master/core_gem/lib/deep_cover/memoize.rb) which is then used [in different places](https://github.com/deep-cover/deep-cover/blob/master/core_gem/lib/deep_cover/coverage/analysis.rb#L6-L7). Yes, I'm lazy enough that I factorized the `@cache ||= ` pattern
> I still not sure we can remain the half-frozen state, so I want to ask other comments.
How about 3 pass?
1) Collect reachable objects; abort on non-freezable.
2) Call `#freeze` on reachable objects. Exception due to custom method failing => half frozen state (just write better code )
3) On success, mark all objects as Ractor shareable.
----------------------------------------
Feature #17145: Ractor-aware `Object#deep_freeze`
https://bugs.ruby-lang.org/issues/17145#change-88063
* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
----------------------------------------
I'd like to propose `Object#deep_freeze`:
Freezes recursively the contents of the receiver (by calling `deep_freeze`) and
then the receiver itself (by calling `freeze`).
Values that are shareable via `Ractor` (e.g. classes) are never frozen this way.
```ruby
# freezes recursively:
ast = [:hash, [:pair, [:str, 'hello'], [:sym, :world]]].deep_freeze
ast.dig(1, 1) # => [:str, 'hello']
ast.dig(1, 1).compact! # => FrozenError
# does not freeze classes:
[[String]].deep_freeze
String.frozen? # => false
# calls `freeze`:
class Foo
def freeze
build_cache!
puts "Ready for freeze"
super
end
# ...
end
[[[Foo.new]]].deep_freeze # => Outputs "Ready for freeze"
```
I think a variant `deep_freeze!` that raises an exception if the result isn't Ractor-shareable would be useful too:
```ruby
class Fire
def freeze
# do not call super
end
end
x = [Fire.new]
x.deep_freeze! # => "Could not be deeply-frozen: #<Fire:0x00007ff151994748>"
```
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>