[PATCH] object.c ruby.h (fwd)

[PATCH] object.c ruby.h (fwd)

[Robert Skarwecki]

Hello everybody,

my name is Robert Skarwecki and this is my first contribution to the Ruby
development.

The patch implements the ToDo task "introduce Boolean class; super of
TrueClass, FalseClass".

A quick test shows the result:
$ ruby -e "puts true.class.ancestors.join(',')"
TrueClass,Object,Kernel
$ ./ruby -e "puts true.class.ancestors.join(',')"
TrueClass,BooleanClass,Object,Kernel

Here are the patched files. Do they reflect the finished state of the task
or is there anything else left to do, if so, what is it ?

Index: object.c
===================================================================
RCS file: /src/ruby/object.c,v
retrieving revision 1.81
diff -r1.81 object.c
29a30
> VALUE rb_cBooleanClass;
1382c1383,1387
<     rb_cTrueClass = rb_define_class("TrueClass", rb_cObject);
---
>     rb_cBooleanClass = rb_define_class("BooleanClass", rb_cObject);
>     rb_undef_method(CLASS_OF(rb_cBooleanClass), "allocate");
>     rb_undef_method(CLASS_OF(rb_cBooleanClass), "new");
>
>     rb_cTrueClass = rb_define_class("TrueClass", rb_cBooleanClass);
1391c1396
<     rb_cFalseClass = rb_define_class("FalseClass", rb_cObject);
---
>     rb_cFalseClass = rb_define_class("FalseClass", rb_cBooleanClass);

Index: ruby.h
===================================================================
RCS file: /src/ruby/ruby.h,v
retrieving revision 1.66
diff -r1.66 ruby.h
553a554
> EXTERN VALUE rb_cBooleanClass;

Bye,
Robert

Boolean class (Re: [PATCH] object.c ruby.h)

[Yukihiro Matsumoto]

Hi,

In message "[PATCH] object.c ruby.h (fwd)"
    on 02/07/25, Robert Skarwecki <skaav@gmx.net> writes:

|my name is Robert Skarwecki and this is my first contribution to the Ruby
|development.
|
|The patch implements the ToDo task "introduce Boolean class; super of
|TrueClass, FalseClass".

Thank you for the contribution.  Two points:

  * use unified diff (diff -u) instead of plain old diff to create
    patches.  Patches created by old diff are too much context
    sensitive.  Even the smallest change will prevent them to be
    applied.

  * most of the entries in the ToDo file are actually "things need to
    be discussed before implementation". ;-)  This one is typical.
    But your work is not vain.  It should be the driving force for
    discussion about this issue.

So, everyone, feel free to discuss.  Do you think we need Boolean
class?

							matz.

Re: [PATCH] object.c ruby.h (fwd)

[GOTO Kentaro]

At Thu, 25 Jul 2002 00:02:28 +0900,
Robert Skarwecki wrote:

> A quick test shows the result:
> $ ruby -e "puts true.class.ancestors.join(',')"
> TrueClass,Object,Kernel
> $ ./ruby -e "puts true.class.ancestors.join(',')"
> TrueClass,BooleanClass,Object,Kernel

Indeed introducing Boolean may make is-a relation clear in the
mathematical sense, but I have two questions.

  * On test stage, we sometimes need is_a?(Boolean) test and `assert'
    method of RUNIT::Assert tests if the value is really true/false.
    Meanwhile, how often do we need Boolean class in run-time?

  * Every object works as a boolean parameter:
      puts 1 if "a"  # puts 1 because "a" is regarded as true value
      !!!x == !x     # true for arbitrary x
      !!!x || !!x    # true for arbitrary x

    Now, how can I explain `"a".is_a?(Boolean) == false'?

By the way, the result above can be obtained by a Ruby script below.
So, I think that Boolean should be an option activated by `require
"boolean"' even if that would be introduced.

% cat boolean.rb 
module Boolean
  def self.append_features(m)
    if m != TrueClass and m != FalseClass
      raise TypeError, "`#{m.name}' isn't TrueFalse nor FalseClass", caller(1)
    end
    super
  end
end

class TrueClass
  include Boolean
end

class FalseClass
  include Boolean
end


% ruby -r boolean -e 'puts true.class.ancestors.join(",")' 
TrueClass,Boolean,Object,Kernel
% ruby -r boolean -e 'puts false.class.ancestors.join(",")'
FalseClass,Boolean,Object,Kernel
% ruby -r boolean -e 'p true.is_a?(Boolean) && false.is_a?(Boolean)'
true
% ruby -r boolean -e 'class Array; include Boolean; end'   
-e:1:in `include': `Array' isn't TrueFalse nor FalseClass (TypeError)
        from -e:1
% 

-- Gotoken

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

GOTO Kentaro <gotoken@notwork.org> writes:

