[#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:70583] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3
From:
mame@...
Date:
2015-08-25 03:35:32 UTC
List:
ruby-core #70583
Issue #11473 has been updated by Yusuke Endoh. Please consider the difference of the development style: hobby development and enterprise development. I'm on hobby development. I mainly use Ruby to write a short program, including one-liner. I don't use a framework like Rails. In this style, `.dup`, command-line argument (including setting RUBYOPT), and magic comment are all big pain. On the other hand, in general the setting is not a pain for the enterprise development like Rails. Each user needs to think nothing if the framework does the setting instead of users. Considering this use case, magic comment and command-line argument may not a reasonable mean even for enterprise style. I guess it would be good if the "immutable by default" setting should be done via method call (e.g., `require "app.rb", string_immutable: true`) or global setting (e.g., `RubyVM::StringImmutable = true`), and so on. So, please keep "mutable by default", and reconsider if the setting means (magic comment and command-line argument) are really suitable for the enterprise development style. -- Yusuke Endoh <mame@ruby-lang.org> ---------------------------------------- Feature #11473: Immutable String literal in Ruby 3 https://bugs.ruby-lang.org/issues/11473#change-53987 * 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/