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 Nair <[EMAIL PROTECTED]> wrote: > 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 Darwin <[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 > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Young > Sent: Wednesday,14 May 14, 2008 11:44 > To: [email protected] > Subject: Re: [Ironruby-core] changes to extname_spec.rb > > Unnikrishnan Nair wrote: > > One more spec change. Could you please review line 8 of this spec, it > > should read > > > > File.extname(".bashrc").should == ".bashrc" > > > > instead of > > > > File.extname(".bashrc").should == "" > Quick question: are the specs supposed to ensure that IronRuby matches > MRI's behaviour, or just that it's internally consistent? I get this in > MRI's IRB: > > irb(main):001:0> File.extname(".bashrc") > => "" > > Also in YARV: > > irb(main):002:0> File.extname(".bashrc") > => "" > > -- > Alex > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
