On the ironruby.net page it says that you''re looking for a zlib implementation. Is that a managed re-implementation of zlib or a managed wrapper around the unmanaged zlib library? Cheers! -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/51db16f7/attachment.html
I''d assume a managed library for cross platform compatibility. Is anyone familiar with the difference between Zlib and System.IO.Compression? Is it possible to use wrap System.IO.Compression to get a compatible Ruby Zlib lib? Or do we need a new managed Zlib implementation? On 9/12/07, Eric Nicholson <enicholson at gmail.com> wrote:> > On the ironruby.net page it says that you''re looking for a zlib > implementation. Is that a managed re-implementation of zlib or a managed > wrapper around the unmanaged zlib library? > > Cheers! > > -Eric > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/7ec34d47/attachment-0001.html
We would love to have a managed implementation since it makes life so much easier - especially as we begin the inevitable move to 64 bit in the future. I haven''t done the investigation between zlib and System.IO.Compression. Are you volunteering, Mike? :) Thanks! -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Mike Moore Sent: Wednesday, September 12, 2007 3:21 PM To: Eric Nicholson Cc: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] zlib implementation I''d assume a managed library for cross platform compatibility. Is anyone familiar with the difference between Zlib and System.IO.Compression? Is it possible to use wrap System.IO.Compression to get a compatible Ruby Zlib lib? Or do we need a new managed Zlib implementation? On 9/12/07, Eric Nicholson <enicholson at gmail.com<mailto:enicholson at gmail.com>> wrote: On the ironruby.net<http://ironruby.net> page it says that you''re looking for a zlib implementation. Is that a managed re-implementation of zlib or a managed wrapper around the unmanaged zlib library? Cheers! -Eric _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/cb2f949f/attachment.html
Good point Mike. In addition to the System.IO.Compression route, there is already a managed zlib implementation at http://www.componentace.com/zlib_.NET.htm They have a very permissive license: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of ComponentAce nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." What''s the policy on including other OSS components? Any chance that this could be used? -Eric On 9/12/07, Mike Moore <blowmage at gmail.com> wrote:> > I''d assume a managed library for cross platform compatibility. Is anyone > familiar with the difference between Zlib and System.IO.Compression? Is > it possible to use wrap System.IO.Compression to get a compatible Ruby > Zlib lib? Or do we need a new managed Zlib implementation? > > On 9/12/07, Eric Nicholson <enicholson at gmail.com> wrote: > > > On the ironruby.net page it says that you''re looking for a zlib > > implementation. Is that a managed re-implementation of zlib or a managed > > wrapper around the unmanaged zlib library? > > > > Cheers! > > > > -Eric > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/025f942d/attachment.html
On 9/12/07, John Lam (CLR) <jflam at microsoft.com> wrote:> > We would love to have a managed implementation since it makes life so > much easier ? especially as we begin the inevitable move to 64 bit in the > future. > > > > I haven''t done the investigation between zlib and System.IO.Compression. > Are you volunteering, Mike? J >I actually spent a couple hours working through Ruby''s Zlib last night trying to familiarize myself with it. I''ve never used it before which is why I asked the question. :) Right now the two big needs are Zlib and YAML. So here are my uninformed thoughts. Please correct me. Zlib:: Determine if we can use System.IO.Compression. If not, we may have to re-implement zlib in C# or use an existing port if the license is compatible. A zlib implementation in C# (using System.IO.Compression if possible) could be useful for other DLR languages, so that''s something to keep in mind. YAML:: From what I''ve read about JRuby''s YAML implementation, getting it to work like Syck was a major issue. We could start with Ola''s RbYAML once IronRuby will run it, but we will probably need to build a native library for performance reasons (just like JRuby did). Long term, the two options I see are porting Ola''s JvYAML, or porting _why''s Syck to C#. I''m somewhat partial to porting Syck so that it can be reused in other languages. I wonder how much of IronRuby''s parser we could re-purpose to get Syck on C#... http://rbyaml.rubyforge.org/ https://jvyaml.dev.java.net/ http://code.whytheluckystiff.net/syck/ Thanks!> > -John > > > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Mike Moore > *Sent:* Wednesday, September 12, 2007 3:21 PM > *To:* Eric Nicholson > *Cc:* ironruby-core at rubyforge.org > *Subject:* Re: [Ironruby-core] zlib implementation > > > > I''d assume a managed library for cross platform compatibility. Is anyone > familiar with the difference between Zlib and System.IO.Compression? Is > it possible to use wrap System.IO.Compression to get a compatible Ruby > Zlib lib? Or do we need a new managed Zlib implementation? > > On 9/12/07, *Eric Nicholson* <enicholson at gmail.com> wrote: > > On the ironruby.net page it says that you''re looking for a zlib > implementation. Is that a managed re-implementation of zlib or a managed > wrapper around the unmanaged zlib library? > > Cheers! > > -Eric > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/d2ec9545/attachment.html
On 9/12/07, Eric Nicholson <enicholson at gmail.com> wrote:> > Good point Mike. > > In addition to the System.IO.Compression route, there is already a managed > zlib implementation at http://www.componentace.com/zlib_.NET.htm They > have a very permissive license: > > "Redistributions of source code must retain the above copyright notice, > this list of conditions and the following disclaimer. > Redistributions in binary form must reproduce the above copyright notice, > this list of conditions and the following disclaimer in the documentation > and/or other materials provided with the distribution. > Neither the name of ComponentAce nor the names of its contributors may be > used to endorse or promote products derived from this software without > specific prior written permission." > > What''s the policy on including other OSS components? Any chance that this > could be used?I''d love an answer to this question. If we reuse an existing library it has to be compatible with the MsPL. So which licenses are compatible? -Eric> > On 9/12/07, Mike Moore <blowmage at gmail.com> wrote: > > > > I''d assume a managed library for cross platform compatibility. Is > > anyone familiar with the difference between Zlib and > > System.IO.Compression? Is it possible to use wrap System.IO.Compressionto get a compatible Ruby Zlib lib? Or do we need a new managed Zlib > > implementation? > > > > On 9/12/07, Eric Nicholson < enicholson at gmail.com> wrote: > > > > > On the ironruby.net page it says that you''re looking for a zlib > > > implementation. Is that a managed re-implementation of zlib or a managed > > > wrapper around the unmanaged zlib library? > > > > > > Cheers! > > > > > > -Eric > > > > > > _______________________________________________ > > > Ironruby-core mailing list > > > Ironruby-core at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/4b7f8084/attachment-0001.html
Thanks for looking into this, Eric! I think that this will work. We don''t have a policy regarding distributing other OSS components with IronRuby. I think that given the finite # of libraries to consider that we''ll look at them on a case by case basis. I think in the case of zlib that redistributing the zlib.net library makes perfect sense. There''s a couple of things that I think would be great: 1) Let''s see if it''s possible to write the zlib .rb wrapper today (I kind of doubt it given our lack of some language features but you can certainly try :)) 2) We would really like zlib.net to run on Silverlight as well. I haven''t looked at the code for zlib, but it would be great if we could see if it would compile under Silverlight (or figure out what we would need to do to get it to compile under Silverlight). I think we''ll wind up redistributing the compiled binary of zlib.net with IronRuby with a multiple license agreement. We need to run this past the lawyers, but I''m pretty confident that shipping a BSD licensed component alongside of our MsPL code should be OK. Worst case we get someone in the community a''la Curt Hibbs to help us package this stuff up :) Thanks! -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Eric Nicholson Sent: Wednesday, September 12, 2007 4:31 PM To: Mike Moore Cc: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] zlib implementation Good point Mike. In addition to the System.IO.Compression route, there is already a managed zlib implementation at http://www.componentace.com/zlib_.NET.htm They have a very permissive license: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of ComponentAce nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." What''s the policy on including other OSS components? Any chance that this could be used? -Eric On 9/12/07, Mike Moore <blowmage at gmail.com<mailto:blowmage at gmail.com>> wrote: I''d assume a managed library for cross platform compatibility. Is anyone familiar with the difference between Zlib and System.IO.Compression? Is it possible to use wrap System.IO.Compression to get a compatible Ruby Zlib lib? Or do we need a new managed Zlib implementation? On 9/12/07, Eric Nicholson < enicholson at gmail.com<mailto:enicholson at gmail.com>> wrote: On the ironruby.net<http://ironruby.net> page it says that you''re looking for a zlib implementation. Is that a managed re-implementation of zlib or a managed wrapper around the unmanaged zlib library? Cheers! -Eric _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/d8e1b96f/attachment.html
Thanks for looking into these libraries, Mike! Regarding zlib: it seems like a binary dependency on zlib.net would work. Do you agree? Regarding YAML: I agree that porting _syck to C# would be a good idea. Does _syck have dependencies on the Ruby parser? BTW, the IronRuby tokenizer is scheduled for a massive overhaul in the next couple of weeks. Thanks! -John From: Mike Moore [mailto:blowmage at gmail.com] Sent: Wednesday, September 12, 2007 4:59 PM To: John Lam (CLR) Cc: Eric Nicholson; ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] zlib implementation On 9/12/07, John Lam (CLR) <jflam at microsoft.com<mailto:jflam at microsoft.com>> wrote: We would love to have a managed implementation since it makes life so much easier - especially as we begin the inevitable move to 64 bit in the future. I haven''t done the investigation between zlib and System.IO.Compression. Are you volunteering, Mike? :) I actually spent a couple hours working through Ruby''s Zlib last night trying to familiarize myself with it. I''ve never used it before which is why I asked the question. :) Right now the two big needs are Zlib and YAML. So here are my uninformed thoughts. Please correct me. Zlib:: Determine if we can use System.IO.Compression. If not, we may have to re-implement zlib in C# or use an existing port if the license is compatible. A zlib implementation in C# (using System.IO.Compression if possible) could be useful for other DLR languages, so that''s something to keep in mind. YAML:: From what I''ve read about JRuby''s YAML implementation, getting it to work like Syck was a major issue. We could start with Ola''s RbYAML once IronRuby will run it, but we will probably need to build a native library for performance reasons (just like JRuby did). Long term, the two options I see are porting Ola''s JvYAML, or porting _why''s Syck to C#. I''m somewhat partial to porting Syck so that it can be reused in other languages. I wonder how much of IronRuby''s parser we could re-purpose to get Syck on C#... http://rbyaml.rubyforge.org/ https://jvyaml.dev.java.net/ http://code.whytheluckystiff.net/syck/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/0c438975/attachment.html
On Wed, 12 Sep 2007 18:02:56 -0600, John Lam (CLR) <jflam at microsoft.com> wrote:> I think we?ll wind up redistributing the compiled binary of zlib.net > with IronRuby with a multiple license agreement. We need to run this > past the lawyers, but I?m pretty confident that shipping a BSD licensed > component alongside of our MsPL code should be OK. Worst case we get > someone in the community a?la Curt Hibbs to help us package this stuff > up J@ http://www.icsharpcode.net/OpenSource/SharpZipLib/ #ziplib (SharpZipLib, formerly NZipLib) is a Zip, GZip, Tar and BZip2 library written entirely in C# for the .NET platform. It is implemented as an assembly (installable in the GAC), and thus can easily be incorporated into other projects (in any .NET language). The creator of #ziplib put it this way: "I''ve ported the zip library over to C# because I needed gzip/zip compression and I didn''t want to use libzip.dll or something like this. I want all in pure C#." License The library is released under the GPL with the following exception: Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Note The exception is changed to reflect the latest GNU Classpath exception. Older versions of #ziplib did have another exception, but the new one is clearer and it doesn''t break compatibility with the old one. Bottom line In plain English this means you can use this library in commercial closed-source applications. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155
Just to make sure we''re all on the same page in terms of zip libraries (there are at least three you could refer to as "zlib.net"), here''s a summary: ZLIB - www.zlib.net The original zlib, used by gzip. BSD style license. Component Ace''s ZLIB.NET - http://www.componentace.com/zlib_.NET.htm Port of zlib to 100% managed .NET. BSD style license ( http://www.componentace.com/data/ZLIB_.NET/license.txt) SharpDevelop''s SharpZipLib - http://www.icsharpcode.net/OpenSource/SharpZipLib/ "*Zip, GZip, Tar and BZip2 library* written entirely in C#". GPL License with an exception System.IO.Compression - http://msdn2.microsoft.com/en-us/library/system.io.compression.aspx "Provides basic compression and decompression services for streams." it''s already in the framework Feel free to add to the list... It''s hard to tell which one is the most likely to be compatible with Ruby''s ZLIB. If non-managed dependency is acceptable, real ZLIB is decent choice. If you want managed, then the Component ACE ZLIB.NET would be a reasonable approach. -Eric On 9/12/07, M. David Peterson <m.david at xmlhacker.com> wrote:> > On Wed, 12 Sep 2007 18:02:56 -0600, John Lam (CLR) <jflam at microsoft.com> > wrote: > > > I think we''ll wind up redistributing the compiled binary of zlib.net > > with IronRuby with a multiple license agreement. We need to run this > > past the lawyers, but I''m pretty confident that shipping a BSD licensed > > component alongside of our MsPL code should be OK. Worst case we get > > someone in the community a''la Curt Hibbs to help us package this stuff > > up J > > @ http://www.icsharpcode.net/OpenSource/SharpZipLib/ > > #ziplib (SharpZipLib, formerly NZipLib) is a Zip, GZip, Tar and BZip2 > library written entirely in C# for the .NET platform. It is implemented as > an assembly (installable in the GAC), and thus can easily be incorporated > into other projects (in any .NET language). The creator of #ziplib put it > this way: "I''ve ported the zip library over to C# because I needed > gzip/zip compression and I didn''t want to use libzip.dll or something like > this. I want all in pure C#." > License > > The library is released under the GPL with the following exception: > > Linking this library statically or dynamically with other modules is > making a combined work based on this library. Thus, the terms and > conditions of the GNU General Public License cover the whole combination. > > As a special exception, the copyright holders of this library give you > permission to link this library with independent modules to produce an > executable, regardless of the license terms of these independent modules, > and to copy and distribute the resulting executable under terms of your > choice, provided that you also meet, for each linked independent module, > the terms and conditions of the license of that module. An independent > module is a module which is not derived from or based on this library. If > you modify this library, you may extend this exception to your version of > the library, but you are not obligated to do so. If you do not wish to do > so, delete this exception statement from your version. > > Note The exception is changed to reflect the latest GNU Classpath > exception. Older versions of #ziplib did have another exception, but the > new one is clearer and it doesn''t break compatibility with the old one. > > Bottom line In plain English this means you can use this library in > commercial closed-source applications. > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/76800731/attachment.html
After looking a bit more closely at System.IO.Compression, I think it actually gives us most of what we need. So in order of preference: 1) System.IO.Compression (we still have to solve the Silverlight problem since I just looked and saw that it doesn''t ship in Silverlight). 2) Component ACE zlib.net - I like the BSD style license - it will be easier to make a case for this. Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Eric Nicholson Sent: Wednesday, September 12, 2007 6:21 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] zlib implementation Just to make sure we''re all on the same page in terms of zip libraries (there are at least three you could refer to as "zlib.net<http://zlib.net>"), here''s a summary: ZLIB - www.zlib.net<http://www.zlib.net> The original zlib, used by gzip. BSD style license. Component Ace''s ZLIB.NET<http://ZLIB.NET> - http://www.componentace.com/zlib_.NET.htm Port of zlib to 100% managed .NET. BSD style license ( http://www.componentace.com/data/ZLIB_.NET/license.txt) SharpDevelop''s SharpZipLib - http://www.icsharpcode.net/OpenSource/SharpZipLib/ "Zip, GZip, Tar and BZip2 library written entirely in C#". GPL License with an exception System.IO.Compression - http://msdn2.microsoft.com/en-us/library/system.io.compression.aspx "Provides basic compression and decompression services for streams." it''s already in the framework Feel free to add to the list... It''s hard to tell which one is the most likely to be compatible with Ruby''s ZLIB. If non-managed dependency is acceptable, real ZLIB is decent choice. If you want managed, then the Component ACE ZLIB.NET<http://ZLIB.NET> would be a reasonable approach. -Eric On 9/12/07, M. David Peterson < m.david at xmlhacker.com<mailto:m.david at xmlhacker.com>> wrote: On Wed, 12 Sep 2007 18:02:56 -0600, John Lam (CLR) < jflam at microsoft.com<mailto:jflam at microsoft.com>> wrote:> I think we''ll wind up redistributing the compiled binary of zlib.net<http://zlib.net> > with IronRuby with a multiple license agreement. We need to run this > past the lawyers, but I''m pretty confident that shipping a BSD licensed > component alongside of our MsPL code should be OK. Worst case we get > someone in the community a''la Curt Hibbs to help us package this stuff > up J@ http://www.icsharpcode.net/OpenSource/SharpZipLib/ #ziplib (SharpZipLib, formerly NZipLib) is a Zip, GZip, Tar and BZip2 library written entirely in C# for the .NET platform. It is implemented as an assembly (installable in the GAC), and thus can easily be incorporated into other projects (in any .NET language). The creator of #ziplib put it this way: "I''ve ported the zip library over to C# because I needed gzip/zip compression and I didn''t want to use libzip.dll or something like this. I want all in pure C#." License The library is released under the GPL with the following exception: Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Note The exception is changed to reflect the latest GNU Classpath exception. Older versions of #ziplib did have another exception, but the new one is clearer and it doesn''t break compatibility with the old one. Bottom line In plain English this means you can use this library in commercial closed-source applications. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070912/feec4a9e/attachment.html
Hello! I would like to add following librariy to the list. DevelopDotNet Compression Library - http://www.developdotnet.com/modules/tinycontent/content/index.php?id=3 Freeware (even for commercial products) with source codes, Artistic License (v. 1.0), it is written in managed C++ and it is based on *ZLib*<http://www.gzip.org/zlib>compression library engine. Very good perf. Good features. --s. p.s. Eric, I apologize for previous post, I do not noticed immediatelly that I sending it not to the list, but directly to your email address. s. On 9/13/07, Eric Nicholson <enicholson at gmail.com> wrote:> > Just to make sure we''re all on the same page in terms of zip libraries > (there are at least three you could refer to as "zlib.net"), here''s a > summary: > > ZLIB - www.zlib.net > The original zlib, used by gzip. BSD style license. > > Component Ace''s ZLIB.NET <http://zlib.net/> - http://www.componentace.com/zlib_.NET.htm > > Port of zlib to 100% managed .NET. BSD style license ( > http://www.componentace.com/data/ZLIB_.NET/license.txt) > > SharpDevelop''s SharpZipLib - > http://www.icsharpcode.net/OpenSource/SharpZipLib/ > "*Zip, GZip, Tar and BZip2 library* written entirely in C#". GPL License > with an exception > > System.IO.Compression - > http://msdn2.microsoft.com/en-us/library/system.io.compression.aspx > "Provides basic compression and decompression services for streams." it''s > already in the framework > > Feel free to add to the list... > > It''s hard to tell which one is the most likely to be compatible with > Ruby''s ZLIB. If non-managed dependency is acceptable, real ZLIB is decent > choice. If you want managed, then the Component ACE ZLIB.NET<http://zlib.net/>would be a reasonable approach. > > -Eric-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/663d4513/attachment-0001.html
About the System.IO.Compression capabilities you can look at this<http://blogs.msdn.com/bclteam/archive/2007/05/16/system-io-compression-capabilities-kim-hamilton.aspx>good post from the BCL blog. They also have plans to implement other algorithms in the future, but did not say when this future will happen, maybe the version after Orcas. 2007/9/13, Slavo Furman <slavof at gmail.com>:> > Hello! > > I would like to add following librariy to the list. > > DevelopDotNet Compression Library - http://www.developdotnet.com/modules/tinycontent/content/index.php?id=3 > > Freeware (even for commercial products) with source codes, Artistic > License (v. 1.0), it is written in managed C++ and it is based on *ZLib*<http://www.gzip.org/zlib>compression library engine. Very good perf. Good features. > > --s. > > p.s. Eric, I apologize for previous post, I do not noticed immediatelly > that I sending it not to the list, but directly to your email address. > s. > > > On 9/13/07, Eric Nicholson <enicholson at gmail.com> wrote: > > > > Just to make sure we''re all on the same page in terms of zip libraries > > (there are at least three you could refer to as " zlib.net"), here''s a > > summary: > > > > ZLIB - www.zlib.net > > The original zlib, used by gzip. BSD style license. > > > > Component Ace''s ZLIB.NET <http://zlib.net/> - http://www.componentace.com/zlib_.NET.htm > > > > Port of zlib to 100% managed .NET. BSD style license ( > > http://www.componentace.com/data/ZLIB_.NET/license.txt) > > > > SharpDevelop''s SharpZipLib - > > http://www.icsharpcode.net/OpenSource/SharpZipLib/ > > "*Zip, GZip, Tar and BZip2 library* written entirely in C#". GPL License > > with an exception > > > > System.IO.Compression - > > http://msdn2.microsoft.com/en-us/library/system.io.compression.aspx > > "Provides basic compression and decompression services for streams." > > it''s already in the framework > > > > Feel free to add to the list... > > > > It''s hard to tell which one is the most likely to be compatible with > > Ruby''s ZLIB. If non-managed dependency is acceptable, real ZLIB is decent > > choice. If you want managed, then the Component ACE ZLIB.NET<http://zlib.net/>would be a reasonable approach. > > > > -Eric > > > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/8c94d34d/attachment.html
On 9/12/07, John Lam (CLR) <jflam at microsoft.com> wrote:> > Thanks for looking into these libraries, Mike! > > Regarding zlib: it seems like a binary dependency on zlib.net would work. > Do you agree? > > Regarding YAML: I agree that porting _syck to C# would be a good idea. > Does _syck have dependencies on the Ruby parser? >Syck doesn''t have a dependency on the Ruby parser, but it does use lex/yacc style gram.y file. I know that the Ruby.NET guys cracked that nut and reused Ruby''s parser.y file, and it looks like IronRuby has a Parser.y file as well. I honestly haven''t looked at this very closely since I first saw it in Ruby.NET, so I''m just assuming that a .NET version of Syck could also use Syck''s gram.y file as a starting place.> BTW, the IronRuby tokenizer is scheduled for a massive overhaul in the > next couple of weeks. >How is this changing? Thanks!> > -John > > > > *From:* Mike Moore [mailto:blowmage at gmail.com] > *Sent:* Wednesday, September 12, 2007 4:59 PM > *To:* John Lam (CLR) > *Cc:* Eric Nicholson; ironruby-core at rubyforge.org > *Subject:* Re: [Ironruby-core] zlib implementation > > > > On 9/12/07, *John Lam (CLR)* <jflam at microsoft.com> wrote: > > We would love to have a managed implementation since it makes life so > much easier ? especially as we begin the inevitable move to 64 bit in the > future. > > > > I haven''t done the investigation between zlib and System.IO.Compression. > Are you volunteering, Mike? J > > I actually spent a couple hours working through Ruby''s Zlib last night > trying to familiarize myself with it. I''ve never used it before which is > why I asked the question. :) > > Right now the two big needs are Zlib and YAML. So here are my uninformed > thoughts. Please correct me. > > Zlib:: Determine if we can use System.IO.Compression. If not, we may have > to re-implement zlib in C# or use an existing port if the license is > compatible. A zlib implementation in C# (using System.IO.Compression if > possible) could be useful for other DLR languages, so that''s something to > keep in mind. > > YAML:: From what I''ve read about JRuby''s YAML implementation, getting it > to work like Syck was a major issue. We could start with Ola''s RbYAML once > IronRuby will run it, but we will probably need to build a native library > for performance reasons (just like JRuby did). Long term, the two options I > see are porting Ola''s JvYAML, or porting _why''s Syck to C#. I''m somewhat > partial to porting Syck so that it can be reused in other languages. I > wonder how much of IronRuby''s parser we could re-purpose to get Syck on > C#... > > http://rbyaml.rubyforge.org/ > https://jvyaml.dev.java.net/ > http://code.whytheluckystiff.net/syck/ >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/ef770517/attachment.html
Before we get too far down into the implementation details, perhaps it might be better to just port JvYAML? I''m adding Ola to this mail - Ola do you think it would be a straightforward port to C#? Thanks, -John From: Mike Moore [mailto:blowmage at gmail.com] Sent: Thursday, September 13, 2007 8:37 AM To: John Lam (CLR) Cc: Eric Nicholson; ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] zlib implementation Syck doesn''t have a dependency on the Ruby parser, but it does use lex/yacc style gram.y file. I know that the Ruby.NET guys cracked that nut and reused Ruby''s parser.y file, and it looks like IronRuby has a Parser.y file as well. I honestly haven''t looked at this very closely since I first saw it in Ruby.NET, so I''m just assuming that a .NET version of Syck could also use Syck''s gram.y file as a starting place. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/275a1e31/attachment-0001.html
From: Mike Moore [mailto:blowmage at gmail.com]>> BTW, the IronRuby tokenizer is scheduled for a massive overhaul in the next couple of weeks. > How is this changing?We inherited the tokenizer and scanner from the Ruby.net codebase which we funded via MSR. When we ripped that code out of their compiler, the token location reporting wound up getting busted. That code is rather complicated, and we have a very nice tokenizer class in IronPython/DLR that we would much rather use instead. So we''re going to spend some time rewriting that stuff to get location reporting correct. Once that works, it should be trivial to enable debugging under VS which is feature that is motivating the rewrite. -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/f215f019/attachment.html
Thanks for the pointer Stefan- it''s funny how I spent a bunch of time trying to track down internally who the owner of SIC was, and then that blog post told me exactly who to send the mail to :) -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Stefan Dobrev Sent: Thursday, September 13, 2007 1:04 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] zlib implementation About the System.IO.Compression capabilities you can look at this<http://blogs.msdn.com/bclteam/archive/2007/05/16/system-io-compression-capabilities-kim-hamilton.aspx> good post from the BCL blog. They also have plans to implement other algorithms in the future, but did not say when this future will happen, maybe the version after Orcas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/74303c80/attachment-0001.html
I took a quick look at the library you mentioned. Correct me if I''m wrong (I''ve only done C++/CLI in .NET 2.0, rather than Managed Extensions for C++ in .NET 1.0, and only very little of it), but it looks like they are using unsafe code. Won''t this screw up the Mono people? I''m guessing portability is probably a high priority. Slavo Furman wrote:> Hello! > > I would like to add following librariy to the list. > > DevelopDotNet Compression Library - > http://www.developdotnet.com/modules/tinycontent/content/index.php?id=3 > <http://www.developdotnet.com/modules/tinycontent/content/index.php?id=3> > Freeware (even for commercial products) with source codes, Artistic > License (v. 1.0), it is written in managed C++ and it is based on *ZLib* > <http://www.gzip.org/zlib> compression library engine. Very good perf. > Good features. > > --s.
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Tony Djordjevski > Sent: Thursday, September 13, 2007 10:42 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] zlib implementation > > I took a quick look at the library you mentioned. > > Correct me if I''m wrong (I''ve only done C++/CLI in .NET 2.0, rather > than > Managed Extensions for C++ in .NET 1.0, and only very little of it), > but > it looks like they are using unsafe code. > > Won''t this screw up the Mono people? I''m guessing portability is > probably a high priority.We definitely want to stay away from unsafe code. One of the nice things about our Silverlight story is that DLR + IronRuby is security transparent (see http://blogs.msdn.com/shawnfa/archive/2007/05/14/silverlight-security-cheat-sheet.aspx for a quick summary and more links). Short story is that we don''t have to undergo security reviews as a result of this. -John
On Thu, 13 Sep 2007 11:37:39 -0600, John Lam (CLR) <jflam at microsoft.com> wrote:> Thanks for the pointer Stefan- it?s funny how I spent a bunch of time > trying to track down internally who the owner of SIC was, and then that > blog post told me exactly who to send the mail to JHey, Kim Hamilton... I know her. :) Well, not personally, but through proxy. My good friend Russ Miles[1] (who is now the Director of Software Development and Co-Founder of my company) and Kim wrote a book together[2]. Isn''t Kim on the Silverlight team? Given the topic of the article linked to[3] from Stefan it seems she would be just the person to talk to about System.IO.Compression support for Silverlight :D (though, come to think of it, all browsers already support gzip compression, so maybe they plan to write a wrapper around each existing browsers implementation?) [1] http://dev.aol.com/blog/mdavidpeterson/2007/02/20/ror-and-the-dotnet-platform_let-go-to-embrace (see third paragraph down) [2] http://www.oreilly.com/catalog/learnuml2/ [3] http://blogs.msdn.com/bclteam/archive/2007/05/16/system-io-compression-capabilities-kim-hamilton.aspx -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155
On Thu, 13 Sep 2007 11:41:32 -0600, Tony Djordjevski <tony at v-sim.com> wrote:> but > it looks like they are using unsafe code. > Won''t this screw up the Mono people?Unsafe code can be compiled via (g)mcs and run via Mono.> I''m guessing portability is > probably a high priority.True, but my guess is that this portability will have more to do with Silverlight/DLR than it will with anything else. Platform specific code would be an issue (via P/Invoke) with portability. So anything that uses P/Invoke would definitely be a problem for the Mono folks. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155
Interesting YAML implementation discussion aside... What''s the goal in implementing Zlib on IR? The reason I ask is that I''m wondering what level of compatibility we want with the canonical implementation. There are a lot of things in the Zlib module/classes that are not readily available in System.IO.Compresssion (Adler-32 hashes, selectable compression levels, etc.). Can we gloss over those and just implement a good inflate/deflate capability? -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/4f26d23f/attachment.html
On 9/13/07, Eric Nicholson <enicholson at gmail.com> wrote:> > Interesting YAML implementation discussion aside... > > What''s the goal in implementing Zlib on IR? The reason I ask is that I''m > wondering what level of compatibility we want with the canonical > implementation. There are a lot of things in the Zlib module/classes that > are not readily available in System.IO.Compresssion (Adler-32 hashes, > selectable compression levels, etc.). Can we gloss over those and just > implement a good inflate/deflate capability?I might be okay with not having Zlib in IronRuby when IR is hosted within Silverlight (partially because that framework is missing System.IO.Compression). But I''d expect IronRuby''s Zlib to be 100% compatible with MRI''s ZLib when used on the desktop and server. 100% or as close as we can get it. Hey Charlie, what are you guys doing for Zlib in JRuby? -Eric> > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/a81cc979/attachment.html
Mike Moore wrote:> On 9/13/07, *Eric Nicholson* <enicholson at gmail.com > <mailto:enicholson at gmail.com>> wrote: > > Interesting YAML implementation discussion aside... > > What''s the goal in implementing Zlib on IR? The reason I ask is > that I''m wondering what level of compatibility we want with the > canonical implementation. There are a lot of things in the Zlib > module/classes that are not readily available in > System.IO.Compresssion (Adler-32 hashes, selectable compression > levels, etc.). Can we gloss over those and just implement a good > inflate/deflate capability? > > > I might be okay with not having Zlib in IronRuby when IR is hosted > within Silverlight (partially because that framework is missing > System.IO.Compression). But I''d expect IronRuby''s Zlib to be 100% > compatible with MRI''s ZLib when used on the desktop and server. 100% or > as close as we can get it. > > Hey Charlie, what are you guys doing for Zlib in JRuby?Our Zlib is implemented using Java''s built-in support for zip compression. There''s a bit of trickery to get it to behave properly, but it''s been working now for 1.5 years without major issues. And we have our own impls of Adler32 et al. - Charlie
On Wed, 12 Sep 2007 19:47:42 -0600, John Lam (CLR) <jflam at microsoft.com> wrote:> 1) System.IO.Compression (we still have to solve the Silverlight > problem since I just looked and saw that it doesn?t ship in Silverlight).Just noticed that the system.dll assembly in Silverlight provides support for the System.Net.DecompressionMethods enumeration, which System.Net.HttpWebRequest.AutomaticDecompression uses to determine the compression/decompression algorithm to use as part of the HttpWebRequest. The values of the enum are Deflate, GZip, or None. Me: "Lutz-O-Mirror on-the-wall, is GZip compression supported after all?" --- public override DecompressionMethods AutomaticDecompression { get { return DecompressionMethods.None; } set { throw new NotSupportedException(); } } --- Me: "DRAT!" Me: "Lutz-O-Mirror on-the-wall, any chance they''ll implement support by end of fall?" Lutz-O-Mirror: "Do I look like a Fortune Teller?" Me: "Yes." Lutz-O-Mirror: "No." Me: "No, they won''t implement support?" Lutz-O-Mirror: "No, I''m not a Fortune Teller! I can only reflect upon what already exists, not what might exist in the future!" Me: "Hmmm... What good is a Fortune Teller who can''t tell me the future?" Lutz-O-Mirror: "I''M NOT A FORTUNE TELLER!" ... and it was at this point of the conversation that I decided it was time to put away Lutz-O-Mirror for the night. Seems some sleep will probably do him some good, huh?! ;-) So while the obviously overworked-and-underpaid Lutz-O-Mirror is sleeping, anybody at MSFT care to take on his fortune telling responsibilities? -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155
> From: M. David Peterson [mailto:m.david at xmlhacker.com] > Sent: Saturday, September 15, 2007 8:58 PM > To: John Lam (DLR); Eric Nicholson; ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] zlib implementation > > Just noticed that the system.dll assembly in Silverlight provides > support for the System.Net.DecompressionMethods enumeration ... > > <snip /> > > anybody at MSFT care to take on his fortune telling responsibilities?I''ve been talking to Kim offline and it seems like compression will be added into Silverlight via an extension. However, since the extension model still hasn''t been baked, we''re going to have to wait a while to figure out exactly *how* this stuff will all hang together. It seems safe to take a dependency on it though - worst case we can build a thunk that lets us swap out one implementation for the final implementation. -John
Thanks for the head''s up! So I guess the approach is to build off of System.IO.Compression for everything possible and recode the rest from scratch. Erring on the side of compatibility with MRI (Matz''s Ruby Interpreter... I had to look it up). I''ve started building some test cases against MRI Zlib with the thinking that they could eventually test out whatever IR implementation gets created. If anyone wants to take a look, I''ll try to make a little more progress tonight and then I''ll be happy to share. -Eric On 9/17/07, John Lam (DLR) <jflam at microsoft.com> wrote:> > > From: M. David Peterson [mailto:m.david at xmlhacker.com] > > Sent: Saturday, September 15, 2007 8:58 PM > > To: John Lam (DLR); Eric Nicholson; ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] zlib implementation > > > > Just noticed that the system.dll assembly in Silverlight provides > > support for the System.Net.DecompressionMethods enumeration ... > > > > <snip /> > > > > anybody at MSFT care to take on his fortune telling responsibilities? > > I''ve been talking to Kim offline and it seems like compression will be > added into Silverlight via an extension. However, since the extension model > still hasn''t been baked, we''re going to have to wait a while to figure out > exactly *how* this stuff will all hang together. > > It seems safe to take a dependency on it though - worst case we can build > a thunk that lets us swap out one implementation for the final > implementation. > > -John > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070917/5215aa9e/attachment.html