alloy / passengerpane

Only enable the ‘open in browser’ button if the application isn't dirty. Closed by e1d57d4.

It should theoretically set the appropriate one based on whether or not config/environment.rb exists and it contains Rails::Initializer: http://github.com/alloy/passengerpane/blob/master/app/models/passenger_application.rb#L212

Does yours not contain that maybe?

Yes, my application contains both a config/environment.rb and Rails::Initializer inside of that file. So you're right, it seems your code should detect it. The only thing I can think of (and I haven't checked your code to find out) is whether this is only detected when a new vhost is created, and not when one is edited? In this case, the vhost already existed (had been using it with a previous version of passenger-pane).

It should try to discover it every time, not that that's actually necessary, so I might cache that. But right now I'm clueless as to what the problem could be, so I'll have to have a good look.

I've added RailsEnv production/development to apache config files and it seems to solve the problem.

What about adding RailsEnv automatically?

I know, it's hacky etc, but it just works :)

I have tried and tried to reproduce this bug, but haven't been able to. Closing it for now, but if any of you could extract an application that causes this or a failing test case, then please file a new one.

Only replace the paths in the user_defined_data when writing out. Closed by 536b769.

At the moment there’s no automated way to do this.

You can, however, edit the other persons /etc/hosts or Host database (man dscl or in the pane source) to point host.local to your machines IP. This works good if you're working on one project for a fair amount of time.

Alternatively you can use the patches in this repo to add bonjour support: http://github.com/kastner/passengerpane

HTH

Hrmm, it seems as if your system RubyCocoa is a bit messed up… Could you see if Ruby is able to load it at all like so?

$ /usr/bin/ruby -r osx/cocoa -e "p OSX::RUBYCOCOA_VERSION" 
"0.13.2"

Nope :(

[06:36:36] ben@folio (master) 
~/projects/teaching/permanent_record $ /usr/bin/ruby -r osx/cocoa -e "p OSX::RUBYCOCOA_VERSION"
/Library/Ruby/Site/1.8/universal-darwin10.0/rubycocoa.bundle: dlopen(/Library/Ruby/Site/1.8/universal-darwin10.0/rubycocoa.bundle, 9): no suitable image found.  Did find: (LoadError)
    /Library/Ruby/Site/1.8/universal-darwin10.0/rubycocoa.bundle: no matching architecture in universal wrapper - /Library/Ruby/Site/1.8/universal-darwin10.0/rubycocoa.bundle
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/osx/foundation.rb:8
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/osx/cocoa.rb:8:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/osx/cocoa.rb:8

I'm at a loss for how this could have happened. Should I just reinstall RubyCocoa and see what happens?

I think you still have an installed RubyCocoa which remains after an upgrade :-/

Can you remove:
1. /Library/Frameworks/RubyCocoa.framework
2. /Library/Ruby/Site/1.8/universal-darwin10.0/rubycocoa.bundle

This should make it pick up the system one again. I hope ;-)

that's the confusing part... I didn't do an upgrade. I did a fresh install then manually migrated my homedir.

At any rate, your suggestion did the trick. Deleted those files, and all is well. Thanks :)

Oh my, that is interesting indeed. But I have no other explanations up my sleeve :)

Glad to hear it works now though!

Make sure we use the system Ruby, or one can change it in the config file. Closed by d31c39a.

You shouldn't touch /usr/bin, stuff like the pane that may depend on it will break.

It would still be fairly easy to fix this in the pref pane, but like I said, you shouldn't be changing anything that comes with the system in /usr/bin in the first place.

If you want to use a different Ruby yourself, then simply make sure that that Ruby is in front of /usr/bin in your PATH.

PS: If some blog post advised to do install Ruby 1.9 this way, please tell them to not do that.

Thanks

I should add, if you do really want this to work this way, make sure the config_installer.rb and config_uninstaller.rb are being executed by the right Ruby. I suspect that is the problem, check the logs in Console.app for more info.

Cheers

