[#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> wrote:

[#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:41483] Re: [ruby-trunk - Feature #5478] import Set into core, add syntax

From: Joshua Ballanco <jballanc@...>
Date: 2011-12-04 22:34:03 UTC
List: ruby-core #41483
On Sun, Dec 4, 2011 at 1:05 PM, Eero Saynatkari <ruby-ml@kittensoft.org>wrote:

> On 2011-12-04, at 16:15:00, Alexey Muranov wrote:
> >
> > But what is wrong with having one class instead of two, if internally
> they behave mostly the same, and one literal notation instead of two?
> Anyway, this was just an idea.
>
> Hash tables aren't Sets, nor the other way around. I'd like to avoid
> messing up data structure definitions any more than they already are.
>
> The only compelling reason for bringing Set into core would be a literal
> syntax – and I agree, as a data structure it would be a useful addition and
> encourage its usage – but I don't really have anything to contribute to the
> particular bikeshed of syntax thereof.
>

Actually, the bulk of Set's functionality is already built on top of Hash.
Personally, since the ability to create Hashes from comma-delimited
key,value lists has been removed in 1.9, I think reintroducing it to create
Set literals is not the worst idea in the world.

Additionally, implementing Set functionality directly on top of Hash would
remove the unfortunate method call overhead that currently exists in the
Set library (note that the implementation of Set#include? is just a call
through to Hash#include?):

>> Benchmark.bmbm do |x|
?>   h = {}
>>   s = Set.new
>>   10000.times { |i| h[i] = nil; s << i }
>>   x.report("Hash#include?") { 1000000.times { h.include? rand(20000) } }
>>   x.report("Set#include?") { 1000000.times { s.include? rand(20000) } }
>> end
Rehearsal -------------------------------------------------
Hash#include?   0.370000   0.000000   0.370000 (  0.370516)
Set#include?    0.440000   0.000000   0.440000 (  0.436806)
---------------------------------------- total: 0.810000sec

                    user     system      total        real
Hash#include?   0.370000   0.000000   0.370000 (  0.361795)
Set#include?    0.430000   0.000000   0.430000 (  0.426560)

In This Thread