[#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:70557] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3
From:
mame@...
Date:
2015-08-23 17:25:48 UTC
List:
ruby-core #70557
Issue #11473 has been updated by Yusuke Endoh. Thank you for the explanation and references. I'm neutral to the magic comment. It would be better if it could specify finer-grained range than a whole file, but I have no strong objection. But "immutable by default" is completely another topic. > However it prevents unintentional string modification. I thought of that. In fact, I can somewhat understand this motivation. However: * Is this type of bug so frequent? I cannot remember the last time when I experienced such a bug. * To prevent this type of bug, why is it sufficient to freeze only literals? `String#+` also must return a frozen String, I think. * I believe that the same logic applies to Array, ultimately. Will all Array literals be also frozen? I don't think that "immutable by default" is a proper way. > In my experiment, modification is about one per 700 lines. Thank you for the quantitative information. How long does it take to fix the 256 places? IMO, the fact that you need so many changes that can be measured quantitatively, shows that this approach is too radical to accept ;-) What do any others think? -- Yusuke Endoh <mame@ruby-lang.org> ---------------------------------------- Feature #11473: Immutable String literal in Ruby 3 https://bugs.ruby-lang.org/issues/11473#change-53967 * 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/