Great!  I could tell yesterday when I was playing that gems was getting 
close.  Some of these could be landed right away and others not.  My
guidelines:

1. Can it be tested in a unit test easily:
 a. Both <=> with nil fit this category
 b. String.oct
2. It is not a hack.  I think the hacks are good to show progress, but
  commenting out YAML === IO check is probably not comittable.
3. It is in something which is rough to have a unit test, but it has no
  impact on anything running in 0.8.2.  Like zlib changes.

  We could distribute fileutils.rb and make the change only in our tree.

  I would like to start getting module owners to start maintaining
JRuby-specific tweaks in the modules.  We have never asked anyone to
yet, but it would make our job a lot simpler over the long haul...I think
as JRuby gains more popularity this will happen naturally.

On Sun, 26 Mar 2006, Charles O Nutter defenestrated me:
> 
>    Rubicon looks pretty good.
> 
>    On 3/26/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
> 
>    The attached fixes make RubyGems setup.rb complete succesfully...but
>    there's a catch.
>    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 @ [2]headius.blogspot.com
>    JRuby Developer @ [3]jruby.sourceforge.net
>    Application Architect @ [4]www.ventera.com
> 
>    --
>    Charles Oliver Nutter @ [5]headius.blogspot.com
>    JRuby Developer @ [6]jruby.sourceforge.net
>    Application Architect @ [7]www.ventera.com
> 
> References
> 
>    1. mailto:[EMAIL PROTECTED]
>    2. http://headius.blogspot.com/
>    3. http://jruby.sourceforge.net/
>    4. http://www.ventera.com/
>    5. http://headius.blogspot.com/
>    6. http://jruby.sourceforge.net/
>    7. http://www.ventera.com/

-- 
+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
| Thomas E Enebo, Protagonist  | "Luck favors the prepared    |
|                              |  mind." -Louis Pasteur       |


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel

Reply via email to