RubyRange.java seems like it is where a @JRubyMethod for this should be made. Enumerable size in 2.0+ appears to be a funcall to a size method if it is available or nil.

Ok cool, thanks @enebo ! I'll take a stab at Range#size tonight. I'll give Enumerable some thought but it might be a little too in depth for me.

Hey @tedpennings, hopefully I'm not chiming in too late, but there's been a couple of recent changes that should help you fix this up:

• Implement Numeric#step.size #1281 added Numeric#intervalStepSize which you'll want to call in your Range#size (similar to how it's implemented in MRI)
• 2.0 Enumerator#size compatibility enhancements #1039 added RubyEnumerator#enumeratorizeWithSize which you'll be able to use in Range#each instead of enumeratorize to fix the enum cases you note above

Then you'll be able to delete exclude :test_size, "needs investigation" from test/mri/excludes/TestRange.rb to get the tests for this in test/mri/ruby/test_range.rb running in CI.

Hope that helps! Let me know if you have any questions...

Thanks @dmarcotte ! I'm going to take a crack at this now. I'll update this issue once I've got something to show 😄

How do the above two commits look? Is there anything that should be done in there to ensure that the @JRubyMethod is only available in 2.0+ mode? (1.9 doesn't have a Range#size method)

I'll take another look at the Range#step and Range#each enumerator size problem tomorrow. I think that's a bit bigger. It might be worth a separate issue. I can create it if that would help.

Looking good @tedpennings! A few notes:

• this should be checking instanceof RubyNumeric rather than instanceof RubyInteger
• test_size won't pass until Range#each.size is fixed, so we should fix it here. You should be able replace enumeratorize(runtime, this, "each"); with enumeratorizeWithSize(context, this, "each", size(context)); to get this going (let me know if I'm missing something here!)
• can you also rebase again from master when you make these changes? The tests happened to be in bad shape the last time you rebased, so Travis can't currently run on your changes

As for 2.0 vs. 1.9: the next major version of JRuby (the version being worked on in master) will only support a single Ruby version, so what you've got here is correct.

Finally, good call on step.size. That needs to be taken care of too, but it should be tackled separately, so yeah sending an issue for that would be great.

Hope that all makes sense! Thanks again, and feel free to let me know if you have more questions.

Ok @dmarcotte - I'll rebase when I get home.

You're right re RubyNumeric instead of RubyInteger. I was thinking of the (quirky) MRI 2.0 behavior where it will return a size for a range of floats, and an Enumerable with size for each/step, but it won't return an array for them.

2.0.0p247 :003 > (1.5..5.5).size
 => 5 
2.0.0p247 :004 > (1.5...5.5).size
 => 4 
2.0.0p247 :005 > (1.5...5.5).each
 => #<Enumerator: 1.5...5.5:each> 
2.0.0p247 :006 > (1.5...5.5).each.size
 => 4 
2.0.0p247 :007 > (1.5...5.5).step
 => #<Enumerator: 1.5...5.5:step> 
2.0.0p247 :008 > (1.5...5.5).step.size
 => 4 
