I have looked through the docs, looked at the code, even gave a cursory (2 page) glance at google, and it is not clear to me what SpecServer is or what it is for. Is it meant to speed up the execution of specs in a rails environment by doing some magic on the database? Or I am thinking it keeps a copy of Rails running to avoid the rails reload delay... Is there any documentation on this so I can go find out instead of bugging the list? :) Regards Mikel
On Mar 13, 2008, at 12:17 AM, Mikel Lindsaar wrote:> I have looked through the docs, looked at the code, even gave a > cursory (2 page) glance at google, and it is not clear to me what > SpecServer is or what it is for. > > Is it meant to speed up the execution of specs in a rails environment > by doing some magic on the database?The spec server does no magic. It load the rails environment, and the runs the specs through Drb (look up the rdoc for Drb/Rinda).> Or I am thinking it keeps a copy of Rails running to avoid the rails > reload delay...Yep - that''s pretty much it. It usually takes a few seconds to load up the rails environment, and if you are running your specs every few seconds, that can shave off a lot of time from your dev cycle over time.> > Is there any documentation on this so I can go find out instead of > bugging the list? :)No - not really. All you need to do is start the spec_server: ruby script/spec_server The specs can then be run through the server with --drb (put it in spec.opts, if you always want to use it). Scott
I guess I could just try it, but does spec_server work with autotest too? ie. ruby script/spec_server & autotest ? On Wed, Mar 12, 2008 at 9:36 PM, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > On Mar 13, 2008, at 12:17 AM, Mikel Lindsaar wrote: > > > I have looked through the docs, looked at the code, even gave a > > cursory (2 page) glance at google, and it is not clear to me what > > SpecServer is or what it is for. > > > > Is it meant to speed up the execution of specs in a rails environment > > by doing some magic on the database? > > The spec server does no magic. It load the rails environment, and the > runs the specs through Drb (look up the rdoc for Drb/Rinda). > > > > Or I am thinking it keeps a copy of Rails running to avoid the rails > > reload delay... > > Yep - that''s pretty much it. It usually takes a few seconds to load > up the rails environment, and if you are running your specs every few > seconds, that can shave off a lot of time from your dev cycle over time. > > > > > > Is there any documentation on this so I can go find out instead of > > bugging the list? :) > > No - not really. All you need to do is start the spec_server: > > ruby script/spec_server > > The specs can then be run through the server with --drb (put it in > spec.opts, if you always want to use it). > > Scott > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- SMS/Text: +63 905 220 2207 Skype: dbit_solutions
On Mar 28, 2008, at 2:35 PM, David Beckwith wrote:> I guess I could just try it, but does spec_server work with > autotest too? > > ie. > ruby script/spec_server & > autotest >Sure. Autotest is a pretty stupid program (and I mean that in a good way). All it does is periodically run a spec command in a subshell. Scott> ? > > > On Wed, Mar 12, 2008 at 9:36 PM, Scott Taylor > <mailing_lists at railsnewbie.com> wrote: >> >> On Mar 13, 2008, at 12:17 AM, Mikel Lindsaar wrote: >> >>> I have looked through the docs, looked at the code, even gave a >>> cursory (2 page) glance at google, and it is not clear to me what >>> SpecServer is or what it is for. >>> >>> Is it meant to speed up the execution of specs in a rails >>> environment >>> by doing some magic on the database? >> >> The spec server does no magic. It load the rails environment, and the >> runs the specs through Drb (look up the rdoc for Drb/Rinda). >> >> >>> Or I am thinking it keeps a copy of Rails running to avoid the rails >>> reload delay... >> >> Yep - that''s pretty much it. It usually takes a few seconds to load >> up the rails environment, and if you are running your specs every few >> seconds, that can shave off a lot of time from your dev cycle over >> time. >> >> >>> >>> Is there any documentation on this so I can go find out instead of >>> bugging the list? :) >> >> No - not really. All you need to do is start the spec_server: >> >> ruby script/spec_server >> >> The specs can then be run through the server with --drb (put it in >> spec.opts, if you always want to use it). >> >> Scott >> >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > SMS/Text: +63 905 220 2207 > Skype: dbit_solutions > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Just to help clarify for the newbies like me. script/spec_server runs in conjunction with script/spec but not ruby your_spec.rb. It seems like the way to use script/spec_server is to have 2 console programs open: ruby script/spec_server That will have the spec_server running in the background and your entire application loaded into memory at the time of execution, and since it''s on top of once console it will be easy to kill and restart when you need to. If you make changes to your application that are loaded up only in the beginning (like installing a new plugin), then you''ll have to restart spec_server. (Q: What about the following cases: make a database schema change, add another user-defined model, add another controller, edit an existing controller, edit an existing model make changes to your routes.rb file, edit a plugin. For which of those cases do you have to restart spec_server and which cases don''t you? ) And in another console run the spec you''re working on: ruby script/spec spec/models/your_spec.rb --drb -c I''ve noticed that autotest doesn''t send commands to the spec_server. Instead it reloads the entire Rails environment and your application''s plugins everytime it executes. This causes autotest to run significantly slower than script server, because when you run the script/spec command the specs are sent to the spec_server which already has your Rails environment fired up and ready to go. If you happen to install a new plugin or something like that, then you''ll have to restart the spec_server. Feel free to correct me, if I''m wrong. I''m just trying to shed some light for new users, hopefully without saying anything that''s not right. I''m just learning all this stuff. David :) On Mar 28, 9:17 pm, Scott Taylor <mailing_li... at railsnewbie.com> wrote:> On Mar 28, 2008, at 2:35 PM, David Beckwith wrote: > > > I guess I could just try it, but does spec_server work with > > autotest too? > > > ie. > > ruby script/spec_server & > > autotest > > Sure. > > Autotest is a pretty stupid program (and I mean that in a good way). > All it does is periodically run a spec command in a subshell. > > Scott > > > > > ? > > > On Wed, Mar 12, 2008 at 9:36 PM, Scott Taylor > > <mailing_li... at railsnewbie.com> wrote: > > >> On Mar 13, 2008, at 12:17 AM, Mikel Lindsaar wrote: > > >>> I have looked through the docs, looked at the code, even gave a > >>> cursory (2 page) glance at google, and it is not clear to me what > >>> SpecServer is or what it is for. > > >>> Is it meant to speed up the execution of specs in a rails > >>> environment > >>> by doing some magic on the database? > > >> The spec server does no magic. It load the rails environment, and the > >> runs the specs through Drb (look up the rdoc for Drb/Rinda). > > >>> Or I am thinking it keeps a copy of Rails running to avoid the rails > >>> reload delay... > > >> Yep - that''s pretty much it. It usually takes a few seconds to load > >> up the rails environment, and if you are running your specs every few > >> seconds, that can shave off a lot of time from your dev cycle over > >> time. > > >>> Is there any documentation on this so I can go find out instead of > >>> bugging the list? :) > > >> No - not really. All you need to do is start the spec_server: > > >> ruby script/spec_server > > >> The specs can then be run through the server with --drb (put it in > >> spec.opts, if you always want to use it). > > >> Scott > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.org > >>http://rubyforge.org/mailman/listinfo/rspec-users > > > -- > > SMS/Text: +63 905 220 2207 > > Skype: dbit_solutions > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
On Mar 29, 2008, at 11:11 PM, David Beckwith wrote:> Just to help clarify for the newbies like me. script/spec_server runs > in conjunction with script/spec but not ruby your_spec.rb. It seems > like the way to use script/spec_server is to have 2 console programs > open: > > ruby script/spec_server > > That will have the spec_server running in the background and your > entire application loaded into memory at the time of execution, and > since it''s on top of once console it will be easy to kill and restart > when you need to. If you make changes to your application that are > loaded up only in the beginning (like installing a new plugin), then > you''ll have to restart spec_server. (Q: What about the following > cases: > make a database schema change, > add another user-defined model, > add another controller, > edit an existing controller, > edit an existing model > make changes to your routes.rb file, > edit a plugin. > For which of those cases do you have to restart spec_server and which > cases don''t you? ) > > And in another console run the spec you''re working on: > > ruby script/spec spec/models/your_spec.rb --drb -c > > I''ve noticed that autotest doesn''t send commands to the spec_server. > Instead it reloads the entire Rails environment and your application''s > plugins everytime it executes. This causes autotest to run > significantly slower than script server, because when you run the > script/spec command the specs are sent to the spec_server which > already has your Rails environment fired up and ready to go. If you > happen to install a new plugin or something like that, then you''ll > have to restart the spec_server.No - It should work - Remember: Autotest is DUMB. Dumb, dumb, dumb. It''s a great tool, but it was written before rspec. It has nothing to do with rspec. All it does is watch a series of files, and reruns a certain command when one of those files changes. So - Autotest has no knowledge of the internals of Rspec. The BUG was that if you put the --drb (or the equivalent -X) flag in your spec.opts file, Rspec would not run them with the drb server. This bug has been fixed in trunk (as far as I know). Scott
On Mar 29, 2008, at 11:11 PM, David Beckwith wrote:> Just to help clarify for the newbies like me. script/spec_server runs > in conjunction with script/spec but not ruby your_spec.rb. It seems > like the way to use script/spec_server is to have 2 console programs > open: > > ruby script/spec_server > > That will have the spec_server running in the background and your > entire application loaded into memory at the time of execution, and > since it''s on top of once console it will be easy to kill and restart > when you need to. If you make changes to your application that are > loaded up only in the beginning (like installing a new plugin), then > you''ll have to restart spec_server. (Q: What about the following > cases: > make a database schema change, > add another user-defined model, > add another controller, > edit an existing controller, > edit an existing model > make changes to your routes.rb file, > edit a plugin. > For which of those cases do you have to restart spec_server and which > cases don''t you? )I''m replying in chunks here, but: AFAIK, anything which is required will need to be reloaded (if it changes). Also - any change to rails itself. Schema changes will require you to reload the server. Not sure about a new model, but, if you say, added a new column to a table, you would most certainly need to reload the spec_server (as rails actually caches ActiveRecord::Base.columns, much to my chagrin the other day in a migration). Anything which is loaded with Kernel#load (or load_once, or whatever rails does) shouldn''t cause you to reload the spec server. So - this means changes to the code of a model or a controller should be safe, since they are load''ed, not required (as require does nothing but return false the second time it is called). I''m not sure about the routes or the plugin scenario. I would assume for the plugin that it depends on how the code is internally loaded up. If it is require''d instead of load''ed, I''d bet that you need to change the spec_server. Also - just a tip for those who might be using (or thinking of using) the spec_server: I''ve noticed that shared example groups aren''t being reloaded properly. This is a bug in rspec which I''ve yet to file a ticket for, mainly out of lack of time. Next time I run across it, I''ll report it. Scott