ninjudd/drip

Limits of drip - rails console? rake test?

kimptoc opened this issue · 4 comments

kimptoc commented

Hi,

I am able to run my app using drip and works fine (much speedier, thanks). I have the rails startup bit in my dripmain.rb. rails server (3.2.12) works fine too.

But "rails console" just returns to the prompt, no error code nor message. Given its more interactive, I can imagine, things like that are not supported (I am using pry). Although, plain irb works fine - so maybe its a pry related issue.

Also when I run some integration tests, like below - I get the below error about loading the test_helper. Works fine when I disable drip - also works fine under spork, which I'd have thought would be using drip - but maybe it bypasses it somehow.

I am using jruby 1.7.3

jruby 1.7.3 (1.9.3p385) 2013-02-21 dac429b on Java HotSpot(TM) 64-Bit Server VM 1.7.0_15-b03 [darwin-x86_64]

JRUBY_OPTS=-J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1 -J-noverify -J-Xshare:on -X-C
JAVACMD=/usr/local/bin/drip

$ rake test TEST=test/integration/dummy_test.rb                   [13:44:30]
    LoadError: no such file to load -- test_helper
          require at org/jruby/RubyKernel.java:1027
          require at /Users/kimptoc/.rvm/gems/jruby-1.7.3@p-ecom1-rails323/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251
  load_dependency at /Users/kimptoc/.rvm/gems/jruby-1.7.3@p-ecom1-rails323/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:236
          require at /Users/kimptoc/.rvm/gems/jruby-1.7.3@p-ecom1-rails323/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251
           (root) at /Users/kimptoc/Dropbox/dev/ecom/ecom1/test/integration/dummy_test.rb:1
          require at org/jruby/RubyKernel.java:1027
          require at /Users/kimptoc/.rvm/gems/jruby-1.7.3@p-ecom1-rails323/gems/activesupport-3.2.12/lib/active_support/dependencies.rb:251

Thanks in advance,
Chris

mrbrdo commented

+1

headius commented

Part of the problem with these commands is the fact that Rails is very spawn-heavy. Most rails commands boot Rails to get app information, then relaunch the requested command with different command line arguments. I would imagine this is not working right with drip. Will investigate a bit myself.

kimptoc commented

Thanks

headius commented

I have created https://github.com/headius/boing as an answer to the Spring preloader. For the Rails commands in question, it avoids launching a subprocess (as Spring does) and starts them directly. It's only an early attempt at building a preload-aware launcher, but it works well for the commands I've tested.