[#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:100464] [Ruby master Feature#17145] Ractor-aware `Object#deep_freeze`
From:
marcandre-ruby-core@...
Date:
2020-10-21 05:23:46 UTC
List:
ruby-core #100464
Issue #17145 has been updated by marcandre (Marc-Andre Lafortune).
Looking at `def freeze` in the top ~400 gems, I found 64 in `sequel` gem alone, and 28 definitions in the rest .
Excluding `sequel`, half do deep freeze. The other use cases:
Cache prebuilding:
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/time_with_zone.rb#L503-L507
https://github.com/jeremyevans/sequel/blob/master/lib/sequel/adapters/mysql.rb#L150
https://github.com/mongodb/mongoid/blob/master/lib/mongoid/criteria.rb#L239
https://github.com/sporkmonger/addressable/blob/master/lib/addressable/uri.rb#L846-L858
https://github.com/sporkmonger/addressable/blob/master/lib/addressable/template.rb#247-L250
Instance variable dupping + freeze:
https://github.com/rails/rails/blob/master/activemodel/lib/active_model/attributes.rb#L118
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/core.rb#L494
Another usecase is lazy defined methods (I presume like `OpenStruct` before the recent changes):
https://github.com/jeremyevans/sequel/blob/master/lib/sequel/plugins/finder.rb#L167
https://github.com/solnic/virtus/blob/master/liblib/virtus/instance_methods.rb#L148
Cases not actually freezing the receiver (?):
https://github.com/mongodb/mongoid/blob/master/lib/mongoid/document.rb#L55-L69
https://github.com/datamapper/dm_core/blob/master/lib/dm-core/support/lazy_array.rb#L300-L313
https://github.com/dtao/safe_yaml/blob/master/lib/safe_yaml/transform/transformation_map.rb#L24
https://github.com/paulelliott/fabrication/blob/master/lib/fabrication/schematic/manager.rb#L23
I've been wanting for a long while to propose an API for caching methods, and that could be made Ractor compatible and would resolve most of these cases, but maybe it's too early to consider it?
I was thinking `cache_method :foo` could "magically" cache the result of `foo` on first call (per Ractor), store it and return that in the future, with no possibility to invalidate that cache or guarantee that the method `foo` couldn't be called a few times in case of race conditions.
----------------------------------------
Feature #17145: Ractor-aware `Object#deep_freeze`
https://bugs.ruby-lang.org/issues/17145#change-88083
* 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>