Hi, I''d like to request a quick implementation status update on the Ruby standard libraries that contain native code ... If you are working on any of the following or know any additional information about any of the following, could you please post a followup email? The following standard libraries are implemented at least to some degree in the IronRuby.Libraries assembly (not sure which are totally complete): digest.so -> IronRuby.Libraries\Digest\Digest.cs digest\md5.so -> IronRuby.Libraries\Digest\Digest.cs openssl.so -> IronRuby.Libraries\OpenSSL\OpenSSL.cs socket.so -> IronRuby.Libraries\Builtin\Socket.cs strscan.so -> IronRuby.Libraries\Builtin\StringScanner.cs zlib.so -> IronRuby.Libraries\Zlib\zlib.cs The following libraries are used by the simple gem and rails use cases that I''ve been investigating, but don''t yet have a checked implementation: digest/sha1.so bigdecimal.so enumerator.so etc.so fcntl.so nkf.so -> Andrew Peters? racc/cparse.so stringio.so -> Eduardo? syck.so -> John Messerly? thread.so -> can be replaced by original thread.rb? Win32API.so -> can be just deleted? The following libraries are not used in any of the simple gems and rails use cases that I''ve been considering. (please let us know if there are any in here that you think should be made a priority): curses.so dbm.so -> used by YAML? dl.so -> used by sqlite3 driver? gdbm.so iconv.so -> used by actionmailer? io.so pty.so readline -> used by debug.rb sdbm.so syslog.so tk.so win32ole.so Cheers, Wayne.
I have been working on the Socket library. John Lam, recently posted a code-review of a patch that I had submitted to RubyForge. I expect the modified patch to get pushed through the process soon. This patch hits most of the Socket classes but not Socket itself. Meanwhile, I have implemented the rest of the Socket class and started working on RSpecs for it. Once these changes are submitted and accepted into the fold then all the methods picked up by Wayne as being required for the specified Rails cases will be implemented. Pete
Just so you are aware, when we switch to the new spec suite (this week after the DLR tuple fix) we will have a location for those specs in /specs/ruby/1.8/core/library/socket. There are existing files in my shelveset, but not many of them have more than the requires. JD -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Monday, May 12, 2008 5:58 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Standard library inventory I have been working on the Socket library. John Lam, recently posted a code-review of a patch that I had submitted to RubyForge. I expect the modified patch to get pushed through the process soon. This patch hits most of the Socket classes but not Socket itself. Meanwhile, I have implemented the rest of the Socket class and started working on RSpecs for it. Once these changes are submitted and accepted into the fold then all the methods picked up by Wayne as being required for the specified Rails cases will be implemented. Pete _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
I''m working on NKF which was the first blocker I encountered after I started looking at sqlite3-ruby. Is anyone else working on sqlite? Andrew. On Tue, May 13, 2008 at 4:49 AM, Jim Deville <jdeville at microsoft.com> wrote:> Just so you are aware, when we switch to the new spec suite (this week > after the DLR tuple fix) we will have a location for those specs in > /specs/ruby/1.8/core/library/socket. There are existing files in my > shelveset, but not many of them have more than the requires. > > JD > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin > Sent: Monday, May 12, 2008 5:58 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Standard library inventory > > I have been working on the Socket library. John Lam, recently posted a > code-review of a patch that I had submitted to RubyForge. I expect the > modified patch to get pushed through the process soon. This patch hits > most > of the Socket classes but not Socket itself. > > Meanwhile, I have implemented the rest of the Socket class and started > working on RSpecs for it. > > Once these changes are submitted and accepted into the fold then all the > methods picked up by Wayne as being required for the specified Rails cases > will be implemented. > > Pete > > > _______________________________________________ > 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/20080513/748f1f4b/attachment-0001.html>
Hi all, I can confirm that the ability to run some simple activerecord/activesupport use cases is currently blocked only by the absence of implementations of the libraries listed in Wayne''s post, plus some major bugs like #19805 and #19971. If anyone is interested, I have also attached an implementation of enumerator in pure Ruby as a replacement for enumerator.so. Once I can get activerecord up and running I should be able to do some meaningful testing of the SQLite3 and MySQL drivers that I have been working on... Regards, Brian On Mon, 12 May 2008 22:24:50 +1000, "Wayne Kelly" <w.kelly at qut.edu.au> said:> Hi, > > I''d like to request a quick implementation status update on the Ruby > standard libraries that contain native code ... > > If you are working on any of the following or know any additional > information about any of the following, could you please post a followup > email? > > The following standard libraries are implemented at least to some degree > in the IronRuby.Libraries assembly (not sure which are totally complete): > digest.so -> IronRuby.Libraries\Digest\Digest.cs > digest\md5.so -> IronRuby.Libraries\Digest\Digest.cs > openssl.so -> IronRuby.Libraries\OpenSSL\OpenSSL.cs > socket.so -> IronRuby.Libraries\Builtin\Socket.cs > strscan.so -> IronRuby.Libraries\Builtin\StringScanner.cs > zlib.so -> IronRuby.Libraries\Zlib\zlib.cs > > The following libraries are used by the simple gem and rails use cases > that I''ve been investigating, but don''t yet have a checked > implementation: > digest/sha1.so > bigdecimal.so > enumerator.so > etc.so > fcntl.so > nkf.so -> Andrew Peters? > racc/cparse.so > stringio.so -> Eduardo? > syck.so -> John Messerly? > thread.so -> can be replaced by original thread.rb? > Win32API.so -> can be just deleted? > > The following libraries are not used in any of the simple gems and rails > use cases that I''ve been considering. (please let us know if there are > any in here that you think should be made a priority): > curses.so > dbm.so -> used by YAML? > dl.so -> used by sqlite3 driver? > gdbm.so > iconv.so -> used by actionmailer? > io.so > pty.so > readline -> used by debug.rb > sdbm.so > syslog.so > tk.so > win32ole.so > > Cheers, Wayne. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-------------- next part -------------- A non-text attachment was scrubbed... Name: enumerator.rb Type: application/octet-stream Size: 1750 bytes Desc: not available URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080513/f1f21658/attachment.obj>
Michael Letterle:> I can confirm that the ability to run some simple > activerecord/activesupport use cases is currently blocked only by the > absence of implementations of the libraries listed in Wayne''s post, > plus some major bugs like #19805 and #19971. If anyone is interested, I > have also attached an implementation of enumerator in pure Ruby as a > replacement for enumerator.so.We have a fix for #19971 coming by Wednesday at the latest. #19805 is already fixed and will show up in the next release. Thanks, -John