Backgroundrb devel - Jun 2006 - one more suggestion for backgroundrb

this:

Index: script/backgroundrb/lib/backgroundrb.rb
==================================================================---
script/backgroundrb/lib/backgroundrb.rb     (revision 16)
+++ script/backgroundrb/lib/backgroundrb.rb     (working copy)
@@ -29,7 +29,11 @@
     # the log via @logger
     def initialize(args)
       @logger = BACKGROUNDRB_LOGGER
-      Thread.new { do_work(args) }
+      begin
+        Thread.new { do_work(args) }
+      rescue Exception => e
+        @logger.error e.inspect
+      end
     end

   end

On Jun 21, 2006, at 2:18 PM, dorian taylor wrote:
> this:
>
> Index: script/backgroundrb/lib/backgroundrb.rb
> ==================================================================> ---
script/backgroundrb/lib/backgroundrb.rb     (revision 16)
> +++ script/backgroundrb/lib/backgroundrb.rb     (working copy)
> @@ -29,7 +29,11 @@
>      # the log via @logger
>      def initialize(args)
>        @logger = BACKGROUNDRB_LOGGER
> -      Thread.new { do_work(args) }
> +      begin
> +        Thread.new { do_work(args) }
> +      rescue Exception => e
> +        @logger.error e.inspect
> +      end
>      end
>
>    end
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
Dorian-

	Commited.. Thanks. I am all tied up doing railsconf stuff this  
weekend but I will be doing a little hack fest on backgroundrb while  
I''m there to get it into a little better shape. I will be moving all  
code into the plugin and only using stubs in script/backgroundrb.  
this will make things easier to work with and test. I appreciate your  
patches and feedback.

	Any feature requests for my hack fest?

Cheers-
-Ezra

Can we name that logger something different since it goes to the
log/backgroundrb.log file instead of one of the dev/test/prod logs?  Just a
suggestion....  Great fix, though, awesome.

There was another post that came by in June with code to fully load the
entire Rails environment  -- versus loading up just the ActiveRecord
connection:

-if CONFIG[''load_rails'']
-  ActiveRecord::Base.establish_connection(YAML.load(ERB.new(IO.read
("#{RAILS_ROOT}/#{CONFIG[''databse_yml'']}")).result)[CONFIG[''environment'']])
-end

+if CONFIG[''load_rails'']
+  require "#{RAILS_ROOT}/config/environment"
+end

It was silently failing for me when loading up models that included required
classes or utilized includes, such as a model that has:  require
''net-ssh''
or something like that.  It was mentioned that this does use a lot of memory
-- it''s true, perhaps this could be another option?  load_full_rails:
true
or document the use of loading up required modules too?

One more request -- does the rake backgroundrb:start task read the config
file for the environment -- I still have to use: 
RAILS_ENV="production"
rake backgroundrb:start to get it to load in production mode.  Though, you
may fix this in your move to stub the scripts.

Great work Ezra, we''re having fun with your backgroundrb, and have a
blog
article coming out on it soon.  Thanks!

On 6/21/06, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
> On Jun 21, 2006, at 2:18 PM, dorian taylor wrote:
>
> > this:
> >
> > Index: script/backgroundrb/lib/backgroundrb.rb
> > ==================================================================>
> --- script/backgroundrb/lib/backgroundrb.rb     (revision 16)
> > +++ script/backgroundrb/lib/backgroundrb.rb     (working copy)
> > @@ -29,7 +29,11 @@
> >      # the log via @logger
> >      def initialize(args)
> >        @logger = BACKGROUNDRB_LOGGER
> > -      Thread.new { do_work(args) }
> > +      begin
> > +        Thread.new { do_work(args) }
> > +      rescue Exception => e
> > +        @logger.error e.inspect
> > +      end
> >      end
> >
> >    end
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
>
> Dorian-
>
>         Commited.. Thanks. I am all tied up doing railsconf stuff this
> weekend but I will be doing a little hack fest on backgroundrb while
> I''m there to get it into a little better shape. I will be moving
all
> code into the plugin and only using stubs in script/backgroundrb.
> this will make things easier to work with and test. I appreciate your
> patches and feedback.
>
>         Any feature requests for my hack fest?
>
> Cheers-
> -Ezra
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>


-- 
Charles Brian Quinn
www.seebq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060621/9bc040f9/attachment.html

On Jun 21, 2006, at 3:12 PM, Charles Brian Quinn wrote:
> Can we name that logger something different since it goes to the  
> log/backgroundrb.log file instead of one of the dev/test/prod  
> logs?  Just a suggestion....  Great fix, though, awesome.
>
> There was another post that came by in June with code to fully load  
> the entire Rails environment  -- versus loading up just the  
> ActiveRecord connection:
>
> -if CONFIG[''load_rails'']
> -  ActiveRecord::Base.establish_connection(YAML.load(ERB.new(IO.read 
>
("#{RAILS_ROOT}/#{CONFIG[''databse_yml'']}")).result)[CONFIG
> [''environment'']])
> -end
>
> +if CONFIG[''load_rails'']
> +  require "#{RAILS_ROOT}/config/environment"
> +end
>
> It was silently failing for me when loading up models that included  
> required classes or utilized includes, such as a model that has:   
> require ''net-ssh'' or something like that.  It was
mentioned that
> this does use a lot of memory -- it''s true, perhaps this could be
> another option?  load_full_rails: true  or document the use of  
> loading up required modules too?
>
> One more request -- does the rake backgroundrb:start task read the  
> config file for the environment -- I still have to use:   
> RAILS_ENV="production" rake backgroundrb:start to get it to load
in
> production mode.  Though, you may fix this in your move to stub the  
> scripts.
>
> Great work Ezra, we''re having fun with your backgroundrb, and have
> a blog article coming out on it soon.  Thanks!
>
>
>         Any feature requests for my hack fest?
>
> Cheers-
> -Ezra
>
> -- 
> Charles Brian Quinn
> www.seebq.com
Charles-

	So how would you like the logger to behave? Do you mean having it  
write into the rails dev and prod log files? Or just an option to  
rename it to something else? I will flesh out the config file and its  
related parser to make it much more flexible and tunable when I  
refactor things. Also will be adding a windows service ability.

-Ezra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060621/81dcf61e/attachment.html

On 6/21/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> Charles-
>
> So how would you like the logger to behave? Do you mean having it write
> into the rails dev and prod log files? Or just an option to rename it to
> something else? I will flesh out the config file and its related parser to
> make it much more flexible and tunable when I refactor things. Also will be
> adding a windows service ability.
>
Logging to the rails log files would be cool -- if it''s possible.  I
imagine
if you loaded the rails environment you could just go ahead and use
logger.info, though I didn''t try it.

All great work, those were just off the top of my head for your hackfest.

Let us know when we can help test.
-- 
Charles Brian Quinn
www.seebq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060621/3424d376/attachment.html