Re: changes to extname_spec.rb

Hi Pete,

I was kind of doing what you are saying but manually though. But after
seeing the specs, I stopped doing it altogether.

I wrote down the test and display the result on the console with puts.
Now run the script with ‘ruby’ on console and redirect the output to a
file (not MRI, I need to change based on what I hear) and then run the
same code against ir and do the same. After that I run my file compare
program and see the differences.

So it is possible to automate what you are suggesting, but don’t you
think the spec was already written to cover all the cases? Wouldn’t it
be a duplicate work? Just curious…

Thanks.

----- Original Message ----
From: Peter Bacon D. [email protected]
To: [email protected]
Sent: Wednesday, May 14, 2008 6:41:43 AM
Subject: Re: [Ironruby-core] changes to extname_spec.rb

I have been working on the basis that MRI is the reference
implementation
and so the specs should reflect that. If, on writing a spec, an obvious
bug
is exposed then we should be sending this on to the RubyLang lot and
getting
them to fix it.

Otherwise if it’s good enough for MRI its good enough for me.


By the way, I had this idea of creating a small program that would help
with
regression testing against MRI. Instead of writing full RSpecs, we
should
write snippets of Ruby that work the classes. The program would then
run
the snippets against MRI and IronRuby (and any other implementation if
you
wanted) and compare the results. That way you could directly check how
similar IR was to MRI without having to fix up the specs all the time.
Also
it would be much quicker and easier to write the specs since you
wouldn’t
have to check what the correct result should be in each case.

For instance, you could have the following snippets of code for the
Fixnum#div method:

2.div(2)
1.div(2)
5.div(2)

8192.div(10)
8192.div(-10)
(-8192).div(10)
(-8192).div(-10)

1.div(0.2)
1.div(0.16)
1.div(0.169)
-1.div(50.4)
1.div(0xffffffff)

0.div(0.0)
10.div(0.0)
-10.div(0.0)
13.div(0)
(obj = Object.new).should_receive(:to_int, :count => 0, :returning 

=>
10)
13.div(obj)
5.div(“2”)

Obviously with some description mechanism and possibly some way of
specifying what should be considered in the output from Ruby: whether to
check the class and value of results returned; type and fields of
objects
passed in; if errors are raised the type and message of the error.

Anyone fancy knocking this up?
Pete

Aren’t we running (or going to be running) the official spec suite (
http://rubyspec.org) ?

These specs are already written on the assumption that MRI /is/ THE
implementation of Ruby.

On Wed, May 14, 2008 at 9:55 AM, Unnikrishnan N. [email protected]

Michael L.:

Aren’t we running (or going to be running) the official spec suite
(http://rubyspec.org) ?

We are going to be checking in the rubyspec suite later this week. I
just got the fix for the DLR tuple bug last night and I’ll push it out
later this morning. That was the major thing that was blocking us from
checking in rubyspec earlier.

Thanks,
-John

Unnikrishnan N.:

I wrote down the test and display the result on the console with puts.

A meta-level note: beware of running things via irb. Things like
FILE don’t behave the way you would expect them to because irb is a
Ruby program. If in doubt, write your code in a file and run it via
ruby.exe.

Thanks,
-John

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs