Ironruby core - Feb 2008 - Curious about IronRuby and IronPython on DLR

Hi,

Just curious to know more about IronRuby and IronPython.

Since both are based on DLR....here are my short questions.

(1) Is the progress same with both the languages.

(2) Will version 1.0 for both will be in the same time frame...

(3) If Rails is the target for declaring IronRuby as 1.0 then..
will django will be the target for declaring IronPython as 1.0

(4) How are the code contributions flowing to IronRuby from other 3rd
party developers when compared to IronRuby...

Thanks
-- 
Posted via http://www.ruby-forum.com/.

well ironpython 1.0 has already been out for some time. its version 2 (i 
think) that they are putting on the DLR, so you could say safely, i 
think, that ironpython is more mature. (but of course ruby is cooler) 
and further along in full language compatibility. This is just my 
perception though. Hopefully somebody who really knows will answer ;)

Softmind Technology wrote:
> Hi,
>
> Just curious to know more about IronRuby and IronPython.
>
> Since both are based on DLR....here are my short questions.
>
> (1) Is the progress same with both the languages.
>
> (2) Will version 1.0 for both will be in the same time frame...
>
> (3) If Rails is the target for declaring IronRuby as 1.0 then..
> will django will be the target for declaring IronPython as 1.0
>
> (4) How are the code contributions flowing to IronRuby from other 3rd
> party developers when compared to IronRuby...
>
> Thanks
>

IronPython is much further along. All of the details about IronPython are
readily available online, including how far it is along in cPython''s
compatibility. I would say no languages will progress at the same time no
matter if they are on the CLR or DLR, language teams are seperate from
platform teams within MS. The polocies for code contributions for both
languages are also very public for you to review yourself.

On Feb 17, 2008 12:07 AM, Karl Prosser <karl at powershell.com> wrote:
> well ironpython 1.0 has already been out for some time. its version 2 (i
> think) that they are putting on the DLR, so you could say safely, i
> think, that ironpython is more mature. (but of course ruby is cooler)
> and further along in full language compatibility. This is just my
> perception though. Hopefully somebody who really knows will answer ;)
>
> Softmind Technology wrote:
> > Hi,
> >
> > Just curious to know more about IronRuby and IronPython.
> >
> > Since both are based on DLR....here are my short questions.
> >
> > (1) Is the progress same with both the languages.
> >
> > (2) Will version 1.0 for both will be in the same time frame...
> >
> > (3) If Rails is the target for declaring IronRuby as 1.0 then..
> > will django will be the target for declaring IronPython as 1.0
> >
> > (4) How are the code contributions flowing to IronRuby from other 3rd
> > party developers when compared to IronRuby...
> >
> > Thanks
> >
>
>
> _______________________________________________
> 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/20080217/584d62f6/attachment.html

Below is a table summarizing the extension libraries that are needed by a number
of simple Rails use cases. These libraries are implemented in Matz''s
Ruby Interpreter in C code rather than in Ruby code, so we''ll need to
port or at least wrap them in some way.


 Use Case

Win32API

Syck
(YAML)

thread

socket

stringio

zlib

digest

strscan

openssl

sqlite3_api

Setup gems

?

?

?















Gem install rails

?

?

?

?

?

?









Rails create app

?

?

?







?

?





Start WEBrick

?

?

?

?







?





WEBrick process static html page

?

?

?

?







?





WEBrick process dynamic controller page

?

?

?

?

?



?

?

?

?

IIS CGI dispatch

?

?

?







?

?

?




I''d like to start working on some of these libraries, but first want to
check who is already working on what. I understand that John Messerly is working
on a YAML port and according to the WIKI, Eduardo Flores is working on stringio
and Curt Hagenlocher is working on strscan. Is this list correct and complete.
Is anyone else already working on any of these libraries?

To support these simple use cases, typically only a small number of functions
from these libraries is actually needed. If you are going to work on any of
these libraries, I can provide you with a list of the actual functions and with
the exact signature/overrides that are actually used by these use cases.
Obviously, other functions will also be needed long term, but by implementing
these functions first we can get basic Rails functionality happening sooner.

Note, there are many different web server options that we could persue. We could
for example not worry about WEBrick and go straight to IIS as a host and so
avoid implementing the socket library. Ultimately, I think we want to be web
server agnostic, That is, we should aim to provide a drop in replacement for
"rubyw.exe" that works regardless of which web server (IIS, Apache,
WEBrick, Mongrel, etc) that administrators choose to adopt. That said, Windows
is currently considered a second class platform for deploying Rails and the
setup can be quite complex and buggy in some configurations. In the longer term
we should aim to improve this situation. For production Rails we''ll
want to support IIS 7.0 well on server machines, but for those that just want to
try it out, I believe we should also make sure it can be made to work on desktop
machines such as mine with IIS 5 and XP.
Your thoughts?

Cheers, Wayne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080218/f89f640b/attachment-0001.html

Below is a table summarizing the extension libraries that are needed by a number
of simple Rails use cases. These libraries are implemented in Matz''s
Ruby Interpreter in C code rather than in Ruby code, so we''ll need to
port or at least wrap them in some way.


 Use Case

Win32API

Syck
(YAML)

thread

socket

stringio

zlib

digest

strscan

openssl

sqlite3_api

Setup gems

?

?

?















Gem install rails

?

?

?

?

?

?









Rails create app

?

?

?







?

?





Start WEBrick

?

?

?

?







?





WEBrick process static html page

?

?

?

?







?





WEBrick process dynamic controller page

?

?

?

?

?



?

?

?

?

IIS CGI dispatch

?

?

?







?

?

?




I''d like to start working on some of these libraries, but first want to
check who is already working on what. I understand that John Messerly is working
on a YAML port and according to the WIKI, Eduardo Flores is working on stringio
and Curt Hagenlocher is working on strscan. Is this list correct and complete.
Is anyone else already working on any of these libraries?

To support these simple use cases, typically only a small number of functions
from these libraries is actually needed. If you are going to work on any of
these libraries, I can provide you with a list of the actual functions and with
the exact signature/overrides that are actually used by these use cases.

Cheers, Wayne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080218/8581f474/attachment-0001.html

Hi Wayne,

This is great!  More below...

On Sun, 17 Feb 2008 17:29:41 -0700, Wayne Kelly <w.kelly at qut.edu.au>
wrote:

> Note, there are many different web server options that we could persue.  
> We could for example not worry about WEBrick and go straight to IIS as a  
> host and so avoid implementing the socket library. Ultimately, I think  
> we want to be web server agnostic, That is, we should aim to provide a  
> drop in replacement for "rubyw.exe" that works regardless of
which web
> server (IIS, Apache, WEBrick, Mongrel, etc) that administrators choose  
> to adopt.
+1.  I would suggest we adopt using either XSP or Cassini, both of which  
are small and capable.  XSP is specifically an HTTP 1.0 server.  Not sure  
if Cassini covers 1.1 or not.  Anyone know?
> That said, Windows is currently considered a second class platform for  
> deploying Rails and the setup can be quite complex and buggy in some  
> configurations. In the longer term we should aim to improve this  
> situation.
Using either XSP or Cassini will help in that if we can get it to run via  
either, then getting it to run via IIS and/or through mod_mono/fastcgi  
should be quite a bit easier.
> For production Rails we''ll want to support IIS 7.0 well on server
> machines, but for those that just want to try it out, I believe we  
> should also make sure it can be made to work on desktop machines such as  
> mine with IIS 5 and XP.
>
> Your thoughts?
We need to place focus on providing support via FastCGI such that getting  
it to work on lighty, Apache, etc. is simple and straight forward.  Using  
Mono''s FastCGI support should make this drop dead simple.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |  
http://dev.aol.com/blog/3155

I think a "sane subset" of supported web servers is the way to go. For
instance, no one uses webrick anymore (most popular is mongrel for development
and mongrel+apache/lighttpd for production), so supporting webrick
isn''t super-important. I completely agree w/the importance of being
web-server agnostic. Also, webrick is a pure ruby app, so by definition
we''ll want to make it work in the long run.

Btw, this is really cool Wayne =)

~js

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Wayne Kelly
Sent: Sunday, February 17, 2008 4:30 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Towards Rails on .NET

Below is a table summarizing the extension libraries that are needed by a number
of simple Rails use cases. These libraries are implemented in Matz''s
Ruby Interpreter in C code rather than in Ruby code, so we''ll need to
port or at least wrap them in some way.


Use Case

Win32API

Syck
(YAML)

thread

socket

stringio

zlib

digest

strscan

openssl

sqlite3_api

Setup gems

*

*

*















Gem install rails

*

*

*

*

*

*









Rails create app

*

*

*







*

*





Start WEBrick

*

*

*

*







*





WEBrick process static html page

*

*

*

*







*





WEBrick process dynamic controller page

*

*

*

*

*



*

*

*

*

IIS CGI dispatch

*

*

*







*

*

*




I''d like to start working on some of these libraries, but first want to
check who is already working on what. I understand that John Messerly is working
on a YAML port and according to the WIKI, Eduardo Flores is working on stringio
and Curt Hagenlocher is working on strscan. Is this list correct and complete.
Is anyone else already working on any of these libraries?

To support these simple use cases, typically only a small number of functions
from these libraries is actually needed. If you are going to work on any of
these libraries, I can provide you with a list of the actual functions and with
the exact signature/overrides that are actually used by these use cases.
Obviously, other functions will also be needed long term, but by implementing
these functions first we can get basic Rails functionality happening sooner.

Note, there are many different web server options that we could persue. We could
for example not worry about WEBrick and go straight to IIS as a host and so
avoid implementing the socket library. Ultimately, I think we want to be web
server agnostic, That is, we should aim to provide a drop in replacement for
"rubyw.exe" that works regardless of which web server (IIS, Apache,
WEBrick, Mongrel, etc) that administrators choose to adopt. That said, Windows
is currently considered a second class platform for deploying Rails and the
setup can be quite complex and buggy in some configurations. In the longer term
we should aim to improve this situation. For production Rails we''ll
want to support IIS 7.0 well on server machines, but for those that just want to
try it out, I believe we should also make sure it can be made to work on desktop
machines such as mine with IIS 5 and XP.
Your thoughts?

Cheers, Wayne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080218/e67546c5/attachment-0001.html

Very cool list!  This should be put on the wiki at Rubyforge methinks...

There''s still a lot to be done in the ruby core too though... there
may be some dependency there for these things to work "right".

I''d be interested in doing the zlib port if noone else has done
anything on it yet, I just recently had to dig into zlib a bit so it''s
kind of fresh.  Feel free to send me what needs implemented.

On Feb 17, 2008 7:29 PM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>
>
> Below is a table summarizing the extension libraries that are needed by a
> number of simple Rails use cases. These libraries are implemented in
Matz''s
> Ruby Interpreter in C code rather than in Ruby code, so we''ll need
to port
> or at least wrap them in some way.
>
>
>
>
>
>  Use Case
>
> Win32API
>
> Syck
>
> (YAML)
>
> thread
>
> socket
>
> stringio
>
> zlib
>
> digest
>
> strscan
>
> openssl
>
> sqlite3_api
>
>
> Setup gems
>
> ?
>
> ?
>
> ?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Gem install rails
>
> ?
>
> ?
>
> ?
>
> ?
>
> ?
>
> ?
>
>
>
>
>
>
>
>
>
>
> Rails create app
>
> ?
>
> ?
>
> ?
>
>
>
>
>
>
>
> ?
>
> ?
>
>
>
>
>
>
> Start WEBrick
>
> ?
>
> ?
>
> ?
>
> ?
>
>
>
>
>
>
>
> ?
>
>
>
>
>
>
> WEBrick process static html page
>
> ?
>
> ?
>
> ?
>
> ?
>
>
>
>
>
>
>
> ?
>
>
>
>
>
>
> WEBrick process dynamic controller page
>
> ?
>
> ?
>
> ?
>
> ?
>
> ?
>
>
>
> ?
>
> ?
>
> ?
>
> ?
>
>
> IIS CGI dispatch
>
> ?
>
> ?
>
> ?
>
>
>
>
>
>
>
> ?
>
> ?
>
> ?
>
>
>
> I''d like to start working on some of these libraries, but first
want to
> check who is already working on what. I understand that John Messerly is
> working on a YAML port and according to the WIKI, Eduardo Flores is working
> on stringio and Curt Hagenlocher is working on strscan. Is this list
correct
> and complete. Is anyone else already working on any of these libraries?
>
> To support these simple use cases, typically only a small number of
> functions from these libraries is actually needed. If you are going to work
> on any of these libraries, I can provide you with a list of the actual
> functions and with the exact signature/overrides that are actually used by
> these use cases. Obviously, other functions will also be needed long term,
> but by implementing these functions first we can get basic Rails
> functionality happening sooner.
>
> Note, there are many different web server options that we could persue. We
> could for example not worry about WEBrick and go straight to IIS as a host
> and so avoid implementing the socket library. Ultimately, I think we want
to
> be web server agnostic, That is, we should aim to provide a drop in
> replacement for "rubyw.exe" that works regardless of which web
server (IIS,
> Apache, WEBrick, Mongrel, etc) that administrators choose to adopt. That
> said, Windows is currently considered a second class platform for deploying
> Rails and the setup can be quite complex and buggy in some configurations.
> In the longer term we should aim to improve this situation. For production
> Rails we''ll want to support IIS 7.0 well on server machines, but
for those
> that just want to try it out, I believe we should also make sure it can be
> made to work on desktop machines such as mine with IIS 5 and XP.
> Your thoughts?
>
> Cheers, Wayne.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com

Wayne Kelly:
> I''d like to start working on some of these libraries, but first
want
> to check who is already working on what. I understand that John
> Messerly is working on a YAML port and according to the WIKI, Eduardo
> Flores is working on stringio and Curt Hagenlocher is working on
> strscan. Is this list correct and complete. Is anyone else already
> working on any of these libraries?
I think it would be awesome if you could start investigating the openssl and
zlib support. Both of these are on the critical path to getting Rails to work
and don''t have other folks looking at them AFAIK.

I think it is important to look at integration with IIS 7 + fastcgi, and then
looking at back-porting to IIS 6 as a lower priority.

I''m still working on the status app. Wayne has already provided me with
the dynamic method traces of these scenarios. Wayne, if you want feel free to
make those files available to the group (I don''t think the list will
make it easy to do this, so uploading them to a server and providing a link will
likely be the best way to do this).

Thanks,
-John

> From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at
rubyforge.org] On Behalf Of
> Michael Letterle [michael.letterle at gmail.com]
> Sent: Monday, 18 February 2008 11:52 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Towards Rails on .NET
>
> I''d be interested in doing the zlib port if noone else has done
> anything on it yet, I just recently had to dig into zlib a bit so
it''s
> kind of fresh.  Feel free to send me what needs implemented.
Sounds good to me, but before we go too far down this path, perhaps we should
discuss the ground
rules for implementing these extension libraries. CRuby implements  many of
these libraries as CRuby
specific thin C wrappers around functionality provided by other native open
source libraries. To build
CRuby for Rails from source you need to go to various other open source
projects, download and
compile each of their bits and make sure their binaries are present on the right
path.

What approaches are deemed acceptable within the IronRuby project?
Firstly, is it OK to have dependences on other open source project or do we need
to implement all of these
components from scratch? Secondly, is it OK to have dependences on native
libraries rather than on fully managed
libraries? (note these are two separate issues). Having our own fully managed
implementations would have many
advantages, but would require more work and wouldn''t keep pace with
advances made in those other libraries.
Wrapping the same native libraries as C Ruby will also increase our
compatability. I''m not proposing policy here,
I''m just raising issues and asking for guidence.

The other issue is where to we put these libraries once we start developing
them? It would be nice to have them all
in the same place, even in their early stages of development. Each I imagine
would be a separate library, so they wouldn''t
interfere with one another. I assume they will not become part of the
IronRuby.Libraries project. Perhaps they could be put
into a separate RubyForge project initially that external contributors could
directly upload to, and then if necessary  moved
into some kind of official tree as they mature?

Cheers, Wayne.

Zlib had been discussed last year (and also the issue with including software
with different licences). Below is one of the snippets (the Silverlight issues
has since been resolved) from one of the archived threads.
http://search.live.com/results.aspx?q=site%3Arubyforge.org+zlib+ironruby&form=QBRE
should give you the other posts on that thread.

And according to
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=2590,
System.IO.Compression is able to support the Python zlib module. So it
definitely sounds appealing, especially for Silverlight, where it would avoid
reduce the download size of IronRuby apps since it is already included in
Silverlight.

John Lam said in
http://rubyforge.org/pipermail/ironruby-core/2007-September/000024.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.
-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Wayne Kelly
Sent: Monday, February 18, 2008 2:35 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Towards Rails on .NET
> From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at
rubyforge.org] On Behalf Of
> Michael Letterle [michael.letterle at gmail.com]
> Sent: Monday, 18 February 2008 11:52 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Towards Rails on .NET
>
> I''d be interested in doing the zlib port if noone else has done
> anything on it yet, I just recently had to dig into zlib a bit so
it''s
> kind of fresh.  Feel free to send me what needs implemented.
Sounds good to me, but before we go too far down this path, perhaps we should
discuss the ground
rules for implementing these extension libraries. CRuby implements  many of
these libraries as CRuby
specific thin C wrappers around functionality provided by other native open
source libraries. To build
CRuby for Rails from source you need to go to various other open source
projects, download and
compile each of their bits and make sure their binaries are present on the right
path.

What approaches are deemed acceptable within the IronRuby project?
Firstly, is it OK to have dependences on other open source project or do we need
to implement all of these
components from scratch? Secondly, is it OK to have dependences on native
libraries rather than on fully managed
libraries? (note these are two separate issues). Having our own fully managed
implementations would have many
advantages, but would require more work and wouldn''t keep pace with
advances made in those other libraries.
Wrapping the same native libraries as C Ruby will also increase our
compatability. I''m not proposing policy here,
I''m just raising issues and asking for guidence.

The other issue is where to we put these libraries once we start developing
them? It would be nice to have them all
in the same place, even in their early stages of development. Each I imagine
would be a separate library, so they wouldn''t
interfere with one another. I assume they will not become part of the
IronRuby.Libraries project. Perhaps they could be put
into a separate RubyForge project initially that external contributors could
directly upload to, and then if necessary  moved
into some kind of official tree as they mature?

Cheers, Wayne.
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Wayne Kelly:
> What approaches are deemed acceptable within the IronRuby project?
> Firstly, is it OK to have dependences on other open source project or
> do we need to implement all of these
> components from scratch?
I think it would be fine to have a dependency on a managed library (see below).
> Secondly, is it OK to have dependences on
> native libraries rather than on fully managed
> libraries? (note these are two separate issues).
I''d rather not have dependencies on native libraries. It makes it much
more difficult to ship a single binary across all of our platforms (Mac,
Windows, *nix).
> The other issue is where to we put these libraries once we start
> developing them? It would be nice to have them all
> in the same place, even in their early stages of development. Each I
> imagine would be a separate library, so they wouldn''t
> interfere with one another. I assume they will not become part of the
> IronRuby.Libraries project. Perhaps they could be put
> into a separate RubyForge project initially that external contributors
> could directly upload to, and then if necessary  moved
> into some kind of official tree as they mature?
There are a number of things that complicates things *now*. We don''t
have require ''foo'' working for compiled Ruby library
assemblies, so everything has to be dumped into IronRuby.Libraries.dll for the
time being. Once we have that working it will make it easier to refactor
libraries into packages.

Thanks,
-John

That leads to the question of... what can we, as outside contributors,
do /now/ to help.  I feel like there''s alot of work going on, that we
just don''t know about... I''d hate to see duplicate efforts
wasted.

On Feb 19, 2008 11:21 PM, John Lam (DLR) <jflam at microsoft.com>
wrote:
> There are a number of things that complicates things *now*. We
don''t have require ''foo'' working for compiled Ruby
library assemblies, so everything has to be dumped into IronRuby.Libraries.dll
for the time being. Once we have that working it will make it easier to refactor
libraries into packages.
>
> Thanks,
> -John
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com

Michael Letterle:
> That leads to the question of... what can we, as outside contributors,
> do /now/ to help.  I feel like there''s alot of work going on, that
we
> just don''t know about... I''d hate to see duplicate
efforts wasted.
Thanks for your enthusiasm, Michael!

Let me give an update on what my team here at Microsoft is doing: we''re
working towards MIX08.

Silverlight is its own branch, and we sync up to Silverlight periodically for
big events. So while we were working on the standard libraries, we
weren''t tracking Silverlight (well John Messerly is, but
that''s a whole other story ... :))

Since MIX is right around the corner (March 5-7), we''re working on
getting demos working for MIX and generally looking at how Ruby and dynamic
languages in general fit with the Silverlight development story. Keep in mind
that Silverlight is initially about browser JavaScript programming (V1) and now
.NET based languages programming (V2). Our job is to make sure that the APIs
that they designed for V2 work well with dynamic languages. And the best way to
do that is by writing code against their APIs.

So we haven''t been spending much time at all working on core libraries
and Ruby features - we''re mostly concerned with getting our demos /
labs working for MIX. This gives us a chance to exercise our .NET interop story
and look for holes in that story (and there are a bunch when it comes to data
binding scenarios). It lets us figure out how much work there still is to do in
our binder.

Once MIX is done, we''ll resume working on libraries and getting the
last few language features implemented.

The best way for you to lay claim (today) to some library is announce your
intentions on this list. There are folks who have claimed stuff on the wiki, but
who haven''t updated us on status. So let''s assume that for now
there aren''t any claims anywhere (with the exception of Wayne Kelly
looking at OpenSSL and zlib support).

My SL demo app for MIX is writing the web app that will let folks
''reserve'' a library to work on based on scenarios. This will
let us focus our efforts on places that need it, as well as providing valuable
status reports without resorting to email. I''m still writing the app
since it involves using a bunch of technology that I don''t really use
all that often. So hang in there ... it will be done soon!

Thanks,
-John

Awesome information, thanks for bringing us all up a bit to speed!

I''m not just referring to libraries though, I''m talking about
the core
functionality (this is, after all, Ironruby-core ;) )

Some (all?) of the libraries will have dependencies on things that
must be implemented in the core IronRuby code, what still needs to be
done in the core code and what can we do to help there?

My assumption (and it may be wrong) is that once a majority of the
core functionality is in place, and stable, then the libraries will
come quicker.

In other words, the cake is still soft in the middle, we can''t start
putting icing on until it''s done baking.  What can we do to help stoke
the oven?

Or is this an unrealistic view?

On Wed, Feb 20, 2008 at 11:14 AM, John Lam (DLR) <jflam at microsoft.com>
wrote:
> Michael Letterle:
>
>
>  > That leads to the question of... what can we, as outside
contributors,
>  > do /now/ to help.  I feel like there''s alot of work going
on, that we
>  > just don''t know about... I''d hate to see duplicate
efforts wasted.
>
>  Thanks for your enthusiasm, Michael!
>
>  Let me give an update on what my team here at Microsoft is doing:
we''re working towards MIX08.
>
[snip]
>
>  The best way for you to lay claim (today) to some library is announce your
intentions on this list. There are folks who have claimed stuff on the wiki, but
who haven''t updated us on status. So let''s assume that for now
there aren''t any claims anywhere (with the exception of Wayne Kelly
looking at OpenSSL and zlib support).
>
>  My SL demo app for MIX is writing the web app that will let folks
''reserve'' a library to work on based on scenarios. This will
let us focus our efforts on places that need it, as well as providing valuable
status reports without resorting to email. I''m still writing the app
since it involves using a bunch of technology that I don''t really use
all that often. So hang in there ... it will be done soon!
>
>
>
>  Thanks,
>  -John
>
>
>  _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com

Michael Letterle:
> Awesome information, thanks for bringing us all up a bit to speed!
>
> I''m not just referring to libraries though, I''m talking
about the core
> functionality (this is, after all, Ironruby-core ;) )
>
> Some (all?) of the libraries will have dependencies on things that must
> be implemented in the core IronRuby code, what still needs to be done
> in the core code and what can we do to help there?
>
> My assumption (and it may be wrong) is that once a majority of the core
> functionality is in place, and stable, then the libraries will come
> quicker.
>
> In other words, the cake is still soft in the middle, we can''t
start
> putting icing on until it''s done baking.  What can we do to help
stoke
> the oven?
There''s a lot of stuff that we still need to work on in the language,
and Wayne''s last mail contains a lot of pointers on things that we
still have to do.

I''m not sure there are any simple tasks that we have in the core
language for folks to hack on. There''s a fairly steep learning curve
there, much more so than in the libs.

The big rocks in core that are left:

1) Better .NET interop - our story for data binding today is virtually
non-existent, we don''t correctly convert blocks to delegates to support
async pattern, etc.
2) String-based eval and bindings
3) Finishing off the Ruby reflection-esque API (essentially everything in
Module).

Thanks,
-John