>   * On test stage, we sometimes need is_a?(Boolean) test and `assert'
>     method of RUNIT::Assert tests if the value is really true/false.
>     Meanwhile, how often do we need Boolean class in run-time?

For what it's worth, I think this is an evil side of the assert
method. Ruby says nil and false are 'false', and everything else is
true. So, if I write a method that's designed to be used as

   if my_method then ...

I'd expect to be able to test it with an assert(), but currently I
can't without writing extra (and distracting) stuff.


I think adding Boolean to Ruby would be confusing, and I'm not sure I
see the need.

At the same time, I'm wondering if it would be possible to unify nil
and false, so that they were both the same object?


Cheers


Dave

unifying nil and false (Re: [PATCH] object.c ruby.h)

[Yukihiro Matsumoto]

Hi,

In message "Re: [PATCH] object.c ruby.h (fwd)"
    on 02/07/25, Dave Thomas <Dave@PragmaticProgrammer.com> writes:

|At the same time, I'm wondering if it would be possible to unify nil
|and false, so that they were both the same object?

"nil" and "false" are treated differently everywhere.  Unifying them
will cause serious compatibility problem.  For example, Thread#status
returns false for threads terminated normally, nil for threads
terminated with exceptions.  See ri Thread#status.  Also I've heard
they're used for three state logic (true - false - undefined).

So it's not easy to unify them.

							matz.

Re: unifying nil and false (Re: [PATCH] object.c ruby.h)

[Dave Thomas]

matz@ruby-lang.org (Yukihiro Matsumoto) writes:

> "nil" and "false" are treated differently everywhere.  Unifying them
> will cause serious compatibility problem.  For example,
> Thread#status returns false for threads terminated normally, nil for
> threads terminated with exceptions.  See ri Thread#status.  Also
> I've heard they're used for three state logic (true - false -
> undefined).

I know, I know...  It was just a wistful question... :)


Dave

Re: unifying nil and false (Re: [PATCH] object.c ruby.h)

[Yukihiro Matsumoto]

Hi,

In message "Re: unifying nil and false (Re: [PATCH] object.c ruby.h)"
    on 02/07/25, Dave Thomas <Dave@PragmaticProgrammer.com> writes:

|I know, I know...  It was just a wistful question... :)

How about going back to Ruby version 0.95?  ;-)
It is the only public version before nil - false separation.

							matz.

Re: [PATCH] object.c ruby.h (fwd)

[GOTO Kentaro]

At Thu, 25 Jul 2002 05:05:46 +0900,
Dave Thomas wrote:

> I'd expect to be able to test it with an assert(), but currently I
> can't without writing extra (and distracting) stuff.

Indeed assert() of Test::Unit::Assertions does not test true/false.  
I think that the assert() is too generic and that can blur the meaning
of an assertion.  Perhaps true-false-test may prevent abuse of
assert() in rubyunit.

> At the same time, I'm wondering if it would be possible to unify nil
> and false, so that they were both the same object?

Something built-in to get truth value of each object may help explain
the boolean aspect in Ruby.

  % ruby -e '
  module Kernel
    def truth() !!self end
  end

  p nil.truth  
  p false.truth
  p :else.truth

  '
  false
  false
  true 

-- Gotoken

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

GOTO Kentaro <gotoken@notwork.org> writes:

> > I'd expect to be able to test it with an assert(), but currently I
> > can't without writing extra (and distracting) stuff.
> 
> Indeed assert() of Test::Unit::Assertions does not test true/false.  
> I think that the assert() is too generic and that can blur the meaning
> of an assertion.  Perhaps true-false-test may prevent abuse of
> assert() in rubyunit.

Hmm - I differ here. I'd expect assert() to work the same way as 'if'
and 'unless' do, so that

    assert(x)

would succeed and fail the same as

    raise "assertion failed" unless x




> Something built-in to get truth value of each object may help explain
> the boolean aspect in Ruby.
> 
>   % ruby -e '
>   module Kernel
>     def truth() !!self end
>   end

Perhaps #to_b?

(But then we'd need a Boolean type for the name to make sense... :))


Dave

Re: [PATCH] object.c ruby.h (fwd)

[nobu.nokada]

Hi,

At Thu, 25 Jul 2002 22:20:32 +0900,
Dave Thomas wrote:
> > Something built-in to get truth value of each object may help explain
> > the boolean aspect in Ruby.
> > 
> >   % ruby -e '
> >   module Kernel
> >     def truth() !!self end
> >   end
> 
> Perhaps #to_b?

How about "true?"?

-- 
Nobu Nakada

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

nobu.nokada@softhome.net writes:

> At Thu, 25 Jul 2002 22:20:32 +0900,
> Dave Thomas wrote:
> > > Something built-in to get truth value of each object may help explain
> > > the boolean aspect in Ruby.
> > > 
> > >   % ruby -e '
> > >   module Kernel
> > >     def truth() !!self end
> > >   end
> > 
> > Perhaps #to_b?
> 
> How about "true?"?

Hi:


Well, to me, a.true? would imply the same as a == true, which isn't
what it does. #to_b, however, implies a conversion to the mythical
Boolean type. :)


Dave

Re: [PATCH] object.c ruby.h (fwd)

[nobu.nokada]

Hi,

At Fri, 26 Jul 2002 02:55:28 +0900,
Dave Thomas wrote:
> Well, to me, a.true? would imply the same as a == true, which isn't
> what it does. #to_b, however, implies a conversion to the mythical
> Boolean type. :)

Hmmm, then a.t?.  It would be lispy...

-- 
Nobu Nakada

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

nobu.nokada@softhome.net writes:

> At Fri, 26 Jul 2002 02:55:28 +0900,
> Dave Thomas wrote:
> > Well, to me, a.true? would imply the same as a == true, which isn't
> > what it does. #to_b, however, implies a conversion to the mythical
> > Boolean type. :)
> 
> Hmmm, then a.t?.  It would be lispy...

Well, I guess the _ideal_ would be to have nothing, and to then have
assert have the same semantics for its parameter as regular
conditional contexts (that is, I _still_ think it is silly for assert
to check that its parameter is 'true' or 'false' when an 'if'
statement doesn't.. :)


Cheers


Dave

Re: [PATCH] object.c ruby.h (fwd)

[GOTO Kentaro]

At Fri, 26 Jul 2002 03:11:02 +0900,
nobu.nokada@softhome.net wrote:
> At Fri, 26 Jul 2002 02:55:28 +0900,
> Dave Thomas wrote:
> > Well, to me, a.true? would imply the same as a == true, which isn't
> > what it does. #to_b, however, implies a conversion to the mythical
> > Boolean type. :)
> 
> Hmmm, then a.t?.  It would be lispy...

Isn't it too hackish :) 

But `?' looks nice because the suffix suggests true-false valued.  As
Dave said, the prefix `to_' would implies conversion to a type.

I vote #truth?.  If someone asks `why not boolean' we can plead that
Boolean algebra is just one of characterizations but not synonym for
the truth value.

