The README wasn’t able to help much, as it only mentioned adding the Ruby path to the start of the ~/.irbrc file. The solution was to add a require ‘rubygems’ to the ~/.irbrc. Although the error didn’t mention it the problem was that wirble couldn’t load because rubygems were instantiated.
Here’s my current ~/.irbrc with the update:

1. “Not recognized by identify”: This one is resulting from a call to ImageMagick (you did know ImageMagic was required, right?) and a bad relationship with Passenger. The easiest way to resolve this is to place the following line in your appropriate environment files (ie. config/environments/development.rb) making sure that it point to your local instance of Imagemagic. For my development environment on OSX it was:

Paperclip.options[:command_path] = "/opt/local/bin"

(I’m using imagemagic from a MacPorts install; if you are on a linux distro you may need to reference /usr/local/bin.)

1.5 “Not recognized by identify” is also caused when you specify “styles” for a has_attached_file type other than a photo. I’m really not sure how to get around this one, but if you are going to use any file types other than images using the following string in your model will cause the error:

:styles => { :large => "300x300", :medium => "200x200", :thumb => "128x128>", :micro => "40x40#"}

2. Don’t name your model “attachment”: I googled around forever trying to figure this one out. In the end it seems to be a namespace error between Paperclip and the app – Paperclip won. I named the mode “client_attachment”.

3. Remember to include your attachment type in you attr_accessible declaration: If you are protecting against mass assignment you’ve an attr_accessible line in your model. Be sure to include the name of the field you’re using for the attachment in the declaration. For example, if you’re using a “photo” for the Paperclip attachment, be sure to add “:photo” to your attr_accessible declaration:

attr_accessible :first_name, :last_name, ..., :photo

Short aside … the plugin allows for a very DRY approach to managing permission from one configuration file, not to mention that it generates a visualization of your ACL, too. This is a huge benefit when building an app that has a number of different security roles. Additionally, it allows access control on the controller, model, query, and view levels. From the site:

Plugin features

• Authorization at controller action level
• Authorization helpers for Views
• Authorization at model level
  • Authorize CRUD (Create, Read, Update, Delete) activities
  • Query rewriting to automatically only fetch authorized records

I was ecstatic about using the plugin but hit a stump when trying to work it out with my own HABTM association in my Rails app. The third requirements mentions, “User objects need to respond to a method :role_symbols that returns an array of role symbols”. My log error kept displaying:

In order to get things to work correctly with a User model, Roles model, and Roles_Users table for the “has_and_belongs_to_many” relationship, you need to make sure you’ve a method in your user model that “correctly” generates a “roles_symbol” array:

Note: Make sure that you use the correct value of the filed in your roles model when serializing. The example used “title” but in my application I used “name” for the column that defined the role.

Finally, I stumbled upon, David Deraedt’s AIR Application Descriptor Manager. Honestly, I didn’t think much about it, and hadn’t much in terms of hopes, but after running through the settings for my file and saving it … eureka! Automatic building took over and I have a successful Application Descriptor.

The culprit: a rogue slash “/” mysteriously placed in the original prevented the descriptor from being built.

Technorati Tags: Flex4, Gumbo, Troubleshooting

He’s 2 months old, has wonderfully bright eyes, a captivating smile, and his big sister tells everyone that she’s having a baby brother.

God gives the greatest of blessings in little 9 pound packages.

See and download the full gallery on posterous
or here on flickr

Posted via email from imarichardson’s posterous

I originally found myself here while beta testing a new subversion client and inadvertently clicking “yes” I want to upgrade my working directory. But that’s another story. Here’s what I did (I’m running Mac OSX 10.5 Leopard):

1. Download and install the Subversion 1.5 binaries from OpenCollabNet (via http://subversion.tigris.org/getting.html#osx). Once you download the .dmg, simply run the installer like you’d normally do any installer. You’d imagine that this would be all but it’s not because the new subversion installs to /opt/subversion/bin rather than /usr/bin.
2. Update your path by either editing the “~/.profile” (for your individual user profile) or “/etc/profile” (for all system users). I chose to do this for my system as I used several accounts for different purposes. If the file doesn’t exist you need to create it. Then add the following line to the top of the file: 
   export PATH=/opt/subversion:$PATH
3. Finally, rename the previous svn executable. You may find that you still cannot access subversion 1.5 if the 1.4 file is still available. Navigate to your /usr/bin folder and rename the old svn located there:
   $sudo mv svn svn.old
   • Thanks much Coals [2] Newcastle for helping me with this one. 
4. Now when running svn –version you should see the 1.5 client referenced.

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.

Reason: Error reading from remote server

---

Apache/2.2.3 (Red Hat) Server at [myserver.com] Port 443

And when viewing the log files I was receiving errors like:

And this, too: (I tried these instructions too, but didn’t work.)

Additionally, I received “Operation Not Permitted” errors when trying to restart and/or stop the mongrel clusters:

Solution

I was able to resolve the issue by killing all the active Mongrel processes and then restarting manually. You can do this by:

1. Viewing all active mongrel processes:

(The second number is the process id; that is the id you’ll use to kill the process.)


2. Killing each process id

“sudo kill -9 [process id]“, For example, to kill the first process listed above:

3. Restarting your Mongrel instances

In order to get things working right I had to update the system files so everything would run:

Now running the update works.