How do I tell when I'm on Cygwin?

[James Edward Gray II]

HighLine has some code like this:

begin
require "Win32API"

if # I'm looking for the line that goes right here (see below).
raise LoadError, "On Cygwin, not pure Windows."
end

# assume we're on Windows here...
rescue LoadError
# assume we're on a Posix OS here...
end

The problem is that Cygwin is using the Windows code and the Posix
code would be a better choice there. What's a test I can use to
detect Cygwin in this scenario?

James Edward Gray II

 

[ara.t.howard]

HighLine has some code like this:

begin
require "Win32API"

if # I'm looking for the line that goes right here (see below).
raise LoadError, "On Cygwin, not pure Windows."
end

# assume we're on Windows here...
rescue LoadError
# assume we're on a Posix OS here...
end

The problem is that Cygwin is using the Windows code and the Posix code would
be a better choice there. What's a test I can use to detect Cygwin in this
scenario?

James Edward Gray II

posix = Process.fork{} and Process.wait rescue nil


-a

 

[Wilson Bilkovich]

posix = Process.fork{} and Process.wait rescue nil

Everyone, please remember that Ara is kidding about this. Please do
not let this become an idiom.
The fact that the Win32 version of Ruby doesn't support fork is a
temporary and unfortunate implementation detail, not something you can
rely on.

 

[ara.t.howard]

Everyone, please remember that Ara is kidding about this. Please do not let
this become an idiom. The fact that the Win32 version of Ruby doesn't
support fork is a temporary and unfortunate implementation detail, not
something you can rely on.

you are spoiling all the fun!

;-)

-a

 

[Gregory Brown]

I /think/ RUBY_PLATFORM is different for cygwin than the pure windows
version, but I don't have a cygwin install nearby to confirm. Perhaps

Via One click installer in regular windows:

irb(main):001:0> RUBY_PLATFORM
=> "i386-mswin32"

On CYGWIN:

irb(main):001:0> RUBY_PLATFORM
=> "i386-cygwin"

 

[M. Edward (Ed) Borasky]

you are spoiling all the fun!

;-)

-a

It's easier even than that ... just look up. If Austin Ziegler is
sneering at you, you're on CygWin.

<ducking>

 

[Gregory Brown]

It's easier even than that ... just look up. If Austin Ziegler is
sneering at you, you're on CygWin.

But that's not true. You can get an identical scenario if you browse to:
shootout.alioth.debian.org

 

[James Edward Gray II]

irb(main):001:0> RUBY_PLATFORM
=> "i386-cygwin"

It seems safer to target this one as an exception, rather than mswin,
so I'll go with that.

One last question though, if Termios was installed for Cygwin would
it work OK there? I'm trying to figure out if I need to bypass
HighLine's search for that too.

Thanks for the help all.

James Edward Gray II

 

[Gregory Brown]

It seems safer to target this one as an exception, rather than mswin,
so I'll go with that.

One last question though, if Termios was installed for Cygwin would
it work OK there? I'm trying to figure out if I need to bypass
HighLine's search for that too.

