burke / zeus

Boot any rails app in under a second.

Zeus

Zeus preloads your Rails app so that your normal development tasks such as console, server, generate, and specs/tests take less than one second.

This screencast gives a quick overview of how to use zeus with Rails.

Zeus is also covered in RailsCasts episode 412.

More generally, Zeus is a language-agnostic application checkpointer for non-multithreaded applications. Currently only ruby is targeted, but explicit support for other languages is possible.

Requirements (for use with Rails)

• macOS 13+ OR Linux 2.6.13+
• Rails 3.x or 4.x
• Compatible Ruby installation
  • Ruby 2.0+
  • Rubinius

Please note: Zeus requires your project to be running on a file system that supports FSEvents or inotify. This means no NFS, CIFS, Samba, or VBox/VMWare shared folders.

Installation

Install the gem.

gem install zeus

Q: "I should put it in my Gemfile, right?"

A: No. You can, but running bundle exec zeus instead of zeus adds precious seconds to commands that otherwise would be quite a bit faster. Zeus was built to be run from outside of bundler.

IMPORTANT

It is common to see tests running twice when starting out with Zeus. If you see your tests/specs running twice, you should try disabling require 'rspec/autotest' and require 'rspec/autorun' (for RSpec), or require 'minitest/autorun' (for Minitest). (see #134 for more information).

Rails Set up

In your app's directory initialize zeus:

zeus init

which will create two files

custom_plan.rb
zeus.json

Force the test environment: In test/test_helper.rb (or spec/spec_helper.rb if using RSpec), change:

ENV['RAILS_ENV'] ||= 'test'

To:

ENV['RAILS_ENV'] = 'test'

More helpful set up hints at this very nice guide put together by Thoughtbot

Usage

Start the server:

zeus start

The server will print a list of available commands.

Run some commands in another shell:

zeus console
zeus server
zeus test test/unit/widget_test.rb
zeus test spec/widget_spec.rb
zeus generate model omg
zeus rake -T
zeus runner omg.rb

Limitations

You need to restart zeus if you make changes to various initialization files. Examples of these files include:

• FactoryBot factories
• RSpec support files

Related gems

• Spork - a DRb server that forks before each run to ensure a clean testing state
• Commands - a persistent console that runs Rails commands without reloading the env
• Spring - like Zeus but in pure Ruby, totally automatic, and included in Rails 4.1+.

If you're switching from Spork, be sure to read the wiki page on Spork.

Customizing Zeus Commands

To add/modify commands, see docs/ruby/modifying.md.

Contributing

To get started hacking on Zeus itself, see docs/overview.md.

See also the handy contribution guide at contributing.md.

Rails 2.3 Support

The default plan bundled with zeus only supports Rails 3.x and 4.x. There is a project to provide Rails 2.3 support here, however it has not been updated in some time.

Legacy Ruby Versions

Due to official Ruby support lapsing in Feb 2015, Ruby 1.9.3 and below are no longer officially supported. Zeus may work with them but we are not actively supporting them at this time. The last release tested with these versions is 0.15.4.

zeus's Issues

On-demand loading for rarely-used / frequently-changing commands

(eg. production server)

cannot load such file -- zeus/server/acceptor_error_state

just tried it on my rails 3.0 app on 1.9.3 (without gc patches) and got this:

/Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:43:in `block in register_acceptors_as_errors': cannot load such file -- zeus/server/acceptor_error_state (LoadError)
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:42:in `each'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:42:in `register_acceptors_as_errors'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:66:in `handle_load_error'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:17:in `rescue in after_setup'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:14:in `after_setup'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/forked_process.rb:69:in `block in run'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/forked_process.rb:63:in `fork'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/forked_process.rb:63:in `run'
    from /Users/mgrosser/.rvm/gems/ruby-1.9.3-p194/gems/zeus-0.3.0/lib/zeus/server/stage.rb:34:in `block in runloop!'

"already initialized constant" warnings

When loading our project up under zeus, I get the following output:

ntalbott@joshua:~/git/spreedly/subscriptions$ zeus start
starting spawner `boot`
starting spawner `default_bundle`
starting spawner `development_environment`
starting spawner `test_environment`
/Users/ntalbott/git/spreedly/subscriptions/app/models/payment_gateways/spreedly_gateway.rb:2: warning: already initialized constant VALID_VISA
/Users/ntalbott/git/spreedly/subscriptions/app/models/payment_gateways/spreedly_gateway.rb:3: warning: already initialized constant VALID_MASTERCARD
/Users/ntalbott/git/spreedly/subscriptions/app/models/payment_gateways/spreedly_gateway.rb:4: warning: already initialized constant GATEWAY_NOT_RESPONDING_VISA
/Users/ntalbott/git/spreedly/subscriptions/app/models/payment_gateways/spreedly_gateway.rb:5: warning: already initialized constant ERROR_VISA
/Users/ntalbott/git/spreedly/subscriptions/app/models/payment_gateways/spreedly_gateway.rb:6: warning: already initialized constant CHARGE_NOT_AUTHORIZED_VISA
starting acceptor `generate`
starting acceptor `runner`
starting acceptor `console`
starting acceptor `server`
starting spawner `prerake`
starting acceptor `rake`
starting spawner `test_helper`
starting acceptor `testrb`
accepting connection for testrb
accepting connection for testrb

Any idea why those constants would be getting initialized twice? Let me know if I can provide more detail.

Minimize importance of zeus init even further

Batch file change notifications to reduce fork/kill spam

I switch branches quiet often and always see things like this:
acceptor is killed/restarted multiple times when it only should be done once (or in this case never since the acceptor has no action associated, but that's another issue...)

Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/application_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/extensions.rb
killing acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/extensions/ar_rails2_compatability.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/scope_extensions.rb
starting acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/application_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/assets_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/mobile_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/rules_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/tabs_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/targets_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/twitter/link_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/user_interface_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/widgets_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/capped_counts.rb
killing acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/extensions/ar_rails2_compatability.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/scope_extensions.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/stats/stat_rollup.rb
Dependency change at /Users/mgrosser/code/zendesk/main/config/environments/test.rb
Dependency change at /Users/mgrosser/code/zendesk/main/test/helpers/base_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/middleware/headers_middleware.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/middleware/middleware_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/ruby_19/utf8_monkey_patches.rb
starting acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/config/application.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/models/account/creation.rb
killing acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/app/models/permission_set.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/models/permission_set/default_roles.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/models/subscription/plan_change_support.rb
Dependency change at /Users/mgrosser/code/zendesk/main/app/helpers/flash_helper.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/extensions/ar_errors.rb
Dependency change at /Users/mgrosser/code/zendesk/main/test/helpers/base_helper.rb
starting acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/extensions.rb
killing acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/extensions/ar_errors.rb
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/tickets/soft_deletion.rb
starting acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/lib/archive.rb
Dependency change at /Users/mgrosser/code/zendesk/main/.zeus.rb
One of zeus's dependencies changed. Not killing zeus. You may have to restart the server.
Dependency change at /Users/mgrosser/code/zendesk/main/config/application.rb
killing acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/test_memory_store.rb
starting acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/auth/warden/callbacks.rb
killing acceptor `testrb`
Dependency change at /Users/mgrosser/code/zendesk/main/lib/zendesk/auth/warden/zendesk_strategy.rb
starting acceptor `testrb

Handshaking a client to an acceptor should not require a fork

Currently client_handler.rb forks to handshake a client to an acceptor. Apart from being desperately in need of refactoring-in-general, this creates a totally unnecessary process that could be handled with threading.

Replication:

1. Look at the code.

Ideas:

a) Fix it.
b) Find a good reason why a fork is actually a good idea here.

