From ullmann at gmail.com  Wed Mar  7 20:28:37 2007
From: ullmann at gmail.com (Andrew Ullmann)
Date: Thu, 8 Mar 2007 01:28:37 +0000 (UTC)
Subject: Camping on Dreamhost - Please Help!
References: <ab5f99300702261828rbf1a58dxe31234f3acdc5543@mail.gmail.com>
Message-ID: <loom.20070308T022544-70@post.gmane.org>


Dan Gottlieb <camping at ...> writes:

> 
> Hi Folks,
> 
> I've been trying to get camping up and running on dreamhost for the
> past six hours, but have had no success.  I'd really appreciate any
> suggestions!
> 

Were you able to get it working? I am struggling as well
and any help would be appreciated.

-Andrew







From camping at dan-gottlieb.com  Wed Mar  7 20:51:38 2007
From: camping at dan-gottlieb.com (Dan Gottlieb)
Date: Wed, 7 Mar 2007 20:51:38 -0500
Subject: Camping on Dreamhost - Please Help!
In-Reply-To: <loom.20070308T022544-70@post.gmane.org>
References: <ab5f99300702261828rbf1a58dxe31234f3acdc5543@mail.gmail.com>
	<loom.20070308T022544-70@post.gmane.org>
Message-ID: <ab5f99300703071751n3cfe74fej95fe06ee5cb7bc76@mail.gmail.com>

Not yet, but I have an idea I want to play with this weekend that I
think will work.  If I can get camping up and running, I'll write up
the steps on the dreamhost wiki.

Dan

On 3/7/07, Andrew Ullmann <ullmann at gmail.com> wrote:
>
> Dan Gottlieb <camping at ...> writes:
>
> >
> > Hi Folks,
> >
> > I've been trying to get camping up and running on dreamhost for the
> > past six hours, but have had no success.  I'd really appreciate any
> > suggestions!
> >
>
> Were you able to get it working? I am struggling as well
> and any help would be appreciated.
>
> -Andrew
>
>
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From _ at whats-your.name  Wed Mar  7 20:48:05 2007
From: _ at whats-your.name (carmen)
Date: Wed, 7 Mar 2007 20:48:05 -0500
Subject: Camping on Dreamhost - Please Help!
In-Reply-To: <loom.20070308T022544-70@post.gmane.org>
References: <ab5f99300702261828rbf1a58dxe31234f3acdc5543@mail.gmail.com>
	<loom.20070308T022544-70@post.gmane.org>
Message-ID: <20070308014805.GA27015@replic.net>

On Thu Mar 08, 2007 at 01:28:37AM +0000, Andrew Ullmann wrote:
> 
> Dan Gottlieb <camping at ...> writes:
> 
> > 
> > Hi Folks,
> > 
> > I've been trying to get camping up and running on dreamhost for the
> > past six hours, but have had no success.  I'd really appreciate any
> > suggestions!
> > 
> 
> Were you able to get it working? I am struggling as well
> and any help would be appreciated.

you can probably just cp -av /usr/lib/ruby into your homedir and then 
export GEM_HOME=~/lib/ruby/gems/1.8/
export GEM_PATH=~/lib/ruby/gems/1.8/
 in .bashrc

and add any more gems you need like camping.

maybe you can bypass the copy/install of ruby and define GEM_PATH to be /usr/lib/ruby/gems/1.8:$HOME/usr/lib/ruby/gems?

maybe you should bug dreamhost to install camping, since its so much lighter than rails i dont see why they wouldnt want to promote it in a shared hosting environment...


> 
> -Andrew
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
> 

From roland.crosby at students.olin.edu  Wed Mar  7 21:57:00 2007
From: roland.crosby at students.olin.edu (Roland Crosby)
Date: Wed, 7 Mar 2007 21:57:00 -0500
Subject: Camping on Dreamhost - Please Help!
In-Reply-To: <20070308014805.GA27015@replic.net>
References: <ab5f99300702261828rbf1a58dxe31234f3acdc5543@mail.gmail.com>
	<loom.20070308T022544-70@post.gmane.org>
	<20070308014805.GA27015@replic.net>
