[#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:70484] [Ruby trunk - Bug #11471] min, min_by, max, max_by with optional parameter return a wrong value
From:
helfper@...
Date:
2015-08-20 22:30:14 UTC
List:
ruby-core #70484
Issue #11471 has been updated by Helder Pereira.
Yes, I was wrong. I missed this check in "nmin_filter":
~~~
if (data->curlen <= data->n)
return;
~~~
Which means that your patch will never execute the "nmin_filter" (that is where the bug lays) until it is called in "nmin_run", and consequently the buffer will grow until the size of the original array (and will not be proportionally to the number of elements we want anymore).
Because your patch makes this piece of code in "nmin_i" useless:
~~~
if (data->curlen == data->bufmax) {
nmin_filter(data);
}
~~~
----------------------------------------
Bug #11471: min, min_by, max, max_by with optional parameter return a wrong value
https://bugs.ruby-lang.org/issues/11471#change-53887
* Author: Tsuyoshi Sawada
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v:
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
This is reported in StackOverflow: http://stackoverflow.com/questions/32121749/why-20-13-14-min2-13-20. Sometimes `min`, `min_by`, `max`, `max_by` with an optional parameter return a wrong value.
[20, 32, 32, 21, 30, 25, 29, 13, 14].min(2) # => [13, 20]
[20, 32, 32, 21, 30, 25, 29, 13, 14].min_by(2, &:itself) # => [13, 20]
[0, 0, 0, 0, 0, 0, 1, 3, 2].max(2) # => [3, 1]
[0, 0, 0, 0, 0, 0, 1, 3, 2].max_by(2, &:itself) # => [3, 1]
---Files--------------------------------
enum_bug_fix.patch (2.05 KB)
enum_bug_fix.patch (2.1 KB)
--
https://bugs.ruby-lang.org/