I have no idea how to install termios for Cygwin since it's not part
of the standard distribution (i don't think), and I'm not really a
Cygwin user.

However, stty is included with Cygwin, so I think highline would work
using that.

 

[M. Edward (Ed) Borasky]

I have no idea how to install termios for Cygwin since it's not part
of the standard distribution (i don't think), and I'm not really a
Cygwin user.

However, stty is included with Cygwin, so I think highline would work
using that.

Just about anything that will compile and execute on Linux will compile
and execute on CygWin. However, since the Ruby community has deprecated
CygWin, I'm not sure why new code should do other than detect it and
complain.

When I run software on a Windows machine, my preference is for native
tools, with CygWin a "plan B" and a Gentoo virtual machine as "plan C".

 

[ara.t.howard]

However, since the Ruby community has deprecated
CygWin, I'm not sure why new code should do other than detect it and
complain.

hi ed - what exactly do you mean by that?

-a

 

[M. Edward (Ed) Borasky]

hi ed - what exactly do you mean by that?

-a

I'm not sure ... I just know every time I mention that I like CygWin
here, I get yelled at.

 

[Gregory Brown]

I'm not sure ... I just know every time I mention that I like CygWin
here, I get yelled at.

Hey, SHUT UP! ;-)

I think it's just that One-Click installer is the preferred method and
is better supported. The philosophical arguments about Cygwin aside,
of course.

 

[Wilson Bilkovich]

I'm not sure ... I just know every time I mention that I like CygWin
here, I get yelled at.

The only real reason not to use it that I'm aware of is that it is fairly slow.
Of course, the native Ruby on Win32 is 10x slower than on Linux for
many tasks, so maybe that's not much of a selling point.

 

[M. Edward (Ed) Borasky]

The only real reason not to use it that I'm aware of is that it is
fairly slow.
Of course, the native Ruby on Win32 is 10x slower than on Linux for
many tasks, so maybe that's not much of a selling point.

Really? Curt, Austin? Is native (one-click) Ruby 1.8.5 slower on, say, a
933 MHz Pentium III running Windows than, say, a gcc-compiled (O2) Ruby
on the same hardware?

Let me drag out my matrix benchmark and dual-booted (Win XP and Gentoo
Linux) Athlon XP laptop and see for myself!

Be back later, as they say in IRC!

 

[Austin Ziegler]

Really? Curt, Austin? Is native (one-click) Ruby 1.8.5 slower on, say, a
933 MHz Pentium III running Windows than, say, a gcc-compiled (O2) Ruby
on the same hardware?

This is mostly because we're not using the latest compiler. That's one
reason I've been pushing so hard for the use of MSVC8 instead of
MSVC6. A MinGW compile is about 5 - 10% faster than the current MSVC6
(because even the slightly older GCC 3.x is a better compiler than the
many-years-old MSVC6). An MSVC8 compile would be up to 30% faster,
IIRC. I'd have to do some benchmarking, but I'm not on a Windows
machine with that right now.

-austin

 

[Austin Ziegler]

I've found this true before. The Cygwin version simply performs better by a
significant margin than the one-click.

I will run some benchmarks again and post as well, as I don't have the old
figures handy.

It's not Cygwin that's faster; it's GCC. You're comparing VC6 -- which
is a compiler released in 1998 -- to GCC 3.4.x released in 2004 or
later. Cygwin may be able to perform even faster, because it may
include GCC 4.x (I don't know; I stopped using Cygwin as soon as I
found more useful tools that didn't require the whole bloody
framework). Cygwin, on the other hand, will impose a certain amount of
overhead because everything essentially goes through the GPLed cygwin
DLL (and that licence choice, my friends, is part of the reason we
shouldn't default to a Cygwin install in any case).

A MinGW build will perform faster than the VC6 build because of six
years of compiler optimizations applied -- to compare apples to
apples, use GCC 2.8 or EGCS 1.1. I suspect that the performance of
Ruby compiled with GCC 2.8 would, well, suck. A VC8 build will perform
faster than either a MinGW build or a VC6 build -- but there are other
tradeoffs that are turning out to be rather hard to deal with and
require assistance from Microsoft. To the limit of what compiler
optimizations make a difference, in any case.

I have little nice to say about Cygwin when people bring it up as a
solution, because it IS *NOT* a "solution" on Windows. It's a hack; a
workaround. It's good to use when you absolutely must use Unix
software that the developers have been too damned lazy to actually
*port* the software to Windows. It's really not much better than using
WINE to run Windows software. It'll work, but that doesn't mean you
really *want* to use it if you don't absolutely have to.

Please, try to compare apples to apples.

If Matz, as usual, has a 1.8.6 release for Christmas (Matz?) I will be
recommending Curt use MinGW to compile Ruby for Windows. The
discussions that are going on with Microsoft will be continuing with
the preferred target for the VC8 build being next year's 1.9.1,
because I suspect it will take nearly that long to build the support
tools we need to make this work properly.

-austin

 

[ara.t.howard]

If Matz, as usual, has a 1.8.6 release for Christmas (Matz?) I will be
recommending Curt use MinGW to compile Ruby for Windows. The
discussions that are going on with Microsoft will be continuing with
the preferred target for the VC8 build being next year's 1.9.1,
because I suspect it will take nearly that long to build the support
tools we need to make this work properly.

thanks for working on this and keeping us in the loop austin.

i'd like to volunteer to help get gsl and narray in the dist if a msys build
comes to fruition - there are few hacks i had to make and it would save
someone some time if i could relate them.

it would be a huge boost to the science world if ruby came out of the box with
a good matrix toolkit like narray and the vast array of scientific codes that
is the gsl.

kind regards.

-a

 

[M. Edward (Ed) Borasky]

I have little nice to say about Cygwin when people bring it up as a
solution, because it IS *NOT* a "solution" on Windows. It's a hack; a
workaround. It's good to use when you absolutely must use Unix
software that the developers have been too damned lazy to actually
*port* the software to Windows.

Amen! But ... it's a boatload less expensive than Reflection X.

If Matz, as usual, has a 1.8.6 release for Christmas (Matz?) I will be
recommending Curt use MinGW to compile Ruby for Windows.

As opposed to a cross-compile with GCC 4.1.1 on a Linux system? Just out
of curiosity, how is the Ruby on a MacOS machine compiled? Then again,
if we are helping Microsoft get VC8 "Ruby Ready", should we be helping
MinGW too?

 

[M. Edward (Ed) Borasky]

thanks for working on this and keeping us in the loop austin.

i'd like to volunteer to help get gsl and narray in the dist if a msys
build
comes to fruition - there are few hacks i had to make and it would save
someone some time if i could relate them.

it would be a huge boost to the science world if ruby came out of the
box with
a good matrix toolkit like narray and the vast array of scientific codes
that
is the gsl.

kind regards.

-a

1. Yeah, if I can't have narray into the core language, it ought to be
in the standard library.

2. Dang, ara, you're gonna make me learn how to work SWIG on Windows,
aren't you?

Seriously, though, once I get all my RAMEAU magic working on its
birthplace, Gentoo Linux, I'd accept some help porting it to Windows and
Macs.

Speaking of which, the goals part of the RAMEAU overview is posted at

http://rubyforge.org/cgi-bin/viewvc.cgi/Rameau/Rameau.pdf?root=cougar&view=co

I'm expecting the first release "Christmas 2006", to continue in the
fine Ruby tradition. I'm not planning to have GSL in the first release,
though, mostly because I don't think I need it given that I'll have R.

By the way, in RAMEAU, I'm trying to stay scripting-language agnostic.
The implementation will use/require Ruby for all the build automation
tasks, and all the test cases and examples will be written in Ruby, but
I don't want to do anything that would rule out users with Perl, Python,
or Tcl/Tk skills using the package. SWIG makes that easy.

But Rake makes it agile and pragmatic.