We are getting closer to the V1 release of IronRuby which is planned for
summer this year. The implementation has become fairly complete and
usable in a lot of scenarios.
Over the last few months, we have also improved our processes to make it
easier for the community to contribute to the project. This includes
moving the sources to GIT, pushing the sources to GIT daily from our
internal repo, adding shortcuts and scripts to make the dev environment
easy to use, having the Microsoft team work out of GIT, and finally
adding information on http://wiki.github.com/ironruby/ironruby/. Many
folks are able to build and run the tests easily.
This opens up the opportunity for more of you to contribute to IronRuby
and help make the V1 release be more complete and solid. If you have
ideas of your own, go for it by all means. If you are looking for
suggestions, I have added a few ideas at http://wiki.github.com/ironruby/ironruby/contributing. There are easy
tasks like fixing RubySpec bugs and difficult tasks like porting a C#
sample. If you are interested in any of the tasks, let us know and we
will do our best to help you get started.
Every little bit helps, so don’t worry if you are not sure how much time
you can commit, if you are not sure how hard the tasks will be, etc. I
would love to see more people signed up for tasks in the “Who is working
on what” section. There are six names there right now. Can we get to a
dozen?
I’ve been promising myself for quite a while that i’d like to get
involved in the challenge of adding an implementation of mocking and
stubbing for CLR objects to ironruby.
It’d be really cool to have something equivalent to jtestr for .net
development - mocks and stubs are one of the essential missing
ingredients. I’ve worked on a number of java projects now where all
of the tests were written in ruby (some MRI+selenium for acceptance
tests but others jtestr for unit and integration tests) - it’s a very
gentle and sensible way to introduce of ruby to ‘the enterprise’. That
and using rake (on top of msbuild) for building .net applications
which seems to be becoming increasingly popular (such as fluent
nhibernate).
Given the way interop works and how generally unfamilar I am with how
the DLR works, perhaps it’d be diving into the deepest end first and I
might drown but i’d be keen to at least do some remote pairing (skype,
vnc, gobby, whatever - i’m in melbourne, australia) with anyone who’s
interested in trying to drive out some specific tasks.
Once you get a few changes in, it will be more useful to focus on bugs
affecting specific real-world apps since that enables real, useful
scenarios. However, starting off fixing RubySpec tags is good too as a
ramp-up activity since the problems are narrowed down, and you don’t
have to debug some large app or framework.
Mark and I have spoke about this before, and really what we need is to
pick a .NET mocking framework and write a RSpec/Mocha-like wrapper
around it, as the APIs provided by Moq, NMock, etc need some
rubification. As Shri said, the DLR-itself won’t help with this. Mark,
does this make sense?
For mocking static CLR interfaces and abstract types, there is not much
the DLR can do. You need to create types on the fly which implement the
CLR interface you want to mock. I believe that is what most of the
popular mocking frameworks like NMock, Moq, RhinoMocks, etc do.
You could take a look at using Test::Unit, RSpec, Bacon, etc for
specifying the expectations, and NMock, Moq, RhinoMocks for mocking CLR
interfaces. That seems to be what jtestr is doing. Would be cool to
flush out the issues involved in using the type families of frameworks.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.