[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
ko1@atdot.net wrote:
Eric Wong <normalperson@yhbt.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
On 2014/10/09 11:04, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
On 2014/10/09 20:41, Xavier Noria wrote:
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, normal@ruby-lang.org wrote:
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
2014-10-16 12:48 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
[ruby-core:65927] Re: [CommonRuby - Feature #8848] Syntax for binary strings
duerst@it.aoyama.ac.jp wrote:
> One reason for this efficiency. String#b creates a duplicate object,
> which is not at all necessary for the frequent use case of String
> literals.
Avoiding one allocation is easy to add to [Feature #10423]
(which avoids string literal allocations for many methods)
> Another reason is encoding validity. To be able to e.g. create a
> "\xFF" binary string, with String#b in an UTF-8 source context, it is
> necessary to allow "\xFF" (temporarily at least) as an (actually
> invalid) UTF-8 string. This may be difficult for some implementations,
> and isn't desirable in general.
We can even go farther than #10423 and move the evaluation of
"string literal".{b,encode,force_encoding} to compile time.
The downside is compatibility with people who wish to override one of
those methods, but doubt anybody overrides those...
There's no new (and strange looking, IMHO) syntax to learn,
it looks like a normal method call, and the optimization would be
usable with existing code.