Komodo

Running Rails on Debian

Question: 

I'm getting fatal error messages trying to create a Rails project on Debian? What do I need to do?

Answer: 

Suppose you try to create a Rails project, and get this error message in the Command Output Window:

getopt: unrecognized option `--skip'
Terminating...

Chances are, you installed rails using the Debian apt-get package manager. The package installs a bash script that wraps Ruby's own Rails library, with its own set of command-line options. This set is wholly incompatible with the standard Rails options, so the tools fail.

It's easy to find web pages that discuss the pro's and con's of relying on Ruby's own Gem package manager vs. Debian's package manager. In this case it would be better to use Ruby's. First run 'apt-get remove rails' to remove the package. And then run 'sudo gem install rails -y' to install a friendlier version of Rails.

Unfortunately you aren't done yet. Our testing showed that gem put the various pieces in /var/lib/gems/1.8/, with Ruby 1.8.6 in /usr/bin. This makes sense, as you wouldn't ant to modify the system area with a third-party package manager.

Knowing this, I would install my own Ruby 1.8.6 in /usr/local/..., and then I would expect gem to install everything in /usr/local/bin and /usr/local/lib/ruby/ (this is untested).

How do I use Mongrel with the Rails tools?

Question: 

We're moving from using Webrick to Mongrel for serving our Rails apps. How do we get Komodo to move along with us?

Answer: 

The problem isn't getting Komodo to move along, but stopping it when necessary.

I only tested this on Windows, please reply and correct me if behavior is different on Linux or OS X. But on Windows, I installed the mongrel and mongrel_service gems,
switched to Komodo, and my existing rails projects automatically started using Mongrel
for running and debugging servers.

The problem at this point is that debugging doesn't work with Mongrel, and I've logged this at http://bugs.activestate.com/show_bug.cgi?id=73405

I've checked in a fix to handle this, but it didn't make the latest 4.2.1 release. The workaround is to modify the 'debug rails app' macro in the Rails project to add "webrick" after "script/server", as in this line:

        var cmd = (obj.ruby + ' -I "'
                   + rbpath
                   + '" -r rdbgp.rb script/server webrick');
        as_rails_macros.runCommand(editor, cmd, options);

If you don't want to make this change more than once, unzip the
Ruby on Rails.kpz file, make this change in the package.kpf file (this
line appears twice, make sure you change it only for the
"debug rails app" macro, not the "run server" macro. Zip package.kpf
back into "Ruby on Rails.kpz" (it has no other files), and new projects
should behave correctly.

I only tested this with Rails versions past 1.2. YMMV if you're using
an older version.

Komodo IDE debugger proxy "pydbgpproxy"

Question: 
  • Why would I want to use the proxy service for debugging?
  • So how does debugger proxing work?
  • How do I setup the Komodo DBGP proxy service for remote debugging?
  • How do I start debugging with my selected Komodo application?
  • What alternatives do I have when the two machines cannot see (connect to) each other?
Answer: 
  • Why would I want to use the proxy service for debugging?
    Note that it is *not* a requirement to use the DBGP proxy for remote debugging applications with Komodo. The proxy is useful when:
    • you have multiple users running the same server/application who wish to be able to debug independantly
    • the network requirements do not allow a direct TCP/IP connection between the application being debugged and the Komodo IDE, so you need to channel through a common proxy.
  • So how does debugger proxing work?
    • The proxy is started first, and listens on two separate ports.
    • Komodo connects to the proxy on one port to tell it the specific proxy key Komodo is using, as well as the IP address and port number Komodo is listening on.
    • The application being debugged connects to the proxy on the other proxy port when it starts a debugging session, sending the required ide key.
    • The proxy service checks the idekey (proxy key) given by the application being debugged and tries to match it to the connected Komodo session(s). If one matches, then the proxy tries to initiate a connection to this Komodo application and if successful the debug session is passed on to Komodo. When no match is found, the debug session is ignored.
  • How do I setup the Komodo DBGP proxy service for remote debugging?
    • You'll need Python installed.
    • pydbgpproxy.exe
    • Start the proxy by navigating to the containing folder of pydbgpproxy.exe, note that the DBGP proxy service can be running anywhere (a linux machine, windows, mac...), as long as both the application/server to
      be debugged and Komodo IDE have TCP/IP access to connect to this proxy instance and vice-versa. I'll call the machine "mymachine" in the examples below.
      Here is the command to start the proxy "dbgpproxy -i IDE-PORT -d DEBUG-PORT":
      pydbgpproxy -i 9001 -d 9000

      The IDE-PORT is where Komodo will to connect with the proxy and the DEBUG-PORT is where the application being debugged will connect to the proxy (see details below).

    • Komodo IDE will need to be configured and connect to this proxy service. Go to Komodo's preferences, then select the "Debugger->Connection" category, it does not matter what port Komodo is configured to listen upon (either a system-provided free port or a specific port is fine). Check the "I am running a debugger proxy and Komodo should use it." checkbox, then fill in the Proxy Listener Address, which is the IP address of where the proxy is running, i.e. "mymachine:9001". Set the proxy key to any string value you wish, I'll use "myname" (without the quotes) for the example.
    • Configure the application/server settings to connect to the proxy server, the details of this will be different between languages, but here are some examples:
        # Python
        pydbgp -d myname:9000 -k myname my_python_code.py
        # Perl
        export PERLDB_OPTS=RemotePort=mymachine:9000
        export DBGP_IDEKEY=myname
        # PHP, uses the Xdebug php.ini settings, like:
        xdebug.remote_host=mymachine
        xdebug.remote_port=9000
        xdebug.idekey=myname
        # Start your PHP debug session in your browser as you normally would, appending the xdebug string to the url "?XDEBUG_SESSION_START=myname"
       
    • Note that if you do not specify an proxy/IDE key when debugging, the user/username of the debugging process will be used.
  • How do I start debugging with my selected Komodo application?
    • You'll need to define your IDE key, this sets the Komodo application you wish to connect to and must match the Proxy Key setting you have placed in your Komodo debugging preferences. The key is defined and passed to the debugging proxy differently, depending upon the language your debugging. Some examples below:
        # Python, -k sets the proxy key
        pydbgp -d myname:9000 -k myname my_python_code.py
        # PHP, start your PHP debug session in your browser as you normally would, appending the xdebug string to the url:
        ?XDEBUG_SESSION_START=myname
        # the name after the equals sign "myname" represents the IDE key
       
    • When you do not define the ide key, the debugging client will use the username as the key, making use of the "USER" and "USERNAME" environment variables as necessary.
  • What alternatives do I have when the two machines cannot see (connect to) each other?

    If you have machine A and machine B that cannot connect to each other, you may be able to use ssh port forwarding to pass the connection along between the two (often useful in the case of a vpn/private network, or where you have only access to an intermediate machine). The actual technique used is what is called a reverse SSH port forwarding, see http://toic.org/2009/01/18/reverse-ssh-port-forwarding/.

    • Run the following code on the client machine (Note: the client machine is where the code is actually running):
      ssh -R 9000:localhost:9000 komodo.machine.com

      if using an intermediate host, replace the localhost with the client address like this:

      ssh -R 9000:client.machine.com:9000 komodo.machine.com
    • Once setup, you should be able to set Komodo to listen for connections locally on port 9000, and set the client to connect to the debugger on it's locally on port 9000 and the ssh tunnel will pass the connection between the two (three for intermediate) machines.

Additional configurations and settings for remote debugging can be found in Komodo's application help menu.

How do you write to the Command Output Window?

Question: 

How do I write some text to Komodo's Command Output Window from a macro?

Answer: 

We don't talk as much about how to present output from macros as we should.
Alert boxes certainly work, and are an easy tool for web developers, but we
all know they get old fast. As long as there's a command output window in
the UI, we might as well write output to that, right?

One of the reasons the docs don't talk about this window is that it was
designed long ago, without much thought to making it scriptable from
outside. The code is somewhat low-level, but works. It also works
from extensions, of course. One day there will probably be a
higher-level entry point in the public API. Until then a function
like this will work fine.

Let's dive into the code.

// Don't make this var, or it won't be visible afterwards.
append_to_command_output_window = function(str) {
    try {
        // First make sure the command output window is visible
        ko.run.output.show(window, false);
        // Second, make sure we're showing the output pane, not the error list pane.
        var deckWidget = document.getElementById("runoutput-deck");
        if (deckWidget.getAttribute("selectedIndex") != 0) {
            ko.run.output.toggleView();
        }
        // Now find out which newline sequence the window uses, and write the
        // text to it.
        var scimoz = document.getElementById("runoutput-scintilla").scimoz;
        var prevLength = scimoz.length;
        var currNL = ["\r\n", "\n", "\r"][scimoz.eOLMode];
        var full_str = str + currNL;
        var full_str_byte_length = ko.stringutils.bytelength(full_str);
        var ro = scimoz.readOnly;
        try {
            scimoz.readOnly = false;
            scimoz.appendText(full_str_byte_length, full_str);
        } finally {
            scimoz.readOnly = ro;
        }
        // Bring the new text into view.
        scimoz.gotoPos(prevLength + 1);
    } catch(ex) {
        alert("problems printing [" + str + "]:" + ex + "\n");
    }
};

If you're following along, you can create a macro (called, maybe,
"append_to_command_output_window", but macro names are mainly for
labeling) and save this text in it.

Notice that this macro doesn't actually *do* anything. It defines
a function, in Komodo's global namespace. You can then access
that function from any other macro simply by invoking
append_to_command_output_window, as in this example:

append_to_command_output_window("my text");
append_to_command_output_window("1 2 3");
append_to_command_output_window(""); // append a blank line
append_to_command_output_window("one last line");

If you give this macro an "On startup" trigger, all your other
JavaScript macros will have automatic access to it.

How do I see all the line numbers in a large document?

Question: 

When I load a large document in Komodo, I only see the last four digits of each
line number in the line number margin. How can I tell whether I'm on line 198065
or 238065 of a 400,000-line document?

Answer: 

While Komodo is designed to work with smaller documents that people create,
need to understand, and manipulate, and these files rarely exceed 10,000
lines in length, sometimes you need to load larger files. A common case is
stepping into a document containing generated code while debugging.

When Komodo loads a document, it counts the number of lines, and determines how
wide the line-number margin should be based on a document that can be twice
as long. Since the width is given in pixels, not characters, the number of
digits you'll see in the margin varies depending on your system.

Also, this code is only run when a buffer is loaded, and when you change the
properties, either global or local, to show line numbers. If you load a
small document and read in a few hundred thousand lines the margin won't
change. To stop truncating the line-numbers, you can either hide
line-numbers, and redisplay them, or use this macro:

var scimoz = ko.views.manager.currentView.scimoz;
var padding = 5;
var textWidth = scimoz.textWidth(0, "" + scimoz.lineCount);
scimoz.setMarginWidthN(0, textWidth + padding);

Why doesn't Ctrl-Shift-U lower-case a selection on Linux

Question: 

The Code menu gives a keybinding of "Ctrl+Shift+U" for "Make Lowercase", but when I try this, the selection is replaced by the letter "u" and the cursor no longer moves. What's going on?

Answer: 

Some Linux platforms use the Shift-Ctrl-U as an signal to move into an in-place Unicode Input Method Editor (IME), and Komodo can't override that to implement the lowercase-selection command. However this isn't the case on all Linux platforms, and we can't have Komodo determine it at runtime either.

If you're on Unix, you can use the Preferences|Editor|Key Bindings to assign this command to a new key binding; I found [Ctrl K + L] is as memorable as the default key sequence, and it isn't being used.

If you do end up in this IME mode, you can press the Escape key to get out of it.

How Do I Install New Dictionaries for Spell-Checking

Question: 

How do I install a new dictionary for Komodo's spell-checker, such as British English or German.

Answer: 

Komodo uses Mozilla's dictionaries. Each dictionary consists of two files, ln-LC.aff and ln-LC.dic, where "ln" is the language's two-letter ISO language code, and "LC" denotes its two-letter locale code. Komodo ships with the files en-US.aff and en-US.dic in the <komodo-install-dir>/lib/mozilla/dictionaries.

You can either copy existing Mozilla dictionaries from other programs, such as the <thunderbird-install-dir>/dictionaries directory, or find the dictionary you need at http://www.mozilla.com/en-US/thunderbird/dictionaries.html

Download the .xpi into a temporary directory, unzip it, and copy the .aff and .dic files to <komodo-install-dir>/lib/mozilla/dictionaries

Komodo should offer the new dictionaries in the Check Spelling dialog's Language drop-down bar. There is no preference to change dictionaries -- Komodo assumes that the most recent language is your preferred one, and remembers it.

One thing to keep in mind is that these dictionaries install into the program's installed area, not the profile area. This is a known bug with all Mozilla-based programs, and work is in progress to improve this on an overall basis -- the new spell-checkers will reportedly be faster, support more natural languages, and will be installed into the profile area. For now, when you migrate from version 4.2 of Komodo to a newer version, you'll have to manually copy the dictionaries over (unless the Komodo installer does that for you at that point).

Komodo column selection

Question: 

Does Komodo support column (block) selection?

Answer: 

Yes, to perform a column selection in Komodo, you will need to hold down the Shift and Alt keys whilst performing selection movements. For large blocks, it is often easier to select the area with the mouse first using the default selection method, then change the selection to a block selection by holding down the Alt and Shift modifiers and using the arrow keys to refine.

What about column editing?

No, column editing is not support by Komodo. Column editing is a follow-on from column selection, in which as you edit, changes are made to all the lines in the block selection, not just the current line.

How to improve Komodo's editing performance

Question: 

In what ways can I increase the performance of the Komodo application?

Answer: 

There are numerous components inside of Komodo that can become a performance hindrance, especially on older computing machines. Luckily, there are a number of features and components that can be turned off. Here are a few of these most common performance sensitive components that can be disabled:

  • Code Intelligence autocomplete and calltips (fires from editor key press events)
  • Syntax checking, aka linting (fires after code changes)
  • Disable wordwrap, as this can become intensive for files with long lines
  • Disable folding, this intensifies the code parsing process
  • Ensure there are no mixed line endings (will show up as green squiggles)
  • If using Komodo IDE SCC integration, ensure the "Do recursive status checks" preference is turned off

Startup ideas

  • Reduce the number of opened files and projects? As this is a large contributor to the startup speed.

Platform specific ideas

  • Mac OS X: Ensure you are using the correct build for your Mac architecture, check the "Komodo->About" menu, it should be macosx-x86 if you have an Intel machine, else macosx-powerpc for PowerPC. See here on how to check your system: http://support.apple.com/kb/HT1531

Feel free to add others as you come across them.

Cheers,
Todd

Why doesn't Rails debugging work on Windows?

Question: 

I was following the Rails tutorial, and everything was working like a champ until I got to the debugging part. The cmd window fires and sits there doing nothing. I understand Rails is all about a zen approach to building web apps, but isn't more supposed to happen?

Answer: 

Yes, the debugger should kick in. The problem is that shortly after the Rails tools were developed, Ruby 1.8.6 was released, and the Windows version of 1.8.6 fixed a bug. The bug was that the Dir#[] class method was accepting paths containing backslashes and quietly converting them to forward slashes, even though the documentation stated that the first argument is a regular expression. While Rubies 1.8.5 and earlier could have an expression like "Dir['c:\\foo\\bar\\*.rb'] and find all the Ruby libraries there, version 1.8.6 (and up I suppose) quietly returns an empty list.

The problem is that the Komodo debugger is extensible, and loads all its modules at run-time, by running Dir[] on a path based on its location. On Windows this path happens to contain backslashes. It didn't used to be a problem. It's fixed on the beta 4.2 versions of Komodo, but if you're trying to get the debugger to run on 4.1, you'll need to make this fix:

Find the file /lib/support/dbgp/rubylib/rdbgp/command.rb
load it in Komodo (or any other editor), find the load_dbgp_commands method,
and add the second line (the 'dir.gsub!' one):

def load_dbgp_commands
  dir = File.dirname(__FILE__)
  dir.gsub!(/\\/, '/') if RUBY_PLATFORM["-mswin"] # Allow for 64-bit, i686
  Dir[File.join(dir, 'commands', '*.rb')].each do |file|
    require file
  end
end