A while back I posted a list of external libraries that we needed to implement
in order to support gems and Rails. The following summarizes the libraries that
I''ve been working on. Could others who are also working on these
libraries please post a status update?

Win32API.so:
  - we just need to delete this library, it''s not really needed.

syck.so (YAML):
  - any progress John?

thread.so:
  - I think we can probably get by for now with Matz''s original
thread.rb implementation was used prior to when the native fastthread support
was added.

socket.so:
 - partially implemented in the currently checked in IronRuby.Library\Builtins
 - I''ve created a pure Ruby implementation of the Socket class for
methods like gethostbyname (just waiting on resolution to my Enum to Fixnum
issue)

stringio.so:
 - any progress Eduardo?

zlib.so:
 - any progress Michael?

digest.so:
 - I have a pure Ruby implementation (just waiting on MemberwiseClone
clarification from Seo and class method bug fix)

strscan.so:
 - any progress Curt?

openssl.so:
 - I''ve posted a pure Ruby implementation of this module

sqlite3_api.so:
 - my colleague Brian Blackwell is investigating this and other database APIs


Again, please post a status update if you are working on any of these libraries.


Cheers, Wayne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080306/de5d0956/attachment.html

On Thu, Mar 6, 2008 at 1:29 AM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>
>
>
> A while back I posted a list of external libraries that we needed to
> implement in order to support gems and Rails. The following summarizes the
> libraries that I''ve been working on. Could others who are also
working on
> these libraries please post a status update?
>
[snip]
>
> zlib.so:
>  - any progress Michael?
>
[snip]
>
> Again, please post a status update if you are working on any of these
> libraries.
>
>
> Cheers, Wayne.
Not yet, I still intend to.  Just need to find the time.  I''ve been
concentrating on learning ruby a bit more first ;)

-- 
Michael Letterle
[Polymath Programmer]
http://blog.prokrams.com

Hi

Is there any objection against using a wrapper around zlib.net ?

On Fri, Mar 7, 2008 at 2:27 AM, Michael Letterle <michael.letterle at
gmail.com>
wrote:
> On Thu, Mar 6, 2008 at 1:29 AM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
> >
> >
> >
> > A while back I posted a list of external libraries that we needed to
> > implement in order to support gems and Rails. The following summarizes
> the
> > libraries that I''ve been working on. Could others who are
also working
> on
> > these libraries please post a status update?
> >
> [snip]
> >
> > zlib.so:
> >  - any progress Michael?
> >
> [snip]
> >
> > Again, please post a status update if you are working on any of these
> > libraries.
> >
> >
> > Cheers, Wayne.
>
> Not yet, I still intend to.  Just need to find the time.  I''ve
been
> concentrating on learning ruby a bit more first ;)
>
> --
> Michael Letterle
> [Polymath Programmer]
> http://blog.prokrams.com
> _______________________________________________
> 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/20080307/a1294e72/attachment.html

This came up on the list a few months ago.  The consensus was that building
off of System.IO.Compression would be the best, and failing that wrapping
Zlib.Net should be possible.

You can dig up the old thread for some more details though.

-Eric

On Thu, Mar 6, 2008 at 3:05 PM, Ivan Porto Carrero <ivan at
flanders.co.nz>
wrote:
> Hi
>
> Is there any objection against using a wrapper around zlib.net ?
>
>
> On Fri, Mar 7, 2008 at 2:27 AM, Michael Letterle <
> michael.letterle at gmail.com> wrote:
>
> > On Thu, Mar 6, 2008 at 1:29 AM, Wayne Kelly <w.kelly at
qut.edu.au> wrote:
> > >
> > >
> > >
> > > A while back I posted a list of external libraries that we needed
to
> > > implement in order to support gems and Rails. The following
summarizes
> > the
> > > libraries that I''ve been working on. Could others who
are also working
> > on
> > > these libraries please post a status update?
> > >
> > [snip]
> > >
> > > zlib.so:
> > >  - any progress Michael?
> > >
> > [snip]
> > >
> > > Again, please post a status update if you are working on any of
these
> > > libraries.
> > >
> > >
> > > Cheers, Wayne.
> >
> > Not yet, I still intend to.  Just need to find the time. 
I''ve been
> > concentrating on learning ruby a bit more first ;)
> >
> > --
> > Michael Letterle
> > [Polymath Programmer]
> > http://blog.prokrams.com
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
>
>
> _______________________________________________
> 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/20080306/630f2be8/attachment.html

I believe the consensus from September was to follow JRuby''s lead and
base
the implementation on System.IO.Compression as much as possible, and code
anything that was needed to get it compatible with the Ruby library.

http://rubyforge.org/pipermail/ironruby-core/2007-September/000024.html

On Thu, Mar 6, 2008 at 2:53 PM, Eric Nicholson <enicholson at gmail.com>
wrote:
> This came up on the list a few months ago.  The consensus was that
> building off of System.IO.Compression would be the best, and failing that
> wrapping Zlib.Net should be possible.
>
> You can dig up the old thread for some more details though.
>
> -Eric
>
>
> On Thu, Mar 6, 2008 at 3:05 PM, Ivan Porto Carrero <ivan at
flanders.co.nz>
> wrote:
>
> > Hi
> >
> > Is there any objection against using a wrapper around zlib.net ?
> >
> >
> > On Fri, Mar 7, 2008 at 2:27 AM, Michael Letterle <
> > michael.letterle at gmail.com> wrote:
> >
> > > On Thu, Mar 6, 2008 at 1:29 AM, Wayne Kelly <w.kelly at
qut.edu.au>
> > > wrote:
> > > >
> > > >
> > > >
> > > > A while back I posted a list of external libraries that we
needed to
> > > > implement in order to support gems and Rails. The following
> > > summarizes the
> > > > libraries that I''ve been working on. Could others
who are also
> > > working on
> > > > these libraries please post a status update?
> > > >
> > > [snip]
> > > >
> > > > zlib.so:
> > > >  - any progress Michael?
> > > >
> > > [snip]
> > > >
> > > > Again, please post a status update if you are working on any
of
> > > these
> > > > libraries.
> > > >
> > > >
> > > > Cheers, Wayne.
> > >
> > > Not yet, I still intend to.  Just need to find the time. 
I''ve been
> > > concentrating on learning ruby a bit more first ;)
> > >
> > > --
> > > Michael Letterle
> > > [Polymath Programmer]
> > > http://blog.prokrams.com
> > > _______________________________________________
> > > Ironruby-core mailing list
> > > Ironruby-core at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/ironruby-core
> > >
> >
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
>
> _______________________________________________
> 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/20080306/6390b0a9/attachment.html