---------------------------------------------------------- Object#truth?
     obj.truth? -> true or false
------------------------------------------------------------------------
     Returns a truth-value for this object.  In Ruby, either false or
     nil is regarded as a negative condition.  Everything else is 
     positive one.  `true' is the representative of positive conditions.
        true.truth?       #=> true
        false.truth?      #=> false
        nil.truth?        #=> false
        "string".truth?   #=> true
        0.truth?          #=> true

And #falsity? for symmetry.

-------------------------------------------------------- Object#falsity?
     obj.falsity? -> true or false
------------------------------------------------------------------------
     nagation of Object#truth?. 

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

GOTO Kentaro <gotoken@notwork.org> writes:

> I vote #truth?.  If someone asks `why not boolean' we can plead that
> Boolean algebra is just one of characterizations but not synonym for
> the truth value.

If you call Regexp#match with a non-string argument, it calls that
argument's to_str method to coerce it into a string.

So, perhaps, if the expression to pass to 'if', 'while', and friends
isn't 'true' or 'false', the interpreter should call #truth? on it to
coerce it into a truth value.[1]

If that sounds logical, then perhaps #to_truth might be a more
consistent name.


Dave


[1] Doing this would allow Perl fans to do

  class String
    def truth?
      !empty?
    end
  end
  class Integer
    def truth?
      !zero?
    end
  end

Aarrgh...

Re: [PATCH] object.c ruby.h (fwd)

[GOTO Kentaro]

At Fri, 26 Jul 2002 05:34:10 +0900,
Dave Thomas wrote:
> If you call Regexp#match with a non-string argument, it calls that
> argument's to_str method to coerce it into a string.
> 
> So, perhaps, if the expression to pass to 'if', 'while', and friends
> isn't 'true' or 'false', the interpreter should call #truth? on it to
> coerce it into a truth value.[1]

Oops! Sorry, I misunderstood that `and' or `or' treat conditions as
same as `if' or `while' do.  Now I agree your opinion but would like
to withdraw proposition to introduce anything built-in to obtain truth
value for each object.  The truth is not simple indeed.

  % ruby17 -e '$_ = "foo"; /x/ or puts :pass' 
  % ruby17 -e '$_ = "foo"; puts :pass unless /x/' 
  pass
  % ruby17 -v
  ruby 1.7.2 (2002-07-13) [i386-freebsd4.5]

