[#107008] [Ruby master Bug#18465] Make `IO#write` atomic. — "ioquatix (Samuel Williams)" <noreply@...>
Issue #18465 has been reported by ioquatix (Samuel Williams).
16 messages
2022/01/09
[#107150] [Ruby master Feature#18494] [RFC] ENV["RUBY_GC_..."]= changes GC parameters dynamically — "ko1 (Koichi Sasada)" <noreply@...>
Issue #18494 has been updated by ko1 (Koichi Sasada).
4 messages
2022/01/17
[#107170] Re: [Ruby master Feature#18494] [RFC] ENV["RUBY_GC_..."]= changes GC parameters dynamically
— Eric Wong <normalperson@...>
2022/01/17
> https://bugs.ruby-lang.org/issues/18494
[#107302] [Ruby master Bug#18553] Memory leak on compiling method call with kwargs — "ibylich (Ilya Bylich)" <noreply@...>
Issue #18553 has been reported by ibylich (Ilya Bylich).
4 messages
2022/01/27
[#107346] [Ruby master Misc#18557] DevMeeting-2022-02-17 — "mame (Yusuke Endoh)" <noreply@...>
Issue #18557 has been reported by mame (Yusuke Endoh).
18 messages
2022/01/29
[ruby-core:107151] [Ruby master Feature#18408] Allow pattern match to set instance variables
From:
"Dan0042 (Daniel DeLorme)" <noreply@...>
Date:
2022-01-17 04:09:43 UTC
List:
ruby-core #107151
Issue #18408 has been updated by Dan0042 (Daniel DeLorme).
ktsj (Kazuki Tsujimoto) wrote in #note-8:
> If assignment to instance variables (or variables other than local variables) is allowed in pattern matching, there are problems such as:
>
> 1. The value during pattern matching can be observed by other threads
> 2. The value of the instance variable will be undefined when pattern matching fails (ref: https://github.com/ruby/ruby/blob/v3_1_0/doc/syntax/pattern_matching.rdoc#label-Appendix+B.+Some+undefined+behavior+examples)
There are a few possible ways to solve these problems right?
1. The value during pattern matching should be stored in a temporary location on the stack
2. Once the pattern match is done, copy the temporary value to ivar
* Copy to ivar even if the pattern match fails; this mimicks the same undefined behavior as lvars
* Copy to ivar only if the pattern match succeeds; most intuitive and trouble-free behavior
* In this case I think it's acceptable to have undefined behavior only for lvars
* But it would be better to have the same predictable behavior as ivars for lvars; IMHO it's better to incur the 1 extra MOV than this undefined behavior. Or maybe I don't understand how this is supposed to "leave room for optimization in the future".
----------------------------------------
Feature #18408: Allow pattern match to set instance variables
https://bugs.ruby-lang.org/issues/18408#change-96004
* Author: Dan0042 (Daniel DeLorme)
* Status: Assigned
* Priority: Normal
* Assignee: ktsj (Kazuki Tsujimoto)
----------------------------------------
I expected this to work:
```ruby
42 => @v
```
But instead it raises "syntax error, unexpected instance variable"
Is this intentional?
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>