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? Thanks, Shri
on 2009-04-04 00:45
on 2009-04-05 04:42
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. Mark.
on 2009-04-05 12:45
Hi Shri, I'm ready to start contributing (I signed the agreement and am now able to run the specs on my machine). I thought I'd focus on system/popen, but maybe there are simple things that have a higher priority ? cheers, -- Thibaut
on 2009-04-06 08:48
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.
on 2009-04-06 09:17
Fixing the tags for IO.popen sounds fine. 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.
on 2009-04-06 09:22
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? ~js