CR: IronRuby tests for IDMOP, and ir_wrap.cmd

tfpt review “/shelveset:iridmop;REDMOND\sborde”

Comment :
Adding unit tests for Ruby’s IDynamicMetaObjectProvider support.
Failing scenarios are tagged with AreEqualBug and
Added Languages\Ruby\Scripts\ir_wrap.cmd as the replacement for
Test\Scripts\ir.cmd which does not exist in GIT. Most of the files are
changed because of this.

DLR interop tests look good.


  •    [DebuggerHiddenAttribute]
  •    internal void AreEqualBug(object x, object y, object 

buggyResult) {

  •        AreEqual(x, buggyResult);
  •    }
  •    [DebuggerHiddenAttribute]
  •    internal void AreEqualBug<T>(Action f, object y) where T : 

Exception {

  •        AssertExceptionThrown<T>(f);
  •    }
  •    [DebuggerHiddenAttribute]
  •    internal void AssertExceptionThrownBug<T>(Action f) where T : 

Exception {

  •        f();
  •    }

At the risk of asking a dumb question: Is it expected that y doesn’t get
used in these? I’m guessing yes, but I want to a) make sure, b) suggest
a comment so that future users don’t think something is missing. Also,
the Exception doesn’t get checked in AssertExceptionThrownBug. Am I
missing something?

In ir_wrap.cmd, we shouldn’t unconditionally set HOME. We may overwrite
a custom setting, and we can probably expect that this script will be
called from a Dev.bat cmd prompt, so HOME should already be set.

Other than that, looks good.


Sounds good.


I will add comments. The code should be as shown. The reason y exists
for now is to document the expected result. However, because the IDMOP
support isn’t baked, IronRuby produces “buggyResult” today. Say 1+2 give
300 today. In that case, I have added "AreEqual(1+2, 3, 300) to document
what the result should be once the bug is fixed, and what the result is

I did wonder about HOME being set. However, I just copied the old
ir.cmd. I don’t want to change this for now to reduce the chance of
breaking something inadvertently. Once the change is in, I can look into
cleaning it up as a separate change.


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