Expected behaviour:

• Only one additional process is created when a client connects.

DSL, ProcessTree and Stage/Acceptor all do kind of the same thing.

Expected outcome:

1. The ugliness is fixed

Great Documentation

running a test after saving a file and before zeus restarts acceptor causes EOFError

running: zeus testrb -Itest -I. test/functional/admin/comments_controller_test.rb test/unit/version_store_test.rb

/Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:51:in `readline': end of file reached (EOFError)
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:51:in `connect_to_server'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:28:in `block (2 levels) in run'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:23:in `open'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:23:in `block in run'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:95:in `raw'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:95:in `maybe_raw'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:22:in `run'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/client.rb:18:in `run'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/zeus/cli.rb:74:in `block (2 levels) in <class:CLI>'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/lib/thrud.rb:94:in `start'
from /Users/steven/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.3.1/bin/zeus:4:in `<top (required)>'
from /Users/steven/.rbenv/versions/1.9.3-p0/bin/zeus:19:in `load'
from /Users/steven/.rbenv/versions/1.9.3-p0/bin/zeus:19:in `<main>'

"fix" Rake::TestTask to leverage Zeus.

Window size issues

Unsure whether this is a winsize handling issue or just fish misbehaving:

zeus 0 * % ruby -I../zeus/lib ../zeus/bin/zeus s
Zeus doesn't seem to be running, try 'zeus start`
                                                 zeus 1 * 1% 

Ensure that when a client disconnects, the command process is killed

I'm not sure whether this is guaranteed-safe right now or not.

Replication:

• Try it out and see if you can force zeus to orphan a command process
• Look through the code and see if you can find a way for it to theoretically happen

Ideas:

• Nope

Expected behaviour:

• We never, ever have, for example, a server hanging there indefinitely because the client died in an unexpected way.

Thrud is not quite generic and is mostly-terrible code.

Clean it up, and pull some of that stuff back into cli.rb.

Not properly reloading rake tasks

cannot load such file -- test_helper (LoadError)

Trying zeus out this morning on my project, and when I run zeus start it starts failing when trying to load the test_helper

starting spawner `test_helper`
/Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:251:in `require': cannot load such file -- test_helper (LoadError)
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:251:in `block in require'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:236:in `load_dependency'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:251:in `require'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/templates/rails.rb:77:in `block (6 levels) in <top (required)>'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:15:in `call'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:15:in `each'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:15:in `after_setup'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:69:in `block in run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `fork'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:34:in `block in runloop!'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:27:in `loop'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:27:in `runloop!'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:70:in `block in run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `fork'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:22:in `block in after_setup'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:in `each'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:in `after_setup'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:69:in `block in run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `fork'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:22:in `block in after_setup'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:in `each'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:in `after_setup'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:69:in `block in run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `fork'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in `run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/server.rb:48:in `run'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/zeus/cli.rb:45:in `start'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/lib/thrud.rb:94:in `start'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/gems/zeus-0.3.1/bin/zeus:4:in `<top (required)>'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/bin/zeus:19:in `load'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/bin/zeus:19:in `<main>'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/bin/ruby_noexec_wrapper:14:in `eval'
    from /Users/user/.rvm/gems/ruby-1.9.3-p194@project/bin/ruby_noexec_wrapper:14:in `<main>'

Probably because we are using rspec and don't have a test_helper, just a spec_helper

WEBrick eats signals

Figure out some way to force remote webrick to quit nicely like mongrel does.

rails-3.2 12h * M?2 % zeus server
=> Booting WEBrick
=> Rails 3.2.7 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2012-08-08 13:24:18] INFO  WEBrick 1.3.1
[2012-08-08 13:24:18] INFO  ruby 1.9.3 (2012-02-16) [x86_64-darwin12.0.0]
[2012-08-08 13:24:18] INFO  WEBrick::HTTPServer#start: pid=99194 port=3000
^C[2012-08-08 13:24:19] ERROR SignalException: SIGTERM
    /Users/burke/.rbenv/versions/1.9.3-p125-perf/lib/ruby/1.9.1/webrick/server.rb:98:in `select'
^\[2012-08-08 13:24:19] ERROR SignalException: SIGQUIT
    /Users/burke/.rbenv/versions/1.9.3-p125-perf/lib/ruby/1.9.1/webrick/server.rb:98:in `select'
^Z

Goes head-to-head with debugger; Zeus loses

I have the debugger gem in my development group:

group :development do
  gem 'debugger'
end

I use Pow, and have an initializer that starts the debugger:

# config/initializers/my_super_secret_ruby_debug_initializer.rb
if (Rails.env.development? || Rails.env.test?) && !$rails_rake_task
  require 'debugger'

  Debugger.settings[:autoeval] = true
  Debugger.settings[:autolist] = 1
  Debugger.settings[:reload_source_on_change] = true
  Debugger.start_remote
end

This combination makes Zeus start the following error-state acceptors:

starting error-state acceptor `generate`
starting error-state acceptor `runner`
starting error-state acceptor `console`
starting error-state acceptor `server`
starting error-state acceptor `rake`

And upon visiting zeus console we discover that:

/…/gems/debugger-1.2.0/lib/ruby-debug.rb:88:in `initialize': Address already in use - bind(2) (Errno::EADDRINUSE)
    from /…/gems/debugger-1.2.0/lib/ruby-debug.rb:88:in `new'
    from /…/gems/debugger-1.2.0/lib/ruby-debug.rb:88:in `start_control'
    from /…/gems/debugger-1.2.0/lib/ruby-debug.rb:59:in `start_remote'
    from /…/config/initializers/my_super_secret_ruby_debug_initializer.rb:8:in `<top (required)>'
    …

I suppose I need to find a way to disable the debugger, or perhaps change the port number, when being booted by Zeus. That is, unless it's possible for Zeus to do something clever.

Any suggestions?

Eliminate client-side exit lag

When a client sends EOF in a console or ^C in another runner, or when a runner completes, there's usually a 500ms lag or so before the connection is dropped and the user returns to their shell prompt. This should be nearly-immediate.

Replication:

1. time zeus runner 'puts "too slow"'

Ideas:

• This could be because of the at_exit blocks, though I kind of doubt they'd have that much of an effect. It'll take some digging
• This is very likely related to #11

Expected behaviour:

• zeus runner 'puts "a"' should take no more than 0.4 seconds.

files loaded in Acceptor actions are not reloadable

low-priority, since the template/rails.rb requires nearly nothing in acceptors.

Comprehensive tests

Zeus generate migration fails silently

zeus generate migration migration_name

appears to do nothing.

Love this project though!

`zeus start` blows up on 1.9.3-p0

$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.3.0]

$ zeus start

/Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server/file_monitor/fsevent.rb:30:in `read_nonblock': end of file reached (EOFError)
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server/file_monitor/fsevent.rb:30:in `read_and_notify_files'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server/file_monitor/fsevent.rb:22:in `block in handle_changed_files'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server/file_monitor/fsevent.rb:20:in `times'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server/file_monitor/fsevent.rb:20:in `handle_changed_files'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server/file_monitor/fsevent.rb:10:in `on_datasource_event'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server.rb:72:in `block (2 levels) in run'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server.rb:71:in `each'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server.rb:71:in `block in run'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server.rb:64:in `loop'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/server.rb:64:in `run'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/zeus/cli.rb:45:in `start'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/lib/thrud.rb:94:in `start'
    from /Users/.../.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/zeus-0.2.4/bin/zeus:4:in `<top (required)>'
    from /Users/.../.rbenv/versions/1.9.3-p0/bin/zeus:19:in `load'
    from /Users/.../.rbenv/versions/1.9.3-p0/bin/zeus:19:in `<main>'

RAILS_ENV=test zeus <command> should do something meaningful

I ran

RAILS_ENV=test zeus rake db:setup

and found that my development db was dropped and recreated

Issue loading io/console

Hey @burke,

Running zeus start seems to work just fine, but running zeus s afterwards gives the following error:

/Users/legrandfromage/.rbenv/versions/1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': no such file to load -- io/console (LoadError)
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/zeus-0.4.4/lib/zeus/client.rb:1:in `<top (required)>'
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/zeus-0.4.4/lib/zeus/cli.rb:74:in `block (2 levels) in <class:CLI>'
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/zeus-0.4.4/lib/thrud.rb:94:in `start'
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/zeus-0.4.4/bin/zeus:4:in `<top (required)>'
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/bin/zeus:23:in `load'
    from /Users/legrandfromage/.rbenv/versions/1.9.2-p290/bin/zeus:23:in `<main>'

I was able to solve the problem by doing a simple gem install io-console, but it'd be nice to have that listed as a dependency or something in the readme. Thanks!

Cucumber Support

Any plans for zeus cucumber?

rb-kqueue-burke introduces a hard dependency on FFI

rb-kqueue-burke introduces a hard dependency on FFI, forcing the host app, to also confirm to this dependency.
Obviously, simply adding zeus as gem to our application solves this.

Unsure what the best course of action is. It is worth a discussion.

Integration tests fail

When running Rails integration tests using zeus, I'm getting weird errors:

ntalbott@joshua:~/git/spreedly/subscriptions$ zeus testrb test/integration/api/v4/v4_comp_subscriber_test.rb -n /OK/
Run options: -n /OK/

# Running tests:

E

Finished tests in 0.574928s, 1.7393 tests/s, 0.0000 assertions/s.

  1) Error:
test: V4CompSubscriber should work OK with no start time and/or amount. (V4CompSubscriberTest):
ActionController::RoutingError: undefined local variable or method `ssl_required' for SessionsController:Class
    /Users/ntalbott/git/spreedly/subscriptions/app/controllers/sessions_controller.rb:4:in `<class:SessionsController>'
    /Users/ntalbott/git/spreedly/subscriptions/app/controllers/sessions_controller.rb:1:in `<top (required)>'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:244:in `require'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:244:in `block in require'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in `load_dependency'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:240:in `require'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:352:in `require_or_load'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:493:in `load_missing_constant'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:183:in `block in const_missing'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:181:in `each'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:181:in `const_missing'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/inflector/methods.rb:124:in `block in constantize'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/inflector/methods.rb:123:in `each'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/inflector/methods.rb:123:in `constantize'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:531:in `block in <class:Reference>'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:541:in `yield'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:541:in `default'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:541:in `get'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/routing/route_set.rb:58:in `controller_reference'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/routing/route_set.rb:44:in `controller'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/routing/route_set.rb:23:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-mount-0.6.14/lib/rack/mount/route_set.rb:148:in `block in call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-mount-0.6.14/lib/rack/mount/code_generation.rb:93:in `block in recognize'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-mount-0.6.14/lib/rack/mount/code_generation.rb:75:in `optimized_each'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-mount-0.6.14/lib/rack/mount/code_generation.rb:92:in `recognize'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-mount-0.6.14/lib/rack/mount/route_set.rb:139:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/routing/route_set.rb:493:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/sass-3.1.10/lib/sass/plugin/rack.rb:54:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/best_standards_support.rb:17:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/head.rb:14:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/methodoverride.rb:24:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/params_parser.rb:21:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/flash.rb:182:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/session/abstract_store.rb:149:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/cookies.rb:302:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activerecord-3.0.10/lib/active_record/query_cache.rb:32:in `block in call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activerecord-3.0.10/lib/active_record/connection_adapters/abstract/query_cache.rb:28:in `cache'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activerecord-3.0.10/lib/active_record/query_cache.rb:12:in `cache'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activerecord-3.0.10/lib/active_record/query_cache.rb:31:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activerecord-3.0.10/lib/active_record/connection_adapters/abstract/connection_pool.rb:354:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/callbacks.rb:46:in `block in call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/callbacks.rb:416:in `_run_call_callbacks'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/callbacks.rb:44:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/sendfile.rb:106:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/remote_ip.rb:48:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/show_exceptions.rb:47:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/railties-3.0.10/lib/rails/rack/logger.rb:13:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/lib/custom_logger.rb:14:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/runtime.rb:17:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/activesupport-3.0.10/lib/active_support/cache/strategy/local_cache.rb:72:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/lock.rb:13:in `block in call'
    <internal:prelude>:10:in `synchronize'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/lock.rb:13:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/actionpack-3.0.10/lib/action_dispatch/middleware/static.rb:30:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/railties-3.0.10/lib/rails/application.rb:168:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/urlmap.rb:47:in `block in call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/urlmap.rb:41:in `each'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-1.2.5/lib/rack/urlmap.rb:41:in `call'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-test-0.5.7/lib/rack/mock_session.rb:30:in `request'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-test-0.5.7/lib/rack/test.rb:209:in `process_request'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/rack-test-0.5.7/lib/rack/test.rb:57:in `get'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/capybara-1.1.2/lib/capybara/rack_test/browser.rb:62:in `process'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/capybara-1.1.2/lib/capybara/rack_test/browser.rb:21:in `visit'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/capybara-1.1.2/lib/capybara/rack_test/driver.rb:32:in `visit'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/capybara-1.1.2/lib/capybara/session.rb:157:in `visit'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/capybara-1.1.2/lib/capybara/dsl.rb:161:in `visit'
    /Users/ntalbott/git/spreedly/subscriptions/test/fixture_support.rb:8:in `method_missing'
    /Users/ntalbott/git/spreedly/subscriptions/test/integration/dsl/spreedly_dsl.rb:3:in `login'
    /Users/ntalbott/git/spreedly/subscriptions/test/test_helper.rb:102:in `new_session_as'
    /Users/ntalbott/git/spreedly/subscriptions/test/integration/api/v4/v4_comp_subscriber_test.rb:6:in `setup'
    /Users/ntalbott/git/spreedly/subscriptions/vendor/ruby/1.9.1/gems/mocha-0.12.3/lib/mocha/integration/mini_test/version_230_to_2101.rb:26:in `run'

1 tests, 0 assertions, 0 failures, 1 errors, 0 skips

This is the first interaction with zeus after starting it up, and the test behaves normally when run without zeus.

Could be related to #62?

'waiting' processes don't handle signals properly after connecting

Very related to #27, I'll bet.

rspec support

Extract AR/AS pre/post-fork stuff into configuration DSL

This is maybe not an issue. I guess it's more of a question of whether I'm okay with having any rails-specific code in the core project.

Currently it's quite framework-agnostic, other than the stuff about clearing/reloading connections littered around the forks. This could be refactored into the configuration DSL in some way, probably. Or it could be left there, providing easily-overridable methods in Zeus::Server::ForkedProcess. The former would be probably preferable, though it complicates the DSL even more. The latter is probably sufficient until I make some effort to target non-rails projects.

No lost processes

Works on nearly all rails projects with no hacks

minitest support

Reloading occasionally doesn't work.

Not sure when/why.

Kicker/guard-like feature for autotesting

files loaded in the boot stage are not reloadable

doesn't stop on debugger

require 'debugger'
debugger

stops outside of zeus, wont stop in zeus. Used to work.

Sending INT or QUIT to a remote process doesn't actually kill it (master, not 0.3.1)

FSEvents-wrapper needs feedback on crash

Right now it just fails silently and never triggers dependencies.

It should be pretty difficult to force it to crash once it's running (especially without specifically trying to), but it will fail to even start on anything other than OS X 10.7+.

Ideally we'd print a message reading something along the lines of: "Zeus can't watch files for changes unless you're using OS X 10.7+", and then we'd... probably exit, but I guess we could keep going without file monitoring, technically.

Do acceptors actually require separate processes?

I don't think they do. It should be possible to go straight from spawner -> runner. It would probably complicate the code, but it would eliminate a ton of extra processes.

Error-state acceptors are already run in-process with the spawner. What's different about command acceptors?

Bulletproof dependency monitoring

replace FSEventStream atomically

or use a lastEvent timestamp or something. Threre's currently a several-microsecond (maybe millisecond?) window when the stream is replaced where events could be lost.

Rails 3.2 handles generators differently

Shouldn't be hard to support 3.0 and 3.2 at the same time, but currently 3.2 breaks.

Sane configuration DSL

Figure out a better way to clean up child processes

at_exit blocks all over the place with conditionals is kind of ghetto.

Not sure if is a bug -- cannot load such file -- test_helper (LoadError)

Hi @burke, I installed zeus yesterday and it worked for me, but is giving me this error/warning in the log from "zeus start", thanks a lot for making an effort to make development faster!

What do you need from my side to help validate if is an issue or just our app.

starting spawner test_helper
/Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:240:in require': cannot load such file -- test_helper (LoadError) from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:240:inblock in require'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:223:in block in load_dependency' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:640:innew_constants_in'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:223:in load_dependency' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:240:inrequire'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/templates/rails.rb:77:in block (6 levels) in <top (required)>' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:15:incall'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:15:in each' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:15:inafter_setup'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:69:in block in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:infork'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:34:inblock in runloop!'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:27:in loop' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:27:inrunloop!'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:70:in block in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:infork'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:22:inblock in after_setup'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:in each' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:inafter_setup'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:69:in block in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:infork'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:22:inblock in after_setup'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:in each' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/stage.rb:21:inafter_setup'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:69:in block in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:infork'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server/forked_process.rb:63:in run' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/server.rb:48:inrun'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/zeus/cli.rb:45:in start' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/lib/thrud.rb:94:instart'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/gems/zeus-0.3.1/bin/zeus:4:in <top (required)>' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/bin/zeus:19:inload'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/bin/zeus:19:in <main>' from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/bin/ruby_noexec_wrapper:14:ineval'
from /Users/supinchecompilla/.rvm/gems/ruby-1.9.3-p194-perf/bin/ruby_noexec_wrapper:14:in `

'

Syntax errors when reloading cause badness

When zeus is reloading a process and encounters a syntax error, you pretty much have to restart zeus.

Reproducing:

1. Load zeus
2. Change a file to be invalid syntactically
3. Try to start a console

Expected behaviour:

1. When attempting to open a console, the error stacktrace is printed to the (client's) screen
2. Every time the error'd file is changed, zeus attempts to restart the failed processes.

(c/o @ssoroka)

Support github.com/wisq/rails_parallel

Sort of depends on #54.

Refactor Everything :(

It's so bad :(

Client processes never terminate

After launching and terminating several client processes, subsequent client processes do not exit when their corresponding server process has been killed

Replication:

1. Start zeus server
2. Run zeus c three times, each time ^D'ing out.
3. Attempt a fourth time, and notice that after ^D, the process does not exit. The process.kill on/around client.rb:73 fails with Errno::ESRCH when you ^C.

Ideas:

• Longshot, but it might be related to at_exit handlers piling up -- the process doesn't terminate immediately, so the client doesn't recognize that it's exited.

Expected behaviour:

Runners can be started any number of times without causing zeus to not notice when they terminate.