# Ruby-dev summary 27761-28026

**URL:** <https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649>\
**Category:** Ruby\
**Created:** [December 19, 2005, 6:18pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649 "2005-12-19T18:18:08Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 6:18pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/1 "2005-12-19T18:18:08Z")

</div>

Hi,

This is ruby-dev summary 27761-28026.

* * *

lity information (webrick, xmlrpc)

Matz reported two vulnerabilities about webrick and xmlrpc (These  
problems allow DoS attack) on ruby 1.8.2 or earlier. Problems were  
fixed on ruby 1.8.3, so it is recommended for all to use ruby 1.8.3 or  
later. There are also patches for ruby 1.8.2.

ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.2-webrick-dos-1.patch  
ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.2-xmlrpc-dos-1.patch

Details of these problems will be posted independently.

[ruby-dev:27794] sample/svr.rb DoS vulnerability

Akira T. reported DoS attack vulnerability of sample/svr.rb. He  
also reported following sequence to reproduce DoS attack.

For more detail, see [ruby-dev:27794].

[ruby-dev:27795] DRb DoS vulnerability

Akira T. also pointed out DoS attack vulnerability on DRb.

For more detail, see [ruby-dev:27795].

BTW, above 4 vulnerabilities are _all reported by Akira T._.

[ruby-dev:27871] Numeric and Complex

Matz requested for comments about following problem:

Ruby’s Numeric class includes Comparable module. This is based on  
assumption that values are linear. However Complex value is not linear.  
Current implementation of Complex#\<=\> is based on Complex#abs, but  
Complex value is used as Range bound.

To solve this problem, Matz proposed following solutions:

- Make new super class of Integer, Float, Rational, etc.  
New class includes Comparable.
- All of classes (Integer, Float, Rational) includes Comparable.
- Change Complex super class other than Numeric.
- Keeping things as they are.

After active discussion, Matz decided follows:

- undef Complex#\<=\>
- add a new method Numeric#scalar?

[ruby-dev:27890] rb\_funcall2() for protected method

Nobuyoshi N. proposed that rb\_funcall2() should invoke protected  
method (with a patch to change this behavior).

Matz accepted this change. And this change enable us to run an example  
of [ruby-talk:169057].

[ruby-dev:27904] ruby 1.8.4 preview2

ruby 1.8.4 preview2 was released.

ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.4-preview2.tar.gz  
MD5: e5a48054fb34f09da17e8e8f04b8c706

This is also announced at [ruby-core:06798] ruby 1.8.4 preview2  
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/06798](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/06798)

If you have time, please check this preview2.

[ruby-dev:27972] A Sample of Ruby/Tk

Hidetoshi NAGAI proposed to commit a sample of Ruby/Tk which posted at  
[ruby-talk:169227] because this sample seems useful.

Matz accepted to commit it in ruby 1.8.4.

[ruby-dev:27984] modified restarg with zsuper

Koichi Sasada proposed that following example should not raise  
ArgumentError because “super” should work as “super(a, \*b)” in this  
case.

```
class C
  def m(a, b)
  end
end

class D < C
  def m(a, *b)
    b[0] ||= 2 # if no rest arguments are given, add one
    super
  end
end

D.new.m(1, 2) # OK, no problem

D.new.m(1)
# wrong number of arguments (1 for 2) (ArgumentError)
# in current interpreter (1.9.0)

```

Matz agreed this proposal.

Current YARV performs this behavior 🙂

[ruby-dev:27991] GC.always

Akira T. proposed “GC.always” method. This method forces ruby  
interpreter to invoke GC whenever it is invokable. It means that GC  
will be invoked at every object allocations, every memory allocations.  
This feature helps interpreter debugging around GC bugs.

Matz refused “GC.always” method name (didn’t refused this feature, only  
method name). Another proposed method name is “GC.debug”.

This issue is still open.

[ruby-dev:27996] How about “Time Literal”?

take\_tk proposed that “Time Literal” represented by ISO 8601. For  
example, 19850412T101530 means Time object as “12 Apr 1985 10:15:30”.

This issue is still open.

* * *

ruby-dev summary index: [ruby-dev summary](http://i.loveruby.net/en/ruby-dev-summary.html)

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 8:00pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/2 "2005-12-19T20:00:32Z")

</div>

SASADA Koichi wrote:  
…

> This issue is still open.  
> This would be helpful for extension writers. Would the method take a  
> block, to turn on the feature only for suspect code?

GC.every\_allocation  
GC.aggressive  
GC.eager  
GC.leave\_no\_garbage\_behind  
GC.fanatically\_tidy

Come on creative people, this is a softball question!

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 8:09pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/3 "2005-12-19T20:09:37Z")

</div>

On Tue, 20 Dec 2005, Joel VanderWerf wrote:

> > method name). Another proposed method name is “GC.debug”.  
> > GC.fanatically\_tidy
> 
> Come on creative people, this is a softball question!

i really, really prefer an options based approach to these kinds of  
things.  
when you have to pick a name for every method the development is slowed.  
pick  
a catch-all and configure it:

GC.gc(:mode =\> “every”) do

end

next week, when someone wants a new feature, it can be added it without  
changing a thing:

GC.gc(:mode =\> “every”, :pool =\> MyCustomPool) do

end

etc.

food for thought.

-a

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 8:49pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/4 "2005-12-19T20:49:11Z")

</div>

On Dec 19, 2005, at 11:08 AM, removed\_email\_address@domain.invalid wrote:

> > > Matz refused “GC.always” method name (didn’t refused this  
> > > GC.gc(:mode =\> “every”) do  
> > > end  
> > > YAGNI

–  
Eric H. - removed\_email\_address@domain.invalid - [http://segment7.net](http://segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 9:16pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/5 "2005-12-19T21:16:46Z")

</div>

On Dec 19, 2005, at 11:52 AM, Joel VanderWerf wrote:

> > > end
> 
> YAGN what? GC.always or an options hash?

Somebody needs GC.always to help with debugging. The options hash  
falls under YAGNI.

–  
Eric H. - removed\_email\_address@domain.invalid - [http://segment7.net](http://segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 9:53pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/6 "2005-12-19T21:53:52Z")

</div>

In article [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid), SASADA Koichi [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> assumption that values are linear. However Complex value is not linear.  
> Current implementation of Complex#\<=\> is based on Complex#abs, but  
> Complex value is used as Range bound.

So basically, the current method compares the magnitude of the complex  
numbers  
interpreted to be a vector of two values. (or in other words, the  
length of  
the hypotenuse is compared). Why is that problematic? Seems like a  
reasonable interpretation.

> - undef Complex#\<=\>
> - add a new method Numeric#scalar?

Well, maybe Complex should be derived from a Vector (in the Mathematical  
sense) class? Vector ‘has’ Numeric types. Not sure if a common base  
class  
between Vector and Numeric is needed (I think probably not).

A Complex would be a Vector with two Numerics, but people using Vector  
directly could create a vector with any number of Numerics. So Complex  
would  
just be a special case of Vector with 2 values and some nice “to\_s”  
functionality.

Phil

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 8:52pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/7 "2005-12-19T20:52:15Z")

</div>

Eric H. wrote:

> > > > will be invoked at every object allocations, every memory allocations.  
> > > > slowed. pick  
> > > > GC.gc(:mode =\> “every”, :pool =\> MyCustomPool) do
> > 
> > end
> 
> YAGNI

YAGN what? GC.always or an options hash?

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 11:00pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/8 "2005-12-19T23:00:47Z")

</div>

On Tue, 20 Dec 2005, Eric H. wrote:

> > YAGN what? GC.always or an options hash?
> 
> Somebody needs GC.always to help with debugging. The options hash falls  
> under YAGNI.

i disagree. this thread shows that, had the original interface been  
option  
based, we’d not need a new one. i know the theory, but consider how  
difficult  
it is to convince matz of a good name - minimizing names minimizes the  
convincing.

-a

---

<div class="post-metadata">

**Author:** ![SASADA\_Koichi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@SASADA\_Koichi](https://www.ruby-forum.com/u/SASADA_Koichi)\
**Post date:** [December 19, 2005, 11:55pm UTC](https://www.ruby-forum.com/t/ruby-dev-summary-27761-28026/50649/9 "2005-12-19T23:55:43Z")

</div>

On Dec 19, 2005, at 1:59 PM, removed\_email\_address@domain.invalid wrote:

> how difficult  
> it is to convince matz of a good name - minimizing names minimizes the  
> convincing.

How does an options hash remove the problem of finding a good name?

There are exactly four methods on GC, 3 class, 1 instance:

$ ruby -e ‘p GC.methods.sort - Object.methods’  
[“disable”, “enable”, “start”]  
$ ruby -e ‘p GC.instance\_methods.sort - Object.methods’  
[“garbage\_collect”]

So GC isn’t really full of names that we can’t use because they’re  
taken. Picking the right name for the feature hasn’t gone away  
because we’re using an options hash.

So if you use an options hash you now have as much as twice as many  
names to choose. Also, an options hash forces the programmer to  
remember twice as much, since they must remember both the key and the  
value (maybe more, since they must remember which method to call as  
well).

Your proposal was:

GC.gc(:mode =\> “every”) do … end

GC::gc isn’t a very good method name for specifying garbage  
collection options, maybe GC::options instead.

:mode looks good, but “every” is just as bad as “always”. It has a  
similar problem to “always”, “What does GC always mean? After every  
expression?”, for “every”, “GC every what?”. Plus, there is the  
non-“every” mode, what do we call it?

By moving to an options hash you’ve made the problem bigger for what  
gain? This is the first new method on GC in one month shy of seven  
years. (Yes, the API for the GC hasn’t changed since it was checked  
in.) I don’t think that an options hash is a prudent choice when the  
API remains unchanged for so long.

Also, I cannot think of any core libraries that use an options hash.

–  
Eric H. - removed\_email\_address@domain.invalid - [http://segment7.net](http://segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)