A sketch for a summer of code application

Ruby
1

Hi

I would like to discuss this sketch summer of code application. Any
advices or critic will be wellcome.

Maybe this proposal is not a good idea. Is you think like that,
argues will be wellcome too. (im not sure this is a good idea or not)

Thanks.

== Cover the core of and VM with RSpec ==

=== Abstract ===

There are a number of Ruby implementations available today. The
“standard” implementation is the original C-language-based
implementation, written by Yukihiro M. (aka Matz), and now
maintained by him and a number of contributors. In the las year,
emerge differentes Ruby Virtual Machine (VM), YARV, Rubinius, JRuby,
Gardens Point Ruby .NET, XRuby or cardinal are some good examples
among others [1]. The goal of this proposal is create a common set of
specification (using rspec) for the Ruby core, that verification the
correct and same behaviour of the differents virtual machines. I would
like the specs be usable for any virtual machine implementation.

The goal in writing a spec is to describe the expected behavior from
the object. Each spec should describe one facet of the behavior. Specs
should prefer clarity and understanding over any other principle

Test Driven Development (TDD) has you define the behaviour of your
system by writing small tests that precisely define some small piece
of your system’s behaviour. Then you implement that behaviour. Then
you clean up & improve your design.

=== Benefits to the Community ===
…

=== The scheme : ===

  • language is for specs that describe language-level constructs.
  • core is for specs for any of the builtin classes in Ruby. These are
    documented at RDoc Documentation.

The ruby core set :

  • language : assignament, class, expression, method, operators,
    variables. exception

  • core library : array, proc, bignum, hash, range, binding, integer,
    regexp, class, io, signal, comparable, kernel , sprintf, marshal,
    string,dir, matchdata, struct, enumerable, math, symbol, errno,
    method, threadgroup, exception, module, thread, false, nil, time,
    file, numeric , true, objectspace, unboundmethod, fixnum, object,
    float, process.

  • core/literals :numbers, string, block, hash, regexp, symbol

=== Development plan ===

  1. Before start the projects. Improve my skills reading the rspec
    mailing list. Read specs code form open source projects that already
    use rspec.

  2. Identify/define the core in the VM across the several current
    implementeation (windows, mac, unix, risc). And document their
    behavior.

    • Discuss in each vm mailing list. Which primitives, structures
      and libraries they think must been in the core of ruby.
    • Discuss in the ruby-devel mailing list the correct behaviour.

  3. Write the rspec for language.

  4. Write specs for core/literals

  5. Write spec for the rest of the core.

  6. Write documentation.

Bibliographie :

1 : http://headius.com/rubyspec/index.php/Ruby_Implementations

–

Pedro Del G.

Email : [email protected]

2

Two things:

  1. Though this is a huge - and needed - community service, I think you
    should reconsider simply because it will really bore you (IMHO). Try
    looking for something more interesting to do (There were many offers,
    one of them mine, spread around the ml in the last few days).

  2. More important would be a mechanism to run rspec in one
    implementation and the tests in another. Pat blogged in an interview
    that something like that was in the works but I’m not sure if it’s
    done. Without it, a spec will be useless to an implementation that
    cannot run rspec - which isn’t a trivial program to run. The beauty of
    tests is being able to work with them throughout the whole path.

Also, there are a few spelling mistakes and a bit of missing grammar.

In general, I’d be happy if you’d do it because it would help all the
alternative implementations a lot and I’m waiting so impatiently for
rubinius :stuck_out_tongue:

Aur

3

On 3/19/07, Pedro Del G. [email protected] wrote:

Hi

I would like to discuss this sketch summer of code application. Any
advices or critic will be wellcome.

Maybe this proposal is not a good idea. Is you think like that,
argues will be wellcome too. (im not sure this is a good idea or not)

Thanks.

Hi Pedro,

It’s great to see the interest in RSpec. Thanks!

I also think that this project could provide great value for the
implementors of other ruby implementations - having a single source
against which all rubies can be verified.

This doesn’t, however, feel like a good candidate for a TDD project to
me. TDD is about using tests to drive the behaviour and design of the
code in granular steps. What you seem to want is to create an
executable specification of an entire system that you can then use to
standardize other systems.

While I think that rspec is a reasonable candidate tool for your
project, you may also want to look at FitNesse (w/ ruby FIT).

Cheers,
David

4

(I realize this is late. I was on vacation.)

On Mar 19, 2007, at 3:28 PM, David C. wrote:

While I think that rspec is a reasonable candidate tool for your
project, you may also want to look at FitNesse (w/ ruby FIT).

Also see Koichi’s recent ideas post about the need for a minimal test
suite for the core.

James Edward G. II

5

On Mar 19, 2007, at 1:38 PM, SonOfLilit wrote:

  1. Though this is a huge - and needed - community service, I think you
    should reconsider simply because it will really bore you (IMHO). Try
    looking for something more interesting to do (There were many offers,
    one of them mine, spread around the ml in the last few days).

How do we know what he would find boring?

Call me odd, but writing tests is fun for me.

James Edward G. II

6

I said that IMHO he would find it boring.

Writing tests could be fun to me, but only as part of a whole coding
experience.

Only writing tests for months would feel the same as only dealing with
APIs. It becomes mechanical without there being problem solving
involved.

Again, only my honest opinion :slight_smile:

Aur

7

Really? This is interesting. Very much so.

Could you show a few of these tests that are really problem solving by
themselves?

James, could you too?

Open a thread if you wish.

I really find this worth note and something that might improve the way
I program.

Aur

8

On 3/26/07, SonOfLilit [email protected] wrote:

I said that IMHO he would find it boring.

Writing tests could be fun to me, but only as part of a whole coding experience.

Only writing tests for months would feel the same as only dealing with
APIs. It becomes mechanical without there being problem solving
involved.

Personally I find the tests to be the fun part of my work… where
most of the problem solving is being done, and the implementation to
be boring!

Maybe it’s because I write tests before code, and also write tests to
corner problems before attempting to fix bugs. Or maybe I just <3
testing :slight_smile:

9

On Mar 26, 9:44 am, James Edward G. II [email protected]
wrote:

How do we know what he would find boring?

Call me odd, but writing tests is fun for me.

Ok, you’re odd. :wink:

Dan

10

On 3/26/07, James Edward G. II [email protected] wrote:

well enough, implementation is just a detail.
Right. For example, I’ve got this ostruct based class in Ruport that
I wanted to make act like HashWithIndifferentAccess.

So i went ahead and wrote this:

def test_options_act_like_indifferent_hash
opts = Ruport::Renderer::Options.new
opts.foo = “bar”
assert_equal “bar”, opts[:foo]
assert_equal “bar”, opts[“foo”]

 opts["f"] = "bar"
 assert_equal "bar", opts[:f]
 assert_equal "bar", opts.f
 assert_equal "bar", opts["f"]

 opts[:apple] = "banana"
 assert_equal "banana", opts.apple
 assert_equal "banana", opts["apple"]
 assert_equal "banana", opts[:apple]

end

Just like a good math problem, once you get the details well defined
and sorted out, the implementation is just route manual labor. :slight_smile:

module Ruport
class Renderer::Options < OpenStruct
def
send(key)
end
def []=(key,value)
send(“#{key}=”,value)
end
end
end

I initially forgot about the []=, and my tests told me right away! :slight_smile:

So if you look at most of my math, it’s like my code. I set
everything up the way I want it to work, which if you take that
approach, is almost all the effort. Then i just fill in the missing
pieces.

11

“Gregory B.” [email protected] writes:

def test_options_act_like_indifferent_hash
opts = Ruport::Renderer::Options.new
opts[:send] = “know thy definition set”
end

12

On Mar 26, 2007, at 12:48 PM, SonOfLilit wrote:

Really? This is interesting. Very much so.

Could you show a few of these tests that are really problem solving by
themselves?

I think Greg just meant that with TDD, you tend to do more of your
thinking on the test writing side. Once you have the test framed
well enough, implementation is just a detail.

James Edward G. II

13

On 3/27/07, Christian N. [email protected] wrote:

“Gregory B.” [email protected] writes:

def test_options_act_like_indifferent_hash
opts = Ruport::Renderer::Options.new
opts[:send] = “know thy definition set”
end

Interesting edge case.

I’m trying to decide if I care enough about it.
How evil is it to access OpenStruct’s @table hash?

If not so evil…
i could just delegate to it.

If evil…
should rethink this, or maybe at least raise errors.

14

“Gregory B.” [email protected] writes:

On 3/27/07, Christian N. [email protected] wrote:

“Gregory B.” [email protected] writes:

def test_options_act_like_indifferent_hash
opts = Ruport::Renderer::Options.new
opts[:send] = “know thy definition set”
end

Interesting edge case.

Also opts[“I don’t like \0-bytes”] = “meh”;
(at least pre-1.9).