NVM...

That works... Umm re-symlinking /usr/bin/ruby was my solution after many different configurations... the default /usr/bin/ruby* files are only symlinks anyway.

I've also encountered trouble with the /usr/bin/rails and using ruby1.9 since it uses /usr/bin/env ruby... Anyway, thanks. ;)

Well, I guess I could change the passenger pane to use the actual bin in /System instead of /usr/bin. I'll open a new ticket for that. Thanks for the discussion :)

(hmm, I guess GFM doesn't actually handle line breaks all that well)

Just to get this clear; You first installed the recent version (1.3) of the prefpane on Leopard and then upgraded to Snow Leopard, and now it doesn't work anymore?

And which version of 10.6 are you currently on? Because unfortunately with the current info I have no idea how to reproduce this…

You have to be sure Apache is running when you install it or it won't work.

Go to the Sharing pref pane and check the web sharing box before installing. That's what I had to do to get it to work for me.

@samsoffes You had those exact same log entries?

@alloy i didn't think to record them when it failed. it is quite possible that is a different issue.

@tdd do you remember if web sharing was on when you tried to install

My built-in Apache has been up all the time (as the Web sharing confirms), as I use it all day long.

Nevermind then. Must have been a different issue.

@samsoffes Damn, too bad, thanks though :)

@tdd Hmm, can you check if you have a RubyCocoa version in /Library/Frameworks and if the md5 of the system RubyCocoa matches mine?

MD5 (/System/Library/Frameworks/RubyCocoa.framework/Versions/Current/RubyCocoa) = 1953a07de6d06710fa410889da9f7abc

Ugh, apperantly we shouldn't reply to issue emails. Pasting here for good reference:

I match yours in /System/Library, but have another one in /Library. Should I kill the latter?

Thanks!

alloy said 1 day ago: Do you remember when/which version you installed into /Library ? And yes, please check if moving it aside helps.

PS: Are you building the pane yourself from source? Or using the downloaded tarball?

@tdd Any progress on this?

Reply was sent directly to my inbox, instead of this issue:

Hey there,

The lib I had in /Library was RubyCocoa-0.13.2.1-OSX10.4universal according to its Receipts entry. Just moving it aside w/o restarting did not help:

cd /Library
mv Frameworks/RubyCocoa.framework /tmp
mv Receipts/RubyCocoa-0.13.2.1-OSX10.4universal.pkg /tmp

I'm not familiar with the logic of OS X framework loading and have no idea whether rebooting now (after putting my moved libs somewhere else than in /tmp…) would be of any help?

Restarting should not be necessary. One question that was unanswered is whether or not you build the pane from source yourself or if you downloaded the binary?

Oh, sorry. No I got the tarball: whenever I try and build it myself, I get an error at some point (which MIGHT have been due to the RubyCocoa version tweak. I'll try and rake it again now).

W00t, that worked! rake built it right up, and the replacer pane that resulted works a charm. So it seems that the tarball may have an issue? Anyway, in my own situation, it's a fix :-)

Thanks for your help!

(A partial) Yay! :)

Still very weird that it doesn't work for you from the tarball. Unfortunately I have no clue how to debug this any further… So closing it for now at least.

Thanks

It sounds like an interesting idea. If you have a more elaborate patch, I'd love to look at if this is something we want in. Thanks.

Any update on this?

This is a feature you would need relatively frequently while you are working on your Rails app so I don’t really see a place for it in the Passenger preference pane. According to the HIG, a "preference should be a setting that the user changes infrequently".

I don't really think so. If you abide by that argument we shouldn't have the restart button there either. Or even, the PreferencePane all together.

You are right. That's actually how it was supposed to work, but I see it just restarts all.

Only restart the selected application. Closed by f660b11.

This is because the pref pane is still a 32 bit version, as noted in the blog post: http://www.fngtps.com/2009/09/new-os-more-pane-passenger-preference-pane-v1-3

Oh you're right, I think I forgot to push some last changes from the office… Will do that tomorrow. Thanks

Pushed

Oh wow, that's nasty. Unfortunately it's such a general error. This basically just means; for some reason during load something went wrong and now the main Class is nil.

I don't think that your custom Ruby and passenger could be the problem. (Unless you removed the system Ruby?) But you could establish that by temporarily removing your custom Ruby from your PATH to see if that makes any difference.

Because this is too hard to debug remotely any further, I'd like to ask you to debug this a bit more. See if you can track down to which part of the source it does actually load.

Thanks

I'd walked away from this for a while, and when I went to check out the preference pane again just now, it magically started working again. I don't think I made any changes to my rails/ruby/apache setup that might have fixed it though. Mac OS 10.6.1 came out, but it's unclear if that's related.

Either way. It's working again now.

Ow wow. Well I'm glad for you! Just unfortunate we couldn't get to the bottom of this…

Anyways, closing for now. Thanks

No support for Nginx is planned.

Simply put, we support what we use ourselves, and for development the defaults on the system (Apache) are good enough. However, I can see that some might want to use Nginx, so we will accept patches for it.

HTH

I might give it a stab, never worked with RubyCocoa so it might be a good learning experience.

Once MacRuby is mature enough, yes, definitely. From the blog post:

The real problem in getting the Passenger preference pane to run in 64-bit mode would be that System Preferences.app wants to use the Objective-C garbage collector. And rightfully so. But the only way to support this easily would be to use MacRuby, which as of yet is not stable enough. But expect the next version of the preference pane to use MacRuby and be a happy 10.6 citizen.

You don't have to select the public directory. Just select your RAILS_ROOT.

Ah, that'd make sense then. Thanks!

Same here, I get the following messages in the console:

09-07-23 9:07:08 PM System Preferences[2458]    -[NSCFNumber pathForImageResource:]: unrecognized selector sent to instance 0x151cd690
09-07-23 9:07:08 PM [0x0-0x176176].com.apple.systempreferences  2009-07-23 21:07:08.277 System Preferences[2458:903] -[NSCFNumber pathForImageResource:]: unrecognized selector sent to instance 0x151cd690
09-07-23 9:07:08 PM System Preferences[2458]    -[NSCFNumber pathForImageResource:]: unrecognized selector sent to instance 0x151cd690
09-07-23 9:07:08 PM [0x0-0x176176].com.apple.systempreferences  2009-07-23 21:07:08.278 System Preferences[2458:903] -[NSCFNumber pathForImageResource:]: unrecognized selector sent to instance 0x151cd690
09-07-23 9:07:17 PM System Preferences[2458]    [NSPrefPaneBundle instantiatePrefPaneObject] (/Users/gianni/Library/PreferencePanes/Passenger.prefPane): should only be called once
09-07-23 9:07:17 PM [0x0-0x176176].com.apple.systempreferences  2009-07-23 21:07:17.865 System Preferences[2458:903] [NSPrefPaneBundle instantiatePrefPaneObject] (/Users/gianni/Library/PreferencePanes/Passenger.prefPane): should only be called once
09-07-23 9:07:18 PM System Preferences[2458]    PrefPanePassenger#willSelect: NoMethodError: undefined method `subviews' for nil:NilClass
09-07-23 9:07:18 PM [0x0-0x176176].com.apple.systempreferences  2009-07-23 21:07:18.260 System Preferences[2458:903] PrefPanePassenger#willSelect: NoMethodError: undefined method `subviews' for nil:NilClass
09-07-23 9:07:18 PM [0x0-0x176176].com.apple.systempreferences      /Users/gianni/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:253:in `setup_passenger_warning!'
09-07-23 9:07:18 PM [0x0-0x176176].com.apple.systempreferences      /Users/gianni/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:52:in `willSelect'
09-07-23 9:07:18 PM [0x0-0x176176].com.apple.systempreferences      /Users/gianni/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:253
09-07-23 9:07:18 PM System Preferences[2458]    undefined method `subviews' for nil:NilClass
09-07-23 9:07:18 PM [0x0-0x176176].com.apple.systempreferences  2009-07-23 21:07:18.262 System Preferences[2458:903] undefined method `subviews' for nil:NilClass

