Mongrel doesn't start under Rails 2.0.2/Win XP

On Jan 12, 2008 5:06 PM, Will G. [email protected] wrote:

Given all this, I’m starting to entertain using JRuby. It ships with
NetBeans, and we know that we can compile with Java successfully…

Compile once, debug everywhere… :smiley:
Hehehe, I remember the days back in 1997 when java was released :smiley:


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Jan 12, 2008 5:07 PM, Kevin W. [email protected] wrote:

you should be fine. Or, make sure you’re not compiling gems. That’s my
approach, at least.

0.9.5 was using the pure-ruby version of the gems, that doesn’t mean
it was right.
Neither ruby compilation troubles where fixed :stuck_out_tongue:


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Jan 12, 2008 4:23 PM, Wes G. [email protected] wrote:

Based on my testing, it appears to me there is something that Mongrel is
loading that is requiring MSVCR80.dll, since 1.0. Isn’t that correct?

No, all the version of mongrel are build with VC6, so the http11
extension is linked to MSVCRT.dll, and not MSVCR80.dll

can you try this on a IRB console?

irb(main):002:0> require ‘rubygems’
=> true
irb(main):003:0> require ‘mongrel’
=> true
irb(main):004:0> Mongrel::Const::MONGREL_VERSION
=> “1.1.2”

If you don’t get the msgbox in that process is because mongrel isn’t
responsible for that. If you get, I’ll suggest you remove the mongrel
gem and clean install it again.

I know. Honestly, I’ve enjoyed the “underdog” role of being “the only
or one of few Windows guys in the room” at Ruby/Rails gathering to some
degree. And when I get the sense that there is Mac elitism at work, it
really bugs me. But, if I’m going to use Rails as a major tool in my
work, it behooves me to make it as easy as possible for myself to
develop. Back when I was doing mostly Java work, it didn’t really
matter that I was on Windows.

Since I started with Rails (back in 0.13) I didn’t have too many
troubles with it. Ruby, by itself, didn’t showed my troubles neither.
But some of the “popular libraries” have them, mostly because some
developers ignores other platforms (part of their elitism or
ignorance).

I use Rails on a daily basis to deploy to linux servers, all without
glitches (trust me: noone).

ssh to some server? no problem. have all your ssh keys? no problem
(pageant, putty ssh agent).

Anyway, I found no problems using Rails on Windows, except those
plugins from some developers that didn’t care about good/fair usage of
resources or the true nature of ruby a being cross-platform language.


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

I found it. Sigh.

Mongrel was trying to use fastthread 1.0.1 which apparently had been
compiled with VC 8 (see below). I’m pretty sure that fastthread is not
even necessary anymore - is that right? When I removed the fastthread
gem, it starts up fine.

Also, check out my VC8 polluted PATH entries:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;
C:\Program Files\Microsoft Visual Studio 8\VC\BIN;
C:\Program Files\Microsoft Visual Studio 8\Common7\Tools;
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin;
C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Bin;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages;

(I got these because I installed the MSVC++ 2005 Express Edition at some
point).

So…just to be clear, should these entries be banished from my PATH
immediately (unless of course I decide to start developing VC++ :])?

Thanks for all of the help, guys.

Wes

On Jan 12, 2008 5:39 PM, Wes G. [email protected] wrote:

I found it. Sigh.

Mongrel was trying to use fastthread 1.0.1 which apparently had been
compiled with VC 8 (see below). I’m pretty sure that fastthread is not
even necessary anymore - is that right? When I removed the fastthread
gem, it starts up fine.

Aha!

that’s Rubygems 0.9.5 fault!

When you tried to install at some point mongrel with 0.9.5, rubygems
pulled fastthread source instead of the pre-compiled gem I made
available.

Anyway, if you’re using PATCHLEVEL above 36 you’re safe, if not, you
need fastthread.

I suggest you update to latest One-Click Installer, do a gem update
–system and use it :slight_smile:

(I got these because I installed the MSVC++ 2005 Express Edition at some
point).

That’s why the gem installation process didn’t fail on you since nmake
and cl.exe was available all the time!

I love to have my PATHs under control (yeah, I’m uscha control freak)
:wink:
Visual Studio made that impossible…

So…just to be clear, should these entries be banished from my PATH
immediately (unless of course I decide to start developing VC++ :])?

Maybe you can create a shortcut for the commandline version, like
previous Visual Studio versions did. Google for that and you will find
good resources about setvc, setvars or setvcvars (bat and cmd).

Thanks for all of the help, guys.

No problem, I was worried that I broke something inside mongrel in
latest release! :stuck_out_tongue:

Take care,


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Luis L. wrote:

Anyway, if you’re using PATCHLEVEL above 36 you’re safe, if not, you
need fastthread.

You mean the patchlevel of ruby in the OCI gotten via ruby -v?

Wes

On Jan 12, 2008 6:20 PM, Wes G. [email protected] wrote:

Luis L. wrote:

Anyway, if you’re using PATCHLEVEL above 36 you’re safe, if not, you
need fastthread.

You mean the patchlevel of ruby in the OCI gotten via ruby -v?

Yep, sorry about that:

ruby -e “puts RUBY_PATCHLEVEL”
111

ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams