[#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:70552] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3
From:
akr@...
Date:
2015-08-23 02:13:11 UTC
List:
ruby-core #70552
Issue #11473 has been updated by Akira Tanaka.
Yusuke Endoh wrote:
> Why do matz and akr want to make String literals immutable, at first? Please explain use case.
My first intent is explained at:
https://bugs.ruby-lang.org/issues/8976
This is refered from this issue as a related ticket.
At the meeting (DevelopersMeeting20150820Japan), matz decided by Matsuda-san's argument.
Matsuda-san explains his motivation in
https://bugs.ruby-lang.org/issues/8976#note-30
In short, current situation frustrate developers, especially library developers.
The problem is caused by an ambivalent between clean code and fast code.
> For performance? Is it more important than usability, in the recent Ruby design?
This issue tries to match performance (fast code) and usability (clean code).
I agree more code (dup, String.new or something new) is required to distinguish
string modifiable from string never modified.
It decline usability.
However it prevents unintentional string modification.
This can improve usability.
So, total usability changes are not trivial.
However if code bloat is small enough, latter (usability improvement) should win.
In my experiment, modification is about one per 700 lines.
I feel the usability decline is acceptable.
My experiment is here:
https://github.com/akr/ruby/tree/frozen-string
```
% git diff -U0 trunk lib/**/*.rb|grep '^+'|grep -v '^+++'|wc
256 1273 10887
% wc lib/**/*.rb|tail -1
175569 537606 4639935 total
```
So, the library modification rate is one per 175569/256=685.8 line.
----------------------------------------
Feature #11473: Immutable String literal in Ruby 3
https://bugs.ruby-lang.org/issues/11473#change-53960
* 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/