You can fix this by installing RubyCocoa. You have to download it and fix the info.plist to make it install on SL.

Bah, I'm having separate issues with Passenger on SL anyways. Something about dlopen and a compiled bundle.

gianni, uninstall and re-install the passenger gem - it needs to be recompiled against 64-bit ruby and there's a native component that only compiles when you install the gem (I wound up recompiling my hand-built ruby and all my native gems, but I'm not sure you need to go that far.)

I'm getting this freezing on Snow Leopard as well. I tried to install RubyCocoa but it won't let me even install it via the DMG file (it puts a ! on the drive and won't let you continue during the install), so that is a no go. I also re-installed passenger via the gem and the preference pane still doesn't work.

Somebody mentioned that you have to modify the DMG installer plist for Snow Leopard... yet they didn't mention what to do --- I've already googled all over the place and cant find anything yet.

You need to download RubyCocoa, copy the RubyCocoa-0.13.2-OSX10.5universal.pkg to your Desktop, right click it and choose Show Packages Contents. Then you open contents and on the Info.plist and inside IFRequirementDicts change versions to reflect Snow Leopard. That is all. After that passenger pane will work great!

Figured it out, see my blog post about it: http://tiny.cc/yo1qK

@jfernandez I followed your directions and got RubyCocoa installed. Thanks! Then I uninstalled the passenger gem and attempted to reinstall the passenger gem and got:

ERROR: Error installing passenger:

ERROR: Failed to build gem native extension.

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ruby.h

Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/passenger-2.2.4 for inspection.
Results logged to /Library/Ruby/Gems/1.8/gems/passenger-2.2.4/ext/phusion_passenger/gem_make.out

Did you run into this? Any idea how to resolve this? Any help is appreciated.

@jfernandez, thanks your blog solved the issue for me.

@shanebo, it means you don't have the Ruby headers. You have to re-install Xcode.

@jrfernandez: The blog post helped me get the preference pane to open again, but now my problem seems to be I can't reach any of the local domains I've set up in it.

Update: I had to delete and re-add all of my projects in the preference pane, but they do come up in the browser now.

Run the passenger apache installer again and setup the passenger conf (snow leopard nukes your httpd.conf)

@jfernandez I did. Here's what I've installed since the Snow Leopard install.

RubyCocoa 13.2 > xcode > passenger 2.2.4 > apache2 module along with the 3 config lines in the conf > passenger pref pane 1.2

All my existing vhosts do exist but can't access them via localhost. I've fired up a ramaze app via terminal to make sure it's not a ruby and/or ramaze issue and all is good in that regard so it must be a passenger problem... Any other ideas?

Just cloned the project and brought it up in XCode 3.2 on Snow Leopard. Built with default options that came up: OS X 10.5 | Debug | i386

Got the following mess in Console upon putting it into System Preferences:

8/30/09 8:54:44 PM  System Preferences[9951]    -[NSCFNumber pathForImageResource:]: unrecognized selector sent to instance 0x15993f70
8/30/09 8:54:44 PM  [0x0-0xce0ce].com.apple.systempreferences   2009-08-30 20:54:44.373 System Preferences[9951:903] -[NSCFNumber pathForImageResource:]: unrecognized selector sent to instance 0x15993f70
8/30/09 8:54:49 PM  System Preferences[9951]    [NSPrefPaneBundle instantiatePrefPaneObject] (/Users/jamesthompson/Library/PreferencePanes/Passenger.prefPane): should only be called once
8/30/09 8:54:49 PM  [0x0-0xce0ce].com.apple.systempreferences   2009-08-30 20:54:49.753 System Preferences[9951:903] [NSPrefPaneBundle instantiatePrefPaneObject] (/Users/jamesthompson/Library/PreferencePanes/Passenger.prefPane): should only be called once
8/30/09 8:54:49 PM  System Preferences[9951]    PrefPanePassenger#willSelect: NoMethodError: undefined method `subviews' for nil:NilClass
8/30/09 8:54:49 PM  [0x0-0xce0ce].com.apple.systempreferences   2009-08-30 20:54:49.818 System Preferences[9951:903] PrefPanePassenger#willSelect: NoMethodError: undefined method `subviews' for nil:NilClass
8/30/09 8:54:49 PM  [0x0-0xce0ce].com.apple.systempreferences       /Users/jamesthompson/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:253:in `setup_passenger_warning!'
8/30/09 8:54:49 PM  [0x0-0xce0ce].com.apple.systempreferences       /Users/jamesthompson/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:52:in `willSelect'
8/30/09 8:54:49 PM  System Preferences[9951]    undefined method `subviews' for nil:NilClass
8/30/09 8:54:49 PM  [0x0-0xce0ce].com.apple.systempreferences   2009-08-30 20:54:49.819 System Preferences[9951:903] undefined method `subviews' for nil:NilClass

I tried fiddling with the build a bit, moving it to use 10.6 SDK, and x86_64 architecture and the errors change to being concerned with garbage collection. So there may be a number of issues at work in getting this working on Snow Leopard.

I'm getting a different error, but from the same method:

PrefPanePassenger#willSelect: NoMethodError: undefined method `hidden=' for nil:NilClass
/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:250:in `setup_passenger_warning!'
/Library/PreferencePanes/Passenger.prefPane/Contents/Resources/PassengerPref.rb:52:in `willSelect'

No worries people, we know about the problem and we will fix it. Eloy has been under the weather an didn't have time to look at it yet. Please hang in there for a while. In the meantime patches are always welcome.

Added RubyCocoa 0.13.2 as compiled for 10.5 universal to vendor and made the project link against and bundle this version.

Closed by 26e905a.

When the path of an application has changed also update it in the user_defined_data.

Closed by fda1dc3.

Lucas Húngaro:

“After I updated XCode from 3.0 to 3.1.2 I had the same problem and managed to solve it by manually installing RubyCocoa 0.13.2 from http://is.gd/EiR6 - the odd thing is that I use Mac OS 10.5.7 and should have RubyCocoa 0.13.2 (as described in the passengerpane docs), but had 0.13.1 instead too.”

I had the same problem on 10.5.7 and the above solution works perfectly. Thanks!

+1 for the solution identified above

agree, struggled for months and update of rubyCocoa to 13.2 finally got it working. hopefully snow leopard won't break this during the upgrade.

I'm on a Leopard to Snow Leopard update and already have 0.13.2. Same issue with the hang.

The RubyCocoa 0.13.2 of SL does not work with the pref pane at all, most have reported more success with the 0.13.2 that's downloadable as a binary. But I will have to take a look at the current state of things anyways. So I'll try to work some on it the coming week and come up with a stable version for SL.

I'm still encountering this issue after installing it from the latest master.

Do you have a version of RubyCocoa installed in /Library/Frameworks ?

Yes, I've installed 1.0.0 to get LimeChat to work.

Always fix the path in the Passenger.prefPane binary to link against the RubyCocoa.framework inside the bundle, even when another version is installed in /Library/Frameworks.

Closed by 844ecb2.

Ok, building it on a machine that has a RubyCocoa version installed in /Library/Frameworks caused the binary to link against that version instead of the bundled one. This should now be fixed in the above commit. If someone feels adventurous they can try it out, but please note that I still have a few things I'd like to finish before I will make a proper release.

The most important thing to mind is that hostnames are registered, if you wish so, but aliases not yet.

I've pulled the latest and it is now showing "public.local" as the hostname when I select an app called "rboard" :) I'll file another issue for this.

Judging by this and the other ticket, can I assume it's working now? :)

Yup, thanks!

Thanks for verifying.