- GzipReadline.gets now properly uses the separator param. The impl is slow (character by character InputStream.read calls), but it works.
I'll be committing shortly.
On 3/26/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
Agreed on all points. The two hacks for IO=== and rescue returning the exception are, I believe easy enough fixes. The latter is an interpreter issue, so I'll tackle that, and I think the IO=== thing is just a matter of findign an appropriate way to define it. Once I have those modified and test cases written I'll commit the rest.
Another option for fileutils might be to include "mswin" in the platform string. I'm not fond of that approach though. My only concern including fileutils directly is that we'll miss future changes (or we'll have to start monitoring changelogs for C ruby much more closely). Of course, we could take a StringIO approach and simply implement our own FileUtils that doesn't make use of things Java cannot support. There's a few ways we could go.On 3/26/06, Thomas E Enebo < [EMAIL PROTECTED]> wrote: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 <[1]headius@headius.com> 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--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
