[#41431] [ruby-trunk - Bug #5694][Open] Proc#arity doesn't take optional arguments into account. — Marc-Andre Lafortune <ruby-core@...>

27 messages 2011/12/01
[#41442] [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Thomas Sawyer <transfire@...> 2011/12/01

[#41443] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Yehuda Katz <wycats@...> 2011/12/01

Maybe we can add a new arity_range method that does this?

[#41496] [ruby-trunk - Bug #5714][Open] Unexpected error of STDIN#read with non-ascii input on Windows XP — Heesob Park <phasis@...>

22 messages 2011/12/06

[#41511] [ruby-trunk - Bug #5719][Open] Hash::[] can't handle 100000+ args — Nick Quaranto <nick@...>

13 messages 2011/12/07

[#41557] [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong — Yukihiro Matsumoto <matz@...>

14 messages 2011/12/08

[#41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords — Martin Bosslet <Martin.Bosslet@...>

17 messages 2011/12/10

[#41672] [ruby-trunk - Feature #5767][Open] Cache expanded_load_path to reduce startup time — Yura Sokolov <funny.falcon@...>

13 messages 2011/12/15

[#41681] Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...>

Since Ruby is built on top of simple concepts, most of the documentation

23 messages 2011/12/15
[#41683] Re: Documentation of the language itself (syntax, meanings, etc) — Gary Wright <gwtmp01@...> 2011/12/15

[#41686] Re: Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2011/12/16

Em 15-12-2011 19:23, Gary Wright escreveu:

[#41717] Feature : optional argument in File.join — Michel Demazure <michel@...>

In Windows, when using File.join, one often ends with a path containing

13 messages 2011/12/19
[#41719] Re: Feature : optional argument in File.join — Luis Lavena <luislavena@...> 2011/12/19

On Mon, Dec 19, 2011 at 6:09 AM, Michel Demazure <michel@demazure.com> wrot=

[#41720] Re: Feature : optional argument in File.join — Michel Demazure <michel@...> 2011/12/19

Luis Lavena wrote in post #1037331:

[#41728] [ruby-trunk - Feature #5781][Open] Query attributes (attribute methods ending in `?` mark) — Thomas Sawyer <transfire@...>

15 messages 2011/12/19

[#41799] Best way to separate implementation specific code? — Luis Lavena <luislavena@...>

Hello,

15 messages 2011/12/24
[#41800] Re: Best way to separate implementation specific code? — KOSAKI Motohiro <kosaki.motohiro@...> 2011/12/24

2011/12/24 Luis Lavena <luislavena@gmail.com>:

[#41811] Re: Best way to separate implementation specific code? — "U.Nakamura" <usa@...> 2011/12/26

Hello,

[#41817] Re: Best way to separate implementation specific code? — Luis Lavena <luislavena@...> 2011/12/26

On Sun, Dec 25, 2011 at 10:51 PM, U.Nakamura <usa@garbagecollect.jp> wrote:

[#41812] [ruby-trunk - Feature #5809][Open] Benchmark#bm: remove the label_width parameter — Benoit Daloze <redmine@...>

11 messages 2011/12/26

[ruby-core:41758] Re: My bug evaluation criteria

From: "NARUSE, Yui" <naruse@...>
Date: 2011-12-20 16:45:08 UTC
List: ruby-core #41758
(2011/12/18 13:53), Marc-Andre Lafortune wrote:
> On Sun, Dec 11, 2011 at 8:59 PM, NARUSE, Yui <naruse@airemix.jp> wrote:
> 
>> ...
>>> To pass the "strict superiority test" (SST), the proposed behavior is judged on:
>>> a) usefulness,
>>> b) consistency,
>>> c) intuitiveness and
>>> d) big O level of performance
>>> It must be superior to the existing behavior on at least one of these
>>> criteria, and not inferior in any.
>>
>> I add one more, the value of behavior's brekage is prior than compatility.
> 
> Sorry, I'm not sure I understand your sentence.

In other words, the *fix* is worth breaking compatibility
or changing the behavior.

>>> A bugfix is "clear" if it is straightforward (SST+NIT) and if the
>>> existing behavior passes the "clear defect test" (ODT):
>>> 1) it crashes Ruby,
>>> 2) it contradicts the documentation or
>>
>> On Ruby, a document and code sometimes conflict.
>> On such case, they theirselves are equal, but as I wrote above,
>> code change introduces incompatibility.
>> So usually the code is prior to the documentation.
> 
> If a behavior is not intentional (as per test above) and contradicts
> the documentation (i.e. the documentation explicitly states some
> result which differs from the current result), I have to disagree with
> you: it's a clear bug, the code is wrong and the documentation should
> be followed. Of course, it's possible to decide to make a feature
> change at this point, change the documentation, etc..., but it is not
> a bug fix.

There are some cases that the document should be fixed:
* the documentation seems wrong.
  On Proc#arity's case, "optional arguments" seems to be "rest arguments"
  because tests and examples in the document convers only rest arguments.
* there are many programs depend on the current behavior.
  You may know HTML5's willful violations.
* the method is deprecated.
  The method is not worth changing; in other word WONTFIX.

>>> 3) it is platform dependent (when it can reasonably be platform independent)
>>
>> What is "reasonably be platform independent" is not clear yet,
> 
> You are right, it's not clear for all cases, but for many cases it is
> clear. Having to rewrite a huge library is not reasonable, changing a
> couple of lines of code is. Impacting the performance by a factor of
> 10 isn't reasonable, but a slowdown of a couple of percent is.

Your work, making ruby's float behavior portable, is the case.

-- 
NARUSE, Yui  <naruse@airemix.jp>

In This Thread

Prev Next