[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70510] [Ruby trunk - Bug #11247] Should position of `using` affect the behavior?
From:
ko1@...
Date:
2015-08-21 10:11:20 UTC
List:
ruby-core #70510
Issue #11247 has been updated by Koichi Sasada.
Okay, I'll fix it.
(I need to remember code about it...)
----------------------------------------
Bug #11247: Should position of `using` affect the behavior?
https://bugs.ruby-lang.org/issues/11247#change-53911
* Author: Koichi Sasada
* Status: Assigned
* Priority: Normal
* Assignee: Koichi Sasada
* ruby -v: ruby 2.3.0dev (2015-06-11 trunk 50798) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
The following script makes two refinements refine class C.
```ruby
class C
def foo
p C
end
end
module R1
refine C do
def foo
p R1
super
end
end
end
module R2
refine C do
def bar
C.new.foo
end
using R1
def baz
C.new.foo
end
end
end
using R2
C.new.bar
C.new.baz
```
R2 refines C with methods `bar` and `baz`. The difference is the place of `using`. `bar` is located before `using` and `baz` is after.
Recent fix changed behavior of this script.
* trunk in May: C and R1, C
* current trunk: R1, C and R1, C
This change is caused by sharing CREF between methods in same CREF scope. It reduce memory consumption (before this fix, we need one CREF per one method).
Is it acceptable change or unacceptable?
--
https://bugs.ruby-lang.org/