On stringio: I''m finishing some compatibility tests with ruby 1.8.6.
Hope
send the patch soon for revision.

Regards

On Thu, Mar 6, 2008 at 12:29 AM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>  A while back I posted a list of external libraries that we needed to
> implement in order to support gems and Rails. The following summarizes the
> libraries that I''ve been working on. Could others who are also
working on
> these libraries please post a status update?
>
> *Win32API.so:*
>   - we just need to delete this library, it''s not really needed.
>
> *syck.so (YAML):*
>   - any progress John?
>
> *thread.so:*
>   - I think we can probably get by for now with Matz''s original
thread.rbimplementation was used prior to when the native fastthread support was
> added.
>
> *socket.so:*
>  - partially implemented in the currently checked in
> IronRuby.Library\Builtins
>  - I''ve created a pure Ruby implementation of the Socket class for
methods
> like gethostbyname (just waiting on resolution to my Enum to Fixnum issue)
>
> *stringio.so:*
>  - any progress Eduardo?
>
> *zlib.so:*
>  - any progress Michael?
>
> *digest.so:
> * - I have a pure Ruby implementation (just waiting on MemberwiseClone
> clarification from Seo and class method bug fix)
>
> *strscan.so:*
>  - any progress Curt?
>
> *openssl.so:*
>  - I''ve posted a pure Ruby implementation of this module
>
> *sqlite3_api.so:*
>  - my colleague Brian Blackwell is investigating this and other database
> APIs
>
>
> Again, please post a status update if you are working on any of these
> libraries.
>
>
> Cheers, Wayne.
>
> _______________________________________________
> 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/20080306/5e3516f3/attachment-0001.html

Alright, I started doing this tonight (finally)  GZip was pretty
straight forward, but Inflate may be a problem,  The
System::IO::Compression.DeflateStream is RFC 1951 compliant /not/
1950.. Meaning it only covers Deflate, not ZLib in general. See here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=97064&wa=wsignin1.0

I''ll research this more tomorrow, I''d hate to have to have an
external
dependency like Zlib.NET

Attached is my fetal like script containing the GZip implementation,
feedback is welcome.

On Thu, Mar 6, 2008 at 4:53 PM, Eric Nicholson <enicholson at gmail.com>
wrote:
> This came up on the list a few months ago.  The consensus was that building
> off of System.IO.Compression would be the best, and failing that wrapping
> Zlib.Net should be possible.
>
> You can dig up the old thread for some more details though.
>
> -Eric
>
>
>
> On Thu, Mar 6, 2008 at 3:05 PM, Ivan Porto Carrero <ivan at
flanders.co.nz>
> wrote:
> > Hi
> >
> > Is there any objection against using a wrapper around zlib.net ?
> >
> >
> >
> >
> >
> > On Fri, Mar 7, 2008 at 2:27 AM, Michael Letterle
> <michael.letterle at gmail.com> wrote:
> >
> > >
> > > On Thu, Mar 6, 2008 at 1:29 AM, Wayne Kelly <w.kelly at
qut.edu.au> wrote:
> > > >
> > > >
> > > >
> > > > A while back I posted a list of external libraries that we
needed to
> > > > implement in order to support gems and Rails. The following
summarizes
> the
> > > > libraries that I''ve been working on. Could others
who are also working
> on
> > > > these libraries please post a status update?
> > > >
> > > [snip]
> > >
> > > >
> > > > zlib.so:
> > > >  - any progress Michael?
> > > >
> > > [snip]
> > >
> > > >
> > > > Again, please post a status update if you are working on any
of these
> > > > libraries.
> > > >
> > > >
> > > > Cheers, Wayne.
> > >
> > > Not yet, I still intend to.  Just need to find the time. 
I''ve been
> > > concentrating on learning ruby a bit more first ;)
> > >
> > > --
> > > Michael Letterle
> > > [Polymath Programmer]
> > > http://blog.prokrams.com
> > > _______________________________________________
> > > Ironruby-core mailing list
> > > Ironruby-core at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/ironruby-core
> > >
> >
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
>
>
> _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib.rb
Type: application/octet-stream
Size: 989 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/ironruby-core/attachments/20080307/96754030/attachment.obj

Michael Letterle:
> Alright, I started doing this tonight (finally)  GZip was pretty
> straight forward, but Inflate may be a problem,  The
> System::IO::Compression.DeflateStream is RFC 1951 compliant /not/
> 1950.. Meaning it only covers Deflate, not ZLib in general. See here:
> https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
> F
> eedbackID=97064&wa=wsignin1.0
>
> I''ll research this more tomorrow, I''d hate to have to
have an external
> dependency like Zlib.NET
Yeah, DeflateStream only implements the basic deflate algorithm, with no
configuration options. Worse, it doesn''t have particularly good
compression ratio. Definitely worth investigating a port of a more fully
featured library...

- John

I''d like to implement zlib in pure ruby, but in the mean time, I think
this should be good enough. Time will tell.  Once we get a good
collection of these libraries together we''ll be able to see
what''s
really needed ;)

Anyway, updated zlib.rb attached, it performs the Gzip and Zlib
decompression... I''m not sure exactly what finish is suppose to do,
the docs are unclear.  I suspect it may not be applicable to the way
I''m returning the decompressed output...

On Fri, Mar 7, 2008 at 2:43 AM, John Messerly <jomes at microsoft.com>
wrote:
> Michael Letterle:
>
>
>  > Alright, I started doing this tonight (finally)  GZip was pretty
>  > straight forward, but Inflate may be a problem,  The
>  > System::IO::Compression.DeflateStream is RFC 1951 compliant /not/
>  > 1950.. Meaning it only covers Deflate, not ZLib in general. See here:
>  >
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
>  > F
>  > eedbackID=97064&wa=wsignin1.0
>  >
>  > I''ll research this more tomorrow, I''d hate to have
to have an external
>  > dependency like Zlib.NET
>
>  Yeah, DeflateStream only implements the basic deflate algorithm, with no
configuration options. Worse, it doesn''t have particularly good
compression ratio. Definitely worth investigating a port of a more fully
featured library...
>
>  - John
>
>
>
>  _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib.rb
Type: application/octet-stream
Size: 2672 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/ironruby-core/attachments/20080307/1280a831/attachment.obj

