[#58730] [ruby-trunk - misc #9188][Open] r43870 make benchmark/bm_so_k_nucleotide.rb slow — "authorNari (Narihiro Nakamura)" <authorNari@...>
17 messages
2013/12/01
[#58955] [ruby-trunk - misc #9188] r43870 make benchmark/bm_so_k_nucleotide.rb slow
— "tmm1 (Aman Gupta)" <ruby@...1.net>
2013/12/08
[#59494] Re: [ruby-trunk - misc #9188] r43870 make benchmark/bm_so_k_nucleotide.rb slow
— Eric Wong <normalperson@...>
2014/01/03
Btw, I took some time to work on this further. Only _very_ lightly
[#59574] Re: [ruby-trunk - misc #9188] r43870 make benchmark/bm_so_k_nucleotide.rb slow
— SASADA Koichi <ko1@...>
2014/01/06
(2014/01/03 12:49), Eric Wong wrote:
[#59575] Re: [ruby-trunk - misc #9188] r43870 make benchmark/bm_so_k_nucleotide.rb slow
— Eric Wong <normalperson@...>
2014/01/06
SASADA Koichi <ko1@atdot.net> wrote:
[#59578] Re: [ruby-trunk - misc #9188] r43870 make benchmark/bm_so_k_nucleotide.rb slow
— SASADA Koichi <ko1@...>
2014/01/06
(2014/01/06 15:49), Eric Wong wrote:
[#58797] [ruby-trunk - Bug #9198][Open] Segfault in TestException#test_machine_stackoverflow — "vo.x (Vit Ondruch)" <v.ondruch@...>
11 messages
2013/12/02
[#58809] [ruby-trunk - Bug #9202][Assigned] Array#uniq freezes duplicate strings — "drbrain (Eric Hodel)" <drbrain@...7.net>
7 messages
2013/12/03
[#58810] [ruby-trunk - Bug #9202] Array#uniq freezes duplicate strings
— "drbrain (Eric Hodel)" <drbrain@...7.net>
2013/12/03
[#58817] [ANN] Developer Meeting Moved to 2013-12-05 — Zachary Scott <e@...>
Greetings!
4 messages
2013/12/03
[#58866] [ruby-trunk - misc #9215][Open] Maintenance Policy for Future Releases (2.1.0 & beyond) — "hone (Terence Lee)" <hone02@...>
17 messages
2013/12/05
[#58914] [ruby-trunk - Bug #9223][Open] Hash#reject!.size does not reflect changes to the hash — "dmarcotte (Daniel Marcotte)" <dmarcotte@...>
9 messages
2013/12/06
[#59095] [ruby-trunk - Bug #9248][Open] Struct methods, segmentation fault — "Soilent (H H)" <konstantin@...>
9 messages
2013/12/13
[#59110] [ruby-trunk - Bug #9249][Open] Ruby incorrectly inspects opaque libc jmp_buf for pointers to heap during GC. — "carlos@... (Carlos O'Donell)" <carlos@...>
8 messages
2013/12/14
[#59122] [ruby-trunk - Bug #9251][Open] ! operator has lower precedence than = in an assignment expression — "rits (First Last)" <redmine@...>
26 messages
2013/12/15
[#59198] [ruby-trunk - Bug #9262][Open] global_method_cache should be configurable or grow automatically — "tmm1 (Aman Gupta)" <ruby@...1.net>
28 messages
2013/12/19
[#59518] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically
— "sam.saffron (Sam Saffron)" <sam.saffron@...>
2014/01/03
[#60145] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically
— normalperson@...
2014/01/27
Issue #9262 has been updated by Eric Wong.
[#61218] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically
— nobu@...
2014/03/02
Issue #9262 has been updated by Nobuyoshi Nakada.
[#59209] [ruby-trunk - Bug #9264][Open] Compiling error: encdb.bundle Undefined symbols for architecture x86_64 — "spastorino (Santiago Pastorino)" <santiago@...>
15 messages
2013/12/19
[#59211] [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— "zzak (Zachary Scott)" <e@...>
2013/12/19
[#59212] Re: [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— Santiago Pastorino <spastorino@...>
2013/12/19
zzak, make distclean is the first thing I've ran. Read the gist again :),
[#59213] Re: [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— Zachary Scott <e@...>
2013/12/19
Sorry I missed the gist, can you try building outside of $srcdir?
[#59214] Re: [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— Santiago Pastorino <spastorino@...>
2013/12/19
It works if I do ...
[#59215] Re: [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— Zachary Scott <e@...>
2013/12/19
I've been using the following:
[#59216] Re: [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— Santiago Pastorino <spastorino@...>
2013/12/20
It works but I'm missing to link against homebrew's gdbm, libyaml and
[#59218] Re: [ruby-trunk - Bug #9264][Feedback] Compiling error: encdb.bundle Undefined symbols for architecture x86_64
— Santiago Pastorino <spastorino@...>
2013/12/20
Now I did ...
[#59222] [ruby-trunk - Bug #9266][Open] dead links to rubyforge — "znz (Kazuhiro NISHIYAMA)" <redmine@...>
7 messages
2013/12/20
[#59260] [ruby-trunk - Feature #9278][Open] Magic comment "immutable: string" makes "literal".freeze the default for that file — "colindkelley (Colin Kelley)" <colin@...>
12 messages
2013/12/22
[#59306] [ruby-trunk - Bug #9295][Open] `Exception#backtrace_locations` returns `nil` — "sawa (Tsuyoshi Sawada)" <sawadatsuyoshi@...>
4 messages
2013/12/24
[#59312] [ANN] Ruby 2.1.0 is released — "NARUSE, Yui" <naruse@...>
Hi,
6 messages
2013/12/25
[#59326] Re: [ANN] Ruby 2.1.0 is released
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2013/12/26
I can't compile it on Debian sid (using RVM):
[#59316] [ruby-trunk - Bug #9300][Open] YAML Regression Concerning Escaping of Strings — "schneems (Richard Schneeman)" <richard.schneeman@...>
9 messages
2013/12/25
[#59359] BigDecimal division in Ruby 2.1 — Andre Bernardes <abernardes@...>
Hi there,
5 messages
2013/12/28
[#59398] [ruby-trunk - Bug #9321][Open] rb_mod_const_missing does not generate a c-return event — "drkaes (Stefan Kaes)" <stkaes@...>
41 messages
2013/12/30
[#59470] [ruby-trunk - Bug #9321] rb_mod_const_missing does not generate a c-return event
— "drkaes (Stefan Kaes)" <stkaes@...>
2014/01/02
[#59408] [ruby-trunk - Feature #9323][Open] IO#writev — "Glass_saga (Masaki Matsushita)" <glass.saga@...>
11 messages
2013/12/30
[#59429] [ruby-trunk - Feature #9330][Open] [PATCH 0/3] avoid redundant fcntl/fstat syscalls for cloexec sockets — "normalperson (Eric Wong)" <normalperson@...>
10 messages
2013/12/31
[#59857] [ruby-trunk - Feature #9330] [PATCH 0/3] avoid redundant fcntl/fstat syscalls for cloexec sockets
— akr@...
2014/01/18
Issue #9330 has been updated by Akira Tanaka.
[ruby-core:59390] [ruby-trunk - Feature #9278] Magic comment "immutable: string" makes "literal".freeze the default for that file
From:
"colindkelley (Colin Kelley)" <colin@...>
Date:
2013-12-30 00:38:44 UTC
List:
ruby-core #59390
Issue #9278 has been updated by colindkelley (Colin Kelley).
Thanks for the quick reply, Charles. Here are my thoughts:
> * A magic comment should not completely change the semantics of a literal type. Encoding magic comments do not suffer from the same issue since they only change how the bytes of the strings are interpreted by the encoding subsystem...they do not change semantics.
I view this `immutable: string` comment as *less* intrusive than the encoding magic comment. The magic encoding was typically required in order get code to compile at all in 1.9. In this case the magic `immutable: string` comment is just a tip to Ruby saying "Feel free to optimize string literals here". The comment is completely optional, as is the optimization. But it's worth it because the optimization has a big speed payoff. 1.6X in the benchmark above. I think most projects will run at least 1.1X faster.
> * A magic comment is far removed from the actual literal strings, meaning that every developer that enters a file will have to keep in mind whether the strings have been forced to be immutable before doing any work with literal strings.
I expect that the `immutable: string` magic comment would typically be dropped at the top of all files in a project. (As many did with the encoding comment when porting to 1.9.) Any project that has automated test coverage is going to want to put the comment throughout as a project policy, because of the speed payoff. [BTW to make it easy to add the comment, we've cloned the magic_encoding gem into a magic_immutable gem here: https://github.com/Invoca/magic_immutable_string]
> * Although this eliminates or reduces calls to .freeze, it causes the opposite effect to get a mutable string in the same file...specifically, you have to call .dup.
Yes, exactly! This magic comment eliminates a giant/infeasible/ugly change (`.freeze` after every string literal) and replaces it with a tiny/feasible one.
Consider Rails. I just did a quick/approximate regex search to count string literals in Rails 3.2.12 and found on the order of 50,000 of string literals. How many of those do you think are mutated? I'm going to guess no more than 10 places across all of Rails. (I'm hoping to get some actual stats using a hack of this branch, but for a quick estimate I audited about 150 cases that mutate a string and didn't find a single case where the receiver was a string literal.)
So if we add the magic comment in Rails, we'll need to add `.dup` (or change to String.new) in up to 10 places instead of adding `.freeze` after 50,000 string literals!
> I think it would be better to consider adding the String#f method proposed during the rework of .freeze optimizations. Adding a .f to a literal string is not very much to ask, and in your particular script, it would actually add *fewer* characters to the code than the magic comment.
I'm with Paul Graham, who argues that expressiveness is counted in tokens, not bytes. So `.f` is no more expressive than `.freeze`. Whether `.f` or `.freeze`, it's still 2 tokens to be added after *every* string literal.
One of Ruby's main differentiators is its beauty and English-like readability. That's certainly what drew me to Ruby. No one who feels that way is going to put `.freeze` or `.f` after every string literal.
In summary, there will certainly be projects that don't bother with the `immutable: string` magic comment (for example, those that lack automated test coverage). But many projects will use it because they will get a big, immediate performance payoff in Ruby 2.1. We're already looking forward to it!
----------------------------------------
Feature #9278: Magic comment "immutable: string" makes "literal".freeze the default for that file
https://bugs.ruby-lang.org/issues/9278#change-43954
Author: colindkelley (Colin Kelley)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: 2.1.0
Building on https://bugs.ruby-lang.org/issues/9042, this pull request adds the magic comment # -*- immutable: string -*- that implies .freeze on every string literal in the file. To get a mutable string in a file that starts with the magic comment, use String.new or ''.dup.
Here is a corresponding github pull request:
https://github.com/ruby/ruby/pull/487
For more details, background, and rationale, please see this blog post:
http://development.invoca.com/magic-comment-immutable-string-makes-ruby-2-1s-literal-freeze-optimization-the-default/
--
http://bugs.ruby-lang.org/