Message-ID: <C738F2FD-1861-4BE9-9F79-9C5DB0144CB8@students.olin.edu>

On Mar 7, 2007, at 8:48 PM, carmen wrote:

> maybe you should bug dreamhost to install camping, since its so  
> much lighter than rails i dont see why they wouldnt want to promote  
> it in a shared hosting environment...

Dreamhost installed Camping at some point recently, but they didn't  
really say much else other than "hey, we installed Camping". Also,  
I'm pretty sure that the installed version is out of date compared to  
the latest release.

From mark.m.fredrickson at gmail.com  Sun Mar 11 23:29:32 2007
From: mark.m.fredrickson at gmail.com (Mark Fredrickson)
Date: Sun, 11 Mar 2007 21:29:32 -0600
Subject: [ANN] Parasite and camping_generator 0.2.0
Message-ID: <3db8a8970703112029i3092ad34obe47cbef04c5b783@mail.gmail.com>

Announcing the the 0.2.0 release of parasite and the camping_generator.

Parasite (from the project page -- http://parasite.rubyforge.org/):

Camping app developers no longer have any reason to envy their Ruby on
Rails friends: Parasite brings generators, environments, and other
Rails-y goodness to the world of Camping app development.

Parasite is currently at version 0.2. The Parasite package is composed
of two gems: parasite and the camping_generator. The first provides a
way to hook into the Rails development environment, while the second
provides a generator for creating Camping apps quickly and painlessly.

More details on installation and usage can be found at:

http://parasite.rubyforge.org/

And to get you interested, some new features/changes in this release:

Release 0-2-0
-- added parasite executable, links into rails environment
-- updated generator to be compatible with changes in Rails
-- updated generator to be compatible with changes in Camping
-- cleaned up some behind the scenes stuff

Cheers,
-Mark

From zimbatm at oree.ch  Mon Mar 12 08:21:52 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Mon, 12 Mar 2007 13:21:52 +0100
Subject: [ANN] Parasite and camping_generator 0.2.0
In-Reply-To: <3db8a8970703112029i3092ad34obe47cbef04c5b783@mail.gmail.com>
References: <3db8a8970703112029i3092ad34obe47cbef04c5b783@mail.gmail.com>
Message-ID: <e3caf1460703120521l2ef42633q267d1c184dcf6544@mail.gmail.com>

Sweet ! I like the concept but your parasite looks to kind :D

-- 
Cheers,
  zimbatm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/camping-list/attachments/20070312/65f25146/attachment.html 

From mark.m.fredrickson at gmail.com  Mon Mar 12 12:06:17 2007
From: mark.m.fredrickson at gmail.com (Mark Fredrickson)
Date: Mon, 12 Mar 2007 11:06:17 -0500
Subject: [ANN] Parasite and camping_generator 0.2.0
In-Reply-To: <e3caf1460703120521l2ef42633q267d1c184dcf6544@mail.gmail.com>
References: <3db8a8970703112029i3092ad34obe47cbef04c5b783@mail.gmail.com>
	<e3caf1460703120521l2ef42633q267d1c184dcf6544@mail.gmail.com>
Message-ID: <3db8a8970703120906w49d9cd72yde110cd24723d7e1@mail.gmail.com>

On 3/12/07, Jonas Pfenniger <zimbatm at oree.ch> wrote:
> Sweet ! I like the concept but your parasite looks to kind :D

Perhaps I should rename it "Cute Cuddly Bug" or something. Don't blame
me - nobody uploaded a scary looking bug or worm to openclipart.org

:-)

-M

From _ at whats-your.name  Mon Mar 12 17:35:08 2007
From: _ at whats-your.name (carmen)
Date: Mon, 12 Mar 2007 17:35:08 -0400
Subject: threading and concurrency
Message-ID: <20070312213508.GG18366@replic.net>

hello all. ive come to the point where im thinking about deploying my 'rails on rails' app-development solution built in camping.

mainly, im wondering what the barriers to thread-safety are.

for db, i use redland, and afaik it spawns a single db connection for each find, and keeps a pool around to reuse. iow, no ActiveRecord.

are class-vars a problem? theres one that i'd like to keep, a 'close' cache of triples in a normal ruby Array.. read/writes to this are fast (much faster than HTML generation in markaby, from what i can tell), but i guess they would need to lock the other threads briefly.

for simplicity. i'd prefer a single interpreter process. otherwise i'm going to have to come up with some distributed cache invalidation scheme (typically the user load is 1-15, small workgroups, which loadwise is fine except they may experience a few seconds lag in their requests if eg a heavy SPARQL query is going on in another request) 

oh, and id like to hear 'sure, but you have to hack up the mongrel configurator slightly, and not do this' rather than 'just use a pack of mongrels'


cheers :)

From michael.gorsuch at gmail.com  Wed Mar 14 20:14:36 2007
From: michael.gorsuch at gmail.com (Michael Gorsuch)
Date: Wed, 14 Mar 2007 20:14:36 -0400
Subject: threading and concurrency
In-Reply-To: <20070312213508.GG18366@replic.net>
References: <20070312213508.GG18366@replic.net>
Message-ID: <2a3f927b0703141714obff9826v2e10059d90d3bfaa@mail.gmail.com>

carmen - I'm not sure _how_ much this will really help you, but I
recently explored a similar issue with an internal Camping app.

In summary, I needed to make sure that all calls to a specific
controller were always executed serially.  i.e. - if two calls came in
at approximately the same time, the second call could not run until
the first one finished.

This was not a problem: I just included the 'thread' library and
wrapped the code in a synchronize block.  The only requirement: I only
run a single mongrel instance.

Simple code example follows:

**********

require 'thread'
....

class Create < R '/create'
  def synchronize
    mutex.synchronize {yield self}
  end

  def mutex
    @mutex ||= Mutex.new
  end

  def get
    synchronize do
      # my code goes here...
    end
  end
end

******************

I hope this helps out some,

Michael Gorsuch
http://www.styledbits.com



On 3/12/07, carmen <_ at whats-your.name> wrote:
> hello all. ive come to the point where im thinking about deploying my 'rails on rails' app-development solution built in camping.
>
> mainly, im wondering what the barriers to thread-safety are.
>
> for db, i use redland, and afaik it spawns a single db connection for each find, and keeps a pool around to reuse. iow, no ActiveRecord.
>
> are class-vars a problem? theres one that i'd like to keep, a 'close' cache of triples in a normal ruby Array.. read/writes to this are fast (much faster than HTML generation in markaby, from what i can tell), but i guess they would need to lock the other threads briefly.
>
> for simplicity. i'd prefer a single interpreter process. otherwise i'm going to have to come up with some distributed cache invalidation scheme (typically the user load is 1-15, small workgroups, which loadwise is fine except they may experience a few seconds lag in their requests if eg a heavy SPARQL query is going on in another request)
>
> oh, and id like to hear 'sure, but you have to hack up the mongrel configurator slightly, and not do this' rather than 'just use a pack of mongrels'
>
>
> cheers :)
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From _ at whats-your.name  Wed Mar 14 23:05:19 2007
From: _ at whats-your.name (carmen)
Date: Wed, 14 Mar 2007 23:05:19 -0400
Subject: threading and concurrency
In-Reply-To: <2a3f927b0703141714obff9826v2e10059d90d3bfaa@mail.gmail.com>
References: <20070312213508.GG18366@replic.net>
	<2a3f927b0703141714obff9826v2e10059d90d3bfaa@mail.gmail.com>
Message-ID: <20070315030519.GB31217@replic.net>

On Wed Mar 14, 2007 at 08:14:36PM -0400, Michael Gorsuch wrote:
> carmen - I'm not sure _how_ much this will really help you, but I
> recently explored a similar issue with an internal Camping app.
> 
> In summary, I needed to make sure that all calls to a specific
> controller were always executed serially.  i.e. - if two calls came in
> at approximately the same time, the second call could not run until
> the first one finished.

thanks. ive got the PP thread chapter bookmarked, and planned to get into it. your example is nice and simple..

mainly i am unclear on what the current concurrency model is - its fairly obvious with rails since for whatever reason it's more popular so theres tons of blogs discussing it, but i cant find anything except a CHANGELOG entry in 1.3 mentioning some method is thread-safe (but does this extend to the entire framework?)

my brief experiments with subjective request timings using 2 browsers, along with stats from httperf, had me thinking everything is already serialized. and here youre suggesting the opposite...

which is it!? i seem to recall a 'dangerous' switch somewhere in mongrel or rails that disabled the explicit serialization.

fwiw, heres my mongrel configurator:

if __FILE__ == $0
  Yard.create
  config = Mongrel::Configurator.new :host => (ARGV[0] || "0.0.0.0") do
    listener :port => (ARGV[1] || 80) do
      uri "/", :handler => Mongrel::Camping::CampingHandler.new(Camping::Reloader.new(__FILE__))
      uri '/s/', :handler => Mongrel::DirHandler.new(File.dirname(__FILE__)+"/s")
      trap("INT") { stop }; run
    end
  end
  config.join
end

> 
> This was not a problem: I just included the 'thread' library and

From zimbatm at oree.ch  Thu Mar 15 08:51:18 2007
From: zimbatm at oree.ch (Jonas Pfenniger)
Date: Thu, 15 Mar 2007 13:51:18 +0100
Subject: threading and concurrency
In-Reply-To: <2a3f927b0703141714obff9826v2e10059d90d3bfaa@mail.gmail.com>
References: <20070312213508.GG18366@replic.net>
	<2a3f927b0703141714obff9826v2e10059d90d3bfaa@mail.gmail.com>
Message-ID: <e3caf1460703150551v41eaa482vcd3eaa54dfb34fd8@mail.gmail.com>

2007/3/15, Michael Gorsuch <michael.gorsuch at gmail.com>:
> carmen - I'm not sure _how_ much this will really help you, but I
> recently explored a similar issue with an internal Camping app.
>
> In summary, I needed to make sure that all calls to a specific
> controller were always executed serially.  i.e. - if two calls came in
> at approximately the same time, the second call could not run until
> the first one finished.
>
> This was not a problem: I just included the 'thread' library and
> wrapped the code in a synchronize block.  The only requirement: I only
> run a single mongrel instance.
>
> Simple code example follows:
>
> **********
>
> require 'thread'
> ....
>
> class Create < R '/create'
>   def synchronize
>     mutex.synchronize {yield self}
>   end
>
>   def mutex
>     @mutex ||= Mutex.new
>   end
>
>   def get
>     synchronize do
>       # my code goes here...
>     end
>   end
> end
>
> ******************
>
> I hope this helps out some,
>
> Michael Gorsuch
> http://www.styledbits.com
>
>
>
> On 3/12/07, carmen <_ at whats-your.name> wrote:
> > hello all. ive come to the point where im thinking about deploying my 'rails on rails' app-development solution built in camping.
> >
> > mainly, im wondering what the barriers to thread-safety are.
> >
> > for db, i use redland, and afaik it spawns a single db connection for each find, and keeps a pool around to reuse. iow, no ActiveRecord.
> >
> > are class-vars a problem? theres one that i'd like to keep, a 'close' cache of triples in a normal ruby Array.. read/writes to this are fast (much faster than HTML generation in markaby, from what i can tell), but i guess they would need to lock the other threads briefly.
> >
> > for simplicity. i'd prefer a single interpreter process. otherwise i'm going to have to come up with some distributed cache invalidation scheme (typically the user load is 1-15, small workgroups, which loadwise is fine except they may experience a few seconds lag in their requests if eg a heavy SPARQL query is going on in another request)
> >
> > oh, and id like to hear 'sure, but you have to hack up the mongrel configurator slightly, and not do this' rather than 'just use a pack of mongrels'
> >
> >
> > cheers :)
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/camping-list
> >
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

Are you sure it's the right way to do ? It seems to me that an
instance of the controller is created on each request. So with your
approach, a mutex is created on each request and your don't have the
benefit of mutex locking. Adding an `at` before @mutex should do the
trick.

-- 
Cheers,
  zimbatm

From walkandre at gmail.com  Tue Mar 27 21:02:03 2007
From: walkandre at gmail.com (=?ISO-8859-1?Q?andr=E9_gustavo_cardozo?=)
Date: Tue, 27 Mar 2007 22:02:03 -0300
Subject: Camping on Dreamhost - Please Help!
Message-ID: <8e46cad20703271802q2b9b44a3q89c174a487300979@mail.gmail.com>

Dan

did you get camping running on dreamhost already??

i?m trying to run it also but i haven't succeed yet. it runs on
command line but when i add the rewrite rules on .htaccess i get a
internal server error.

I emailed support to ask about ScriptAlias and they say they cannot
change or add that to apache conf.



-- 
Andr? G. Cardozo

From michael.gorsuch at gmail.com  Tue Mar 27 22:03:00 2007
From: michael.gorsuch at gmail.com (Michael Gorsuch)
Date: Tue, 27 Mar 2007 22:03:00 -0400
Subject: Camping on Dreamhost - Please Help!
In-Reply-To: <8e46cad20703271802q2b9b44a3q89c174a487300979@mail.gmail.com>
References: <8e46cad20703271802q2b9b44a3q89c174a487300979@mail.gmail.com>
Message-ID: <2a3f927b0703271903o27ea5f99t30afc7984d1fb1f3@mail.gmail.com>

Andre - I have a working camping app on Dreamhost.

My .htaccess:


AddHandler fastcgi-script .fcgi
Options +FollowSymLinks +ExecCGI

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/stats/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/failed_auth.html$ [OR]
#RewriteCond %{REQUEST_URI} ^/static/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/mint/(.*)$
RewriteRule ^.*$ - [L]

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

**********

my dispatch.fcgi:

#!/home/styledbits/local/bin/ruby
require 'rubygems'
require 'camping'
require 'camping/fastcgi'
ENV["FORCE_ROOT"]=1.to_s
Camping::Models::Base.establish_connection :adapter => 'sqlite3',
:database => "wankosphere.sqlite3"
Camping::FastCGI.serve("wankosphere.rb")


On 3/27/07, andr? gustavo cardozo <walkandre at gmail.com> wrote:
> Dan
>
> did you get camping running on dreamhost already??
>
> i?m trying to run it also but i haven't succeed yet. it runs on
> command line but when i add the rewrite rules on .htaccess i get a
> internal server error.
>
> I emailed support to ask about ScriptAlias and they say they cannot
> change or add that to apache conf.
>
>
>
> --
> Andr? G. Cardozo
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From mark.m.fredrickson at gmail.com  Tue Mar 27 22:52:49 2007
From: mark.m.fredrickson at gmail.com (Mark Fredrickson)
Date: Tue, 27 Mar 2007 21:52:49 -0500
Subject: Pimpin' a patch: moving the bin/camping logic to classes
Message-ID: <3db8a8970703271952h1b1990cesea93e655d36592c0@mail.gmail.com>

Hello,

Zimbatm suggested the best way to push a patch into camping was to
take my case to the people. So here it is. If you want to jump
straight to the patch:

http://code.whytheluckystiff.net/camping/ticket/117

Goal: Move the logic in the camping command line launcher into several classes

Why? In the next version of parasite (http://parasite.rubyforge.org)
I'd like to take over several of the standard Rails script/* tools.
For example, script/sever and script/console.

Camping already supports launching different servers (including an IRB
session), but the logic for that (including all the reloader goodness)
is tied up the bin/camping script. The linked patch above splits that
logic in one class per server type, each descending from a parent
class that handles a lot of initialization and interfacing with
Camping::Reloader other other libraries. With this patch, I can simply
overwrite script/server and script/console with little Ruby scripts
that call into the appropriate Camping classes.

I think this patch will also help with adding the --daemonize
functionality or in a environment where you might like to quickly
create a bunch of camping servers from within a Ruby script (e.g. a
shared hosting environment or similar).

For most users, this change would cause no change in behavior and
usage. But for people looking to do more with the creation of camping
servers, this could be very helpful.

I'm unclear on any next steps, but if you like the idea and/or the
patch, please comment on the issue:

http://code.whytheluckystiff.net/camping/ticket/117

We'll see where it goes from here.

Cheers,
-Mark

From why at whytheluckystiff.net  Tue Mar 27 23:09:42 2007
From: why at whytheluckystiff.net (why the lucky stiff)
Date: Tue, 27 Mar 2007 21:09:42 -0600
Subject: Pimpin' a patch: moving the bin/camping logic to classes
In-Reply-To: <3db8a8970703271952h1b1990cesea93e655d36592c0@mail.gmail.com>
References: <3db8a8970703271952h1b1990cesea93e655d36592c0@mail.gmail.com>
Message-ID: <20070328030941.GK36566@beekeeper.hobix.com>

On Tue, Mar 27, 2007 at 09:52:49PM -0500, Mark Fredrickson wrote:
> I'm unclear on any next steps, but if you like the idea and/or the
> patch, please comment on the issue:
> 
> http://code.whytheluckystiff.net/camping/ticket/117

The next step is for me to accept it and I accept it.  You can go
ahead apply this to trunk yourself, if you like, Mark.  Thanks a lot
for doing this!

_why

From camping at dan-gottlieb.com  Wed Mar 28 20:08:02 2007
From: camping at dan-gottlieb.com (Dan Gottlieb)
Date: Wed, 28 Mar 2007 20:08:02 -0400
Subject: Camping on Dreamhost - Please Help!
In-Reply-To: <8e46cad20703271802q2b9b44a3q89c174a487300979@mail.gmail.com>
References: <8e46cad20703271802q2b9b44a3q89c174a487300979@mail.gmail.com>
Message-ID: <ab5f99300703281708y2586f394j6c3755094015e31f@mail.gmail.com>

HI Andre,

I haven't looked at the apache redirect stuff yet, but if you're using
the DH install of ruby and camping, i've figured out the following:

1) DH installed camping with all dependencies EXCEPT markaby, so at
the very least you'll need to install markaby in your own directory
(i'd recommend installing the full camping gem there)

2) When running cgi/fcgi scripts, DH's 's server ignores the .bashrc
file (though they'll tell you that they don't), so you'll need to set
the gem path (ENV["GEM_PATH"] ) in your dispatch script.

Hope this helps!

Dan

From walkandre at gmail.com  Wed Mar 28 21:09:53 2007
From: walkandre at gmail.com (=?ISO-8859-1?Q?andr=E9_gustavo_cardozo?=)
Date: Wed, 28 Mar 2007 22:09:53 -0300
Subject: Camping on Dreamhost - Please Help!
In-Reply-To: <ab5f99300703281708y2586f394j6c3755094015e31f@mail.gmail.com>
References: <8e46cad20703271802q2b9b44a3q89c174a487300979@mail.gmail.com>
	<ab5f99300703281708y2586f394j6c3755094015e31f@mail.gmail.com>
Message-ID: <8e46cad20703281809q7ffcedeel1b0b65bdca1d8a2f@mail.gmail.com>

I got my own gems installed and everything seems to be working, with
no problems except the htaccess configuration and i still getting a
lot of strange errors from fast-cgi.

i?m going to try michael configuration and maybe install my own ruby as he did.




On 3/28/07, Dan Gottlieb <camping at dan-gottlieb.com> wrote:
> HI Andre,
>
> I haven't looked at the apache redirect stuff yet, but if you're using
> the DH install of ruby and camping, i've figured out the following:
>
> 1) DH installed camping with all dependencies EXCEPT markaby, so at
> the very least you'll need to install markaby in your own directory
> (i'd recommend installing the full camping gem there)
>
> 2) When running cgi/fcgi scripts, DH's 's server ignores the .bashrc
> file (though they'll tell you that they don't), so you'll need to set
> the gem path (ENV["GEM_PATH"] ) in your dispatch script.
>
> Hope this helps!
>
> Dan
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>


-- 
Andr? G. Cardozo