Re: A sketch for a summer of code application.

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 :P

Aur


On 3/19/07, Pedro Del Gallego <[e-mail]> 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.
>
> ------------------------------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------------------------------
>
>  == 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 Matsumoto (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 http://ruby-doc.org/core.
>
> 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 ===
>
>  0) Before start the projects. Improve my skills reading the rspec
> mailing list. Read specs code form  open source projects that already
> use rspec.
>
>  1) 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 Gallego
>
> Email              :   [e-mail]
>
>