Some Float values don't survive Marshal round-trip

RubyFloat.marshalDump is missing logic which MRI has. This is not too tough and you solve two bugs for the price on one (also resolve JRUBY-4335).

Patch for the fix

This was easy as the Pattern had to be modified. I will add a few specs/tests later this day.
JRUBY-4335 could be fixed with this, too.

Hi Michael, thanks for looking into this. But why 100? (in the patch).

For example, now Marshal.load(Marshal.dump(3.7e+31)) does work, but Marshal.load(Marshal.dump(3.7e+99)) returns 37.0.

P.S. Additional specs/tests are always appreciated! The best way is to add them to RubySpecs:
http://rubyspec.org/ (repository is at http://github.com/rubyspec/rubyspec )

Attaching the patch with specs here would be OK as well.

Argh. I tested it with everything else but with 99.
In MRI there is the pattern "%.*g" and in JRuby it was "%.32g" so I guessed it would help to make a 100.

I'll dig in it again and provide clear specs and a patch.

Thanks for testing this with 99.

Changed "%.32g" to "%.9999g".
Now the Tests from JRUBY-4335 all work. And all Double-Values up to Infinity work.
Will add Specs to rubyspec.

Thanks! The new patch does cover all the possible values (since the max float is up to 10e+308). The only concern for me is that this is very inefficient. Compare, for example:

MRI:

Marshal.dump(3.7e+304)
=> "\004\bf\0203.7e+304\000\004\314"

JRuby:

Marshal.dump(3.7e+304)
=> "\004\bf\0021\0013700000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000"

Still, inefficient is much better than totally wrong!

I tried the rubyspec and there are a minimum of three other marshal.load/dump problems.
I suggest to not open more issues and I try to get the failing specs to run correctly.
After this I add my other specs for handling float objects to rubyspec.

OK?

I think after the fixes from Ola we could close this one and JRUBY-4335.

It is premature to close this ticket (or JRUBY-4335). Even after Ola's commits, plenty of cases shown in JRUBY-4335 fail.

For example:

surfboard:~$ jruby --1.9 -v -e 'a=1.62333431327361442e+31; p d=Marshal.dump(a); p Marshal.load(d)'
jruby 1.5.0.dev (ruby 1.9.2dev trunk 24787) (2010-01-11 1d3e1ad) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_17) [x86_64-java]
"\x04\bf\x1616233343132736143"
1.62333431327361e+16
surfboard:~$ ruby1.9 -v -e 'a=1.62333431327361442e+31; p d=Marshal.dump(a); p Marshal.load(d)'
ruby 1.9.2dev (2010-01-11 trunk 26246) [x86_64-darwin10.2.0]
"\x04\bf\x1E1.6233343132736143e+31\x00\x18F"
1.6233343132736143e+31

The bug was reported against RUby 1.8.7, so I only tested and fixed it regarding this env.
But you're absolutely right to test it also with 1.9, so I'll dig a bit deeper into it.

EDIT: When I run your spec I get definitely the same results with JRuby 1.8.7 and 1.9.2 and with MRI

... well this is embarrassing; It seems I've broken JRuby

Commit 157d2eeb5a6df0f6dcaba19bf276900291a1a610 (related to http://jira.codehaus.org/browse/JRUBY-3357) introduced this bug.

I'll try to make a patch to fix this. Sorry!

Proposed fix

Or perhaps using org.jruby.util.Sprintf would be a better idea, since it handles %g formatting properly

John: If you're still out there, would you be interested in modifying your patch to just use Sprintf? I agree that seems like the better path, rather than introducing another piece of one-off logic...

John pointed me in the right direction, and I fixed this by just calling into our Sprintf logic. It's passing all provided cases now, and I included a modified version of his test from JRUBY-4335 as part of the commit.

commit ab3899a959209725904845a101d703a244b25279
Author: Charles Oliver Nutter <headius@headius.com>
Date: Tue Dec 28 16:04:38 2010 -0600

Fix marshalled Float format to match Ruby. JRUBY-4334 and JRUBY-4335.