During the install of the sources-0.0.1.gem, two odd things seem to be happening:
- sources-0.0.1.gem is modified, and corrupted
- the files contained in the original uncorrupted gem do not appear to be written out to the correct place in the JRuby distribution
I have not started to dig into these issues yet. I believe the corrupting of the gem is probably key to both.
The fixes:
- YAML is looking for an IO to come in, but GzipReader does not === with IO. I think perhaps it's an issue with IO not ==='ing correctly. Commenting out this check allows YAML to continue. This is temporary. (credit to Tom for noticing this)
- in a "readline" method in yaml.rb, an IOError is rescued and ignored; at this point, nil should be returned, but because of a bug in the interpreter (unfixed as yet) the IOError is returned. I modified it to explicitly return nil for the moment. This is temporary.
- Zlib::ZStream#finish doesn't appear to work correctly, because the underlying @stream doesn't have a finish method. I only ran into this during some other testing, but I commented it out for now.
- A couple style and grammatical fixes in zlib.rb
- A rogue "1" in GzipReader.readchar (I'm guessing it was a typo)
- Comparable#== can also return nil if <=> returns nil (like if one of the compared objects is nil)
- Dummy implementations of File::Stat#symlink? and File::Stat#blksize, used within FileUtils for copying files
- String#oct needs to return 0 for empty strings
- Time#<=> needs to return nil if the object compared to is nil
- In Ruby source, in fileutils.rb, the following change is needed (added "java" to the list; we'll have to find a better way to do this so methods like File::Stat#dev and #ino are never called):
def fu_windows?
/mswin|mingw|bccwin|wince|emx|java/ =~ RUBY_PLATFORM
end
This last one brings up another question too...how could we set up JRuby so that we can provide our own implementations of specific core Ruby methods. If, for example, we could always just redefine fu_windows? to return true, there would be no need for a change to Ruby's own files. Food for thought...
I have not run Rubicon against these yet, and I have not created test cases for them. These fixes took quite a bit of digging, so let me know if there's any suggestions on better ways to handle them.
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
rubygems-work.patch
Description: Binary data
