Hi everyone, I'm working on porting ext/zlib to MacRuby right now. I took a look at zliby - though it's certainly nice to have a zlib implementation in pure Ruby, zliby seems to be kind of dead in the water (according to its RubyForge page, it hasn't been updated in almost a year). Additionally, zliby is orders of magnitude slower than ext/zlib (decompressing a 2MB gzipped MP3 with ext/zlib took 0.064 seconds with ext/zlib and 73.909 seconds (yes, over a minute) with zliby). Porting the library will take a little while, as for performance reasons zlib needs to use ByteStrings. So be patient, and it'll be here before you know it. :-) -- Patrick
We are almost there, Etc, Zlib and Socket are still missing. Last I heard, Laurent had a "plan" for Zlib, knowing him, it's probably a great and efficient idea. Make sure to check with him before starting on that. (running some benchmarks on zliby wouldn't hurt anyone)
Once function_method will be working again, many more stdlibs should also be in a better shape (Math, CMath etc..)
There is a lot of work being done, unfortunately not much we can see yet.
- Matt
Hey Patrick, How about the getting the ffi zlib implementation to work? Seems to me that it would kill two birds with one stone, i.e. getting FFI in a more usable state and a C backed zlib implementation. Eloy On 18 aug 2009, at 23:52, Patrick Thomson wrote:
Hi everyone,
I'm working on porting ext/zlib to MacRuby right now. I took a look at zliby - though it's certainly nice to have a zlib implementation in pure Ruby, zliby seems to be kind of dead in the water (according to its RubyForge page, it hasn't been updated in almost a year). Additionally, zliby is orders of magnitude slower than ext/zlib (decompressing a 2MB gzipped MP3 with ext/zlib took 0.064 seconds with ext/zlib and 73.909 seconds (yes, over a minute) with zliby). Porting the library will take a little while, as for performance reasons zlib needs to use ByteStrings. So be patient, and it'll be here before you know it. :-)
-- Patrick
We are almost there, Etc, Zlib and Socket are still missing. Last I heard, Laurent had a "plan" for Zlib, knowing him, it's probably a great and efficient idea. Make sure to check with him before starting on that. (running some benchmarks on zliby wouldn't hurt anyone)
Once function_method will be working again, many more stdlibs should also be in a better shape (Math, CMath etc..)
There is a lot of work being done, unfortunately not much we can see yet.
- Matt
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Eloy, I would also love to have a ffi-based zlib but we need zlib urgently for RubyGems and I don't think our FFI implementation will be ready soon. It is still our objective to finish FFI and maybe we can quickly rewrite the extension in pure Ruby for the release. The current extension is anyway imported from the original Ruby project, we just need to tweak it a little bit so that it works with the GC and the new ByteString class. Laurent On Aug 18, 2009, at 3:13 PM, Eloy Duran wrote:
Hey Patrick,
How about the getting the ffi zlib implementation to work? Seems to me that it would kill two birds with one stone, i.e. getting FFI in a more usable state and a C backed zlib implementation.
Eloy
On 18 aug 2009, at 23:52, Patrick Thomson wrote:
Hi everyone,
I'm working on porting ext/zlib to MacRuby right now. I took a look at zliby - though it's certainly nice to have a zlib implementation in pure Ruby, zliby seems to be kind of dead in the water (according to its RubyForge page, it hasn't been updated in almost a year). Additionally, zliby is orders of magnitude slower than ext/zlib (decompressing a 2MB gzipped MP3 with ext/zlib took 0.064 seconds with ext/zlib and 73.909 seconds (yes, over a minute) with zliby). Porting the library will take a little while, as for performance reasons zlib needs to use ByteStrings. So be patient, and it'll be here before you know it. :-)
-- Patrick
We are almost there, Etc, Zlib and Socket are still missing. Last I heard, Laurent had a "plan" for Zlib, knowing him, it's probably a great and efficient idea. Make sure to check with him before starting on that. (running some benchmarks on zliby wouldn't hurt anyone)
Once function_method will be working again, many more stdlibs should also be in a better shape (Math, CMath etc..)
There is a lot of work being done, unfortunately not much we can see yet.
- Matt
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hey Laurent, Fair enough, point taken :) Eloy On 19 aug 2009, at 00:20, Laurent Sansonetti wrote:
Hi Eloy,
I would also love to have a ffi-based zlib but we need zlib urgently for RubyGems and I don't think our FFI implementation will be ready soon. It is still our objective to finish FFI and maybe we can quickly rewrite the extension in pure Ruby for the release. The current extension is anyway imported from the original Ruby project, we just need to tweak it a little bit so that it works with the GC and the new ByteString class.
Laurent
On Aug 18, 2009, at 3:13 PM, Eloy Duran wrote:
Hey Patrick,
How about the getting the ffi zlib implementation to work? Seems to me that it would kill two birds with one stone, i.e. getting FFI in a more usable state and a C backed zlib implementation.
Eloy
On 18 aug 2009, at 23:52, Patrick Thomson wrote:
Hi everyone,
I'm working on porting ext/zlib to MacRuby right now. I took a look at zliby - though it's certainly nice to have a zlib implementation in pure Ruby, zliby seems to be kind of dead in the water (according to its RubyForge page, it hasn't been updated in almost a year). Additionally, zliby is orders of magnitude slower than ext/zlib (decompressing a 2MB gzipped MP3 with ext/zlib took 0.064 seconds with ext/zlib and 73.909 seconds (yes, over a minute) with zliby). Porting the library will take a little while, as for performance reasons zlib needs to use ByteStrings. So be patient, and it'll be here before you know it. :-)
-- Patrick
We are almost there, Etc, Zlib and Socket are still missing. Last I heard, Laurent had a "plan" for Zlib, knowing him, it's probably a great and efficient idea. Make sure to check with him before starting on that. (running some benchmarks on zliby wouldn't hurt anyone)
Once function_method will be working again, many more stdlibs should also be in a better shape (Math, CMath etc..)
There is a lot of work being done, unfortunately not much we can see yet.
- Matt
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Great, good luck Patrick! - Matt On Tue, Aug 18, 2009 at 2:52 PM, Patrick Thomson <pthomson@apple.com> wrote:
Hi everyone,
I'm working on porting ext/zlib to MacRuby right now. I took a look at zliby - though it's certainly nice to have a zlib implementation in pure Ruby, zliby seems to be kind of dead in the water (according to its RubyForge page, it hasn't been updated in almost a year). Additionally, zliby is orders of magnitude slower than ext/zlib (decompressing a 2MB gzipped MP3 with ext/zlib took 0.064 seconds with ext/zlib and 73.909 seconds (yes, over a minute) with zliby). Porting the library will take a little while, as for performance reasons zlib needs to use ByteStrings. So be patient, and it'll be here before you know it. :-)
-- Patrick
We are almost there, Etc, Zlib and Socket are still missing.
Last I heard, Laurent had a "plan" for Zlib, knowing him, it's probably a great and efficient idea. Make sure to check with him before starting on that. (running some benchmarks on zliby wouldn't hurt anyone)
Once function_method will be working again, many more stdlibs should also be in a better shape (Math, CMath etc..)
There is a lot of work being done, unfortunately not much we can see yet.
- Matt
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (4)
-
Eloy Duran
-
Laurent Sansonetti
-
Matt Aimonetti
-
Patrick Thomson