Diff of ProjectPlan.wiki r20 - rubyspecs - Project Hosting on Google Code

Changes to /wiki/ProjectPlan.wiki

r19 vs. r20 Edit

‹r19 r20 r30›

Revision r20

Go to:

Project members, sign in to write a code review

/wiki/ProjectPlan.wiki r19

/wiki/ProjectPlan.wiki r20

#summary RubySpecs Project Plan

#labels Featured,Phase-Requirements,Phase-Design

This project is about writing an executable Ruby specification using [http://rspec.rubyforge.org/ RSpec].

It will be based on [http://rubini.us/ Rubinius]' specs and infrastructure.

The [http://jruby.codehaus.org/ JRuby] team has offered to clean up their tests and contribute them to the general [http://www.ruby-lang.org/ Ruby community] by releasing them as a part of the [http://rubyforge.org/projects/rubytests/ RubyTests project].

The project can be split into the following parts:

*Infrastructure ([FlorianGross Florian Gross])*

The infrastructure from Rubinius should provide a fairly good base. It already provides support for a critical thing: Testing an inferior (target) Ruby implementation that cannot yet run RSpec by using a superior (host) Ruby to control the specifications. Currently, this is implemented by wrapping the code to run on the target Ruby with the `sample {}` method. (Later, it might make sense to add heuristics to automatically recognize the code for the target.)

The host/target system of Rubinius already has backends for Rubinius itself and [http://www.ruby-lang.org/ MRI]. I'd like to add support for JRuby, [http://www.atdot.net/yarv/ Ruby 1.9] and other implementations.

Charles O. Nutter of the JRuby project has expressed that having a mini RSpec implementation might be a good idea so that new implementations could be independent of other (more complete) Ruby implementations at an earlier stage.

Proprietary features of implementations could be included in sub folders. If done so, they should be disabled by default for all the other implementations.

We'll also need to deal with changes in 1.9. I think it is a good idea to keep additional specs for those in sub folders as well. When those features have become part of an official release we will merge them with the main files.

In general, everything that is changed because of a new Ruby version should be annotated with the version and what was changed in detail.

*Core language specs ([FlorianGross Florian Gross])*

This is the specification of core language concepts and syntax. The target would only need to support `puts()` to be able to run the specs. Of course, it will need to implement more to actually pass them, but it shouldn't need to support `Object#inspect` or `Marshal.dump` to pass the test for conditional statements.

I'd like to base the order of the specs on the language introductions available at [http://www.ruby-doc.org/ ruby-doc.org]. Ideally, these would allow to develop a Ruby compiler / interpreter spec-first.

There is some parts of Ruby where there is quite a bit of controversity if they are an implementation detail or part of the defined API. This will need to be sorted out.

This might also include specificating [http://www.atdot.net/yarv/ YARV]'s byte code. This is not too important yet, but in the future I think there might be interest in directly executing byte code.

*[Coreruntime Core Runtime librabry ]*

This is the specification are for thoses classes that support the OOP in Ruby. The most important ones should be specified first.

*[Corelibrary Core library specs] ([PedroDelGallego Pedro Del Gallego])*

This is the specification of all classes, modules, objects and methods that Ruby provides by default. The most important ones should be specified first.

These specs can use the `Object#inspect` (and `Marshal.dump`?) functionality offered by the host/target infrastructure so they remain concise.

*[Standardlibrary Standard library specs]*

Specifications for everything that ships with Ruby, but is not loaded by default.

For things that are already well specified elsewhere (for example [http://www.yaml.org/ YAML]) it would be OK to only specify the Ruby API.

|| ||

We'll try to concentrate on core infrastructure, the core language specs and the core library specs. Florian will primarily focus on language specs and Pedro on library specs, but that shouldn't be seen as a strict separation. We'll try to make these as complete and detailed as possible.

In general we will try to completely specificate one aspect before moving on to the next one. This is to avoid a shallow and fragmented specification. It's better to have a focused and detailed one.

	/wiki/ProjectPlan.wiki r19		/wiki/ProjectPlan.wiki r20

1	#summary RubySpecs Project Plan	1	#summary RubySpecs Project Plan
2	#labels Featured,Phase-Requirements,Phase-Design	2	#labels Featured,Phase-Requirements,Phase-Design
3		3
4	This project is about writing an executable Ruby specification using [http://rspec.rubyforge.org/ RSpec].	4	This project is about writing an executable Ruby specification using [http://rspec.rubyforge.org/ RSpec].
5	It will be based on [http://rubini.us/ Rubinius]' specs and infrastructure.	5	It will be based on [http://rubini.us/ Rubinius]' specs and infrastructure.
6		6
7	The [http://jruby.codehaus.org/ JRuby] team has offered to clean up their tests and contribute them to the general [http://www.ruby-lang.org/ Ruby community] by releasing them as a part of the [http://rubyforge.org/projects/rubytests/ RubyTests project].	7	The [http://jruby.codehaus.org/ JRuby] team has offered to clean up their tests and contribute them to the general [http://www.ruby-lang.org/ Ruby community] by releasing them as a part of the [http://rubyforge.org/projects/rubytests/ RubyTests project].
8		8
9	The project can be split into the following parts:	9	The project can be split into the following parts:
10		10
11	*Infrastructure ([FlorianGross Florian Gross])*	11	*Infrastructure ([FlorianGross Florian Gross])*
12		12
13	The infrastructure from Rubinius should provide a fairly good base. It already provides support for a critical thing: Testing an inferior (target) Ruby implementation that cannot yet run RSpec by using a superior (host) Ruby to control the specifications. Currently, this is implemented by wrapping the code to run on the target Ruby with the `sample {}` method. (Later, it might make sense to add heuristics to automatically recognize the code for the target.)	13	The infrastructure from Rubinius should provide a fairly good base. It already provides support for a critical thing: Testing an inferior (target) Ruby implementation that cannot yet run RSpec by using a superior (host) Ruby to control the specifications. Currently, this is implemented by wrapping the code to run on the target Ruby with the `sample {}` method. (Later, it might make sense to add heuristics to automatically recognize the code for the target.)
14		14
15	The host/target system of Rubinius already has backends for Rubinius itself and [http://www.ruby-lang.org/ MRI]. I'd like to add support for JRuby, [http://www.atdot.net/yarv/ Ruby 1.9] and other implementations.	15	The host/target system of Rubinius already has backends for Rubinius itself and [http://www.ruby-lang.org/ MRI]. I'd like to add support for JRuby, [http://www.atdot.net/yarv/ Ruby 1.9] and other implementations.
16		16
17	Charles O. Nutter of the JRuby project has expressed that having a mini RSpec implementation might be a good idea so that new implementations could be independent of other (more complete) Ruby implementations at an earlier stage.	17	Charles O. Nutter of the JRuby project has expressed that having a mini RSpec implementation might be a good idea so that new implementations could be independent of other (more complete) Ruby implementations at an earlier stage.
18		18
19	Proprietary features of implementations could be included in sub folders. If done so, they should be disabled by default for all the other implementations.	19	Proprietary features of implementations could be included in sub folders. If done so, they should be disabled by default for all the other implementations.
20		20
21	We'll also need to deal with changes in 1.9. I think it is a good idea to keep additional specs for those in sub folders as well. When those features have become part of an official release we will merge them with the main files.	21	We'll also need to deal with changes in 1.9. I think it is a good idea to keep additional specs for those in sub folders as well. When those features have become part of an official release we will merge them with the main files.
22		22
23	In general, everything that is changed because of a new Ruby version should be annotated with the version and what was changed in detail.	23	In general, everything that is changed because of a new Ruby version should be annotated with the version and what was changed in detail.
24		24
25	*Core language specs ([FlorianGross Florian Gross])*	25	*Core language specs ([FlorianGross Florian Gross])*
26		26
27	This is the specification of core language concepts and syntax. The target would only need to support `puts()` to be able to run the specs. Of course, it will need to implement more to actually pass them, but it shouldn't need to support `Object#inspect` or `Marshal.dump` to pass the test for conditional statements.	27	This is the specification of core language concepts and syntax. The target would only need to support `puts()` to be able to run the specs. Of course, it will need to implement more to actually pass them, but it shouldn't need to support `Object#inspect` or `Marshal.dump` to pass the test for conditional statements.
28		28
29	I'd like to base the order of the specs on the language introductions available at [http://www.ruby-doc.org/ ruby-doc.org]. Ideally, these would allow to develop a Ruby compiler / interpreter spec-first.	29	I'd like to base the order of the specs on the language introductions available at [http://www.ruby-doc.org/ ruby-doc.org]. Ideally, these would allow to develop a Ruby compiler / interpreter spec-first.
30		30
31	There is some parts of Ruby where there is quite a bit of controversity if they are an implementation detail or part of the defined API. This will need to be sorted out.	31	There is some parts of Ruby where there is quite a bit of controversity if they are an implementation detail or part of the defined API. This will need to be sorted out.
32		32
33	This might also include specificating [http://www.atdot.net/yarv/ YARV]'s byte code. This is not too important yet, but in the future I think there might be interest in directly executing byte code.	33	This might also include specificating [http://www.atdot.net/yarv/ YARV]'s byte code. This is not too important yet, but in the future I think there might be interest in directly executing byte code.
34		34
35	*[Coreruntime Core Runtime librabry ]*	35	*[Coreruntime Core Runtime librabry ]*

		36
36	This is the specification are for thoses classes that support the OOP in Ruby. The most important ones should be specified first.	37	This is the specification are for thoses classes that support the OOP in Ruby. The most important ones should be specified first.
37		38
38	*[Corelibrary Core library specs] ([PedroDelGallego Pedro Del Gallego])*	39	*[Corelibrary Core library specs] ([PedroDelGallego Pedro Del Gallego])*
39		40
40	This is the specification of all classes, modules, objects and methods that Ruby provides by default. The most important ones should be specified first.	41	This is the specification of all classes, modules, objects and methods that Ruby provides by default. The most important ones should be specified first.
41		42
42	These specs can use the `Object#inspect` (and `Marshal.dump`?) functionality offered by the host/target infrastructure so they remain concise.	43	These specs can use the `Object#inspect` (and `Marshal.dump`?) functionality offered by the host/target infrastructure so they remain concise.
43		44
44	*[Standardlibrary Standard library specs]*	45	*[Standardlibrary Standard library specs]*
45		46
46	Specifications for everything that ships with Ruby, but is not loaded by default.	47	Specifications for everything that ships with Ruby, but is not loaded by default.
47		48
48	For things that are already well specified elsewhere (for example [http://www.yaml.org/ YAML]) it would be OK to only specify the Ruby API.	49	For things that are already well specified elsewhere (for example [http://www.yaml.org/ YAML]) it would be OK to only specify the Ruby API.
49		50
50	\|\| \|\|	51	\|\| \|\|
51		52
52	We'll try to concentrate on core infrastructure, the core language specs and the core library specs. Florian will primarily focus on language specs and Pedro on library specs, but that shouldn't be seen as a strict separation. We'll try to make these as complete and detailed as possible.	53	We'll try to concentrate on core infrastructure, the core language specs and the core library specs. Florian will primarily focus on language specs and Pedro on library specs, but that shouldn't be seen as a strict separation. We'll try to make these as complete and detailed as possible.
53		54
54	In general we will try to completely specificate one aspect before moving on to the next one. This is to avoid a shallow and fragmented specification. It's better to have a focused and detailed one.	55	In general we will try to completely specificate one aspect before moving on to the next one. This is to avoid a shallow and fragmented specification. It's better to have a focused and detailed one.