Rails - Sep 2005 - Pure Ruby SCGI Rails (No More libevent)

Hello Everyone,

I am pleased to announce that I''ve reimplemented the SCGI Rails work I
did in pure Ruby and made it even easier to install and use.  It gets reasonably
good performance compared with the original libevent based version while being
much smaller (416 lines).  It should work on every platform that has Ruby and
require no compilation, C extensions, or external requirements other than a web
server supporting SCGI.  The performance is about the same as FastCGI but 20%
slower than the original libevent SCGI I wrote.

You can pick up the single file script you need (and a lighttpd.conf file) from:

http://www.zedshaw.com/downloads/scgi_rails/scgi_rails-0.1.tar.bz2

It is a single Ruby script that you just run in your Rails directory to get some
pretty good raw speed.  It also supports all of the original features such as
simple clustering and configuration.

== Configuration

There''s an included lighttpd.conf sample that you can use to base your
lighttpd configuration on.  I also tested it with mod_scgi under Apache 2, but
not as extensively.  All you need to do is run lighttpd one and you
shouldn''t have to restart it when you need to restart your Rails
application.  They are independent.


== Examples

Using the script is really easy.  Let''s say you copied into your
favorite rails application directory.  You want to start it up and just run it
in development mode:

	ruby scgi_rails start -D

This starts Rails under SCGI in the same way that script/server would.  This is
really nice since now you can easily flip into development mode without touching
your lighttpd/Apache2 setup.  This also runs it so that CTRL-C stops it.

Alright, now you want to run it in production but keep it in the foreground:

	ruby scgi_rails start -e production -D

Just runs it in production mode so you can test that too.  Now you want to run
it for deployment:

	ruby scgi_rails start -e production -c 3

This runs your rails application in production mode, and it spawns 3 child
processes so that each can process many requests while the other ones are busy. 
These children also listen to the one configured port (9999) at the same time
using a simple trick.  If you have multiple processors then this will give you a
massive boost.  It also means that you get simple single-machine clustering
without having to reconfigure the lighttpd/Apache2 configuration.

Ok, you''ve got 3 children running, but what are they doing?  Look at
the log/scgi.log file for some information.  It will write out any exceptions
and prints out $stderr output the Rails application prints (usually Erb
messages).  You can also do:

	ruby scgi_rails status

And get some simple status files in /tmp/scgi_* that you can review.  Right now
they just print the PIDs of each.  You can also look at the children.yaml file.

Finally, if you want to stop all the processes easily, you just do:

	ruby scgi_rails stop

And that''s pretty much it.  Just use --help to get more on the start,
status or stop commands.

Enjoy the fun!  Hopefully this helps rocket SCGI into acceptance in the Rails
community.  Please send me any comments and suggestions or bugs.

Zed A. Shaw
http://www.zedshaw.com/

That was quick!
Nice work, Zed. I'll download it and run it asap. Btw, how does its
performance compare with fcgi?

Jacob

On 9/11/05, Zed A. Shaw <zedshaw@zedshaw.com>
wrote:
> Hello Everyone,
> 
> I am pleased to announce that I've reimplemented the SCGI Rails work I
did in pure Ruby and made it even easier to install and use.  It gets reasonably
good performance compared with the original libevent based version while being
much smaller (416 lines).  It should work on every platform that has Ruby and
require no compilation, C extensions, or external requirements other than a web
server supporting SCGI.  The performance is about the same as FastCGI but 20%
slower than the original libevent SCGI I wrote.
> 
> You can pick up the single file script you need (and a lighttpd.conf file)
from:
> 
> http://www.zedshaw.com/downloads/scgi_rails/scgi_rails-0.1.tar.bz2
> 
> It is a single Ruby script that you just run in your Rails directory to get
some pretty good raw speed.  It also supports all of the original features such
as simple clustering and configuration.
> 
> == Configuration
> 
> There's an included lighttpd.conf sample that you can use to base your
lighttpd configuration on.  I also tested it with mod_scgi under Apache 2, but
not as extensively.  All you need to do is run lighttpd one and you
shouldn't have to restart it when you need to restart your Rails
application.  They are independent.
> 
> 
> == Examples
> 
> Using the script is really easy.  Let's say you copied into your
favorite rails application directory.  You want to start it up and just run it
in development mode:
> 
>         ruby scgi_rails start -D
> 
> This starts Rails under SCGI in the same way that script/server would. 
This is really nice since now you can easily flip into development mode without
touching your lighttpd/Apache2 setup.  This also runs it so that CTRL-C stops
it.
> 
> Alright, now you want to run it in production but keep it in the
foreground:
> 
>         ruby scgi_rails start -e production -D
> 
> Just runs it in production mode so you can test that too.  Now you want to
run it for deployment:
> 
>         ruby scgi_rails start -e production -c 3
> 
> This runs your rails application in production mode, and it spawns 3 child
processes so that each can process many requests while the other ones are busy. 
These children also listen to the one configured port (9999) at the same time
using a simple trick.  If you have multiple processors then this will give you a
massive boost.  It also means that you get simple single-machine clustering
without having to reconfigure the lighttpd/Apache2 configuration.
> 
> Ok, you've got 3 children running, but what are they doing?  Look at
the log/scgi.log file for some information.  It will write out any exceptions
and prints out $stderr output the Rails application prints (usually Erb
messages).  You can also do:
> 
>         ruby scgi_rails status
> 
> And get some simple status files in /tmp/scgi_* that you can review.  Right
now they just print the PIDs of each.  You can also look at the children.yaml
file.
> 
> Finally, if you want to stop all the processes easily, you just do:
> 
>         ruby scgi_rails stop
> 
> And that's pretty much it.  Just use --help to get more on the start,
status or stop commands.
> 
> Enjoy the fun!  Hopefully this helps rocket SCGI into acceptance in the
Rails community.  Please send me any comments and suggestions or bugs.
> 
> Zed A. Shaw
> http://www.zedshaw.com/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Yeah, it actually took me about an hour today after I gave up on the original
path of development.  For performance here''s the metrics I got using
httperf with each running in production mode:

* Webrick -- 18.9 req/s (35.5 ms standard deviation)
* Original scgi_rails --  62.2 req/s (12.5 ms standard deviation)
* new scgi_rails -- 53.5 req/s (16.9 ms standard deviation)
* fastcgi -- 51.3 req/s (19.2 ms standard deviation)

The new scgi_rails and fastcgi are both about the same in performance on my
little computer based on the width of their standard deviations.  In other
words, if I ran this test a whole bunch of times they would eventually average
out to be about the same.

But then again, the new scgi_rails script is 416 lines of pure Ruby that can
compete with fastcgi but also give you simple clustering which should help blow
the doors off of it.

Zed A. Shaw
http://www.zedshaw.com/


On Sun, 11 Sep 2005 18:56:45 -0700
Jacob Quinn Shenker <jqshenker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> That was quick!
> Nice work, Zed. I''ll download it and run it asap. Btw, how does
its
> performance compare with fcgi?
> 
> Jacob
>

Wow. Kudos!

On 9/12/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
>external requirements other than a web server supporting SCGI.  The
performance is
>about the same as FastCGI but 20% slower than the original libevent
SCGI I wrote.

Will you still maintain the libevent version as well for those of us
after that last 20%?

Ben

Zed,
If Ruby 2.0 (or whatever version) fixes the thread issue (uses
libevent for threads) will you then bring back the original,
libevent-ized scgi code?

Jacob

On 9/11/05, Ben Myles <ben.myles@gmail.com> wrote:
> On 9/12/05, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> >external requirements other than a web server supporting SCGI.  The
> performance is
> >about the same as FastCGI but 20% slower than the original libevent
> SCGI I wrote.
> 
> Will you still maintain the libevent version as well for those of us
> after that last 20%?
> 
> Ben
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

I wanted to run an independent erb code generator so I did following in my 
model class:

require ''erb''
License < ActiveRecord etc.  #License is model here


etc etc

fh = File.new("voice/grammars/licenses.grxml", "w+")
File.open("voice/grammars/licenses.template") { |fd|
erb = ERb.new( fd.read )
fh.print erb.result( binding )
}
fh.close


===================he above  choked on ERb and complained it was trying to open
e_rb.rb !! Some
of DHH''s hidden linguistics?

Fix was to change ERb into ERB and it worked fine.

Anyone any ideas?
.
.
.

Zed will this run in shared hosting environments such as dreamhost?   
Is SCGI commonly found on shared hosts or is this something only  
folks with root access can have fun with?

- Jim

On Sep 11, 2005, at 6:47 PM, Zed A. Shaw wrote:
> Hello Everyone,
>
> I am pleased to announce that I''ve reimplemented the SCGI Rails  
> work I did in pure Ruby and made it even easier to install and  
> use.  It gets reasonably good performance compared with the  
> original libevent based version while being much smaller (416  
> lines).  It should work on every platform that has Ruby and require  
> no compilation, C extensions, or external requirements other than a  
> web server supporting SCGI.  The performance is about the same as  
> FastCGI but 20% slower than the original libevent SCGI I wrote.
>
> You can pick up the single file script you need (and a  
> lighttpd.conf file) from:
>
> http://www.zedshaw.com/downloads/scgi_rails/scgi_rails-0.1.tar.bz2
>
> It is a single Ruby script that you just run in your Rails  
> directory to get some pretty good raw speed.  It also supports all  
> of the original features such as simple clustering and configuration.
>
> == Configuration
>
> There''s an included lighttpd.conf sample that you can use to base
> your lighttpd configuration on.  I also tested it with mod_scgi  
> under Apache 2, but not as extensively.  All you need to do is run  
> lighttpd one and you shouldn''t have to restart it when you need to
> restart your Rails application.  They are independent.
>
>
> == Examples
>
> Using the script is really easy.  Let''s say you copied into your  
> favorite rails application directory.  You want to start it up and  
> just run it in development mode:
>
>     ruby scgi_rails start -D
>
> This starts Rails under SCGI in the same way that script/server  
> would.  This is really nice since now you can easily flip into  
> development mode without touching your lighttpd/Apache2 setup.   
> This also runs it so that CTRL-C stops it.
>
> Alright, now you want to run it in production but keep it in the  
> foreground:
>
>     ruby scgi_rails start -e production -D
>
> Just runs it in production mode so you can test that too.  Now you  
> want to run it for deployment:
>
>     ruby scgi_rails start -e production -c 3
>
> This runs your rails application in production mode, and it spawns  
> 3 child processes so that each can process many requests while the  
> other ones are busy.  These children also listen to the one  
> configured port (9999) at the same time using a simple trick.  If  
> you have multiple processors then this will give you a massive  
> boost.  It also means that you get simple single-machine clustering  
> without having to reconfigure the lighttpd/Apache2 configuration.
>
> Ok, you''ve got 3 children running, but what are they doing?  Look
> at the log/scgi.log file for some information.  It will write out  
> any exceptions and prints out $stderr output the Rails application  
> prints (usually Erb messages).  You can also do:
>
>     ruby scgi_rails status
>
> And get some simple status files in /tmp/scgi_* that you can  
> review.  Right now they just print the PIDs of each.  You can also  
> look at the children.yaml file.
>
> Finally, if you want to stop all the processes easily, you just do:
>
>     ruby scgi_rails stop
>
> And that''s pretty much it.  Just use --help to get more on the  
> start, status or stop commands.
>
> Enjoy the fun!  Hopefully this helps rocket SCGI into acceptance in  
> the Rails community.  Please send me any comments and suggestions  
> or bugs.
>
> Zed A. Shaw
> http://www.zedshaw.com/
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

Would like to correspond with...
Thanks
John

Sorry Ben, I''m probably going to see how Ruby 1.9 with Rite performs
and do some more tweaking on this script.  The previous version just
couldn''t be made stable enough to run properly for anyone.  No point in
20% more speed if it can''t run reliably.  And the latest metrics I did
make it more like 14% than 20%.

But don''t trust these metrics for your installation.  Make sure to try
the latest script in your own setup with a few children running before you think
it doesn''t perform well.  My experience is that it gets pretty damn
good performance already compared with fastcgi, and it''s so damn small
it''ll be easier for people to tweak and extend.

Zed A. Shaw
http://www.zedshaw.com/


On Mon, 12 Sep 2005 13:22:16 +1000
Ben Myles <ben.myles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 9/12/05, Zed A. Shaw
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:
> >external requirements other than a web server supporting SCGI.  The
> performance is
> >about the same as FastCGI but 20% slower than the original libevent
> SCGI I wrote.
> 
> Will you still maintain the libevent version as well for those of us
> after that last 20%?
> 
> Ben
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Jim, the new pure-ruby scgi_rails should run fine in a shared
environment (on a high port).

Ben

On 9/12/05, Jim Jeffers
<rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org>
wrote:
> Zed will this run in shared hosting environments such as dreamhost?
> Is SCGI commonly found on shared hosts or is this something only
> folks with root access can have fun with?

Ahh, just read about the threading issues.
 
So long as it keeps pace with FastCGI I''m a happy camper. Besides,
it''s pretty neat to have a single ruby script do all the work with no
dependencies. Lose some performance, gain some flexibility :-)
 
Ben
 
On 9/12/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
> Sorry Ben, I''m probably going to see how Ruby 1.9 with Rite
performs and do some more tweaking on this script.  The previous version just
couldn''t be made stable enough to run properly for anyone.  No point in
20% more speed if it can''t run reliably.  And the latest metrics I did
make it more like 14% than 20%.
<..snip..>

I got a error:

C:\nx\jwc2005>ruby scgi_rails start
ERROR: unsupported signal SIGHUP

on a Windows 2003 Server

Hi John:

Create an init.rb file in your RAILS_ROOT directory with the following
one-liner:

system ''ruby script\server''

Then package it into an exe like normal.
This will start the application on port 3000.

I am still looking for a good way to
launch the default browser or package
gecko with the exe.

hth,
-- Tom.

On 9/11/05, speechexpert
<speechexpert-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org>
wrote:
> Would like to correspond with...
> Thanks
> John
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
"Nothing will ever be attempted, if all
 possible objections must first be
 overcome." - Samuel Johnson

I think this will open a browser in Windows

system( ENV["COMSPEC"], "/c", "start", url ) if
RUBY_PLATFORM =~ /win/


unix.. dunno.. can try $BROWSER?


On 9/12/05, Tom Jordan <tdjordan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 
> Hi John:
> 
> Create an init.rb file in your RAILS_ROOT directory with the following
> one-liner:
> 
> system ''ruby script\server''
> 
> Then package it into an exe like normal.
> This will start the application on port 3000.
> 
> I am still looking for a good way to
> launch the default browser or package
> gecko with the exe.
> 
> hth,
> -- Tom.
> 
> On 9/11/05, speechexpert
<speechexpert-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org> wrote:
> > Would like to correspond with...
> > Thanks
> > John
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> 
> 
> --
> "Nothing will ever be attempted, if all
> possible objections must first be
> overcome." - Samuel Johnson
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
-- 
choonkeat 
- http://blog.yanime.org/ 
- http://www.rssfwd.com/


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Jim, 

If you can install the cmdparse gem (or source/library) and this script, then
run it you should be good on the SCGI side of things.  The remaining part is to
configure the web server.  That requires either the mod_scgi Apache module, or a
recent lighttpd with SCGI.  If you have those then you should be able to
configure the web server and you''re good.

Some hosting services might require that you install it.  What you can do is
they have apache and you have a shell account, then grab the mod_scgi source,
compile it with apxs, but change the install directory to someplace other than
the default.  The default apache location will surely require root access.  Once
the module is installed in a different location you might be able to configure
your Apache instance to use it manually.

Otherwise, you''ll have to contact your hosting provider.

Zed A. Shaw
http://www.zedshaw.com/

On Sun, 11 Sep 2005 20:41:13 -0700
Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org>
wrote:
> Zed will this run in shared hosting environments such as dreamhost?   
> Is SCGI commonly found on shared hosts or is this something only  
> folks with root access can have fun with?
> 
> - Jim

Looks like Windows Ruby doesn''t know what the signals mean. 
There''s probably also problems with forking.  I''ll test it out
on Windows today and post an update.

Zed A. Shaw
http://www.zedshaw.com/


On Mon, 12 Sep 2005 14:19:48 +0800
hui <fortez-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I got a error:
> 
> C:\nx\jwc2005>ruby scgi_rails start
> ERROR: unsupported signal SIGHUP
> 
> on a Windows 2003 Server
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

No point then, I''ll just let Ruby do it''s thing and complain
if it isn''t implemented correctly.

Of course, that depends on when Ruby 2.0 comes out, which could potentially be
never.  We''re all familiar with software that promises tons of features
and never materializes.

Zed A. Shaw
http://www.zedshaw.com/


On Sun, 11 Sep 2005 20:29:12 -0700
Jacob Quinn Shenker <jqshenker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Zed,
> If Ruby 2.0 (or whatever version) fixes the thread issue (uses
> libevent for threads) will you then bring back the original,
> libevent-ized scgi code?
> 
> Jacob
>

2005/9/12, Zed A. Shaw
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>:
> No point then, I''ll just let Ruby do it''s thing and
complain if it isn''t implemented correctly.
> 
> Of course, that depends on when Ruby 2.0 comes out, which could potentially
be never.  We''re all familiar with software that promises tons of
features and never materializes.
> 
hi zed,
I tried your SCGI Rails but I keep getting errors (I am using Fedora
Core 4 Linux, Rails 0.13.1):

log/scgi.log:

ERROR: Malformed request:  does not end with ; it ended with
Malformed request:  does not end with ; it ended with   (RuntimeError)
scgi_rails:128:in `read_payload''
scgi_rails:114:in `connected''
scgi_rails:78:in `accepted''
scgi_rails:75:in `initialize''
scgi_rails:75:in `new''
scgi_rails:75:in `accepted''
scgi_rails:65:in `run''
scgi_rails:62:in `initialize''
scgi_rails:62:in `new''
scgi_rails:62:in `run''
scgi_rails:275:in `execute''
/usr/lib/ruby/gems/1.8/gems/cmdparse-2.0.0/lib/cmdparse.rb:412:in
`parse''
scgi_rails:413

any clue what this is?

thanks and regards,
oliver

Thanks, that seems to bring the browser up.
Now we just need to add it so that the browser comes up
after the webrick instance has initialized.
Maybe in script/server?

-- Tom.

On 9/12/05, choonkeat <choonkeat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I think this will open a browser in Windows
>  system( ENV["COMSPEC"], "/c", "start", url )
if RUBY_PLATFORM =~ /win/
> 
>  
> unix.. dunno.. can try $BROWSER?
>  
>  
> 
> On 9/12/05, Tom Jordan
<tdjordan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 
> > Hi John:
> > 
> > Create an init.rb file in your RAILS_ROOT directory with the following
> > one-liner:
> > 
> > system ''ruby script\server''
> > 
> > Then package it into an exe like normal.
> > This will start the application on port 3000. 
> > 
> > I am still looking for a good way to
> > launch the default browser or package
> > gecko with the exe.
> > 
> > hth,
> > -- Tom.
> > 
> > On 9/11/05, speechexpert
<speechexpert-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org > wrote:
> > > Would like to correspond with...
> > > Thanks
> > > John
> > >
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> > 
> > 
> > --
> > "Nothing will ever be attempted, if all 
> > possible objections must first be
> > overcome." - Samuel Johnson
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org 
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> > 
> 
> -- 
> choonkeat 
> - http://blog.yanime.org/ 
> - http://www.rssfwd.com/ 
>  
>  

-- 
"Nothing will ever be attempted, if all
 possible objections must first be
 overcome." - Samuel Johnson

That''s odd, thought I fixed that.  It''s typo in the script
from a little
while back.

I''m making a new release tonight with all sorts of fixes.  Hang tight
and that should be fixed.

Wait, I should ask:  You are running this through an Apache or lighttpd
server with mod_scgi right?  Not connecting to it directly?  That error
basically says that you gave it a bad SCGI request.

Zed

On Mon, 2005-09-12 at 16:06 +0200, Oliver Kiessler
wrote:
> 2005/9/12, Zed A. Shaw
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>:
> > No point then, I''ll just let Ruby do it''s thing and
complain if it isn''t implemented correctly.
> > 
> > Of course, that depends on when Ruby 2.0 comes out, which could
potentially be never.  We''re all familiar with software that promises
tons of features and never materializes.
> > 
> 
> hi zed,
> I tried your SCGI Rails but I keep getting errors (I am using Fedora
> Core 4 Linux, Rails 0.13.1):
> 
> log/scgi.log:
> 
> ERROR: Malformed request:  does not end with ; it ended with
> Malformed request:  does not end with ; it ended with   (RuntimeError)
> scgi_rails:128:in `read_payload''
> scgi_rails:114:in `connected''
> scgi_rails:78:in `accepted''
> scgi_rails:75:in `initialize''
> scgi_rails:75:in `new''
> scgi_rails:75:in `accepted''
> scgi_rails:65:in `run''
> scgi_rails:62:in `initialize''
> scgi_rails:62:in `new''
> scgi_rails:62:in `run''
> scgi_rails:275:in `execute''
> /usr/lib/ruby/gems/1.8/gems/cmdparse-2.0.0/lib/cmdparse.rb:412:in
`parse''
> scgi_rails:413
> 
> any clue what this is?
> 
> thanks and regards,
> oliver
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Thanks Tom, missed your earlier reply. I am a bit puzzled by why you want a 
browser to come up. Is that part of your app or part of the packaging?
When you say, "package it into an exe like normal," what do you mean?
There seem to be two programs: tar2rubyscript and rubyscript2exe.
Are you thinking of applying one then the other?
Thanks in advance,
John B
PS - off to try your idea

----- Original Message ----- 
From: "Tom Jordan"
<tdjordan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: <choonkeat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
Sent: Monday, September 12, 2005 10:23 AM
Subject: Re: [Rails] Anyone use the RubyScript2exe facility for 
packagingRails App?


Thanks, that seems to bring the browser up.
Now we just need to add it so that the browser comes up
after the webrick instance has initialized.
Maybe in script/server?

-- Tom.

On 9/12/05, choonkeat <choonkeat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I think this will open a browser in Windows
>  system( ENV["COMSPEC"], "/c", "start", url )
if RUBY_PLATFORM =~ /win/
>
>
> unix.. dunno.. can try $BROWSER?
>
>
>
> On 9/12/05, Tom Jordan
<tdjordan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Hi John:
> >
> > Create an init.rb file in your RAILS_ROOT directory with the following
> > one-liner:
> >
> > system ''ruby script\server''
> >
> > Then package it into an exe like normal.
> > This will start the application on port 3000.
> >
> > I am still looking for a good way to
> > launch the default browser or package
> > gecko with the exe.
> >
> > hth,
> > -- Tom.
> >
> > On 9/11/05, speechexpert
<speechexpert-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org > wrote:
> > > Would like to correspond with...
> > > Thanks
> > > John
> > >
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> >
> >
> > --
> > "Nothing will ever be attempted, if all
> > possible objections must first be
> > overcome." - Samuel Johnson
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
> -- 
> choonkeat
> - http://blog.yanime.org/
> - http://www.rssfwd.com/
>
>