By the way, how about asking the auther to fit the behavior of
RubyUnit's assert() to Test::Unit's?

  % ruby ~/foo.rb
  Test::Unit ------------------------------
  Loaded suite TestTU
  Started...
  .
  Finished in 0.003085 seconds.
  1 runs, 1 assertions, 0 failures, 0 errors
  RubyUnit ------------------------------

  TestRU#test_x E.
  Time: 0.177137
  FAILURES!!!
  Test Results:
   Run: 1/1(1 asserts) Failures: 0 Errors: 1
  Errors: 1
  /home/gotoken/foo.rb:21:in `test_x'(TestRU): 1st argument <1> type should be TrueClass or FalseClass. (TypeError)
          from /home/gotoken/foo.rb:25
  % cat ~/foo.rb
  puts "Test::Unit ------------------------------"

  require "test/unit"
  require "test/unit/ui/console/testrunner"

  class TestTU < Test::Unit::TestCase
    def test_x
      assert(1)
    end
  end

  Test::Unit::UI::Console::TestRunner.run(TestTU)

  puts "RubyUnit ------------------------------"

  require "runit/testcase"
  require "runit/cui/testrunner"

  class TestRU < RUNIT::TestCase
    def test_x
      assert(1)
    end
  end

  RUNIT::CUI::TestRunner.run(TestRU.suite)

  % 

-- Gotoken

Re: [PATCH] object.c ruby.h (fwd)

[NAKAMURA, Hiroshi]

Hi,

> From: Dave Thomas
> Sent: Thursday, July 25, 2002 10:21 PM

> > > I'd expect to be able to test it with an assert(), but currently I
> > > can't without writing extra (and distracting) stuff.
> > 
> > Indeed assert() of Test::Unit::Assertions does not test 
> true/false.  
> > I think that the assert() is too generic and that can blur 
> the meaning
> > of an assertion.  Perhaps true-false-test may prevent abuse of
> > assert() in rubyunit.
> 
> Hmm - I differ here. I'd expect assert() to work the same way as 'if'
> and 'unless' do, so that
> 
>     assert(x)
> 
> would succeed and fail the same as
> 
>     raise "assertion failed" unless x

+1 to gotoken.  assert is for tester.  When someone put on
tester's hat, (s)he should assert to check true/false
explicitly, I think.

Back to the main topic about introducing Boolean class,
I don't have any idea because I seldom use TrueClass and
FalseClass with Ruby...  Does Ruby/C API user use TrueClass
/FalseClass instead of true/false(instances)?

How about introducing Boolean and aliasing TrueClass and
FalseClass to Boolean?

Regards,
// NaHi

Re: [PATCH] object.c ruby.h (fwd)

[YANAGAWA Kazuhisa]

In message <m2bs8vr1h7.fsf@zip.local.thomases.com>
Dave@PragmaticProgrammer.com writes:

> So, perhaps, if the expression to pass to 'if', 'while', and friends
> isn't 'true' or 'false', the interpreter should call #truth? on it to
> coerce it into a truth value.[1]
> 
> If that sounds logical, then perhaps #to_truth might be a more
> consistent name.

That's like my old proposal on.... where? :-) Matz rejected that since
its cost may be too expensive.  So if you state it strongly, show its
usefulness and effective implementation.



> [1] Doing this would allow Perl fans to do
> 
>   class String
>     def truth?
>       !empty?
>     end
>   end
>   class Integer
>     def truth?
>       !zero?
>     end
>   end

My proposal is inspired by a discussion on Regexp.last_match, where
someone said `/re/.match() should return always MatchData'.  To solve
its compatibility problem, introducing a conversion method like to_ary
or to_int then we can write `if /re/.match() ...' again, where
MatchData#to_bool returns true if matched, false else.

# Uhm, a bad summary :-P


-- 
kjana@dm4lab.to                                  July 26, 2002
Translators, traitors.

Re: [PATCH] object.c ruby.h (fwd)

[Michal Rokos]

On Thu, Jul 25, 2002 at 08:06:17PM +0900, GOTO Kentaro wrote:
> Something built-in to get truth value of each object may help explain
> the boolean aspect in Ruby.
> 
>   % ruby -e '
>   module Kernel
>     def truth() !!self end
>   end
> 
>   p nil.truth  
>   p false.truth
>   p :else.truth
> 
>   '
>   false
>   false
>   true 
>

	I think if the RTEST returns 0 for Qnil or Qfalse, so Qnil is
	the same as Qfalse. (nil is false)

	If I look at SmallTalk: they distinguish between nil and false
	and I feel that thier attitude is the right one.

	To get the same level of real-word-perception as SmallTalk has,
	it is needed to:
	(1)	* raise error if argument to RTEST isn't kind of Boolean
	(2)	* remove all #to_* and boolean (#&, #|) methods for nil.

Note (1): I know that if we do this all code will be broken and has to
be rewritten or corrected. And that's why this has no solution for 
Ruby 1.x (- hopefully in Rite?)

Note (2): Makes it sence to convert 'Nothing' (nil) to Float or
Integer??? I don't think so.

PS: nil is instance NillClass (in Ruby). Class name in SmallTalk is
'UndefinedObject' - personally: I think that using nil in this sence
(UndefinedObject) is the right perception of 'nil' term.
 
	But there are much more skilled SmallTalkers than I have - I'd
	like to hear their opinion...
	
		Michal

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Michal Rokos                         Czech Technical University, Prague
E-mail:m.rokos@sh.cvut.cz      ICQ:36118339      Jabber:majkl@jabber.cz
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

Michal Rokos <m.rokos@sh.cvut.cz> writes:

> 	To get the same level of real-word-perception as SmallTalk has,
> 	it is needed to:
> 	(1)	* raise error if argument to RTEST isn't kind of Boolean
> 	(2)	* remove all #to_* and boolean (#&, #|) methods for nil.

Although this is a pure approach, I think it would make programming in
Ruby harder. Being able to say things like

   while line = gets
     ...
   end

is just too useful for the small tasks folks often use Ruby
for. Wrapping that up in a more theoretically sound

  while !(line = gets).nil?

loses a lot.

Now I know that folks would then say: but you shouldn't do
this. ARGF.each or whatever is more expressive and avoids the
problem. And I agree. But the reality is that the user community
appreciates the variety of styles supported by Ruby, and one of the
reasons people take to Ruby in the first place is the ability to write
familiar looking code.


Cheers


Dave

Re: [PATCH] object.c ruby.h (fwd)

[Yukihiro Matsumoto]

Hi,

In message "Re: [PATCH] object.c ruby.h (fwd)"
    on 02/07/27, Michal Rokos <m.rokos@sh.cvut.cz> writes:

|Note (1): I know that if we do this all code will be broken and has to
|be rewritten or corrected. And that's why this has no solution for 
|Ruby 1.x (- hopefully in Rite?)

Parhaps.

|Note (2): Makes it sence to convert 'Nothing' (nil) to Float or
|Integer??? I don't think so.

But they are useful for some cases.  So we need stronger reason than
"does't make sense" to remove them.

							matz.

Re: [PATCH] object.c ruby.h (fwd)

[Masaki Suketa]

In message "Re: [PATCH] object.c ruby.h (fwd)"
    on 02/07/26, GOTO Kentaro <gotoken@notwork.org> writes:

> By the way, how about asking the auther to fit the behavior of
> RubyUnit's assert() to Test::Unit's?

Older version of RubyUnit's assert() behavior is same as Test::Unit's.
The behavior has been changed to avoid confusion of assert and 
assert_equal.

  str = 'foo'
  str += 'bar'
  assert('foobar', str) #  str must be 'foobar'

The above code is not correct(assert_equal should be used instead of
assert). But older version of RubyUnit can not notice it because
1st argument is true.

I am not sure which behavior is better. Can I ignore this kind of 
confusion? Any idea?

  Regards,
  Masaki Suketa

Re: [PATCH] object.c ruby.h (fwd)

[Dave Thomas]

Masaki Suketa <masaki.suketa@nifty.ne.jp> writes:

>   str = 'foo'
>   str += 'bar'
>   assert('foobar', str) #  str must be 'foobar'
> 
> The above code is not correct(assert_equal should be used instead of
> assert). But older version of RubyUnit can not notice it because
> 1st argument is true.
> 
> I am not sure which behavior is better. Can I ignore this kind of 
> confusion? Any idea?

There's not much we can do if people call the incorrect method :)

If this is a problem that occurs frequently, then perhaps we could go
the way JUnit went and deprecate 'assert' in favor of 'assert_true'
(or possibly 'assert_truth').


Cheers


Dave

A truth? patch + benchmarks

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]



> -----Original Message-----
> From: YANAGAWA Kazuhisa [mailto:kjana@dm4lab.to]
> Sent: Friday, July 26, 2002 12:11 PM
> To: ruby-core@ruby-lang.org
> Subject: Re: [PATCH] object.c ruby.h (fwd)
> 
> In message <m2bs8vr1h7.fsf@zip.local.thomases.com>
> Dave@PragmaticProgrammer.com writes:
> 
> > So, perhaps, if the expression to pass to 'if', 'while', and friends
> > isn't 'true' or 'false', the interpreter should call #truth? on it
to
> > coerce it into a truth value.[1]
> >
> > If that sounds logical, then perhaps #to_truth might be a more
> > consistent name.
> 
> That's like my old proposal on.... where? :-) Matz rejected that since
> its cost may be too expensive.  So if you state it strongly, show its
> usefulness and effective implementation.

Trying to answer your first question, it seems to me that
Every time you are dealing with the Null-Pattern such a
facility might come in handy. The proliferation of the
``false'' value in Python and indirectly the existence of
the conversion methods #to_something in the NilClass are a
testimony for this.


I also cooked up simple minded an implementation. It is based on
a FL_FALSE flag (I defined it to be 1<<5 not sure if this can
case any problem?) similar to the frozen or tainted flags - that
is I added there methods (the method names ain't great ..)

#falsify : the ``truth-state'' is set to false)
#verify  : the ``truth-state'' is set to true)
#truth?  : tests the truth state.
           obj.truth? returns true if obj is
           an immediate value != false,nil (in other
           words obj is a Symbol, Fixnum or ``True'')
           or obj non immediate object and the false
           flag is not set.


A welcome side affect of this implementation is, that you
cannot change the truth-state of Fixnums and O particular
so Perl fans would be still pissed off;-)).
 

A few words about the included benchmarks.  I pitted
3 type of implementation (and two compilers Mingw32
and VC7) against each other. 

a) Stock Ruby (as of today).
b) The patched Ruby
c) The patched Ruby where I replaced the macro calls 
   RTEST(ruby_debug) and RTEST(rbuy_verbose)
   with PURE_RTEST(ruby_debug) and PURE_RTEST(ruby_verbose)
   macro call - where PURE_TEST is ``original RTEST'' macro.


The first test is a gc and memory intensive problem.
(It is a solution to Tobias Reif [ruby-talk:33425]
maximal anagram chain problem - my wordlist contains
about 230,000 English words).

In this test a) & b) perform about the same but c)
is ~ 10 percent faster.


The second test is the simple ``program flow
test'' (no gc work involved).

---
# loop.rb
require 'benchmark'
include Benchmark


i = 0
bm do |x|
  x.report do
    while (i) do
     i+= 1
     i = nil if i == 5000000
   end
  end
end 
---
 
The result are quite surprising. Both b) and c)
(which is slightly slower in this case) outperform
a) by almost 20 percent.


All in all even if the false flag scheme is
rejected it is probably a good idea to replace
some of the current RTEST(obj) macro calls
with an inlined c-function version.



/Christoph

[-- Attachment #2: bench.tar.gz --]
[-- Type: application/octet-stream, Size: 2182 bytes --]

[-- Attachment #3: patch.tar.gz --]
[-- Type: application/octet-stream, Size: 1037 bytes --]

Re: A truth? patch + benchmarks

[ts]

>>>>> "C" == Christoph  <chr_news@gmx.net> writes:

C> I also cooked up simple minded an implementation. It is based on
C> a FL_FALSE flag (I defined it to be 1<<5 not sure if this can
C> case any problem?) similar to the frozen or tainted flags - that
C> is I added there methods (the method names ain't great ..)

 Not really sure but the values < 64 reserved for T_MASK

#define T_NIL    0x01
#define T_OBJECT 0x02
[etc]
#define T_NODE   0x3f

#define T_MASK   0x3f


Guy Decoux

RE: A truth? patch + benchmarks

[Christoph]

> -----Original Message-----
> From: ts [mailto:decoux@moulon.inra.fr]
> Sent: Wednesday, July 31, 2002 5:04 PM
> To: ruby-core@ruby-lang.org
> Cc: ruby-core@ruby-lang.org
> Subject: Re: A truth? patch + benchmarks
> 
> >>>>> "C" == Christoph  <chr_news@gmx.net> writes:
> 
> C> I also cooked up simple minded an implementation. It is based on
> C> a FL_FALSE flag (I defined it to be 1<<5 not sure if this can
> C> case any problem?) similar to the frozen or tainted flags - that
> C> is I added there methods (the method names ain't great ..)
> 
>  Not really sure but the values < 64 reserved for T_MASK
> 
> #define T_NIL    0x01
> #define T_OBJECT 0x02
> [etc]
> #define T_NODE   0x3f
> 
> #define T_MASK   0x3f

Hm, what about using FL_USER7? More generally, is there any 
unused flag left?


/Christoph

Re: A truth? patch + benchmarks

[Yukihiro Matsumoto]

Hi,

In message "RE: A truth? patch  + benchmarks"
    on 02/08/01, "Christoph" <chr_news@gmx.net> writes:

|>  Not really sure but the values < 64 reserved for T_MASK
|> 
|> #define T_NIL    0x01
|> #define T_OBJECT 0x02
|> [etc]
|> #define T_NODE   0x3f
|> 
|> #define T_MASK   0x3f
|
|Hm, what about using FL_USER7? More generally, is there any 
|unused flag left?

Unfortunately, there's no bit available for all objects.  All flag
bits are used to represent NODEs' line number.

By the way, I still don't know why the inlined function is faster than
the simple macro.  Does anybody reveal the secret for me?

							matz.

RE: A truth? patch + benchmarks

[Christoph]

> -----Original Message-----
> From: Yukihiro Matsumoto [mailto:matz@ruby-lang.org]
> Sent: Thursday, August 01, 2002 9:03 AM
> To: ruby-core@ruby-lang.org
> Subject: Re: A truth? patch + benchmarks
> 
> Hi,
> 
> In message "RE: A truth? patch  + benchmarks"
>     on 02/08/01, "Christoph" <chr_news@gmx.net> writes:
> 
> |>  Not really sure but the values < 64 reserved for T_MASK
> |>
> |> #define T_NIL    0x01
> |> #define T_OBJECT 0x02
> |> [etc]
> |> #define T_NODE   0x3f
> |>
> |> #define T_MASK   0x3f
> |
> |Hm, what about using FL_USER7? More generally, is there any
> |unused flag left?
> 
> Unfortunately, there's no bit available for all objects.  All flag
> bits are used to represent NODEs' line number.

To bad ... but maybe we might see something like it in 2.0? (or
even better body smatter cooks something up for the current 
development line - maybe only replace the RTEST calls in the
crucial IF_NODE, WHILE_NODE ...  part?)

> 
> By the way, I still don't know why the inlined function is faster than
> the simple macro.  Does anybody reveal the secret for me?

I don't know (besides a not particular helpful  ``your compiler
always knows best'' ;-). Anyway  I run the two tests (on Mswin32)
subdividing the macro call RTEST(v) following strategy c) (of
my previous post)

PURE_TEST(v) = .. original macro call for
            ruby_verbose and ruby_debug test.

and setting  the rest of the RTEST(obj) macro calls to


static inline int
rb_truth_test(VALUE obj)
{
  if (~Qnil & obj) return 1;
  return 0;
}


Not surprisingly, this version tested as fast or faster then
any of my other test candidates.



/Christoph

Re: A truth? patch + benchmarks

[ts]

>>>>> "C" == Christoph  <chr_news@gmx.net> writes:

C> static inline int
C> rb_truth_test(VALUE obj)
C> {
C>   if (~Qnil & obj) return 1;
C>   return 0;
C> }

 Well, personnally I've not found a difference between the macro and inline
 version (and the assembler generated was the same)

C> Not surprisingly, this version tested as fast or faster then
C> any of my other test candidates.

 You are sure that it's not an artefact ?



Guy Dcoux

RE: A truth? patch + benchmarks

[Christoph]

> -----Original Message-----
> From: ts [mailto:decoux@moulon.inra.fr]
> Sent: Friday, August 02, 2002 9:21 AM
> To: ruby-core@ruby-lang.org
> Cc: ruby-core@ruby-lang.org
> Subject: Re: A truth? patch + benchmarks
> 
> >>>>> "C" == Christoph  <chr_news@gmx.net> writes:
> 
> C> static inline int
> C> rb_truth_test(VALUE obj)
> C> {
> C>   if (~Qnil & obj) return 1;
> C>   return 0;
> C> }
> 
>  Well, personnally I've not found a difference between the macro and
inline
>  version (and the assembler generated was the same)

Don't know but maybe the compiler sometimes wisely decides not 
to inline - or does some other type of global optimizations?

Anyway the size of the dll are different (vc7)- ls -l ...

794624 Aug  1 18:26 mswin32-ruby17.dll (rb_truth_test version)
791552 Aug  2 09:53 mswin32-ruby17.dll (PURE_RTEST = RTEST) 


> 
> C> Not surprisingly, this version tested as fast or faster then
> C> any of my other test candidates.
> 
>  You are sure that it's not an artefact ?

I did not want to (and somehow still don't want to)
believe that this isn't an artifact myself.  But I am
getting these counter intuitive results on several
platforms mswin32, mingw32 and cygwin (3.1.1 gcc) 
and the results seem very consistent (well at least
until I, eehm - more likely you, find my setup mistake;-).

 
/Christoph

Re: [PATCH] object.c ruby.h (fwd)

[Masaki Suketa]

In message "Re: [PATCH] object.c ruby.h (fwd)"
    on 02/07/27, Dave Thomas <Dave@PragmaticProgrammer.com> writes:

> There's not much we can do if people call the incorrect method :)

Ok. I will change the behavior of assert of RubyUnit like as Test::Unit.

  Regards,
  Masaki Suketa

Re: A truth? patch + benchmarks

[Yukihiro Matsumoto]

Hi,

In message "RE: A truth? patch  + benchmarks"
    on 02/08/02, "Christoph" <chr_news@gmx.net> writes:

|> Unfortunately, there's no bit available for all objects.  All flag
|> bits are used to represent NODEs' line number.
|
|To bad ... but maybe we might see something like it in 2.0? (or
|even better body smatter cooks something up for the current 
|development line - maybe only replace the RTEST calls in the
|crucial IF_NODE, WHILE_NODE ...  part?)

If it is really efficient, I think we can reserve a bit ot two for
it.  But I want to know the secret of this magic.

							matz.

RE: A truth? patch + benchmarks

[Christoph]

> From: Yukihiro Matsumoto 
...
> |> Unfortunately, there's no bit available for all objects.  All flag
> |> bits are used to represent NODEs' line number.
> |
> |To bad ... but maybe we might see something like it in 2.0? (or
> |even better body smatter cooks something up for the current
> |development line - maybe only replace the RTEST calls in the
> |crucial IF_NODE, WHILE_NODE ...  part?)
> 
> If it is really efficient, I think we can reserve a bit ot two for

One bit should be enough.  My tests indicate that for the current
Implementation this would have been efficient, but I obviously can
only guess, how this or a similar scheme, would fair in an interpreter
rewrite.   

> it.  But I want to know the secret of this magic.

Actually, I am not quite sure to what ``magic'' you are referring to
(which only seems fair, since my emails are usually incomprehensible;-).

If the ``magic'' is referring to my observed speedup of replacing 
most RTEST macro calls with an inlined function call (at least on
my windows machine this effect seems to be real), I really have 
to pass (besides making uneducated guesses) but I tend to think that 
this "compilation optimization artifact" is wedded to the current 
implementation (putting things in perspective, changing from VC6 to
VC7 has an even bigger impact on speed).

Just been curious (and pushy;-). I counted 26 ``T_VALUES'' in ruby.h,
so from my naive point of view it might be possible (after 
rearranging the ``T_VALUES'' a bit, eehm, <= 31) to free up the sixth
bit as a false/true bit. Of course, I tried this and did not see any
obvious ill effect (running ``make test''  and ``rubicon'' on cygwin)
- I guess that's what they call wishful thinking;-).  

My question is, what did I overlook this time?


/Christoph

Re: [PATCH] object.c ruby.h (fwd)

[NAKAMURA, Hiroshi]

Hi,

> From: Masaki Suketa [mailto:masaki.suketa@nifty.ne.jp] 
> Sent: Saturday, August 03, 2002 6:05 PM

> > There's not much we can do if people call the incorrect method :)
> 
> Ok. I will change the behavior of assert of RubyUnit like as 
> Test::Unit.

-1 for this change but I can live with it.

I'll write 'assert( foo == true )' or 'assert( !!foo )'
explicitly, if it'll be changed.

// NaHi

Re: A truth? patch + benchmarks

[nobu.nokada]

Hi,

At Mon, 5 Aug 2002 09:58:11 +0900,
Christoph wrote:
> If the ``magic'' is referring to my observed speedup of replacing 
> most RTEST macro calls with an inlined function call (at least on
> my windows machine this effect seems to be real), I really have 
> to pass (besides making uneducated guesses) but I tend to think that 
> this "compilation optimization artifact" is wedded to the current 
> implementation (putting things in perspective, changing from VC6 to
> VC7 has an even bigger impact on speed).

It's true with gcc 2.95.3 under i686-linux.

> Just been curious (and pushy;-). I counted 26 ``T_VALUES'' in ruby.h,
> so from my naive point of view it might be possible (after 
> rearranging the ``T_VALUES'' a bit, eehm, <= 31) to free up the sixth
> bit as a false/true bit. Of course, I tried this and did not see any
> obvious ill effect (running ``make test''  and ``rubicon'' on cygwin)
> - I guess that's what they call wishful thinking;-).  

The modification means that *all* extension libraries must be
recompiled.  Particularly, many extensions use T_DATA which is
bigger than 31.  I guess it shouldn't be until (at least) minor
version will change.

-- 
Nobu Nakada

Re: [PATCH] object.c ruby.h (fwd)

[Masaki Suketa]

In message "Re: [PATCH] object.c ruby.h (fwd)"
    on 02/08/05, "NAKAMURA, Hiroshi" <nahi@keynauts.com> writes:

> > Ok. I will change the behavior of assert of RubyUnit like as 
> > Test::Unit.
> 
> -1 for this change but I can live with it.
> 
> I'll write 'assert( foo == true )' or 'assert( !!foo )'
> explicitly, if it'll be changed.

If I add assert_true method which checks 'foo == true',
could you live with it more pleasantly?

  Regards,
  Masaki Suketa

Re: [PATCH] object.c ruby.h (fwd)

[NAKAMURA, Hiroshi]

Hi Suketa-san,

> From: Masaki Suketa [mailto:masaki.suketa@nifty.ne.jp] 
> Sent: Tuesday, August 06, 2002 8:53 PM

> > > Ok. I will change the behavior of assert of RubyUnit like as 
> > > Test::Unit.
> > 
> > -1 for this change but I can live with it.
> > 
> > I'll write 'assert( foo == true )' or 'assert( !!foo )'
> > explicitly, if it'll be changed.
> 
> If I add assert_true method which checks 'foo == true',
> could you live with it more pleasantly?

Yes, I can.  At the next, does method 'assert' become
'deprecated'?  ...Sorry, I don't mean it.  I just
remembered JUnit...

// NaHi

Re: [PATCH] object.c ruby.h (fwd)

[Masaki Suketa]

In message "Re: [PATCH] object.c ruby.h (fwd)"
    on 02/08/09, "NAKAMURA, Hiroshi" <nahi@keynauts.com> writes:

> > If I add assert_true method which checks 'foo == true',
> > could you live with it more pleasantly?
> 
> Yes, I can.  At the next, does method 'assert' become
> 'deprecated'?  ...Sorry, I don't mean it.  I just
> remembered JUnit...

No, at least I never deprecate 'assert' method.

  assert(foo)  # foo should not be nil nor false.
  assert_true(foo) # foo should be true.

If I want to test that foo should not be nil,
I'll use assert. If I want to test that 
foo should be true, I'll use assert_true.

  Regards,
  Masaki Suketa

Re: [PATCH] object.c ruby.h (fwd)

[NAKAMURA, Hiroshi]

Hi, Suketa-san,

> From: Masaki Suketa [mailto:masaki.suketa@nifty.ne.jp] 
> Sent: Saturday, August 10, 2002 9:20 PM

> > > If I add assert_true method which checks 'foo == true',
> > > could you live with it more pleasantly?
> > 
> > Yes, I can.  At the next, does method 'assert' become
> > 'deprecated'?  ...Sorry, I don't mean it.  I just
> > remembered JUnit...
> 
> No, at least I never deprecate 'assert' method.
> 
>   assert(foo)  # foo should not be nil nor false.
>   assert_true(foo) # foo should be true.

It's slightly regrettable for me that it won't be deprecated.
But don't care about me.  I'm only one of users. :)

> If I want to test that foo should not be nil,
> I'll use assert. If I want to test that 
> foo should be true, I'll use assert_true.

If I want to test "foo should not be nil", I'll write
  assert_true( foo != nil )
because it it straight for me to show my intent than
  assert( foo )

Regards,
// NaHi

Mswin32 build flags

[Christoph]

Hi,

the current mswin32 build unfortunately (globally;-)
turns off the global optimization flag /Og, a real pit,
since using global optimization seems to result in ruby
binaries that (in some benchmarks) runs almost (together
with the "PURE_TEST != RTEST = inline method" compile
trick possibly) twice as fast as their ``stock compiled''
counter parts. (They are also faster than cygwin builds
btw.)

Unfortunately these builds also miserably fail the basic 
``nmake test'', however by only turning off the /Og 
flag turning the compilation of the file ``sprint.c'' 
one seems to get an executable which seem to enjoy
the speed gain of a full /Og optimization which 
passes the basic  "nmake test" (true at least for 
VC 7) - so I am wondering if there are known issues
against such a compilation strategy?
 

/Christoph
 

Re: Mswin32 build flags

[U.Nakamura]

Hello,

In message "Mswin32 build flags"
    on Aug.16,2002 15:52:41, <chr_news@gmx.net> wrote:
| Unfortunately these builds also miserably fail the basic 
| ``nmake test'', however by only turning off the /Og 
| flag turning the compilation of the file ``sprint.c'' 
| one seems to get an executable which seem to enjoy
| the speed gain of a full /Og optimization which 
| passes the basic  "nmake test" (true at least for 
| VC 7) - so I am wondering if there are known issues
| against such a compilation strategy?

Because there are more problems with /Og flag
(GC, Regexp, etc).
So, I cannot say that /Og is reliable.


Regards,
--
U.Nakamura <usa@osb.att.ne.jp>

RE: Mswin32 build flags

[Christoph]

> -----Original Message-----
> From: U.Nakamura [mailto:usa@osb.att.ne.jp]
> Sent: Friday, August 16, 2002 9:13 AM
> To: ruby-core@ruby-lang.org
> Subject: Re: Mswin32 build flags
> 
> Hello,
> 
> In message "Mswin32 build flags"
>     on Aug.16,2002 15:52:41, <chr_news@gmx.net> wrote:
> | Unfortunately these builds also miserably fail the basic
> | ``nmake test'', however by only turning off the /Og
> | flag turning the compilation of the file ``sprint.c''
> | one seems to get an executable which seem to enjoy
> | the speed gain of a full /Og optimization which
> | passes the basic  "nmake test" (true at least for
> | VC 7) - so I am wondering if there are known issues
> | against such a compilation strategy?
> 
> Because there are more problems with /Og flag
> (GC, Regexp, etc).
> So, I cannot say that /Og is reliable.

Thanks  (and sorry for the late reply) 


I played around with this yesterday and essentially found 
four methods which not should be compiled with the /Og flag 
(turned on/off with the optimize pragma)


rb_big2dbl(x) ( bignum.c  811 )
rb_f_sprintf  ( sprintf.c 105 )
rb_obj_as_string(obj) ( string.c  280)
pack_pack     ( pack.c 332 ) 

Compiled like this ruby (1.7.3 (2002-08-29) [i386-mswin32])
fails no additional rubicon test, in fact it passes one 
additional, hence all, thread tests (on my machine at least).
An additional advantage is that the notoriously low recursion
limit (on mswin32) is also improved by a factor of two.  

It is really a pity that the /Og flag is not totally reliable,
but why not make it a configure option or at least mention it 
the ``README''  + put on/off optimize macros around known ``iffy''
methods? The speed increase is sooo substantial that it should not
be ignored imho - (I'm particularly thinking about Andy's binary 
distribution here).

   

/Christoph