[Rubygems-developers] rubygems beta time?

Eric Hodel drbrain at segment7.net
Tue Jan 9 11:39:49 EST 2007

On Jan 8, 2007, at 19:42, Jim Weirich wrote:
> Michael Studman wrote:
>> So a bit of debugging later and JRuby's Marshal is choking on the
>> Specification#hash for rwdtorrent version 0.04. In memory, this  
>> spec's
>> instance variables look like this:
>> { [...] @executables=Wed Oct 05 03:00:00 UTC 2005 [...] }
>> I also swear I saw some other weird values in a previous debug run  
>> too
>> that are no longer apparent.
> Thanks for tracking that down.  I non-array value for @executables  
> will
> cause grief when calculating default_executable.  Essentially the  
> 'size'
> method will fail.
> I've gone through the code and did a spot check for other potential
> problems, fixed one or two other places and added a few tests for
> pathologically bad values.  The problem is that *any* instance  
> variable
> might be wrong and therefore any code that messes with the instance
> variables is suspect.
> I really wish I could understand why these values are so messed up in
> the spec.  Looks like everything is hunky-dory in the yaml file.  The
> only thing I can think of is that the spec data is corrupted during  
> the
> marshal/unmarshal process.  Since this seems to be primarily a JRuby
> issue, it makes me wonder if there is a problem with JRuby  
> marshalling.

Same here.

require 'rubygems/source_info_cache'
si = Gem::SourceInfoCache.cache_data['http://gems.ource_index
p si.search(/rwdtorrent/).first.instance_variable_get(:@executables)
# => ["rwdtorrent"]

> (Question:  Is the JRuby marshall format the same as standard Ruby's?
> Do the JRuby gem and the standard gem both store their marshalled  
> cache
> files in the same place?  Are they possibly interfering with each  
> other?)

Can you gzip and post a JRuby source_cache file that's corrupt?  Or  
run the above against a JRuby source_cache with a matzruby?

Eric Hodel - drbrain at segment7.net - http://blog.segment7.net


More information about the Rubygems-developers mailing list