Turns out it was because in my original install of the prefpane I had used the “ports” version of a required ruby file, per instructions, since I was using the MacPort version of Apache. The easy fix is to just reinstall the prefpane. All of my sites now show up in the site listing and I can add the new site I’m currently developing.

I encountered another problem now. When I ran my autotest but tried to shut it down by hitting Control-C twice in a row, the tests would just reset and run again. Double Control-C is supposed to interrupt the process and allow me to shut it down. This it did not do.

I am also running the autotest/menu plugin that is supposed to explicitly ask you whether you want to quit, restart or just keep going when you hit Control-C, even if it’s just hitting it once. This is the best possible option and is what I recommend, but it wasn’t happening. There were no prompts to quit, continue, or restart. Just restarting the entire test suite EVERY time I hit Control-C, whether it was two quick hits or 10 hits a row.

I originally looked at the code thinking that I should fix it there. Autotest provides hooks into it’s process. Run, interrupt, quit, etc. I figured it had to do with one of those so I first tried just commenting out the :interrupt hook code on lines 39-41 in ZenTest-4.0.0/lib/autotest/snarl.rb. This worked and I was happy. However it still didn’t feel right. I didn’t want to hack the code and ask them to fix it. It must be working for other people because I haven’t seen other people complaining about it.

Turns out the fix is a really easy one and requires no hacking on the gem code at all. It was just a problem with the order of my “require” lines in my .autotest file. My original .autotest file looked like this…

require 'redgreen/autotest'
require 'Win32/Console/ANSI'
require 'autotest/snarl'
require 'autotest/menu'
require 'autotest/timestamp'

The .autotest file that WORKS swaps the “snarl” and “menu” lines around, like so…

require 'redgreen/autotest'
require 'Win32/Console/ANSI'
require 'autotest/menu'
require 'autotest/snarl'
require 'autotest/timestamp'

NoMethodError: undefined method `admin' for #<Admin::RegistrationsController>

but what was the first line that came up in the backtrace?

app/controllers/admin/registrations_controller.rb:18:in `show'

This was giving me fits. There’s no call to ‘admin’ in the ‘show’ method. I knew there had to be something else so I searched for how to see more of the backtrace.

The BacktraceCleaner introduced in Rails 2.3.2 cleans out backtrace lines coming from the Rails framework (Railties, etc). This is usually what you want. However, I was sure that my error was coming from somewhere in the framework. Turns out it’s really simple to turn off the backtrace cleaner. Add this line in a ‘setup’ method in your test_helper.rb file.

Rails.backtrace_cleaner.remove_silencers!

Very simple, very easy. My name is Chef Tell.

NoMethodError: undefined method `assert_select_email' for #<UserMailerTest>

I posted to the rubyonrails-talk google group but never got a response, and I was not the first to post about this problem to that group. However I found someone else commenting on this in an rspec lighthouse ticket and they’d fixed it for their setup. It was an easy conversion to non-rspec and here’s the line you need to add to your test/test_helper.rb file

include ActionController::Assertions::SelectorAssertions

I’m not sure why it’s broken but it appears to have regressed in one of the Rails 2.3.2 RCs.

this is a sample of a line that would cause log_buddy to barf.  it just so happens to also be the line that causes the error. 

c:/ruby/lib/ruby/gems/1.8/gems/log_buddy-0.0.5/lib/log_buddy.rb:98:in `read_line'

the original line looked like this…

file, line_number = frame.split(/:/, 2)

the fix is to replace that line with

file, line_number = frame.reverse.split(/:/, 3)[1..2].map(&:reverse).reverse

yeah.  ugly, and maybe could be written better but it works for me.

now if only I could get log_buddy to output good inspections of objects I toss to it… like “current_user”.  I’m prolly using it wrong right now, but this isn’t helpful…

current_user = '#<User:0x47143d8>'

just saying. 

UPDATE: I monkeypatched log_buddy to fix this functionality. I created a “RAILS_ROOT/lib/log_buddy_extensions.rb” file with the following code.

class LogBuddy

  private

  # Return the calling line
  def self.read_line(frame)
    file, line_number = frame.reverse.split(/:/, 3)[1..2].map(&:reverse).reverse
    line_number = line_number.to_i
    lines = File.readlines(file)
    lines[line_number - 1]
  end