Kim is the dev who works on System.IO.Compression. I asked her about whether
Ruby''s zlib library could be built on top of System.IO.Compression?
Here are her comments and questions. Michael, if you would like to get any
guidance/answers from Kim, she is available for response.


I''m not sure if you saw my blog on this topic, but zlib can be
implemented by wrapping our DeflateStream with the header/checksum modifications
described in the blog.
http://blogs.msdn.com/bclteam/archive/2007/05/16/system-io-compression-capabilities-kim-hamilton.aspx

John (Lam) asked me about that blog in the past. At the time I looked at the
Ruby docs to see what would be missing from a zlib implementation created that
way. These were the issues:
*              Zlib::Deflate.set_dictionary: we don''t support preset
dictionaries. Do you have a feel for how common it is to use present
dictionaries in Ruby?
*              We don''t support compression levels, as in
Zlib::Deflate.delate(level).

Both of these can be worked around, but these are ways in which our capabilities
are inferior if the workaround above is used.

Thanks,
Shri
Want to work on IronPython, IronRuby,
F#?<http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx>
Visit http://blogs.msdn.com/ironpython



-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of John Messerly
Sent: Thursday, March 06, 2008 11:43 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] External libraries implementation status update



Michael Letterle:


> Alright, I started doing this tonight (finally)  GZip was pretty
> straight forward, but Inflate may be a problem,  The
> System::IO::Compression.DeflateStream is RFC 1951 compliant /not/
> 1950.. Meaning it only covers Deflate, not ZLib in general. See here:
> https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
> F
> eedbackID=97064&wa=wsignin1.0
>
> I''ll research this more tomorrow, I''d hate to have to
have an external
> dependency like Zlib.NET


Yeah, DeflateStream only implements the basic deflate algorithm, with no
configuration options. Worse, it doesn''t have particularly good
compression ratio. Definitely worth investigating a port of a more fully
featured library...



- John



_______________________________________________

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/20080307/a7f97ccc/attachment-0001.html

Shri and Kate,

Thank you for the reply and for researching this.  I pretty much came
to the same conclusion, the file I posted earlier pretty much takes
the approach outlined below.  At this point I''m actually attempting to
implement zlib in pure ruby.  I''m curious to see the performance in
both MRI and IronRuby...

On Fri, Mar 7, 2008 at 6:03 PM, Shri Borde <Shri.Borde at microsoft.com>
wrote:
>
>
>
>
> Kim is the dev who works on System.IO.Compression. I asked her about
whether
> Ruby''s zlib library could be built on top of
System.IO.Compression? Here are
> her comments and questions. Michael, if you would like to get any
> guidance/answers from Kim, she is available for response.
>
>
>
>
>
> I''m not sure if you saw my blog on this topic, but zlib can be
implemented
> by wrapping our DeflateStream with the header/checksum modifications
> described in the blog.
>
>
http://blogs.msdn.com/bclteam/archive/2007/05/16/system-io-compression-capabilities-kim-hamilton.aspx
>
>
>
> John (Lam) asked me about that blog in the past. At the time I looked at
the
> Ruby docs to see what would be missing from a zlib implementation created
> that way. These were the issues:
>
> ?              Zlib::Deflate.set_dictionary: we don''t support
preset
> dictionaries. Do you have a feel for how common it is to use present
> dictionaries in Ruby?
>
> ?              We don''t support compression levels, as in
> Zlib::Deflate.delate(level).
>
>
>
> Both of these can be worked around, but these are ways in which our
> capabilities are inferior if the workaround above is used.
>
>
>
> Thanks,
>
> Shri
>
> Want to work on IronPython, IronRuby, F#? Visit
> http://blogs.msdn.com/ironpython
>
>
>
> -----Original Message-----
>  From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Messerly
>  Sent: Thursday, March 06, 2008 11:43 PM
>  To: ironruby-core at rubyforge.org
>  Subject: Re: [Ironruby-core] External libraries implementation status
> update
>
>
>
> Michael Letterle:
>
>
>
> > Alright, I started doing this tonight (finally)  GZip was pretty
>
> > straight forward, but Inflate may be a problem,  The
>
> > System::IO::Compression.DeflateStream is RFC 1951 compliant /not/
>
> > 1950.. Meaning it only covers Deflate, not ZLib in general. See here:
>
> > https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
>
> > F
>
> > eedbackID=97064&wa=wsignin1.0
>
> >
>
> > I''ll research this more tomorrow, I''d hate to have
to have an external
>
> > dependency like Zlib.NET
>
>
>
> Yeah, DeflateStream only implements the basic deflate algorithm, with no
> configuration options. Worse, it doesn''t have particularly good
compression
> ratio. Definitely worth investigating a port of a more fully featured
> library...
>
>
>
> - John
>
>
>
> _______________________________________________
>
> Ironruby-core mailing list
>
> Ironruby-core at rubyforge.org
>
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

Michael Letterle wrote:
> Shri and Kate,
> 
> Thank you for the reply and for researching this.  I pretty much came
> to the same conclusion, the file I posted earlier pretty much takes
> the approach outlined below.  At this point I''m actually
attempting to
> implement zlib in pure ruby.  I''m curious to see the performance
in
> both MRI and IronRuby...
This is cool..will you release it as a separate project? I'' dlike to
try
it in JRuby too, and the Rubinius guys might be interested as well 
(since they have some unholy love for turtles, or something).

- Charlie

That''s the plan, I saw some other people asking for it as well...
I''m
not sure it''s a GREAT idea, especially without some optimizations...
but what I got I''ll be posting.

On Mon, Mar 10, 2008 at 5:16 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> Michael Letterle wrote:
>  > Shri and Kate,
>  >
>  > Thank you for the reply and for researching this.  I pretty much came
>  > to the same conclusion, the file I posted earlier pretty much takes
>  > the approach outlined below.  At this point I''m actually
attempting to
>  > implement zlib in pure ruby.  I''m curious to see the
performance in
>  > both MRI and IronRuby...
>
>  This is cool..will you release it as a separate project? I'' dlike
to try
>  it in JRuby too, and the Rubinius guys might be interested as well
>  (since they have some unholy love for turtles, or something).
>
>  - Charlie
>
>
> _______________________________________________
>  Ironruby-core mailing list
>  Ironruby-core at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

On 3/6/08, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>
> strscan.so:
>  - any progress Curt?
I was under the impression that I had finished this, but I''m thousands
of miles away from being able to check.  Have you tried to use
StringScanner?

--
Curt Hagenlocher
curt at hagenlocher.org

I''ve got the rubyforge project up for the pure ruby zlib
implementation, SVN has what I got so far, which is basically just
Zlib::Inflate, http://rubyforge.org/projects/zliby/  it''s rough, but
I''m adding to it.

On Fri, Mar 7, 2008 at 5:46 PM, Michael Letterle
<michael.letterle at gmail.com> wrote:
> I''d like to implement zlib in pure ruby, but in the mean time, I
think
>  this should be good enough. Time will tell.  Once we get a good
>  collection of these libraries together we''ll be able to see
what''s
>  really needed ;)
>
>  Anyway, updated zlib.rb attached, it performs the Gzip and Zlib
>  decompression... I''m not sure exactly what finish is suppose to
do,
>  the docs are unclear.  I suspect it may not be applicable to the way
>  I''m returning the decompressed output...
>
>
>
>  On Fri, Mar 7, 2008 at 2:43 AM, John Messerly <jomes at
microsoft.com> wrote:
>  > Michael Letterle:
>  >
>  >
>  >  > Alright, I started doing this tonight (finally)  GZip was
pretty
>  >  > straight forward, but Inflate may be a problem,  The
>  >  > System::IO::Compression.DeflateStream is RFC 1951 compliant
/not/
>  >  > 1950.. Meaning it only covers Deflate, not ZLib in general. See
here:
>  >  >
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
>  >  > F
>  >  > eedbackID=97064&wa=wsignin1.0
>  >  >
>  >  > I''ll research this more tomorrow, I''d hate to
have to have an external
>  >  > dependency like Zlib.NET
>  >
>  >  Yeah, DeflateStream only implements the basic deflate algorithm,
with no configuration options. Worse, it doesn''t have particularly good
compression ratio. Definitely worth investigating a port of a more fully
featured library...
>  >
>  >  - John
>  >
>  >
>  >
>  >  _______________________________________________
>  >  Ironruby-core mailing list
>  >  Ironruby-core at rubyforge.org
>  >  http://rubyforge.org/mailman/listinfo/ironruby-core
>  >
>
>
>
>
>
> --
>  Michael Letterle
>  [Polymath Programmer]
>  http://michaeldotnet.blogspot.com
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

Just an FYI, I made the first offical release, Zliby
(http://rubyforge.org/projects/zliby/), it does Gzip decompression as
well as Zlib decompression, and implements all the methods that Dr.
Kelly listed.  Note though it does rely on a few methods not yet
implemented, notably Time.at and block_given?  ... I''ll get back to
you on that ;)

On Tue, Mar 11, 2008 at 2:20 PM, Michael Letterle
<michael.letterle at gmail.com> wrote:
> I''ve got the rubyforge project up for the pure ruby zlib
>  implementation, SVN has what I got so far, which is basically just
>  Zlib::Inflate, http://rubyforge.org/projects/zliby/  it''s rough,
but
>  I''m adding to it.
>
>  On Fri, Mar 7, 2008 at 5:46 PM, Michael Letterle
>
> <michael.letterle at gmail.com> wrote:
>
>
> > I''d like to implement zlib in pure ruby, but in the mean
time, I think
>  >  this should be good enough. Time will tell.  Once we get a good
>  >  collection of these libraries together we''ll be able to see
what''s
>  >  really needed ;)
>  >
>  >  Anyway, updated zlib.rb attached, it performs the Gzip and Zlib
>  >  decompression... I''m not sure exactly what finish is
suppose to do,
>  >  the docs are unclear.  I suspect it may not be applicable to the way
>  >  I''m returning the decompressed output...
>  >
>  >
>  >
>  >  On Fri, Mar 7, 2008 at 2:43 AM, John Messerly <jomes at
microsoft.com> wrote:
>  >  > Michael Letterle:
>  >  >
>  >  >
>  >  >  > Alright, I started doing this tonight (finally)  GZip was
pretty
>  >  >  > straight forward, but Inflate may be a problem,  The
>  >  >  > System::IO::Compression.DeflateStream is RFC 1951
compliant /not/
>  >  >  > 1950.. Meaning it only covers Deflate, not ZLib in
general. See here:
>  >  >  >
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
>  >  >  > F
>  >  >  > eedbackID=97064&wa=wsignin1.0
>  >  >  >
>  >  >  > I''ll research this more tomorrow, I''d
hate to have to have an external
>  >  >  > dependency like Zlib.NET
>  >  >
>  >  >  Yeah, DeflateStream only implements the basic deflate
algorithm, with no configuration options. Worse, it doesn''t have
particularly good compression ratio. Definitely worth investigating a port of a
more fully featured library...
>  >  >
>  >  >  - John
>  >  >
>  >  >
>  >  >
>  >  >  _______________________________________________
>  >  >  Ironruby-core mailing list
>  >  >  Ironruby-core at rubyforge.org
>  >  >  http://rubyforge.org/mailman/listinfo/ironruby-core
>  >  >
>  >
>  >
>  >
>  >
>  >
>  > --
>  >  Michael Letterle
>  >  [Polymath Programmer]
>  >  http://michaeldotnet.blogspot.com
>  >
>
>
>
>  --
>  Michael Letterle
>  [Polymath Prokrammer]
>  http://blog.prokrams.com
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

> From: Curt Hagenlocher
> Sent: Tuesday, 11 March 2008 8:13 PM
> Subject: Re: [Ironruby-core] External libraries implementation status
update
>
> On 3/6/08, Wayne Kelly <w.kelly at qut.edu.au> wrote:
> >
> > strscan.so:
> >  - any progress Curt?
>
> I was under the impression that I had finished this, but I''m
> thousands of miles away from being able to check.  Have you
> tried to use StringScanner?
OK, sorry, I didn''t realize that this external module was already
implemented as a Builtin.

Cheers, Wayne.

On Mon, Mar 17, 2008 at 11:32 PM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>
>> I was under the impression that I had finished this, but I''m
>> thousands of miles away from being able to check.  Have you
>> tried to use StringScanner?
>
> I didn''t realize that this external module was already implemented
as a Builtin.
Yeah, there''s no mechanism yet for loading it from an external module.
 Or at least, there wasn''t when it was implemented.

--
Curt Hagenlocher
curt at hagenlocher.org