Forum: Ruby ruby-dev summary 27761-28026

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2005-12-19 18:18
(Received via mailing list)
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 Tanaka 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 Tanaka also pointed out DoS attack vulnerability on DRb.

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


BTW, above 4 vulnerabilities are *all reported by Akira Tanaka*.


[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 Nakada 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/...

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 Tanaka 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: http://i.loveruby.net/en/ruby-dev-summary.html
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2005-12-19 20:00
(Received via mailing list)
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!
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-19 20:09
(Received via mailing list)
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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2005-12-19 20:49
(Received via mailing list)
On Dec 19, 2005, at 11:08 AM, ara.t.howard@noaa.gov wrote:

>>> Matz refused "GC.always" method name (didn't refused this
>   GC.gc(:mode => "every") do
>   end
YAGNI

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2005-12-19 20:52
(Received via mailing list)
Eric Hodel 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?
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2005-12-19 21:16
(Received via mailing list)
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 Hodel - drbrain@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Eb9493c94d8db9887e5f15284d2c767f?d=identicon&s=25 unknown (Guest)
on 2005-12-19 21:53
(Received via mailing list)
In article <43A6EB14.8040509@atdot.net>, SASADA Koichi  <ko1@atdot.net>
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
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-19 23:00
(Received via mailing list)
On Tue, 20 Dec 2005, Eric Hodel 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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2005-12-19 23:55
(Received via mailing list)
On Dec 19, 2005, at 1:59 PM, ara.t.howard@noaa.gov 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 Hodel - drbrain@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
This topic is locked and can not be replied to.