[#101179] Spectre Mitigations — Amel <amel.smajic@...>
Hi there!
5 messages
2020/12/01
[#101180] Re: Spectre Mitigations
— Chris Seaton <chris@...>
2020/12/01
I wouldn’t recommend using Ruby to run in-process untrusted code in the first place. Are people doing that?
[#101694] Ruby 3.0.0 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 3.0.0. From 2015 we
4 messages
2020/12/25
[ruby-core:101525] [Ruby master Feature#17393] `Ractor::Moved#inspect`
From:
marcandre-ruby-core@...
Date:
2020-12-18 21:11:07 UTC
List:
ruby-core #101525
Issue #17393 has been updated by marcandre (Marc-Andre Lafortune).
Yes, that looks good, that is what I was proposing in note 1 too
----------------------------------------
Feature #17393: `Ractor::Moved#inspect`
https://bugs.ruby-lang.org/issues/17393#change-89310
* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
It could be helpful to define `Ractor::Moved#inspect` and output the source location of when the data was moved. If preferred, it could raise an error with this information:
```
x = []
Ractor.new{ receive }.send(x, move: true)
p x # => "Data was moved in `example.rb:4`"
# or
p x # => "Data was moved in `example.rb:4`" (Ractor::MovedError)
```
Also @zverok and myself were wondering if there was a technical reason to freeze `Ractor::Moved`? If not, is it only to "force" people to use refinements (which are allowed on frozen classes)? It's already known that it is in general a bad idea to modify builtin classes, so it's not clear to me that freezing that class is best.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>