[BOUNTY] Pure Ruby Zlib::GzipWriter
Daniel Berger
There's a project out there called "zliby" [1] which partially
implements the zlib library. Unfortunately, only the Zlib::GzipReader
class has been implemented so far. I'd like to have a pure Ruby
implementation of the Zlib::GzipWriter class.
I've put in a feature request [2] but I'd like to see it expedited. In
order to expedite this, I'm offering $100 to anyone who can implement
it. In order to qualify for the bounty, your Zlib::GzipWriter class
must meet the following criteria:
* It must be pure Ruby. No extensions. No FFI.
* It must have tests (and pass them)
* It must match the current Zlib::GzipWriter interface
* It must be cross platform
* It must be able to generate a proper gem file from a gemspec (the
acid test)
* It must be contributed back to the zliby project
* It must be done within 60 days of this post
If these conditions are met, you will receive your bounty via PayPal.
What's my motivation? Mainly MS Windows. I run a hand built version of
Ruby, and getting the zlib wrapper to build with MS VC++ is such a
colossal PITA that I'd like to avoid it completely. Beyond that,
however, is that it eliminates a third party dependency (zlib) and
gives me the ability to create gems. At the moment I can only read
them.
Any takers? Any matchers?
Regards,
Dan
[1] http:/www.rubyforge.org/projects/zliby
[2] http://rubyforge.org/tracker/index.php?func=detail&aid=23239&group_id=5769&atid=22371
rogerdpack
> order to expedite this, I'm offering $100 to anyone who can implement
> it. In order to qualify for the bounty, your Zlib::GzipWriter class
> must meet the following criteria:
Would be nice to someday no longer have the dependency of rubygems on
zlib.
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a6966f6fc1424f61
Then there'd be one less setup hurdle for ruby.
I'm a watcher for now though :)
-=R
Charles Oliver Nutter
Of course you could use JRuby, which doesn't have such issues with zlib
and Windows...
- Charlie
Daniel Berger
On Dec 21, 1:08 pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> rogerdpack wrote:
> >> I've put in a feature request [2] but I'd like to see it expedited. In
> >> order to expedite this, I'm offering $100 to anyone who can implement
> >> it. In order to qualify for the bounty, your Zlib::GzipWriter class
> >> must meet the following criteria:
> > That would indeed be convenient.
> > Would be nice to someday no longer have the dependency of rubygems on
> > zlib.
> >http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a6...
> > Then there'd be one less setup hurdle for ruby.
> > I'm a watcher for now though :)
>
> Of course you could use JRuby, which doesn't have such issues with zlib
> and Windows...
I thought JRuby used FFI. No? If not, it should just be matter of
porting the code. But if so, you still have two third party
dependencies - FFI and zlib.dll.
Regards,
Dan
Charles Oliver Nutter
> I thought JRuby used FFI. No? If not, it should just be matter of
> porting the code. But if so, you still have two third party
> dependencies - FFI and zlib.dll.
The JVM includes zlib and obviously has a very nice version for Windows.
We just wrap the JVM's zlib-based compression classes. But that doesn't
really solve your original problem since you want to run a handbuilt C
Ruby...
- Charlie
The Higgs bozo
>
> What's my motivation? Mainly MS Windows. I run a hand built version of
> Ruby, and getting the zlib wrapper to build with MS VC++ is such a
> colossal PITA that I'd like to avoid it completely. Beyond that,
> however, is that it eliminates a third party dependency (zlib) and
> gives me the ability to create gems. At the moment I can only read
> them.
As a cheap shortcut, could you store a base64-encoded zlib dll in a .rb
file, decode it, then call it with DL or FFI?
--
Posted via http://www.ruby-forum.com/.
Daniel Berger
I'm not really sure how to do that, and it's not really what I'm
looking for I'm afraid.
Regards,
Dan
The Higgs bozo
You didn't know how, or didn't understand? DL is part of the standard
library. You could carry around the zlib dll right inside an .rb file,
and use DL to call the zlib function(s) you needed.
I understand you were looking for a general-purpose solution, but in the
meantime this does what you need, albeit gymnastically. Namely, zlib on
Windows without the requirement of building a ruby extension.
Daniel Berger
On Dec 21, 10:59 pm, The Higgs bozo <higgs.b...@gmail.com> wrote:
> Daniel Berger wrote:
> > On Dec 21, 5:16 pm, The Higgs bozo <higgs.b...@gmail.com> wrote:
> >> file, decode it, then call it with DL or FFI?
> > I'm not really sure how to do that, and it's not really what I'm
> > looking for I'm afraid.
>
> You didn't know how, or didn't understand? DL is part of the standard
> library. You could carry around the zlib dll right inside an .rb file,
> and use DL to call the zlib function(s) you needed.
Just to clarify for purposes of the bounty, no DL, and no distributed
dll's.
> I understand you were looking for a general-purpose solution, but in the
> meantime this does what you need, albeit gymnastically. Namely, zlib on
> Windows without the requirement of building a ruby extension.
I really do appreciate the suggestion but it's not what I'm looking
for.
Regards,
Dan
Joel VanderWerf
> library. You could carry around the zlib dll right inside an .rb file,
> and use DL to call the zlib function(s) you needed.
Out of curiosity, how do you suggest doing this? Put the dll in the DATA
section, write to a tmp file, and load? Or is there some magic?
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Roger Pack
> Ruby, and getting the zlib wrapper to build with MS VC++ is such a
> colossal PITA that I'd like to avoid it completely. Beyond that,
> however, is that it eliminates a third party dependency (zlib) and
> gives me the ability to create gems. At the moment I can only read
> them.
One thing I use to help me compile on doze is Lavena's rubyinstaller
[I'm sure you've seen it..].
Anyway I'll match $50 :)
-=r
Daniel Berger
Excellent Roger, thank you.
By the way, MS Windows is not the only reason removing the external
dependency on zlib would be a good thing:
http://rubyforge.org/tracker/index.php?func=detail&aid=23354&group_id=126&atid=575
Regards,
Dan
Daniel Berger
Yet more ammunition:
http://www.misuse.org/science/2007/09/07/ruby-zlib-buffer-error-on-windows/
Regards,
Dan
Roger Pack
> Yet more ammunition:
>
> http://www.misuse.org/science/2007/09/07/ruby-zlib-buffer-error-on-windows/
Interesting. I wonder if it's somehow related to
http://redmine.ruby-lang.org/issues/show/776
Daniel Berger
On Jan 3, 8:21 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> > Yet more ammunition:
>
> >http://www.misuse.org/science/2007/09/07/ruby-zlib-buffer-error-on-wi...
>
> Interesting. I wonder if it's somehow related to http://redmine.ruby-lang.org/issues/show/776
It probably is, but there's nothing we can do about it since zlib
isn't developed separately as a gem, and it would still require that
someone build a binary.
If we had a pure Ruby version available as a gem on the other hand...
:)
Regards,
Dan
Charles L.
> If we had a pure Ruby version available as a gem on the other hand...
>
> :)
>
> Regards,
>
> Dan
I'm most of the way done, just missing dynamic huffman trees, and more
interface similarity with zlib. Need to change the specs from zliby
though as the algorithm I'm using is not identical to zlib and gives
different (but still valid) results.
For example, zlib's lz77 phase doesn't seem to behave optimally wrt
repeats:
>> Zlib::Deflate.deflate(0.chr * 10, 9).length
=> 10
>> CZlib::Deflate.deflate(0.chr * 10, 9).length
=> 11
>> CZlib::Inflate.inflate(Zlib::Deflate.deflate(0.chr * 10, 9)) == 0.chr * 10
=> true
>> CZlib::Inflate.inflate(CZlib::Deflate.deflate(0.chr * 10, 9)) == 0.chr * 10
=> true
(using CZlib for inflation there as I've not integrated it with the
zliby code yet).
Heesob Park
2009/1/6 Daniel Berger <djbe...@gmail.com>:
>
> If we had a pure Ruby version available as a gem on the other hand...
>
> :)
>
I finished translation and testing of the pure ruby version.
The ruby version is exact same api interface and functionality with
the zlib c source code.
It is also compatible with ruby 1.8.x and 1.9.x and includes
examble.rb and minizip.rb for testing.
You can download at http://121.78.227.9/rbzlib/
I am working on translation of ruby library zlib.c to pure ruby code.
Regards,
Park Heesob
Daniel Berger
> Hi,
>
> 2009/1/6 Daniel Berger <djbe...@gmail.com>:
>> If we had a pure Ruby version available as a gem on the other hand...
>>
>> :)
>>
> I finished translation and testing of the pure ruby version.
> The ruby version is exact same api interface and functionality with
> the zlib c source code.
> It is also compatible with ruby 1.8.x and 1.9.x and includes
> examble.rb and minizip.rb for testing.
>
> You can download at http://121.78.227.9/rbzlib/
Awesome!
> I am working on translation of ruby library zlib.c to pure ruby code.
Looks like you and Charles L. are in a race. :)
Regards,
Dan
Daniel Berger
Sounds like you're on track. But, you're in a race with Park Heesob. :)
Dan
Charles L.
>
> Sounds like you're on track. But, you're in a race with Park Heesob. :)
>
> Dan
Heh. :) Somehow I think he's got it covered. That reimplementation of
zlib in ruby is actually pretty cool. I'm curious Park, as to how much
you did by hand and how much you were able to automate it...?
I've put the deflate code i wrote on pastie - http://pastie.org/355367
It's about 600 lines, but needs cleaning up. Will probably be ~500 when
I've added in dynamic trees and cleaned it up a bit.
Prelim benchmarks show the current bottleneck to be the LZ77
implementation which is interesting. I think for it to perform
acceptably, a lot more of the code needs to become more idiomatic,
higher-level ruby.
Roger Pack
>> I am working on translation of ruby library zlib.c to pure ruby code.
>
> Looks like you and Charles L. are in a race. :)
Maybe you can collaborate? :)
Let us know when somebody think it's about done :)
Heesob Park
2009/1/8 Charles L. <aqua...@gmail.com>:
> Daniel Berger wrote:
>>
>> Sounds like you're on track. But, you're in a race with Park Heesob. :)
>>
>> Dan
>
> Heh. :) Somehow I think he's got it covered. That reimplementation of
> zlib in ruby is actually pretty cool. I'm curious Park, as to how much
> you did by hand and how much you were able to automate it...?
>
I dit it all by hand. There is no royal road to translating C to Ruby:)
> I've put the deflate code i wrote on pastie - http://pastie.org/355367
>
> It's about 600 lines, but needs cleaning up. Will probably be ~500 when
> I've added in dynamic trees and cleaned it up a bit.
>
> Prelim benchmarks show the current bottleneck to be the LZ77
> implementation which is interesting. I think for it to perform
> acceptably, a lot more of the code needs to become more idiomatic,
> higher-level ruby.
In my test, the deflation is very slow but the inflation is endurable.
Moreover, for the compatibility of the various Ruby version, It shows
bad performance in Ruby 1.8.x.
Regards,
Park Heesob
Daniel Berger
On Jan 7, 11:08 pm, "Heesob Park" <pha...@gmail.com> wrote:
> Hi,
>
> 2009/1/8 Charles L. <aquas...@gmail.com>:> Daniel Berger wrote:
>
> >> Sounds like you're on track. But, you're in a race with Park Heesob. :)
>
> >> Dan
>
> > Heh. :) Somehow I think he's got it covered. That reimplementation of
> > zlib in ruby is actually pretty cool. I'm curious Park, as to how much
> > you did by hand and how much you were able to automate it...?
>
> I dit it all by hand. There is no royal road to translating C to Ruby:)
>
> > I've put the deflate code i wrote on pastie -http://pastie.org/355367
Excellent, thanks!
> > It's about 600 lines, but needs cleaning up. Will probably be ~500 when
> > I've added in dynamic trees and cleaned it up a bit.
>
> > Prelim benchmarks show the current bottleneck to be the LZ77
> > implementation which is interesting. I think for it to perform
> > acceptably, a lot more of the code needs to become more idiomatic,
> > higher-level ruby.
>
> In my test, the deflation is very slow but the inflation is endurable.
> Moreover, for the compatibility of the various Ruby version, It shows
> bad performance in Ruby 1.8.x.
As long as it's usable I'm happy. We can benchmark, profile and
optimize later. :)
regards,
Dan
Charles L.
>
> Maybe you can collaborate? :)
> Let us know when somebody think it's about done :)
>
> -=r
I'm not sure there's much room for collaboration at the Zlib wrapper &
below level, but perhaps the GzipFile and upwards (ie Reader/Writer)
implementations can be shared.
The big thing is just good specs, and the existing rubyspec ones could
use some work which will benefit all of us.
I've added most of the remaining missing functionality to my version (ie
dynamic huffman tree's etc), and added back in the inflate functionality
from zliby, and put the result up on github -
http://github.com/aquasync/ruby-zlib/tree/master
I've since added enough of the GzipWriter & GzipFile functionality that
the existing specs all pass (see below. note the GzipFile specs use
GzipWriter). Unable to push this last commit to github presently, but
will try later.
It is likely complete enough for the purposes of creating rubygems, but
is still missing functionality, which needs specing out (Eg wtf is
Zlib::GzipWriter.wrap, Zlib::GzipWriter reimplements a lot of IO
functions like puts, etc).
Zlib::Deflate#set_dictionary
- sets the dictionary
Zlib::Deflate#deflate
- deflates some data
Zlib::Deflate::deflate
- deflates some data
Zlib::GzipFile#closed?
- returns the closed status
Zlib::GzipFile#close
- finishes the stream and closes the io
Zlib::GzipFile#comment
- returns the name
- raises an error on a closed stream
Zlib::GzipFile#orig_name
- returns the name
- raises an error on a closed stream
Zlib::GzipWriter#mtime=
- sets mtime using Integer
- sets mtime using Time
- raises if the header was written
GzipWriter#write
- writes some compressed data
Heesob Park
You can download at http://121.78.227.9/rbzlib/pzlib.rb
Regards,
Park Heesob
Daniel Berger
> Roger Pack wrote:
>
> > Maybe you can collaborate? :)
> > Let us know when somebody think it's about done :)
>
> > -=r
>
> I'm not sure there's much room for collaboration at the Zlib wrapper &
> below level, but perhaps the GzipFile and upwards (ie Reader/Writer)
> implementations can be shared.
>
> The big thing is just good specs, and the existing rubyspec ones could
> use some work which will benefit all of us.
Agreed.
> I've added most of the remaining missing functionality to my version (ie
> dynamic huffman tree's etc), and added back in the inflate functionality
> from zliby, and put the result up on github -http://github.com/aquasync/ruby-zlib/tree/master
Thanks. Unfortunately, I cannot download it. IE7 and FF3 simply do
nothing when I click on the download link. FF2 (before I upgraded)
gave me a "file not found" error.
This actually happens to me a lot with github, on not just on Windows.
> I've since added enough of the GzipWriter & GzipFile functionality that
> the existing specs all pass (see below. note the GzipFile specs use
> GzipWriter). Unable to push this last commit to github presently, but
> will try later.
Ok, I'll look for it and just copy/paste files individually when
you're ready.
Regards,
Dan
Daniel Berger
On Jan 8, 8:23 pm, "Heesob Park" <pha...@gmail.com> wrote:
> 2009/1/8 Daniel Berger <djber...@gmail.com>:
>
> > On Jan 7, 11:08 pm, "Heesob Park" <pha...@gmail.com> wrote:
> >> Hi,
>
> >> 2009/1/8 Charles L. <aquas...@gmail.com>:> Daniel Berger wrote:
>
> >> >> Sounds like you're on track. But, you're in a race with Park Heesob :)
>
> >> >> Dan
>
> >> > Heh. :) Somehow I think he's got it covered. That reimplementation of
> >> > zlib in ruby is actually pretty cool. I'm curious Park, as to how much
> >> > you did by hand and how much you were able to automate it...?
>
> >> I dit it all by hand. There is no royal road to translating C to Ruby:)
>
> >> > I've put the deflate code i wrote on pastie -http://pastie.org/355367
>
> > Excellent, thanks!
>
> >> > It's about 600 lines, but needs cleaning up. Will probably be ~500 when
> >> > I've added in dynamic trees and cleaned it up a bit.
>
> >> > Prelim benchmarks show the current bottleneck to be the LZ77
> >> > implementation which is interesting. I think for it to perform
> >> > acceptably, a lot more of the code needs to become more idiomatic,
> >> > higher-level ruby.
>
> >> In my test, the deflation is very slow but the inflation is endurable.
> >> Moreover, for the compatibility of the various Ruby version, It shows
> >> bad performance in Ruby 1.8.x.
>
> > As long as it's usable I'm happy. We can benchmark, profile and
> > optimize later. :)
>
> Finally I translated the whole zlib.c to ruby code.
> You can download athttp://121.78.227.9/rbzlib/pzlib.rb
Looks very promising but doesn't quite work yet:
C:\>gem install ptools
ERROR: While executing gem ... (NoMethodError)
undefined method `ZSTREAM_IS_FINISHED' for #<Zlib::GzipReader:
0x2f8e8bc>
I think you need some tests. ;)
BTW, I'm assuming this is basically a wholesale replacement of zliby?
If so, the module should be renamed from PZlib to just Zlib.
Otherwise, Rubygems will complain about the lack of a Gem::Zlib
definition.
Keep up the good work!
Regards,
Dan
Daniel Berger
On Jan 8, 6:56 pm, "Charles L." <aquas...@gmail.com> wrote:
> Roger Pack wrote:
>
> > Maybe you can collaborate? :)
> > Let us know when somebody think it's about done :)
>
> > -=r
>
> I'm not sure there's much room for collaboration at the Zlib wrapper &
> below level, but perhaps the GzipFile and upwards (ie Reader/Writer)
> implementations can be shared.
>
> The big thing is just good specs, and the existing rubyspec ones could
> use some work which will benefit all of us.
>
> I've added most of the remaining missing functionality to my version (ie
> dynamic huffman tree's etc), and added back in the inflate functionality
> from zliby, and put the result up on github -http://github.com/aquasync/ruby-zlib/tree/master
<snip>
Ok, I was able to download the project and I ran the specs:
C:\ruby\src\ruby-zlib>spec specs
............FF.......................
1)
'Zlib::Deflate#params changes the deflate parameters' FAILED
expected: "x\001\000\v\000\364\377abcdefghijk\002,'\027\000#
\364\005<",
got: "x\234KLJNIMK\317\310\314\312\316\311\005\000#
\364\005<" (using ==)
C:/ruby/src/ruby-zlib/specs/deflate/params_spec.rb:16
2)
NameError in 'Zlib::Deflate#set_dictionary sets the dictionary'
uninitialized constant Zlib::Deflate
C:/ruby/src/ruby-zlib/specs/deflate/set_dictionary_spec.rb:6
C:/ruby/src/ruby-zlib/specs/deflate/set_dictionary_spec.rb:5:in `each'
C:/ruby/src/ruby-zlib/specs/deflate/set_dictionary_spec.rb:5
Finished in 1.688 seconds
38 examples, 2 failures
Ruby 1.8.6-p114 built with VC++ 8
Windows XP Pro
RSpec 1.1.11
Regards,
Dan
Charles L.
> Ok, I was able to download the project and I ran the specs:
>
> C:\ruby\src\ruby-zlib>spec specs
>
> 1)
> 'Zlib::Deflate#params changes the deflate parameters' FAILED
> expected: "x\001\000\v\000\364\377abcdefghijk\002,'\027\000#
> \364\005<",
> got: "x\234KLJNIMK\317\310\314\312\316\311\005\000#
> \364\005<" (using ==)
> C:/ruby/src/ruby-zlib/specs/deflate/params_spec.rb:16
>
> 2)
> NameError in 'Zlib::Deflate#set_dictionary sets the dictionary'
> uninitialized constant Zlib::Deflate
> C:/ruby/src/ruby-zlib/specs/deflate/set_dictionary_spec.rb:6
> C:/ruby/src/ruby-zlib/specs/deflate/set_dictionary_spec.rb:5:in `each'
> C:/ruby/src/ruby-zlib/specs/deflate/set_dictionary_spec.rb:5
>
> Finished in 1.688 seconds
>
> 38 examples, 2 failures
>
> Ruby 1.8.6-p114 built with VC++ 8
> Windows XP Pro
> RSpec 1.1.11
>
> Regards,
>
> Dan
Yeah the github download functionality seems broken for me most of the
time also... :/
Anyway, the params failure is the only failure I get. Thats because I've
not implemented the NO_COMPRESSION mode yet, and is an easy fix. The
other error you're getting is odd, as Zlib::Deflate is defined, and if
it weren't none of the other deflate specs would have passed!
Heesob Park
2009/1/10 Daniel Berger <djbe...@gmail.com>:
> Hi,
>
> On Jan 8, 8:23 pm, "Heesob Park" <pha...@gmail.com> wrote:
>> 2009/1/8 Daniel Berger <djber...@gmail.com>:
>>
>> > On Jan 7, 11:08 pm, "Heesob Park" <pha...@gmail.com> wrote:
>> >> Hi,
>>
>> >> 2009/1/8 Charles L. <aquas...@gmail.com>:> Daniel Berger wrote:
>>
>> >> >> Sounds like you're on track. But, you're in a race with Park Heesob. :)
I fixed some typo and renamed PZlib to Zlib and pzlib.rb to zlib.rb
I succeeded "gem install ptools" with zlib.rb
You can download it at http://121.78.227.9/rbzlib/zlib.rb
Regards,
Park Heesob
Luis Lavena
The work-in-progress of One-Click Installer:
Luis@KEORE (D:\Users\Luis\projects\oss\ruby-zlib.git)
$ spec specs
.............F........................
1)
'Zlib::Deflate#params changes the deflate parameters' FAILED
expected: "x\001\000\v\000\364\377abcdefghijk\002,'\027\000#
\364\005<",
got: "x\234KLJNIMK\317\310\314\312\316\311\005\000#
\364\005<" (using ==)
D:/Users/Luis/projects/oss/ruby-zlib.git/specs/deflate/params_spec.rb:
16
Finished in 1.219 seconds
38 examples, 1 failure
Luis@KEORE (D:\Users\Luis\projects\oss\ruby-zlib.git)
$ ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]
Luis@KEORE (D:\Users\Luis\projects\oss\ruby-zlib.git)
$ spec --version
rspec 1.1.11.6
Not bad, really not bad!
Anyone knows any web application for bounties? I'm interested in
contribute to this one and also one for Readline!!!
Regards,
--
Luis Lavena
Roger Pack
> contribute to this one and also one for Readline!!!
Yeah I'm in for Readline :)
Note that highline has a getc for windows, and cmd is also readline
like, so I believe it is possible :)
-=r
As a note I get the same error message Luis does.
Heesob Park
You can download ruby18-rreadline-0.5.4.tbz at [2].
Regards,
Park Heesob
[1] http://raa.ruby-lang.org/project/ruby_readline
[2] http://www.filewatcher.com/m/ruby18-rreadline-0.5.4.tbz.13944.0.0.html
Luis Lavena
> 2009/1/10 Roger Pack <r...@doachristianturndaily.info>:>> Anyone knows any web application for bounties? I'm interested in
> >> contribute to this one and also one for Readline!!!
>
> > Yeah I'm in for Readline :)
> > Note that highline has a getc for windows, and cmd is also readline
> > like, so I believe it is possible :)
>
> > -=r
> > As a note I get the same error message Luis does.
>
> I guess you are looking for ruby_readline [1] .
>
Hello Park,
Actually I'm looking to an API-compatible replacement, which should
work with IRB and auto complete capabilities.
Not only that, but a solution that can work across platforms,
including Windows :-)
There is a solution called RawLine [1] but is not API-compliant with
ReadLine.
Thank you again for your pointer.
[1] http://rubyforge.org/projects/rawline/
--
Luis Lavena
Heesob Park
2009/1/10 Luis Lavena <luisl...@gmail.com>:
I found the pure Perl implementation of the readline libraries called
libterm-readline-perl-perl [1]
I hope some one could port it into Ruby.
If no one port it until the end of this month, I will port it.
BTW, I succeeded "gem build" as well as "gem install" with my zlib.rb
and rbzlib.rb.
You should test it with the latest zlib.rb and rbzlib.rb at [2]
[1] http://www.filewatcher.com/b/ftp/ftp.linux.it/debian/pool/main/libt/libterm-readline-perl-perl.0.0.html
[2] http://121.78.227.9/rbzlib/
Regards,
Park Heesob
Luis Lavena
>
> > On Jan 10, 8:15 am, Heesob Park <pha...@gmail.com> wrote:
> >> 2009/1/10 Roger Pack <r...@doachristianturndaily.info>:>> Anyone knows any web application for bounties? I'm interested in
> >> >> contribute to this one and also one for Readline!!!
>
> >> > Yeah I'm in for Readline :)
> >> > Note that highline has a getc for windows, and cmd is also readline
> >> > like, so I believe it is possible :)
>
> >> > -=r
> >> > As a note I get the same error message Luis does.
>
> >> I guess you are looking for ruby_readline [1] .
>
> > Hello Park,
>
> > Actually I'm looking to an API-compatible replacement, which should
> > work with IRB and auto complete capabilities.
>
> > Not only that, but a solution that can work across platforms,
> > including Windows :-)
>
> > There is a solution called RawLine [1] but is not API-compliant with
> > ReadLine.
>
> > Thank you again for your pointer.
>
> > [1]http://rubyforge.org/projects/rawline/
>
> I found the pure Perl implementation of the readline libraries called
> libterm-readline-perl-perl [1]
>
> I hope some one could port it into Ruby.
> If no one port it until the end of this month, I will port it.
Well, I don't have the time, but I can give some contribution for it,
so :-D
> BTW, I succeeded "gem build" as well as "gem install" with my zlib.rb
> and rbzlib.rb.
> You should test it with the latest zlib.rb and rbzlib.rb at [2]
>
I've run the specs of Zlib for your code:
Finished in 0.328 seconds
38 examples, 25 failures
--
Luis Lavena
Michal Suchanek
compression results.
Of course, the spec might be more high-level but then an
implementation that does not compress at all would likely work as
well.
Thanks
Michal
Michal Suchanek
I think the rreadline implementation is compatible. I once tried it
because the readline on Windows was broken, and aside for renaming
something to make irb find it it worked for me.
Thanks
Michal
Luis Lavena
The failures are related to wrong number of arguments.
if a replacement for Zlib is developed, it must comply with Zlib specs
located in rubyspec:
http://github.com/rubyspec/rubyspec/tree/b83d7e5f40659f551c7e94667ffeeb0ea7c6bcfe/library/zlib
It should implement the exact same compression strategies. If not, is
not a "drop-in" replacement.
> Of course, the spec might be more high-level but then an
> implementation that does not compress at all would likely work as
> well.
The spec is being used across IronRuby, Rubinius, JRuby and the Ruby C
(MRI). So the pure-ruby replacement must comply.
--
Luis Lavena
Heesob Park
As before, you can download at http://121.78.227.9/rbzlib/
Finished in 1.323951 seconds
77 files, 38 examples, 88 expectations, 0 failures, 0 errors
Regards,
Park Heesob
Daniel Berger
Ok, I tried again. Reading seemed to work fine. For writing it worked
fine for small libs, but when I tried it against my largest project,
windows-pr, I got this:
C:\Documents and Settings\djberge\workspace\windows-pr>ruby windows-
pr.gemspec
C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:859:in `log': Result
too large - log (Errno::ERANGE)
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:859:in
`log2'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:901:in
`chooseblock'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:882:in
`times'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:882:in
`chooseblock'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:613:in
`outsym'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:575:in
`match'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:430:in
`lz77_compress'
from C:/ruby/lib/ruby/site_ruby/1.8/zlib/deflate.rb:490:in
`deflate'
... 10 levels...
from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/builder.rb:68:in
`open'
from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/builder.rb:68:in
`write_package'
from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/builder.rb:37:in
`build'
from windows-pr.gemspec:25
It's about 60 files. If you'd like to try windows-pr yourself you can
grab it via:
cvs -d :pserver:anon...@rubyforge.org:/var/cvs/win32utils login
cvs -d :pserver:anon...@rubyforge.org:/var/cvs/win32utils checkout
Regards,
Dan
Daniel Berger
On Jan 11, 5:25 am, "Heesob Park" <pha...@gmail.com> wrote:
> 2009/1/11 Luis Lavena <luislav...@gmail.com>:
> >http://github.com/rubyspec/rubyspec/tree/b83d7e5f40659f551c7e94667ffe...
>
> > It should implement the exact same compression strategies. If not, is
> > not a "drop-in" replacement.
>
> >> Of course, the spec might be more high-level but then an
> >> implementation that does not compress at all would likely work as
> >> well.
>
> > The spec is being used across IronRuby, Rubinius, JRuby and the Ruby C
> > (MRI). So the pure-ruby replacement must comply.
>
> At last, my zlib.rb and rbzlib.rb passed rubyspec zlib test
> As before, you can download athttp://121.78.227.9/rbzlib/
>
> Finished in 1.323951 seconds
>
> 77 files, 38 examples, 88 expectations, 0 failures, 0 errors
Good work. I just tried it out. Both reading and writing seemed to
work fine. Generating a gem for my largest project, windows-pr, worked
fine as well.
Awesome!!!
Announcement forthcoming...
Regards,
Dan
Daniel Berger
On Jan 9, 5:34 pm, Luis Lavena <luislav...@gmail.com> wrote:
> On Jan 9, 9:26 pm, "Charles L." <aquas...@gmail.com> wrote:
<snip>
> Anyone knows any web application for bounties? I'm interested in
> contribute to this one and also one for Readline!!!
I think that's a fantastic idea Luis!
I can live without a pure Ruby readline (though I'd certainly welcome
it). I'd rather have a pure Ruby OpenSSL. :)
Regards,
Dan
Jano Svitok
> I can live without a pure Ruby readline (though I'd certainly welcome
> it). I'd rather have a pure Ruby OpenSSL. :)
What parts of OpenSSL? ;-)
J.
Robert Dober
<snip>
> Ok, I'll look for it and just copy/paste files individually when
> you're ready.
wget http://github.com/aquasync/ruby-zlib/tarball/master
seems to work just fine.
HTH
Robert
--
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov
Daniel Berger
> Hi,
>
> There's a project out there called "zliby" [1] which partially
> implements the zlib library. Unfortunately, only the Zlib::GzipReader
> class has been implemented so far. I'd like to have a pure Ruby
> implementation of the Zlib::GzipWriter class.
>
> I've put in a feature request [2] but I'd like to see it expedited. In
> order to expedite this, I'm offering $100 to anyone who can implement
> it. In order to qualify for the bounty, your Zlib::GzipWriter class
> must meet the following criteria:
>
> * It must be pure Ruby. No extensions. No FFI.
> * It must have tests (and pass them)
> * It must match the current Zlib::GzipWriter interface
> * It must be cross platform
> * It must be able to generate a proper gem file from a gemspec (the
> acid test)
> * It must be contributed back to the zliby project
> * It must be done within 60 days of this post
<snip>
And the winner is...Park Heesob! We actually had two competitors for
the bounty (much to my surprise), and it was very close (again, to my
surprise), but in the end Park's code passed an acid test that
Charles' code did not.[1]
So, congratulations to Park Heesob for not only creating a
Zlib::GzipWriter implementation, but for also creating a pure Ruby
version of the underlying zlib 1.2.3 library!
WOOHOO!
Regards,
Dan
[1] However, I hate to see Charles go unrewarded for his wonderful
efforts, so any matchers are free to distribute their bounties as they
see fit.
Michael Letterle
> Zlib::GzipWriter implementation, but for also creating a pure Ruby
> version of the underlying zlib 1.2.3 library!
>
> WOOHOO!
>
> Regards,
>
> Dan
>
> [1] However, I hate to see Charles go unrewarded for his wonderful
> efforts, so any matchers are free to distribute their bounties as they
> see fit.
This is just awesome, thanks Dan for putting up some cash to make this
happen! Compression was more difficult then decompression and I just
didn't have the time. Going to look into combining Park's code into
zliby.. though Charles stuff looks interesting too....
Luis Lavena
I have some bucks with Park and Charles names printed on them ;-)
Park: I have your Paypal info, will send you as soon as possible.
Charles: can you tell me your paypal email?
Again: do anyone knows a good platform to to bounties for open source
projects?
Regards,
--
Luis Lavena
Charles L.
> I have some bucks with Park and Charles names printed on them ;-)
>
> Park: I have your Paypal info, will send you as soon as possible.
>
> Charles: can you tell me your paypal email?
>
> Again: do anyone knows a good platform to to bounties for open source
> projects?
>
> Regards,
Thanks Luis, but never mind, it was more about the challenge, and also
supporting the effort to ease problems on windows. I primarily use ruby
on windows, and make use of the fruits of your (one click installer),
and daniel berger's (win32 process, sys-*, et al) labors every day (at
work that is :). Props to you guys for making ruby on windows useable...
Daniel Berger
Just the parts that Ruby's openssl wrapper uses.
Dan
Michael Letterle
Charles,
I like how you laid out your project and whatnot. My "dream" is to make
zliby more then just a zlib compression library, but a more general
compression library and command line tool. Your compression code seems
to be more in the same style as my decompression implementation, any
qualms against me incorporating some of your stuff?
I also added Park to the zliby ruby-forge project, if you'd like I can
add you as well, or add you as a collaborator on the zliby github
project.
Charles L.
> Charles,
>
> I like how you laid out your project and whatnot. My "dream" is to make
> zliby more then just a zlib compression library, but a more general
> compression library and command line tool. Your compression code seems
> to be more in the same style as my decompression implementation, any
> qualms against me incorporating some of your stuff?
>
> I also added Park to the zliby ruby-forge project, if you'd like I can
> add you as well, or add you as a collaborator on the zliby github
> project.
Hi Michael,
Sure feel free to add me on the rubyforge/github, or just copy the
relevant files back in if you prefer. There's a few small fixes needed
to the deflate code, but after that it might be a good candidate for
inclusion.
The idea of a general ruby compression library is nice. With rubyzip,
and a pure ruby zlib, all thats probably missing is bzip2, and bwt is
fairly straight forward (I believe I saw a python implementation in
around 100 lines).
I'm really hoping some of that javascript vm goodness will find its way
to ruby though (or psyco equivalent or whatever), because without it,
pure ruby compression (or any algorithmic code) remains unsuitable for
general purpose use.
Daniel Berger
I didn't notice much of a slowdown with Park's version when installing
gems or building gems, though I didn't do any sort of formal benchmarking.
It would be interesting to see some real benchmarks with MRI, JRuby and 1.9.
Regards,
Dan