WinRuby?

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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Heesob Park <phasisgmail.com> wrote:
> Hi,
>
>
> 2007/9/24, Daniel Berger <djberg96gmail.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.c
odegear.com/products/3rdrail) could be
> the reliable distributer.
>
> Regards,
>
> Park Heesob
>
>
> _______________________________________________
> win32utils-devel mailing list
> win32utils-develrubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel

>

Are we planing to support "fork" in a ActiveState
sort of way?

pth
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Patrick Hurley <phurleygmail.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.

Regards,

Dan
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Daniel Berger <djberg96gmail.com> wrote:
> On 9/23/07, Patrick Hurley <phurleygmail.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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Daniel Berger <djberg96gmail.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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Patrick Hurley <phurleygmail.com> wrote:
> On 9/23/07, Daniel Berger <djberg96gmail.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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Daniel Berger <djberg96gmail.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.cab
oo.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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/23/07, Luis Lavena <luislavenagmail.com> wrote:
> On 9/23/07, Daniel Berger <djberg96gmail.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.cab
oo.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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel

On 9/24/07, Daniel Berger <djberg96gmail.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
_______________________________________________
win32utils-devel mailing list
win32utils-develrubyforge.org
http://rubyforge.org/mailman/listinfo/win32utils-devel