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
on 17.02.2008 05:43
on 17.02.2008 06:13
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 ;)
on 17.02.2008 14:24
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 18.02.2008 04:11
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.
on 18.02.2008 04:13
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.
on 18.02.2008 04:26
Hi Wayne, This is great! More below... On Sun, 17 Feb 2008 17:29:41 -0700, Wayne Kelly <w.kelly@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
on 18.02.2008 09:31
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@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Wayne Kelly Sent: Sunday, February 17, 2008 4:30 PM To: ironruby-core@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.
on 18.02.2008 14:53
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@qut.edu.au> wrote: > > socket > > > > þ > > > þ > þ > > > > þ > > > > check who is already working on what. I understand that John Messerly is > functionality happening sooner. > Rails we'll want to support IIS 7.0 well on server machines, but for those > -- Michael Letterle [Polymath Programmer] http://michaeldotnet.blogspot.com
on 19.02.2008 06:17
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
on 19.02.2008 06:18
> From: ironruby-core-bounces@rubyforge.org [ironruby-core-bounces@rubyforge.org] On Behalf Of > Michael Letterle [michael.letterle@gmail.com] > Sent: Monday, 18 February 2008 11:52 PM > To: ironruby-core@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.
on 19.02.2008 08:56
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.
on 20.02.2008 07:37
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
on 20.02.2008 13:59
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@microsoft.com> wrote: > -- Michael Letterle [Polymath Programmer] http://michaeldotnet.blogspot.com
on 20.02.2008 17:15
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
on 20.02.2008 21:28
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@microsoft.com> wrote: > [snip] > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Programmer] http://michaeldotnet.blogspot.com
on 21.02.2008 17:29
Michael Letterle: > 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
on 06.03.2008 07:31
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.
on 06.03.2008 14:28
On Thu, Mar 6, 2008 at 1:29 AM, Wayne Kelly <w.kelly@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
on 06.03.2008 21:10
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@gmail.com>
on 06.03.2008 22:58
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@flanders.co.nz>
on 06.03.2008 23:41
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 07.03.2008 05:52
On stringio: I'm finishing some compatibility tests with ruby 1.8.6. Hope send the patch soon for revision. Regards
on 07.03.2008 06:52
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 07.03.2008 08:44
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
on 07.03.2008 22:55
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 08.03.2008 00:11
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
on 10.03.2008 13:54
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@microsoft.com> wrote: > > John (Lam) asked me about that blog in the past. At the time I looked at the > > Want to work on IronPython, IronRuby, F#? Visit > update > > > > library... > > Ironruby-core@rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 10.03.2008 22:18
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
on 10.03.2008 23:08
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@sun.com> wrote: > 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 11.03.2008 11:15
On 3/6/08, Wayne Kelly <w.kelly@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@hagenlocher.org
on 11.03.2008 19:26
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@gmail.com> wrote: > > > > F > > > -- > Michael Letterle > [Polymath Programmer] > http://michaeldotnet.blogspot.com > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 16.03.2008 04:59
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@gmail.com> wrote: > > I'd like to implement zlib in pure ruby, but in the mean time, I think > > > > > > eedbackID=97064&wa=wsignin1.0 > > > _______________________________________________ > > Michael Letterle > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 18.03.2008 07:38
> 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 18.03.2008 07:51
On Mon, Mar 17, 2008 at 11:32 PM, Wayne Kelly <w.kelly@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@hagenlocher.org