[#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:70519] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3
From:
wycats@...
Date:
2015-08-21 15:28:28 UTC
List:
ruby-core #70519
Issue #11473 has been updated by Yehuda Katz. I would like to suggest a phased transition across several releases in Ruby 2.x (the specific version numbers and flag names are just examples): 1. In Ruby 2.3, it is possible to turn on warnings when mutating a String literal (--warn-frozen-strings). 1. the warnings come with the place in the source where the String was originally created 2. In Ruby 2.4 (or 2.5?), the warning is on by default 1. Once it is on by default, it probably makes sense to include the source location of the String on with a flag (--string-literal-source-information) 2. At this point, it could be useful to have an error mode (--error-frozen-strings) I think the magic comment solution might be helpful, but the real problems with upgrades will come from interactions between two gems. One gem might install the "frozen string literals" magic comment, and a completely other gem might try to mutate it. The second gem cannot use a magic comment to un-freeze the string, and it wouldn't be correct to submit a pull request to the first gem to remove the magic comment! I think that a transition path across multiple releases that slowly increases the severity of the warning will help us identify how big of a problem the change will be. At the same time, it will help us transition to the new semantics a bit at a time. If the change is more of an issue than we think, it just means we need more releases of "on-by-default warning" before we can turn it into a mandatory error. Once we learn more about the kinds of problems that end up existing, there may be other things we can do to help with the transition that target those use-cases directly. ---------------------------------------- Feature #11473: Immutable String literal in Ruby 3 https://bugs.ruby-lang.org/issues/11473#change-53922 * Author: Koichi Sasada * Status: Open * 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/