[#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:70582] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3
From:
akr@...
Date:
2015-08-25 00:23:36 UTC
List:
ruby-core #70582
Issue #11473 has been updated by Akira Tanaka. Steve Shreeve wrote: > As a ruby user since 2001, I'd agree with Yusuke Endoh, when he suggests the long-term design preference of Ruby should be: > > usability > compatibility > performance I think the usability can be improved. We don't need to choose "foo" and "foo".freeze. We will need to choose "foo" and "foo".dup instead. The latter decision is easier than the former because the former needs benchmark and what is core loop. I think the social problem is caused by the former decision is difficult, or different between people. After this issue, developers can write clean and fast code with less brain power and the social problem is solved. This effect can win the small code bloat with dup (or String.new or something new). I agree the compatibility problem. I hope the migration path, the magic comment and command line option, mitigate the problem enough. Current code can work for Ruby 3.0 with trivial one line addition: "# frozen-string-literal: false". If the performance improvement can be discarded, even the addition is unnecessary. The only necessity is the command line option, --disable-frozen-string-literal. The performance will be better. So, this issue doesn't violate Endoh-san and your order. > Seems like there should be a quick way to flag strings as immutable (perhaps just prefixing with a sigil such as '@'?) and that this approach would be used in libraries and other performance centric code. But, if this change means that the following won't work (not my code, just copied from above): It can, if we find a good one and succeed to persuade matz. For example, Endoh-san have an idea: +"foo". (See comment #6) Maybe, !"foo" is another option. I feel "foo".dup is good enough, though. ---------------------------------------- Feature #11473: Immutable String literal in Ruby 3 https://bugs.ruby-lang.org/issues/11473#change-53986 * 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/