Hi all, With the latest 1.8.6 release out today, I was wondering - what would you all think of a Windows-only fork of Ruby? I mean Perl has ActiveState, right? It ships with a slightly different interpreter and different libraries, so why not Ruby? Here''s what I''m thinking: * Win2k or later. No 95/98/ME support. No cygwin/mingw, either. * Assume VC++ 8. Use whatever switches we want to optimize. * Scrap huge chunks of the stdlib, and add new libraries. * Use Windows specific functions where beneficial. * Remove UNIX-only functions/methods (or create equivalent functions). * TCHAR through and through, with possible Unicode benefits down the road. * ANSI C Areas I''m looking to improve specifically: File File::Stat Dir IO Process Socket Kernel#select Areas I''m looking to improve in general: Speed Tests (tailored for Windows) More Speed More Tests But, before I dive into this I would need serious help. How many of you would be willing to join me? I''m really looking for people who know C/C++, are at least somewhat familiar with the Windows API, and are willing to have commit access. On the other hand, if you absolutely HATE the idea, please say so. I don''t want to chase anyone away. :) Lemme know! Regards, Dan
Hi, 2007/9/24, Daniel Berger <djberg96 at gmail.com>:> > Hi all, > > With the latest 1.8.6 release out today, I was wondering - what would > you all think of a Windows-only fork of Ruby? I mean Perl has > ActiveState, right? It ships with a slightly different interpreter and > different libraries, so why not Ruby? > > Here''s what I''m thinking: > > * Win2k or later. No 95/98/ME support. No cygwin/mingw, either. > * Assume VC++ 8. Use whatever switches we want to optimize. > * Scrap huge chunks of the stdlib, and add new libraries. > * Use Windows specific functions where beneficial. > * Remove UNIX-only functions/methods (or create equivalent functions). > * TCHAR through and through, with possible Unicode benefits down the road. > * ANSI C > > > Areas I''m looking to improve specifically: > > File > File::Stat > Dir > IO > Process > Socket > Kernel#select > > Areas I''m looking to improve in general: > > Speed > Tests (tailored for Windows) > More Speed > More Tests > > But, before I dive into this I would need serious help. How many of you > would be willing to join me? I''m really looking for people who know > C/C++, are at least somewhat familiar with the Windows API, and are > willing to have commit access. > > On the other hand, if you absolutely HATE the idea, please say so. I > don''t want to chase anyone away. :) > > Lemme know!I agree totally with you. And I also hope the win32 native thread support if possible. The another area is the interface with .NET framework support(it is called IronRuby). I think if we made the WinRuby, the 3rdrail( http://www.codegear.com/products/3rdrail) could be the reliable distributer. Regards, Park Heesob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/win32utils-devel/attachments/20070924/4fac159a/attachment-0001.html
On 9/23/07, Heesob Park <phasis at gmail.com> wrote:> Hi, > > > 2007/9/24, Daniel Berger <djberg96 at gmail.com>: > > Hi all, > > > > With the latest 1.8.6 release out today, I was wondering - what would > > you all think of a Windows-only fork of Ruby? I mean Perl has > > ActiveState, right? It ships with a slightly different interpreter and > > different libraries, so why not Ruby? > > > > Here''s what I''m thinking: > > > > * Win2k or later. No 95/98/ME support. No cygwin/mingw, either. > > * Assume VC++ 8. Use whatever switches we want to optimize. > > * Scrap huge chunks of the stdlib, and add new libraries. > > * Use Windows specific functions where beneficial. > > * Remove UNIX-only functions/methods (or create equivalent functions). > > * TCHAR through and through, with possible Unicode benefits down the road. > > * ANSI C > > > > > > Areas I''m looking to improve specifically: > > > > File > > File::Stat > > Dir > > IO > > Process > > Socket > > Kernel#select > > > > Areas I''m looking to improve in general: > > > > Speed > > Tests (tailored for Windows) > > More Speed > > More Tests > > > > But, before I dive into this I would need serious help. How many of you > > would be willing to join me? I''m really looking for people who know > > C/C++, are at least somewhat familiar with the Windows API, and are > > willing to have commit access. > > > > On the other hand, if you absolutely HATE the idea, please say so. I > > don''t want to chase anyone away. :) > > > > Lemme know! > > > I agree totally with you. > > And I also hope the win32 native thread support if possible. > > The another area is the interface with .NET framework support(it is called > IronRuby). > > I think if we made the WinRuby, the > 3rdrail(http://www.codegear.com/products/3rdrail) could be > the reliable distributer. > > Regards, > > Park Heesob > > > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >Are we planing to support "fork" in a ActiveState sort of way? pth
On 9/23/07, Patrick Hurley <phurley at gmail.com> wrote: <snip>> Are we planing to support "fork" in a ActiveState sort of way? > > pthI''m open to at least trying, but we should probably look at the latest AS Perl implementation. But, that''s down the road a bit. My inclination is to fix Kernel#select first and see what falls out from that. Regards, Dan
On 9/23/07, Daniel Berger <djberg96 at gmail.com> wrote:> On 9/23/07, Patrick Hurley <phurley at gmail.com> wrote: > > <snip> > > > Are we planing to support "fork" in a ActiveState sort of way? > > > > pth > > I''m open to at least trying, but we should probably look at the latest > AS Perl implementation. But, that''s down the road a bit. My > inclination is to fix Kernel#select first and see what falls out from > that.As a followup to that I''m considering turning Process into a class, and implementing Process.new so we can have lightweight processes ((or something along those lines). It was you, Patrick, that convinced me that we need both native threads AND lightweight processes of some sort. :) Regards, Dan
On 9/23/07, Daniel Berger <djberg96 at gmail.com> wrote:> As a followup to that I''m considering turning Process into a class, > and implementing Process.new so we can have lightweight processes ((or > something along those lines). It was you, Patrick, that convinced me > that we need both native threads AND lightweight processes of some > sort. :)So are you thinking something along the lines of Evan Phonix''s syndey, with a single global VM lock? pth
On 9/23/07, Patrick Hurley <phurley at gmail.com> wrote:> On 9/23/07, Daniel Berger <djberg96 at gmail.com> wrote: > > As a followup to that I''m considering turning Process into a class, > > and implementing Process.new so we can have lightweight processes ((or > > something along those lines). It was you, Patrick, that convinced me > > that we need both native threads AND lightweight processes of some > > sort. :) > > So are you thinking something along the lines of Evan Phonix''s syndey, > with a single global VM lock?I''m not sure yet. That''s down the road. For the early stages I just want to get the base classes and stdlib cleaned up, refactored, and sped up where possible. Regards, Dan
On 9/23/07, Daniel Berger <djberg96 at gmail.com> wrote:> > I''m not sure yet. That''s down the road. For the early stages I just > want to get the base classes and stdlib cleaned up, refactored, and > sped up where possible. > > Regards, > > DanDan, I just done a few rounds of test of latest release of ruby built with VC8, and to be honest, I get better performance from a hand-made build with MinGW. http://pastie.caboo.se/pastes/95210 I have pin-point almost every dependency needed by ruby 1.8.6 and built every extension bundled with it with VC8. The only one that I couldn''t manage to get working was Tk, but I guess we could discard it ;-) Let me know if that helps the process, and I will like to see your VC8 numbers. Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
On 9/23/07, Luis Lavena <luislavena at gmail.com> wrote:> On 9/23/07, Daniel Berger <djberg96 at gmail.com> wrote: > > > > I''m not sure yet. That''s down the road. For the early stages I just > > want to get the base classes and stdlib cleaned up, refactored, and > > sped up where possible. > > > > Regards, > > > > Dan > > Dan, I just done a few rounds of test of latest release of ruby built > with VC8, and to be honest, I get better performance from a hand-made > build with MinGW. > > http://pastie.caboo.se/pastes/95210 > > I have pin-point almost every dependency needed by ruby 1.8.6 and > built every extension bundled with it with VC8. > > The only one that I couldn''t manage to get working was Tk, but I guess > we could discard it ;-) > > Let me know if that helps the process, and I will like to see your VC8 numbers.While that''s interesting, speed isn''t one of the primary factors in making WinRuby. It''s just something I''d like to do along the way. I will not support mingw. VC 8 will be our compiler. Regards, Dan
On 9/24/07, Daniel Berger <djberg96 at gmail.com> wrote:> While that''s interesting, speed isn''t one of the primary factors in > making WinRuby. It''s just something I''d like to do along the way. I > will not support mingw. VC 8 will be our compiler. >Um, even that speed is one concern. I sympathize with you. With latest free compiler released by microsoft, we could provide a good fundation and could be easily expanded by end users (like solve the issue of no compilers will compile extensions for current release of ruby). As I said, I want to offer the time I invested in solve the dependencies to get base ruby built with VC8.>From the 21 official extensions (bundled with current mswin32 build),I only failed to build 2: tk and tk/tkutil. http://pastie.caboo.se/100080 I didn''t take the msbuild / solutions path since to create them it requires VisualStudio, which I didn''t installed to avoid conflict with free compiler distro. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
I''d like to know everyone'' s opinion of the Rubinius project. It currently doesn''t support Windows, but the developers want to. I know there are a lot of great Windows developers here, so would the Rubinius project be a good place to start on a good Windows Ruby implementation? regards, Gordon Thiesfeld -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/win32utils-devel/attachments/20071004/33b72fd5/attachment.html
Gordon Thiesfeld wrote:> I''d like to know everyone'' s opinion of the Rubinius project. It > currently doesn''t support Windows, but the developers want to. I know > there are a lot of great Windows developers here, so would the Rubinius > project be a good place to start on a good Windows Ruby implementation?That remains to be seen, and we won''t know until RubyConf 2007 at the earliest. My general impression of Rubinius so far is that any platform without the GNU toolchain is a second class citizen and Windows is a 3rd class citizen. Regards, Dan
On 10/4/07, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote:> I''d like to know everyone'' s opinion of the Rubinius project. It currently > doesn''t support Windows, but the developers want to. I know there are a lot > of great Windows developers here, so would the Rubinius project be a good > place to start on a good Windows Ruby implementation? >Let me correct you on this one: supporting windows right now isn''t important (not that they want to). Besides the GNU toolchain needed by Rubinius, you also need Git, which is a real pain to get working on Windows (outside cygwin, using mingw-git port). So not only you will have to spent time getting Rubinius working on Win32, but also all the toolchain correctly working... that''s a huge problem. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
> Let me correct you on this one: supporting windows right now isn''t > important (not that they want to). > > Besides the GNU toolchain needed by Rubinius, you also need Git, which > is a real pain to get working on Windows (outside cygwin, using > mingw-git port). > > So not only you will have to spent time getting Rubinius working on > Win32, but also all the toolchain correctly working... that''s a huge > problem.Fair enough. I was basing my statements off of a post by Wilson Bilkovich*, where he says he wants to get it to compile on VC8 at some point. I''m not sure of the level of effort that would take, but I thought I''d ask here to get some opinions and see if there was any interest. * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/228625 Thanks, Gordon
On 10/8/07, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote:> > Let me correct you on this one: supporting windows right now isn''t > > important (not that they want to). > > > > Besides the GNU toolchain needed by Rubinius, you also need Git, which > > is a real pain to get working on Windows (outside cygwin, using > > mingw-git port). > > > > So not only you will have to spent time getting Rubinius working on > > Win32, but also all the toolchain correctly working... that''s a huge > > problem. > > Fair enough. I was basing my statements off of a post by Wilson > Bilkovich*, where he says he wants to get it to compile on VC8 at some > point. I''m not sure of the level of effort that would take, but I > thought I''d ask here to get some opinions and see if there was any > interest. > > * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/228625 >>From that post it seems they want to get rid of glib dependency (which is good).Guess that whey they reach that point, someone could step in and implement a configure-like batch file for VC8/VC9. Hopefully when the time comes, mingw-git will be integrated to git and will be more simple to get your copy of rubinius code on windows (I highly doubt about that, but miracles often happens)... -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
On 10/8/07, Luis Lavena <luislavena at gmail.com> wrote:> On 10/8/07, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote: > > > Let me correct you on this one: supporting windows right now isn''t > > > important (not that they want to). > > > > > > Besides the GNU toolchain needed by Rubinius, you also need Git, which > > > is a real pain to get working on Windows (outside cygwin, using > > > mingw-git port). > > > > > > So not only you will have to spent time getting Rubinius working on > > > Win32, but also all the toolchain correctly working... that''s a huge > > > problem. > > > > Fair enough. I was basing my statements off of a post by Wilson > > Bilkovich*, where he says he wants to get it to compile on VC8 at some > > point. I''m not sure of the level of effort that would take, but I > > thought I''d ask here to get some opinions and see if there was any > > interest. > > > > * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/228625 > > > > >From that post it seems they want to get rid of glib dependency (which is good). > > Guess that whey they reach that point, someone could step in and > implement a configure-like batch file for VC8/VC9. > > Hopefully when the time comes, mingw-git will be integrated to git and > will be more simple to get your copy of rubinius code on windows (I > highly doubt about that, but miracles often happens)... > > -- > Luis Lavena > Multimedia systems > - > Leaders are made, they are not born. They are made by hard effort, > which is the price which all of us must pay to achieve any goal that > is worthwhile. > Vince Lombardi > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >Missing git is not the end of the world. They provide an SVN mirror, you cannot commit from it, but that may be enough for porting to windows. I personally believe that Rubinius has the best internal design of any of the "future ruby" implementations -- time will tell if it pays off. Evan seems like a very reasonable guy and I would expect he would welcome porting support to Win32 -- but he is reasonably concentrating on the platforms on which he develops, and the tool chain used on those platforms. pth
On 10/8/07, Patrick Hurley <phurley at gmail.com> wrote:> Missing git is not the end of the world. They provide an SVN mirror, > you cannot commit from it, but that may be enough for porting to > windows.I know is not the end of the world. But providing patches using svn diff instead of git could be problematic (found the strip (-p1) option too complicated when working with different VCS).> I personally believe that Rubinius has the best internal > design of any of the "future ruby" implementations -- time will tell > if it pays off. Evan seems like a very reasonable guy and I would > expect he would welcome porting support to Win32 -- but he is > reasonably concentrating on the platforms on which he develops, and > the tool chain used on those platforms. >I agree on that Rubinius is just an amazing project, and is growing at huge rate. Tried it myself a few weeks back on linux and I must say I''m impressed. Also I understand that you must focus on the task (get it working in the platform he uses) than trying to debug it everywhere before. We should keep on eye on it and maybe provide specs to the language (I checked out the mspec and the spec folder to try it with MRI 1.8). For the time being, 1.8.x is ''production ready'' on win32, could be enhanced and get better features. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi