[#43077] problems committing — Aaron Patterson <tenderlove@...>
It seems like the disk might be full on the svn server:
5 messages
2012/03/05
[#43090] "\\".gsub("\\", "\\\\") == "\\" ?!!! — Rodrigo Rosenfeld Rosas <rr.rosas@...>
Please, help me understand what is happening here.
6 messages
2012/03/06
[#43094] Re: "\\".gsub("\\", "\\\\") == "\\" ?!!!
— Xavier Noria <fxn@...>
2012/03/06
A literal passed as second argument to gsub goes over two
[#43120] [ruby-trunk - Bug #6124][Open] What is the purpose of "fake" gems in Ruby — Vit Ondruch <v.ondruch@...>
27 messages
2012/03/07
[#43142] Questions about thread performance (with benchmark included) — Rodrigo Rosenfeld Rosas <rr.rosas@...>
A while ago I've written an article entitled "How Nokogiri and JRuby
10 messages
2012/03/08
[#43785] Re: Questions about thread performance (with benchmark included)
— Tomoyuki Chikanaga <nagachika00@...>
2012/03/28
Hello, Rodrigo.
[#43797] Re: Questions about thread performance (with benchmark included)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/03/28
Em 27-03-2012 23:22, Tomoyuki Chikanaga escreveu:
[#44213] Re: Questions about thread performance (with benchmark included)
— SASADA Koichi <ko1@...>
2012/04/09
Hi,
[#44214] Re: Questions about thread performance (with benchmark included)
— Urabe Shyouhei <shyouhei@...>
2012/04/09
#### MRI threads myths and facts #####
[#44220] Re: Questions about thread performance (with benchmark included)
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/04/09
Hi Urabe, thank you for your input, but I think you have
[#43245] [ruby-trunk - Bug #6131][Open] Ctrl-C handler do not work from exec process (Windows) — Luis Lavena <luislavena@...>
10 messages
2012/03/12
[#43279] [ruby-trunk - Bug #6148][Open] ruby_1_9_3 revision conflict — Jon Forums <redmine@...>
4 messages
2012/03/14
[#43313] [ruby-trunk - Feature #6150][Open] add Enumerable#grep_v — Suraj Kurapati <sunaku@...>
17 messages
2012/03/15
[#43325] [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime — Charles Nutter <headius@...>
25 messages
2012/03/16
[#43326] [ruby-trunk - Bug #6154] Eliminate extending WaitReadable/Writable at runtime
— Charles Nutter <headius@...>
2012/03/16
[#43369] Re: [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime
— Tanaka Akira <akr@...>
2012/03/17
2012/3/16 Charles Nutter <headius@headius.com>:
[#43334] [ruby-trunk - Bug #6155][Open] Enumerable::Lazy#flat_map raises an exception when an element does not respond to #each — Dan Kubb <dan.kubb@...>
9 messages
2012/03/16
[#43345] [ruby-trunk - Bug #6159][Open] Enumerable::Lazy#inspect — Benoit Daloze <redmine@...>
10 messages
2012/03/16
[#43497] [ruby-trunk - Bug #6179][Open] File::pos broken in Windows 1.9.3p125 — "jmthomas (Jason Thomas)" <jmthomas@...>
24 messages
2012/03/20
[#43502] [ruby-trunk - Feature #6180][Open] to_b for converting objects to a boolean value — "AaronLasseigne (Aaron Lasseigne)" <aaron.lasseigne@...>
17 messages
2012/03/20
[#43529] [ruby-trunk - Bug #6183][Open] Enumerator::Lazy performance issue — "gregolsen (Innokenty Mikhailov)" <anotheroneman@...>
36 messages
2012/03/21
[#43814] [ruby-trunk - Feature #6219][Open] Return value of Hash#store — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
20 messages
2012/03/28
[#43904] [ruby-trunk - Feature #6225][Open] Hash#+ — "trans (Thomas Sawyer)" <transfire@...>
36 messages
2012/03/29
[#43909] [ruby-trunk - Feature #6225][Assigned] Hash#+
— "mame (Yusuke Endoh)" <mame@...>
2012/03/29
[#43923] [ruby-trunk - Feature #6225] Hash#+
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/03/30
[#43951] [ruby-trunk - Bug #6228][Open] [mingw] Errno::EBADF in ruby/test_io.rb on ruby_1_9_3 — "jonforums (Jon Forums)" <redmine@...>
28 messages
2012/03/30
[#43996] [ruby-trunk - Bug #6236][Open] WEBrick::HTTPServer swallows Exception — "regularfry (Alex Young)" <alex@...>
13 messages
2012/03/31
[#44015] [Ruby 1.8 - Bug #6239][Open] super Does Not Pass Modified Rest Args When Originally Empty — "mudge (Paul Mucur)" <mudge@...>
6 messages
2012/03/31
[ruby-core:43272] Re: [ruby-trunk - Bug #6085] Treatment of Wrong Number of Arguments
From:
"Martin J. Dürst" <duerst@...>
Date:
2012-03-14 08:47:42 UTC
List:
ruby-core #43272
While we are at it, can we also change the extremely cryptic "for".
Whenever I see an error message of the form "wrong number of arguments
(X for Y)". Is it X arguments given for Y arguments expected, or X
arguments expected for Y arguments given?
If I look at the Rubinius example (e.g. "ArgumentError: method 'upcase':
given 1, expected 0", I don't have to worry about the directionality,
but then I could easily think that I used an argument *value* of 1 where
it expected an argument *value* of 0.
So the best would be an error message along the following lines:
wrong number of arguments (given: X, expected: Y)
Regards, Martin.
On 2012/03/13 20:38, Yusuke Endoh wrote:
> Hello,
>
>> On Mon, Mar 12, 2012 at 10:31 AM, Yui NARUSE<naruse@airemix.jp> wrote:
>>> Use one of follwing:
>>> * https://github.com/marcandre/ruby/compare/rb_arity_check
>>> * https://github.com/marcandre/ruby/compare/rb_arity_check.diff
>>> * https://github.com/marcandre/ruby/compare/rb_arity_check.patch
>>
>> Nice, thanks! I'll provide this kind of link in the future, quite helpful.
>
> Cool, thanks.
>
>
> 2012/3/13, Marc-Andre Lafortune<ruby-core@marc-andre.ca>:
>> On Mon, Mar 12, 2012 at 8:07 AM, Yusuke Endoh<mame@tsg.ne.jp> wrote:
>>> One concern: I'm afraid if this change affects people who parses
>>> the message string of WNA. What do you think? There is not such
>>> people, is there? I don't want to be pedantic, but I can't feel
>>> sure because I can no longer use Google codesearch... Google!!
>>
>> The error type is part of the language specs, but I feel like error messages
>> are not meant to be parsed and are subject to change. In this particular
>> case, I just checked and Rubinius gives different error messages
>> (ArgumentError: method 'upcase': given 1, expected 0).
>
> Sounds good. At least, Rubinius community does not know any actual
> case where WNA message is parsed.
>
>
>> The changes I propose
>> are also minimal in their approach and make parsing even easier!
>
> You know, making parsing easy is not the purpose or the right way.
> My concern is just about compatiblity.
>
>
>>> Anyway, I agree that the current is awkward. If no one complains,
>>> I'm positive to import it tentatively.
>>
>> Thanks. Just let me know after you've looked at it and I'll gladly commit
>> these.
>
> Looks good to me.
> It brings not only behavior consistency but also good refactoring
> effect.
>
> I noticed some minor issues below.
>
> vm_insnhelper.c:
>
> +static inline VALUE
> +rb_arg_error_new(int argc, int min, int max) {
> + const char *template = "wrong number of arguments (%d for %d..%d)";
> + if (min == max) {
> + template = "wrong number of arguments (%d for %d)";
> + }
> + else if (max == UNLIMITED_ARGUMENTS) {
> + template = "wrong number of arguments (%d for %d+)";
> + }
> + return rb_exc_new3(rb_eArgError, rb_sprintf(template, argc, min, max));
> +}
>
> It would be good to match the number of %d and actual arguments.
>
>
> eval.c:
>
> - if (i< argc) goto wrong_args;
> + if (i< argc) rb_raise(rb_eArgError, "wrong arguments");
>
> I guess this line can be removed, though this is not your fault.
>
>
> test/ruby/test_arity.rb
>
> assert_equal "0 for 1", err_mess{ "".sub!{} }
>
> This assertion fails. Did you mean "0 for 1..2" ?
>
>
>>> Off topic. Are you interested in improving a keyword argument?
>>> There is some issues on its implementation, but I have no time to
>>> work on it :-(
>>
>> I'm not sure I have the technical skills needed, but I can definitely try to
>> help. In any case I wanted to work on checking for named arguments and
>> giving a better error message in those cases too. What else could I help on?
>
> So far, the remaining issues I know are better error message, and #5989.
>