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
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 >(Continue reading)
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.
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@...> 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(Continue reading)
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
Sweet ! I like the concept but your parasite looks to kind :D
--
Cheers,
zimbatm
_______________________________________________ Camping-list mailing list Camping-list@... http://rubyforge.org/mailman/listinfo/camping-list
On 3/12/07, Jonas Pfenniger <zimbatm@...> 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
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 :)
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
<at> 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@...
> http://rubyforge.org/mailman/listinfo/camping-list
>
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
RSS Feed5 | |
|---|---|
1 | |
17 | |
2 | |
9 | |
3 | |
3 | |
43 | |
2 | |
55 | |
154 | |
76 | |
11 | |
12 | |
89 | |
17 | |
69 | |
14 | |
46 | |
6 | |
6 | |
9 | |
1 | |
10 | |
17 | |
6 | |
5 | |
14 | |
104 | |
65 | |
99 | |
11 | |
31 | |
27 | |
5 | |
11 | |
3 | |
22 | |
44 | |
5 | |
19 | |
13 | |
41 | |
31 | |
11 | |
8 | |
26 | |
13 | |
6 | |
16 | |
13 | |
4 | |
19 | |
58 | |
44 | |
113 | |
5 | |
18 | |
15 | |
11 | |
3 | |
36 | |
37 | |
75 | |
13 | |
21 | |
19 | |
46 | |
34 | |
17 | |
11 | |
42 | |
3 | |
39 | |
6 |
