[#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:107156] [Ruby master Feature#18408] Allow pattern match to set instance variables
From:
"palkan (Vladimir Dementyev)" <noreply@...>
Date:
2022-01-17 07:23:41 UTC
List:
ruby-core #107156
Issue #18408 has been updated by palkan (Vladimir Dementyev).
Dan0042 (Daniel DeLorme) wrote in #note-11:
> 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
So, we need to scan the whole pattern, reserver stack locations for all *mentioned* variables and resolve them when match succeeds. Sounds like a plan, but...
I can come up with a yet another interesting case:
```ruby
@a = 2
case {a: 1, b: 1}
in a: @a, b: ^@a
end
```
I think, the pattern should match; hence we need to track all vars in the pattern and point them to the corresponding temp stack location. Okay, that seems to be feasible.
What if we have the following code:
```ruby
@a = 2
case {a: 1, b: 2}
in a: @a, b: ^(@a + 1)
end
```
Oops. The pin expression is not *controlled* by the pattern matching iseq construction. So, it will refer to the original value.
Another option could be to implement a rollback: again, store original values of all vars before evaluate the whole pattern, and every time a match failed restore the values. That would result in additional N stack allocations (N is the total number of all affected vars in patterns) and (N+2)K additional instructions (K is the number of patterns; put once in the beginning, restore after every pattern unmatched, pop in the end).
However, that would lead to the potential thread-safety issues; and unlike the current proposed version, which is pretty straightforward, the "rollback" approach is less predictable (end users have no idea about it).
> * Copy to ivar even if the pattern match fails; this mimicks the same undefined behavior as lvars
At least, this option is consistent
----------------------------------------
Feature #18408: Allow pattern match to set instance variables
https://bugs.ruby-lang.org/issues/18408#change-96011
* 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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>