Forum: Ruby Pure Ruby Zlib::GzipWriter

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

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

> 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/a6966f6fc1424f61
Then there'd be one less setup hurdle for ruby.
I'm a watcher for now though :)
-=R

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/a6966f6fc1424f61
> 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...

- Charlie

On Dec 21, 1:08 pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> > 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

Daniel Berger wrote:
> 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

Daniel Berger wrote:
> 
> 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?

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.

Regards,

Dan

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.

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.

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

The Higgs bozo wrote:
> 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?

> 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.

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

On Dec 26, 8:05 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> > 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.
>
> 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 :)

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

On Dec 15 2008, 9:32 am, Daniel Berger <djber...@gmail.com> wrote:
> must meet the following criteria:
> 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.

Yet more ammunition:

http://www.misuse.org/science/2007/09/07/ruby-zlib-buffer-error-on-windows/

Regards,

Dan

> 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
-=r

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

Daniel Berger wrote:
> 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).

Hi,

2009/1/6 Daniel Berger <djberg96@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

Heesob Park wrote:
> 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

Charles L. wrote:
> interface similarity with zlib. Need to change the specs from zliby 
>>> 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).

Sounds like you're on track. But, you're in a race with Park Heesob. :)

Dan

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'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.

>> 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 :)

-=r

Hi,

2009/1/8 Charles L. <aquasync@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

On Jan 7, 11:08 pm, "Heesob Park" <pha...@gmail.com> wrote:
> > 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!

> 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

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

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

2009/1/8 Daniel Berger <djberg96@gmail.com>:
>>
>> > It's about 600 lines, but needs cleaning up. Will probably be ~500 when
>
> 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 at http://121.78.227.9/rbzlib/pzlib.rb

Regards,

Park Heesob

On Jan 8, 6:56 pm, "Charles L." <aquas...@gmail.com> wrote:
>
> 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

Hi,

On Jan 8, 8:23 pm, "Heesob Park" <pha...@gmail.com> wrote:
>
> >> > It's about 600 lines, but needs cleaning up. Will probably be ~500 when
>
> > 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

On Jan 8, 6:56 pm, "Charles L." <aquas...@gmail.com> wrote:
>
> 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

Daniel Berger wrote:
> 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

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!

Hi,

2009/1/10 Daniel Berger <djberg96@gmail.com>:
>> >> >> Sounds like you're on track. But, you're in a race with Park Heesob. :)
>>
>> >> In my test, the deflation is very slow but the inflation is endurable.
>
> definition.
>
> Keep up the good work!
>
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

On Jan 9, 9:26 pm, "Charles L." <aquas...@gmail.com> wrote:
> >      got: "x\234KLJNIMK\317\310\314\312\316\311\005\000#
> > Finished in 1.688 seconds
>
> 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!
> --
> Posted viahttp://www.ruby-forum.com/.

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,

> 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.

2009/1/10 Roger Pack <rdp@doachristianturndaily.info>:
>
I guess you are looking for ruby_readline [1] .

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

On Jan 10, 8:15 am, Heesob Park <pha...@gmail.com> wrote:
> 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/

Hi,

2009/1/10 Luis Lavena <luislavena@gmail.com>:
>>
>
> 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.

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

On Jan 10, 2:47 pm, Heesob Park <pha...@gmail.com> wrote:
> >> > like, so I believe it is possible :)
>
> 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

On 10/01/2009, Luis Lavena <luislavena@gmail.com> wrote:
>  >
>  >
>  >
>  so :-D
>
>  Finished in 0.328 seconds
>
>
> 38 examples, 25 failures
>
I guess it's expected. Different implementations give different
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

On 10/01/2009, Heesob Park <phasis@gmail.com> wrote:
>  >> > like, so I believe it is possible :)
>  > work with IRB and auto complete capabilities.
>  >
>
> 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.
>

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

On Jan 10, 4:21 pm, Michal Suchanek <hramr...@gmail.com> wrote:
>
>
>
>
> I guess it's expected. Different implementations give different
> compression results.
>

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.

2009/1/11 Luis Lavena <luislavena@gmail.com>:
>> >  > >> >> contribute to this one and also one for Readline!!!
>> >  > > Hello Park,
>> >  > > Thank you again for your pointer.
>> >  so :-D
>>
>
> 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 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

On Jan 9, 4:26 pm, "Charles L." <aquas...@gmail.com> wrote:
> >      got: "x\234KLJNIMK\317\310\314\312\316\311\005\000#
> > Finished in 1.688 seconds
>
> 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!

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:anonymous@rubyforge.org:/var/cvs/win32utils login

cvs -d :pserver:anonymous@rubyforge.org:/var/cvs/win32utils checkout

Regards,

Dan

On Jan 11, 5:25 am, "Heesob Park" <pha...@gmail.com> wrote:
> >> >  > > On Jan 10, 8:15 am, Heesob Park <pha...@gmail.com> wrote:
> >> >  > >> I guess you are looking for ruby_readline [1] .
> >> >  > > ReadLine.
>
>
> >http://github.com/rubyspec/rubyspec/tree/b83d7e5f40659f551c7e94667ffe...
>
> 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

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

On 01/11/2009, Daniel Berger <djberg96@gmail.com> wrote:
>  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.

On Fri, Jan 9, 2009 at 6:23 PM, Daniel Berger <djberg96@gmail.com> 
wrote:
<snip>
> Ok, I'll look for it and just copy/paste files individually when
> you're ready.
Hopefully that is not necessary
wget http://github.com/aquasync/ruby-zlib/tarball/master
seems to work just fine.
HTH
Robert

On Dec 15 2008, 9:32 am, Daniel Berger <djber...@gmail.com> wrote:
> 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.

Daniel Berger wrote:
> On Dec 15 2008, 9:32�am, Daniel Berger <djber...@gmail.com> wrote:
> 
> So, congratulationns 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.


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....

On Jan 12, 12:38 pm, Daniel Berger <djber...@gmail.com> wrote:
>
> > acid test)
> So, congratulations to Park Heesob for not only creating a
> efforts, so any matchers are free to distribute their bounties as they
> see fit.

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 wrote:
> 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...

Jano Svitok wrote:
> On 01/11/2009, Daniel Berger <djberg96@gmail.com> wrote:
>>  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? ;-)

Just the parts that Ruby's openssl wrapper uses.

Dan

Charles L. wrote:
> Luis Lavena wrote:
>> 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...

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.

Michael Letterle wrote:
> 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.

Charles L. wrote:
>> add you as well, or add you as a collaborator on the zliby github 
> 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.

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