[#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:70565] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3
From:
mame@...
Date:
2015-08-24 11:56:18 UTC
List:
ruby-core #70565
Issue #11473 has been updated by Yusuke Endoh. > "immutable by default" is a way to solve the ambivalent with matz's preference. So, you mean: * because the magic comment is not accepted as-is, * we suppose "immutable by default" as a future goal, and * the magic comment can be now accepted as a migration path. The logic seems weird to me. What is the true goal? If "immutable by default" is the true goal, we should discuss the advantage/disadvantage of itself. The magic comment is irrelevant. > I think the major factor why matz accept "immutable by default" is not this effect. The advantages are: + improves the performance + prevents users from shooting themselves in the foot (this effect is limited) The disadvantages are: - breaks the compatibility significantly - damages the usability IMO, the long-term design preference of Ruby should be: usability > compatibility > performance. -- Yusuke Endoh <mame@ruby-lang.org> ---------------------------------------- Feature #11473: Immutable String literal in Ruby 3 https://bugs.ruby-lang.org/issues/11473#change-53974 * Author: Koichi Sasada * Status: Assigned * Priority: Normal * Assignee: Yukihiro Matsumoto ---------------------------------------- Matz said "All String literals are immutable (frozen) on Ruby 3". This ticket is place holder to discuss about that. -- https://bugs.ruby-lang.org/