2.0.0p247 :009 > (1.5...5.5).to_a
TypeError: can't iterate from Float
    from (irb):9:in `each'
    from (irb):9:in `to_a'
    from (irb):9
    from /Users/ted/.rvm/rubies/ruby-2.0.0-p247/bin/irb:13:in `<main>'

Last night another test case came to mind that I think we need to consider. RubyNumeric/intervalStepSize doesn't handle RubyBignum. For a range size, that's actually a significant limitation, so RubyNumeric.intervalStepSize might need refactoring.

Here's the error you get with my present PR from Bignums:

 $ bin/jruby -S irb
irb(main):001:0> a=2**64
=> 18446744073709551616
irb(main):002:0> b=a**2 # 2^128
=> 340282366920938463463374607431768211456
irb(main):003:0> c=b**2  # 2^256
=> 115792089237316195423570985008687907853269984665640564039457584007913129639936
irb(main):004:0> c.class
=> Bignum
irb(main):005:0> (b..c)
=> 340282366920938463463374607431768211456..115792089237316195423570985008687907853269984665640564039457584007913129639936
irb(main):006:0> (b..c).size
Java::JavaLang::ClassCastException: org.jruby.RubyBignum cannot be cast to org.jruby.RubyFixnum
    from org.jruby.RubyNumeric.intervalStepSize(RubyNumeric.java:917)
    from org.jruby.RubyRange.size(RubyRange.java:676)
    from org.jruby.RubyRange$INVOKER$i$0$0$size.call(RubyRange$INVOKER$i$0$0$size.gen)
    from org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:306)
    from org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:136)
    from org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:60)
    from org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
    from org.jruby.ast.RootNode.interpret(RootNode.java:129)
    from org.jruby.evaluator.ASTInterpreter.INTERPRET_EVAL(ASTInterpreter.java:95)
    from org.jruby.evaluator.ASTInterpreter.evalWithBinding(ASTInterpreter.java:179)
    from org.jruby.RubyKernel.evalCommon(RubyKernel.java:934)
    from org.jruby.RubyKernel.eval19(RubyKernel.java:898)
    from org.jruby.RubyKernel$INVOKER$s$0$3$eval19.call(RubyKernel$INVOKER$s$0$3$eval19.gen)
    from org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:180)
    from org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:70)
    from org.jruby.ast.FCallManyArgsNode.interpret(FCallManyArgsNode.java:60)
... 126 levels...
    from Users.n0173592.Developer.jruby.bin.jirb.load(/Users/n0173592/Developer/jruby/bin/jirb)
    from org.jruby.Ruby.runScript(Ruby.java:809)
    from org.jruby.Ruby.runScript(Ruby.java:802)
    from org.jruby.Ruby.runNormally(Ruby.java:671)
    from org.jruby.Ruby.runFromMain(Ruby.java:520)
    from org.jruby.Main.doRunFromMain(Main.java:395)
    from org.jruby.Main.internalRun(Main.java:290)
    from org.jruby.Main.run(Main.java:217)
    from org.jruby.Main.main(Main.java:197)
    from sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    from sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    from sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    from java.lang.reflect.Method.invoke(Method.java:606)
    from org.flatland.drip.Main.invoke(Main.java:117)
    from org.flatland.drip.Main.start(Main.java:88)
    from org.flatland.drip.Main.main(Main.java:64)irb(main):007:0> 

Great catch on the class cast error @tedpennings! I'll get that fixed up very soon; I reckon you don't need to worry about it for your PR.

Hm I think I failed at git :( I'll create a new PR for this one change and you can close this as unmerged.

For future reference, how would I rebase to make this work but not have a million commits in this PR?

Hrm... looks like you were working on master in your fork, so I think when you rebased it and force-pushed, the commits you pulled in are now in a strict sense "different" from the ones already in jruby/master.

You should be able to avoid this by always working on a branch in your fork, and keeping its master up to date from jruby/master with git pull upstream master (this assumes you called your jruby remote "upsteam", i.e. you've done git remote add upstream git@github.com:jruby/jruby.git)

Note that since the rebase monkeyed with your master's history, to get back to a good state, the easiest thing may be to re-fork and apply your changes in a branch there.

Hope that solves it for you... as always, more questions are welcome.

Thanks, doing that now. I'll create a new PR once it's done.

I think I'm going to add some rspec tests for different strange range conditions too, just so we have our bases covered re integer overflows and casts, e.g., (Fixnum..Bignum).size #=> Fixnum; (Fixnum..Bignum).size #=> Bignum; (Bignum..Bignum).size #=> Fixnum, etc

Sounds good.

The specs sound great too, but I'd say they should be sent to RubySpec rather than be added here, so you should be good to go with the PR as-is.

Let me know if you need anything else!

(Oh, and let me know if it'll be a while before you can send for whatever reason. No worries if that's the case! It's just that I'm putting off sending a change that would conflict with yours to avoid causing you churn, but I don't want to sit on it too long.)

Ok all set, see #1305 . Thanks for all the help!