end

and I figured out that the “current_user” line above shouldn’t be …

d { current_user }

it should be

d { current_user.inspect }

that outputs what I want …

current_user.inspect = '#<User id: 1, login: "matte", email: "matte@localhost", crypted_password: "...", salt: "...", created_at: "2007-08-30 18:23:32", updated_at: "2008-07-08 18:57:45", remember_token: "...", remember_token_expires_at: "2008-07-22 18:57:45", name: "...", password_reset_code: nil, company_id: 2, active: true>'

Categories belong_to CategoryTypes
CategoryTypes has_many Categories

The one thing I’m doing a little different from the BNS readme is that I’m not assigning my scope column id directly. I’m using one of Jamis Buck’s recommendations.

Moving associated creations to the model

I have a “data” attribute subset of fields in my form. It’s just one field “category_type”. Note, not category_type_id. It’s just a choice I made. This gives me the following params being passed to the controller…

{ :text => 'Tom Servo', :data => { :category_type => 1 } }

Then in a before_create method “assign_additional_data” where I look up the CategoryType using the passed id. This is so that it’s possible to raise an error if that CategoryType has been deleted in the short interval between form creation and submission.

before_create :assign_additional_data
...
def assign_additional_data
  return if @data.nil?
  self.category_type = CategoryType.find(@data[:category_type])
end

This is a long way of saying that I have a before_create call being added to the queue of callbacks. However, BNS has one as well. It sets the lft and rgt column values. I was getting caught by the order that the before_create methods were queued up. My model assigned the acts_as_nested_set before my before_create call

class Category < ActiveRecord::Base
  acts_as_nested_set :scope=> :category_type
  before_create :assign_additional_data
  ...
end

I had a clean db table and in my console I created two categories…

>> c1 = Category.create({ :text => 'Satellite of Love', :data => { :category_type => 1 } } )
=> #<Category id: 1, parent_id: nil, lft: 1, rgt: 2, text: "Satellite of Love", category_type_id: 1>
>> c2 = Category.create({ :text => 'Croooow', :data => { :category_type => 1 } } )
=> #<Category id: 1, parent_id: nil, lft: 1, rgt: 2, text: "Croooow", category_type_id: 1>

WHA? Why didn’t the lft and rgt columns increment like they’re supposed to. c2 is supposed to be “3″ and “4″ respectively, until that category is assigned as a child of another category. I finally (after my headbashing) figured it out. It was because I was assigning the category_type scope AFTER BNS calls it’s before_create method used to assign lft/rgt column values.

Snipped from better_nested_set.rb

before_create :set_left_right
  ...
  # On creation, automatically add the new node to the right of all existing nodes in this tree.
  def set_left_right # already protected by a transaction within #create
    maxright = base_set_class.maximum(right_col_name, :conditions => scope_condition) || 0
    self[left_col_name] = maxright+1
    self[right_col_name] = maxright+2
  end

Because my scope condition parameters weren’t being assigned until after BNS’ before_create method, the scope id that needed to be set wasn’t being set. So my sql statement called for the “maximum” part in the code above came out as…

SELECT max(rgt) AS max_rgt FROM `categories` WHERE (categories.category_type_id IS NULL)

See, category_type_id is NULL, not the “1″ I wanted. And because of that maxright gets assigned “0″ and the lft and rgt columns are give “1″ and “2″, respectively.

Well, let’s reverse the order in my Category model and see what happens.

class Category < ActiveRecord::Base
  before_create :assign_additional_data
  acts_as_nested_set :scope=> :category_type
  ...
end

Creating the two categories again gives us this…

:text => 'Tom Servo', :lft => 1, :rgt => 2, :category_type_id => 1
:text => 'Croooow', :lft => 3, :rgt => 4, :category_type => 1

Excellent! It worked. Let’s see what the “maximum” sql statement says…

SELECT max(rgt) AS max_rgt FROM `categories` WHERE (categories.category_type_id = 1)

Ahh, finally. category_type_id is being assigned the correct value.

So, if you are getting the “Impossible move, target node cannot be inside moved tree” error, check to see that if you’re using your own before_create methods, that they’re assigned before your call to acts_as_nested_set.