+1

Should be pretty easy, as micronaut config and running is very similiar to RSpec.

it seems that github needs to make the little voting box bigger. See that up arrow, with '0 votes'. That is how you vote for things in github issues :) That causes them to float to the top.

Yep, never noticed that until today =). Thanks, voted.

I'm working on the Merb support for Spork. So far I've managed to add support for Merb detection, Merb env loading so you can start Spork for Merb with the spork command.

However class reloading and running bundled project doesn't work yet.

Actually.. in addition to having all of spork reload what would be very cool is if we could send arbitrary code (via DRb) to the parent spork process that would be evaluated. That way, we could tell it only to reload certain parts that we know need to be reloaded. Just an idea.. reloading all of it is probably easier to do at this point.

This sounds very cool. In order to achieve the "reload specific portions of the app part" we would have to create a few layers of forked processes, similar to how passenger does it. I think having a full restart occur would be a great start and may suffice.

I just sent a pull request to both of you with a rough initial reload implementation to take a look at.

This gist: http://gist.github.com/216680 shows how to use the kicker gem to send Drb spec_sever.reload requests when code files change in rails.

Hmm ... I just found a much simpler work-around for at least one part of this problem.

Here's a simple description of what I'd like to do:

• Have a rails model and the spec test for that model open in textmate
• command-R in the spec test to see the results
• change code in the model
• command-R again in the spec test to see new results

We are using Factory girl and normally when we run this command to see what is loaded in prefork:

spork -d | grep -A25 models

I see FactoryGirl load all the model classes we are using factories for -- of course by doing that in prefork it means that any model changes I make after spork startup don't appear after the fork.

We added this file: config/initializers/spork.rb

if defined?(Spork)
  Spork.trap_class_method(Factory, :find_definitions)
end

reference, Tim's suggestion in this thread: http://groups.google.com/group/sporkgem/browse_thread/thread/24e6342e6629d371#

This delays FactoryGirls loading of the model classes it needs to introspect until after the fork.

My simple test above now works.

My test environment is setup to cache classes (config/environments./test.rb)

config.cache_classes = true

My vendored rails is 2.3.4.

I had thought the model classes would be eagerly loaded in this case but appears not to be the case.

Thinking about how to get the most performance using spork in testing -- obviously the first step is to use more mocks and less factories/fixtures ... but after that a useful generalization is:

• load as many app classes and generate app/state in prefork as possible AND is necessary for your tests
• don't load classes in prefork that you are working on (or app state that might be affected by the change in these classes)

It might be helpful if after Spork started I could add or subtract classes from prefork app state. My method above which reloads the whole prefork is just brute force. If I had kicker watching for fsevents and in the case above removed just the model class I was working on from the prefork -- that might help. I don't know how unloading the class would affect the app state if it already had instances using the earlier versions of the model ...?

Would it be out of the question to rework your inheritance scheme so that ApplicationController does inherit straight from "ActionController::Base" ?

IE:

class ApplicationController < ApplicationController::Base
end

class BaseApplicationController < ApplicationController
end

class UsersController < BaseApplicationController
end

In other words, what is specific motivation for ApplicationController not inheriting from ApplicationController::Base?

Loading the real file is problematic because it will start to grab and preload all sorts of dependencies from your app, causing you to have to restart Spork more often in order for it to see your changes. (additionally, it's not feasible to NOT preload ApplicationController, because rspec-rails WILL, along with all of your ApplicationController's dependencies).

If the above isn't feasible, one possible option would be to create an over-ridable configuration parameter on Spork specifying where the preloadable-bare-bones ApplicationController lies, causing Spork to direct any attempt to load ApplicatonController there rather than it's own stubbish ApplicationController.

Maybe I'm the only one in the world doing this, but I consider this a bug in spork.

Certainly, though, the inheritance scheme could use a module instead of a class.

Taking the premise that this is a bug with Spork, how would you propose to fix it?

Not sure - this is why I was asking your advice ;)

As far as I'm concerned, if it isn't a bug in Spork, it's (one of many) gross aspects of rails.

I'm up for moving my code into a module.

I was trying to understand how you arrived at the conclusion that this is a bug in sport.

I would lean towards this being that rails wasn't intended to be used the way spork is using it, so spork has to do some forceful operations to get it to behave. As such, a case could be made that rails has an underlying design flaw.

I originally called it a bug in spork because an older version of spork worked fine (that one was preloading ApplicationController, which I consider a nuisance more than anything else).

This version of spork won't work at all unless I first factor my code.

BTW: What are you imagining for the parameter idea? Something like this:

http://gist.github.com/799ff78d064b48d2cf30

?

Here's a patch:

http://github.com/smtlaissezfaire/spork/tree/application_controller_loading

I believe that won't work because some parts of the rails code base (and rspec-rails too, I believe) explicitly call "require 'application_controller.rb'". The way spork blocks this is by sticking the path with the blank application_controllers to the front of the lib path, satisfying all attempts to "require 'application_controller.rb'", and then later deliberately requiring the application's ApplicationController before the specs are run.

Tim

Yes - I realized that - which is why I didn't remove the application_helper.rb files, etc.

Sorry if that wasn't obvious from the specs

Have you tried using ruby-prof ? You can tell it to profile a specified block, then write the results for that block to a file.

The problem was that views loading + application loading just took longer in rails 2.3 (view loading because of the eager loading)
My current solution is to disable views reloading, but keep the application loading(since spork does not make much sense without...) -> see hacks below

the only real solution to this "your app is just too large"-problem cold be partially reloading e.g. reloading a file when it changes, but for this to work the e.g. odel must be unloaded, which i dont know how to do.....but maybe you got any further idea ;)

cheers mg

#insert before Spork.prefork
begin
  require 'spork/app_framework/rails'
  module Spork::AppFramework::Rails::NinjaPatcher
    #views are preloaded <-> spork must be restarted for view changes
    def delay_eager_view_loading
      puts "removed because i am too slow..."
    end
    # no application files reload <-> ultra-fast + any app/xxx change needs spork restart
    def delay_app_preload
      puts "removed because i am too slow..."
    end
    def delay_application_controller_loading
      puts "removed because i am too slow..."
    end
  end
rescue
end

Yeah i found a solution: disable Rails app/ eager-loading, now im back to 1 second startup :D

begin
  require 'spork/app_framework/rails'
  module Spork::AppFramework::Rails::NinjaPatcher
    # views are preloaded <-> spork must be restarted for view changes
    def delay_eager_view_loading
      puts "removed because i am too slow..."
    end

    # do not preload application files <-> fast test start
    def delay_app_preload
      ::Rails::Initializer.send(:define_method, :load_application_classes) do
      end
    end
  end
rescue
end

could you add something like Sporl.rails.eager_load_classes = false and Spork.rails.preload_views=false ?

I think that should be the default. Though I'm wondering, have you tried just turning off cache_classes? What would be the consequence of that?

Yep, this would work too. cache_classes is the default for test environment, dunno why...

ok, so I am thinking of having spork display a warning if cache_classes is true. Do you guys think that will be an appropriate solution?

Setting cache_classes to false is a neat trick, actually. Just running a single, simple spec (with time rake spec SPEC=(the spec file)) I've reduced the time from 10.1s to 4.5s (my app is bloated so I think that's probably why it's not like 1.0s). I think displaying a message of some kind would be good.

Just to help me, this is an issue from this thread:

http://groups.google.com/group/sporkgem/browse_thread/thread/631f143d2c10277d

Yeah, that's the right thread. You don't give me much hope in your answer there ;-)
But I often use custom helpers so I stumbled across this problem with my first rails app I wanted to use with spork.

I'm getting the same error after upgrading.