-- 
"Nothing will ever be attempted, if all
 possible objections must first be
 overcome." - Samuel Johnson
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Dan Sketcher wrote:
> Wow. Kudos!
+1
Justin

It depends on what your app is trying to be.
If you just want to compile the app as a server or a stand alone application.

Image for a moment making a rails application and packaging it up to
be used not on the web, but on the desktop.

Provide an icon on the desktop, the user clicks on it and up pops a UI shell
that connects to a local only port [ localhost not 0.0.0.0 ]

My fist impulse is to have it launch a browser and use it as the UI shell.
when the shell closes, the server backend shuts down.

-- Tom.


On 9/12/05, speechexpert
<speechexpert-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org>
wrote:
> Thanks Tom, missed your earlier reply. I am a bit puzzled by why you want a
> browser to come up. Is that part of your app or part of the packaging?
> When you say, "package it into an exe like normal," what do you
mean?
> There seem to be two programs: tar2rubyscript and rubyscript2exe.
> Are you thinking of applying one then the other?
> Thanks in advance,
> John B
> PS - off to try your idea
> 
> ----- Original Message -----
> From: "Tom Jordan"
<tdjordan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> To: <choonkeat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
> Sent: Monday, September 12, 2005 10:23 AM
> Subject: Re: [Rails] Anyone use the RubyScript2exe facility for
> packagingRails App?
> 
> 
> Thanks, that seems to bring the browser up.
> Now we just need to add it so that the browser comes up
> after the webrick instance has initialized.
> Maybe in script/server?
> 
> -- Tom.
> 
> On 9/12/05, choonkeat
<choonkeat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I think this will open a browser in Windows
> >  system( ENV["COMSPEC"], "/c", "start",
url ) if RUBY_PLATFORM =~ /win/
> >
> >
> > unix.. dunno.. can try $BROWSER?
> >
> >
> >
> > On 9/12/05, Tom Jordan
<tdjordan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > Hi John:
> > >
> > > Create an init.rb file in your RAILS_ROOT directory with the
following
> > > one-liner:
> > >
> > > system ''ruby script\server''
> > >
> > > Then package it into an exe like normal.
> > > This will start the application on port 3000.
> > >
> > > I am still looking for a good way to
> > > launch the default browser or package
> > > gecko with the exe.
> > >
> > > hth,
> > > -- Tom.
> > >
> > > On 9/11/05, speechexpert
<speechexpert-rphTv4pjVZMJGwgDXS7ZQA@public.gmane.org > wrote:
> > > > Would like to correspond with...
> > > > Thanks
> > > > John
> > > >
> > > > _______________________________________________
> > > > Rails mailing list
> > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > > >
> > >
> > >
> > > --
> > > "Nothing will ever be attempted, if all
> > > possible objections must first be
> > > overcome." - Samuel Johnson
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> >
> > --
> > choonkeat
> > - http://blog.yanime.org/
> > - http://www.rssfwd.com/
> >
> >
> 
> 
> --
> "Nothing will ever be attempted, if all
>  possible objections must first be
>  overcome." - Samuel Johnson
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
> 

-- 
"Nothing will ever be attempted, if all
 possible objections must first be
 overcome." - Samuel Johnson

Tom Jordan wrote:
> It depends on what your app is trying to be.
> If you just want to compile the app as a server or a stand alone
application.
> 
> Image for a moment making a rails application and packaging it up to
> be used not on the web, but on the desktop.
> 
> Provide an icon on the desktop, the user clicks on it and up pops a UI
shell
> that connects to a local only port [ localhost not 0.0.0.0 ]
> 
> My fist impulse is to have it launch a browser and use it as the UI shell.
> when the shell closes, the server backend shuts down.
>
I''ve done this for WATIR, so as to distribute a desktop app for 
launching Web app test scripts from a Web page menu, and for an Og/Nitro 
application for dynamic database creation.

Quite slick, really, and a nice way to bundle up code with a simple UI.



James
-- 

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com  - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com  - Playing with Better Toys