os x

I'm stuck in Full Screen mode on OS X! Help!


I entered full screen mode through the Komodo menu and now now I'm stuck. How do I get out?


If you are stuck in Komodos Full Screen mode and you can't seem to turn it off, we have a work around for you until the issue is resolved properly.

- Cmd + Q to exit Komodo
- open the following file in a text editing program: /Users/*username*/Library/Application Support/KomodoIDE/8.0/prefs.xml
- search the "startupFullScreen" preference and change the 1 to 0
- DELETE the prefs.xmlc file (it's a back and will over write the change you just made)
- start Komodo

Once you've accomplished this you can assign a keybinding to full screen mode through Preferences > Editor > Key bindings: Search "full screen" and assign whichever key binding you like to it.

This will not be an issue for long.

- Carey

Common OS X problems


ActivePerl isn't working on OS X. Why?


-Are you still getting the system version of Perl instead of ActivePerl?
You likely have not finished the installation. Read the Configuration step in the Installation Guide, which explains how to set $PATH so that ActivePerl is found ahead of the system version.
If you don't put ActivePerl on $PATH, then you must access ActivePerl and ppm using the full directory path, /usr/local/ActivePerl-5.16/bin/perl (or equivalent for other releases).

-I set $PATH yesterday, and I'm sure I had ActivePerl working, but today it's not working.
Changes to $PATH are volatile. You have to make the changes permanent by setting up your $PATH in your .profile shell configuration file.

-I can't do that. I don't have a .profile in my home directory.
No you don't. Apple designed OS X to use GUI interfaces, and they didn't think a config file for the command line shell would be necessary. You have to manually replicate what every other flavor of Unix does; copy /etc/profile to .profile in your home directory, and make changes to your personal copy.

-I did that, but it still isn't working.
You have to restart your shell before changes to .profile get read.

-Ok, I did all that, and Perl is working every time, but PPM won't add or remove modules.
You are a normal user. ActivePerl is installed into a directory which normal users can't write. PPM needs to be run through "sudo ppm" to give it the elevated privilege to manage modules.

-Huh? I wanted to replace the Apple Perl with ActivePerl. This process doesn't do that. How can I force ActivePerl to replace the Apple version?
Don't. Some of your system tools, and quite a few other vendor products expect to find a specific version of Perl in a specific place on a specific version of OS X. Replacing the Apple Perl will break things, and it is difficult to put things back without re-installing your operating system. Apple Perl will co-exist happily with ActivePerl if the defaults in the ActivePerl installer are used. Both versions will still be usable if you supply full paths to the command.

-Can't I just edit the system default /etc/profile to put ActivePerl on $PATH first? Won't that make it the default Perl?
Yes, it will, and so will creating symbolic links in system directories that are already high on the $PATH. Either of these approaches might still break third party software and system tools if they don't use hard-coded paths to the Apple Perl. On the positive side, making ActivePerl the default Perl in one of these ways is very simple to back out if for some reason things go pear shaped.

-I did everything above, but all I get is weird crashes when I run ActivePerl.
Do you have PERL5LIB set to point at the Apple Perl? Using PERL5LIB can force Perl to load libraries which contain incompatible binaries.

-I've got PPM working, but the module I want isn't available. I tried to build it locally from the CPAN source code, but I just can't seem to set the right compiler options.
ActivePerl binaries are multi-platform. Some releases were PPC/x86, and newer releases are x86/x86_64. When you compile a module locally, the compiler will only build a single architecture binary, and no matter which platform you are on, it won't match the dual architecture of the ActivePerl binaries unless you use the Apple SDK to convert what you build to match. Using the Apple SDK is a topic outside the scope of ActivePerl support.

Debugging Ruby on Snow Leopard


I recently upgraded my Mac to Snow Leopard, and now when I try to debug Ruby I get a message like this:

Error: dlopen(/Applications/Komodo IDE.app/.../ruby_debug.bundle,
no suitable image found. Did find:
/Applications/Komodo IDE.app/.../ruby_debug.bundle:
mach-o, but wrong architecture

How do I debug again?


Yes, it's Yet Another Ruby Debugging question.

Snow Leopard is essentially a 64-bit machine, and the
ruby-debug-base gem that ships with Komodo is 32-bit.

The best thing to do is to rename the directory in
/Applications/Komodo IDE.app/Contents/SharedSupport/dbgp/rubylib/
from "1.8" to "1.8-32"

and the install and build the appropriate ruby-debug-base gem
with this command:

sudo gem install ruby-debug-base

You might not be out of the woods yet. If you get an error message
complaining that header files can't be found, you probably need
to install the XCode Dev Tools.

-- Eric