[#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:70280] [Ruby trunk - Bug #11406] Inconsistent behavior when creating a range of strings which end in an integer greater than 10
From:
nobu@...
Date:
2015-08-09 08:09:21 UTC
List:
ruby-core #70280
Issue #11406 has been updated by Nobuyoshi Nakada.
Hans Mackowiak wrote:
> i think that might break some things ... (it might break some applications)
>
> like with "1.2.9".succ, i dont know if that still work
`String#succ` isn't changed at all with my patch, but only `String#upto` when the receiver and the limit share common prefix and numerical suffixes.
The case affected is that alphabetical part is followed by the numerical suffix.
E.g.,
~~~ruby
"1a2b9".upto("1a2b10").to_a
~~~
returns an empty array now, but `["1a2b9", "1a2b10"]` with this patch.
In other words, your example has been handled specially already.
----------------------------------------
Bug #11406: Inconsistent behavior when creating a range of strings which end in an integer greater than 10
https://bugs.ruby-lang.org/issues/11406#change-53704
* Author: Michael Martinez
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v: 2.2.2
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
# Steps to Reproduce
In Ruby v2.2.2
1. Create a range of strings using 'foo1' up to 'foo9':
~~~ruby
('foo1'..'foo9').to_a
=> ["foo1", "foo2", "foo3", "foo4", "foo5", "foo6", "foo7", "foo8", "foo9"]
~~~
Observe the results are as we expect
2. Create a range of strings using 'foo1' up to 'foo10'
~~~ruby
('foo1'..'foo10').to_a
=> ["foo1", "foo2","foo3","foo4","foo5", "foo6", "foo7", "foo8", "foo9", "fop0","fop1", "fop2", "fop3", "fop4", "fop5", "fop6", "fop7", "fop8", "fop9", "foq0", ....]
~~~
Also:
~~~ruby
('foo1'..'foo10').to_a.size
=> 4707939
~~~
Observe that the output loops `1..9` about 523104 times (arbitrarily?)
# Expected Results
The output in step 1 makes me expect for Ruby's range class to intelligently create ranges using a strings that include integers inside them. However this only seems to work for `1..9` ranges.
# Actual Results
Inconsistent behavior for range creation.
---Files--------------------------------
Screen Shot 2015-07-29 at 5.40.16 PM.png (54.4 KB)
--
https://bugs.ruby-lang.org/