Komodo

Komodo 5.0 features

Product: Komodo

This is an overview of the major items included in the Komodo 5.0 release. Some of these new features below are only available in the Komodo IDE version.

Improved Look and Feel

Komodo now provides a more native look and feel across all platforms, with tabs and sidebars being re-designed to be simpler and easier to use.

The user interface changes are more prominent on Mac OS X and Linux systems, with Linux using native OS theming... Yay!

Multiple Window support

Use the "Window->New Window" to open multiple Komodo interfaces. Open different work projects into separate Komodo instances to help compartmentalize your development focus.

Komodo will even restore your multiple instances with the same workspace, including desktop location upon shutting down and restarting Komodo!

Code Formatters (IDE only)

You can use code formatters for quickly reformatting your documents within Komodo. For example, if you have a JSON (JavaScript) file that contains all information on the one line, make it readable by using the built-in JavaScript formatter JS Beautify. You will go from:

to a nicely formatted:

Komodo comes with a number of pre-configured formatters, with the ability to configure additional language formatters through the Komodo preferences system.

SCC Support for Mercurial, Bazaar and Git (IDE only)

Three new Source Code Control (SCC) systems were added to Komodo 5, these were Mercurial, Bazaar and Git, which takes Komodo's supported SCC count to 6 (CVS, Subversion and Perforce were already supported).

Komodo requires these SCC clients to be installed on your machine and you can configure the settings through Komodo's SCC preferences.

SCC Checkout Wizard (IDE only)

Komodo provides a wizard to assist is making a checkout from Source Code Control. Simply choose the SCC type, provide the source and destinations and check it out!

All of the SCC components are support except for Perforce (as Perforce is using a completely different checkout mechanism).

Improved Tabstops

The tab-stop support in Komodo 5 has been greatly improved. Tab-stops can be used within snippets and new file templates in assist in quickly add a piece of templated information.

Tab-stop improvements:

  • they are now visually highlighted
  • you can create linked tab-stops to update repeated instances
  • linked tab-stop instances are updated inline when the main tab-stop is updated
  • you can create nested tab-stops
  • removed the use of specific tab-stop markers (chevrons)

Add-ons Searching and Installation

You can use Komodo's "Tools->Add-ons" menu to bring up the add-ons dialog. You can see a list of recommended add-ons, search for specific add-ons, and install directly from the dialog.

Add-ons are also known as extensions, you can even port existing Firefox extensions to Komodo.

Crash Reporting

Whenever Komodo has a serious problem and is unable to operate correctly (i.e. it crashes), the crash reporter dialog will appear, offering the ability to submit the fault to the Komodo development team.

It is recommended you submit all crash reports, as these crash reports contain crucial information to assist the development team in diagnosing the problem.

Other Komodo releases

Resetting the Komodo user data directory

Question: 

How do I:

  • reset my preferences
  • fix corruption in the code intelligence database or preferences
  • reinstall Komodo "from scratch"
  • etc. ?
Answer: 

Komodo keeps user preferences, a code intelligence database, and a number of other files in a user data directory. It's location on various platforms is described here:

http://docs.activestate.com/komodo/5.0/trouble.html#appdata_dir

Sometimes files in this directory can become corrupted, causing problems running Komodo. If this problem can't be tracked down to a particular file in the user data directory, there is a nuclear option:

  • close Komodo if it's running
  • delete, move or rename the user data directory
  • restart Komodo

Komodo will generate a fresh user data directory.

If you have preferences or a Toolbox you want to keep, move or rename the directory (e.g. "5.0-corrupt") instead of deleting it. You can then try moving some of the files (e.g. prefs.xml or toolbox.kpf) from the original directory back into the fresh user data directory.

IndexError: list index out of range

Question: 

I'm getting "IndexError: list index out of range" when I try to install Komodo on Linux. Why?

Answer: 

The Komodo installer is a gzipped tarball. It needs to be decompressed and untarred with g(un)zip and GNU tar compatible tools ('tar xzvf ...' should work on most systems).

Unpacking the tar.gz file using some other tools (such as WinZip) may cause the archive to be corrupted or missing components, leading to install errors like this one:

install: Installing ActiveState Komodo to '/opt/Komodo-IDE-4'...
Traceback (most recent call last):
File "./support/_install.py", line 620, in <module>
sys.exit( main(sys.argv) )
File "./support/_install.py", line 607, in main
interactiveInstall(suppressShortcut)
File "./support/_install.py", line 506, in interactiveInstall
install(installDir, suppressShortcut)
File "./support/_install.py", line 515, in install
destDir=destDir)
File "./support/_install.py", line 397, in _install
"libpython?.?.so"))[0]
IndexError: list index out of range

If you are seeing errors like this, try re-downloading the tar.gz file and unpacking it with 'tar -xzvf Komodo-<version>-<platform>.tar.gz'.

Writing Unittest Harnesses for Komodo 4.4: An Introduction

Product: Komodo | tags: extensible harness testplan unittest

In the good old days (i.e. two months ago), like the Model T, you could run any unittest harness in Komodo you wanted as long as it was black. Now Komodo allows you to write test harnesses for any language, and have the results show up in Komodo's Test Results area. This article shows how.

Adding a Test Harness to Komodo

We shipped a unittest harness in version 4.3 of Komodo, but strictly speaking it was closer to 1.0 functionality. We hard-wired four separate test harnesses, one for each of Perl, Python, Ruby, and PHP. Naturally, as soon as we launched 4.3 there was a barrage of requests for new test harnesses. With the functionality in 4.4 we're sharing the joy in writing tests. This document will explain how the test plans are structured, and what you need to do to write your own.

What is Sleuth?

"Sleuth" is a name we internally use for the unittest integration component. It has a well-defined meaning in English, but is rarely used, and therefore less likely to conflict or create confusion with existing systems. For example, Komodo has its own unittest framework. If we called this component "UnitTest", it could lead to confusion.

Structure of a Test Harness

The file sleuth.py defines two classes, KoSleuthHarness and KoSleuthHarnessRunner. KoSleuthHarnessRunner is the higher-level class, and is the one Komodo uses to run a set of tests. KoSleuthHarness is a lower-level class that launches the actual test process, reads its output, filters it, parses it, and writes information back to Komodo for it to display in the Test Results tab.

Neither class is an XPCOM class, so there are no IDL files that Komodo ships, but these are their external interfaces:

class KoSleuthHarness:
    def __init__(self, args, launch_dir=None):
        # args: array of strings
        # launch_dir: directory to run program from
    def filter_line(self, line, line_num):
        # line: string
        # Callback, return True if the line should be filtered (not parsed)
    def run(self):
        # An inner generator called by KoSleuthHarnessRunner.run
    def stop(self):
        # An inner function called by KoSleuthHarnessRunner.stop
        
class KoSleuthHarnessRunner:
    def __init__(self):
        # Initializes this class
    def lookupOutsideKoPath(self, programName):
        # programName : string, like "perl"
        # returns either the full path, or None
    def run(self):
        # A generator, yields a stream of lines read from the process
    def stop(self):
        # Called by Komodo to end the process

By itself, the code in sleuth.py cannot run any test harnesses. Each test harness is represented by a pure-Python module that needs to do the following things:

  • Live in a file with a name and location that Komodo can discover. The section on writing extensions will cover the directory structure to use. Harness filenames must end with "_harness.py".
  • Define a subclass of KoSleuthHarnessRunner.
  • Most harnesses will also need to define a subclass of KoSleuthHarness, although currently the koPHP_PHPUnit_harness.py harness defines a trivial subclass of it.
  • Set a module global called harnessName to the name of your harness. Harness names should be namespaced, to avoid collision -- currently the last harness loaded wins at run-time. These values will appear in harness selection menus in the Komodo dialogs for creating and editing test plans.
  • Define a register function that Komodo will call at startup time:
    class PHP_PHPUnit_SleuthHarness:
        # ...
    harness_name = "PHP - PHPUnit"
    def register(sleuthManager):
        sleuthManager.register('PHP', harness_name, PHP_PHPUnit_SleuthHarness)

Whenever Komodo wants to run your harness, it will create a new instance of the class passed in the third argument to the register method. This means you can't maintain persistent data in each of these classes; use module globals if you need to.

Have a look at the harnesses that Komodo ships. Notice that the PHP and Python harnesses are relatively thin wrappers around sleuth.py. By contrast, the Perl TAP harness has to do much more work, as it's parsing output, rather than plugging code into the underlying test harness.

Notice also that error messages are relayed back to the UI by setting the self._initial_msgs field to a list of sleuth-formatted error messages back to sleuth.py. The upper-level HarnessRunner class checks for these before launching the actual process; if it finds any, it normally relays them back to the caller (remember that the run method is a generator, not a function). This is a good way to present missing prerequisites back to the user.

Talking to Komodo: the Sleuth Language

These are the six different directives Komodo is watching for:

    @suite_started@:
    start a new test suite
    
    @test_started@: testname
    
    @fault@: line
    - a line of a possibly multi-line fault associated with the current test.
    
    @into@: line
    - non-error information the user might find interesting
    
    @test_result@: P | F | E
    
    @suite_finished@: N:n P:p F:f E:e; t
    - finished the current test suite. n, p, f, e stand for the number
    of tests, number passed, number failures, and number errors.
    t gives the elapsed time

Any other output is emitted to Komodo and treated as part of either the current fault or info event, or will be discarded.

Yes, tests that emit any of the above strings as part of their output will confuse Komodo.

Defining New Test Harnesses

In general, you'll need to spend more time figuring out how to plug in your test-runner into the framework you're targeting, or parse its output, then you should spend getting a new framework to work with Komodo. Test harness extensions are very simple, and follow this layout:

dir/
    - install.rdf
    - sleuth-harnesses/
        - *
            - *_harness.py

That's it. The sleuth-harnesses may contain more than one subdirectory: each of those subdirectories can define one or more test harnesses. The reason for the extra level of directories is to make it easier to package several different types of harnesses in a single extension.

The nose.xpi extension implements not one but two harnesses for working with Python's nose testing framework. Nose is good at "sniffing" out things to test in a directory, much better than the unittest-based test harness shipped with Komodo. I noticed that by adding a --with-doctests argument to the invocation of Nose, it would run docstring-based tests instead of tests that implemented unittest. I first duplicated the contents of as_nose_harness.py into as_nose_doctest_harness.py, got it to work (by adding one extra argument), and then refactored the common part of the two files into as_nose_common.py. These harnesses work with versions 0.9 and 0.10 of Nose.

Before you can use them, you need to install Nose, of course, and also install the sleuthplug.py module that I bundled in the extension. At some point I'll touch base with Brandon Corfman, who first directed my attention to this framework, to find out a way to run plugins without installing them. But meanwhile I've got a Ruby Test::Unit harness to write.

Komodo 4.4 features

Product: Komodo

This is an overview of the major items included in the Komodo 4.4 release. These new features below are only available in the Komodo IDE version.

You can also watch a screencast of these new features here:
http://community.activestate.com/new-features-komodo-4-4

Sections menulist

The sections menulist is a new item added to the Komodo statusbar. Upon clicking this statusbar element (or using the command - Ctrl-F8) a menulist will appear that outlines the main sections contained in your current Komodo editor file.

You can select an item in the menulist which will proceed to take you to the matching location in your document. When you type additional characters, the list will be filtered down to those items partially matching your input.

The benefits of the sections menulist over the code browser are:

  • Shows only the current file context
  • Shows only the functions and classes (not variables)
  • It provides layout information for non-codeintel languages (C++, Java, )
  • Regex based, so can be easily customized
  • Easy to add support for additional languages

Multi file SCC commit

Komodo now has an updated commit dialog that is used for SCC Commit operations. The dialog will show update-to-date scc status for all files listed in the tree, updating itself asynchronously. The dialog makes it easy to add additional files/directories. The dialog also offers the ability to see the diff from the files you are about to check in.

SCC changelist

Komodo now provides the ability to manage groups of scc files. You can find this new tab in the right-hand pane (next to the Komodo toolbox). This is very useful when working on a specific set of files, create a new changelist and then drag/drop the files you wish to have involved. SCC operations can be performed on these changelist items, which operate on the group of files inside the changelist. Komodo keeps track of the scc files you edit in a default changelist set, which quickly shows you the files your likely interested in.

Unit testing

There have been a number of improvements made to Komodo's integrated Unit Testing components.

Extensibility: Komodo now finds and registers the unit test harnesses dynamically. Additional unit test harnesses are best added through Komodo extensions. See the Komodo addons site for a Python Nose extension which provides two test harnesses, one for the PyUnit library and the other for Python doctest.

UI improvements: Test plans can now be associated either with project preferences, as in version 4.3, or through the individual file preferences. There are no longer any global test plans. The Tools|Test menu is now used to manage file-based test plans. A "[Tools|Test|Move Global Test Plans to Document...]" allows the copying of any existing global test plan created in version 4.3 to migrate to a file-based test.

Other Komodo releases

How to setup and use CakePHP with Komodo

Question: 

How do I setup Komodo to best work with my CakePHP applications?

Answer: 

Prerequisites
CakePHP relies on many applications: a web server (like Apache), a database (like MySQL) and PHP 4.3.2 or greater, so ensure you follow the necessary instructions for setting this up for your operating system, see the CakePHP installation section for details:
http://manual.cakephp.org/chapter/installing

I will not cover the setting up of a CakePHP application, but expect the user has an existing CakePHP application they want to work on using Komodo.

Configuring Komodo to work with CakePHP

  • PHP interpreter
    Komodo needs to know where the PHP interpreter is, this is so Komodo can provide PHP specific functionality such as Syntax Checking, Debugging and Code Completion.
    • Go to the Komodo preferences, select the "Languages->PHP" category and check/set the PHP interpreter to point to the PHP executable you have installed.
  • PHP Frameworks
    Komodo needs to know where your third-party PHP code is located, so that it can assist in providing adequate PHP code completions, calltips and code intelligence benefits. Generally for applications that install as part of the PHP standard library location or are added to the php interpreter's php.ini file, this is not necessary, but for frameworks that are configured through the web platform (i.e. http.conf) this step is necessary.
    • Go to the Komodo preferences, select the "Languages->PHP" category and in the "PHP Directories" area, select the "Add..." button to browse to where the core CakePHP libraries are installed, i.e. "/wwwroot/cake/cake" on my linux machine.
  • Setup your project
    Komodo provides help for managing your application development through the use of projects. Projects let you view the application layout, edit and manage files/folders as well as providing command, macro and snippet tools.
    • Use the menu "File->New->Project" to start creating a new project. Save the project to the base directory where your CakePHP application resides, i.e. "/wwwroot/cake/app/App1.kpf"
    • Once saved, the project itself and the list of files/folders should appear in Komodo's project pane, where you sort, expand/collapse and click on to open for editing
    • As you edit your CakePHP application files, you should notice completions for CakePHP functions and classes, try this for an example:
      $session = new CakeSession();
      $session->

      You should have calltip/completions when you type the open paren "new CakeSession(", when you type "$s" and when you type the "session->".

  • Bake run command
    Bake is a command line PHP script that will automagically generate a model, controller, and views based on the design of your database.
    • On your application project, right-click and select menu "Add->New Command...", call it "Bake", set the "Start in:" field to be "%p" which means the active project and then use the command text below:
    • For the command, use
      %(php) /wwwroot/cake/cake/scripts/bake.php

      , or if the script is provided as a windows batch file, you can simply just specifiy this file as

      /wwwroot/cake/cake/scripts/bake.bat
    • Bake runs interactively, so you can either run it through Komodo Command Output Tab (the default) or choose to run it in it's own separate console window, whichever is your preference.

Other Komodo/CakePHP resources
Komodo Macros for inserting CakePHP template hints

Advantages of using Komodo IDE
The advantages of using Komodo are many (just note that I am of course somewhat biased, heh).

  • Komodo comes already prepared with most things you need for PHP development, such as integrated source code control and code intelligence helpers, so you don't need to play around with specific plugins or download a special build to get up and running.
  • Komodo provides code completions and calltips easily, simply define what PHP frameworks you need and and it's done, calltips and completions appear immediately afterwards.
  • Komodo IDE provides debugging tools to help analyse your code and data in real time.
  • Komodo IDE provides additional web tools to help with client/server development, such as the HTTP Inspector and the JavaScript debugger.
  • Most of Komodo is open source, so you can dig into the code and contribute if you feel like it: http://www.openkomodo.com/

Hope that helps.

Cheers,
Todd

JavaScript Debugger Incompatibility

Question: 

Javascript debugging will not work, when I try to debug the page hangs and nothing happens in Komodo, even though Komodo states there is a debugging session.

Answer: 

The current JavaScript debugger included with Komodo 4 has a known incompatibility with the 'Flashgot' Firefox extension, first reported here:

http://community.activestate.com/forum-topic/cant-debug-javascript-komod...

The user reports that uninstalling Flashgot solved the issue. There may be incompatibilities with other Firefox extensions, so if you are having similar problems but do not have Flashgot installed, try this approach to troubleshooting the problem:

- in the Firefox Addons manager, disable all extensions except for JSLib and the Komodo JS Debugger
- verify that JS debugging now works
- try enabling your extensions one by one and re-test JS debugging. This should allow you to identify which extension is causing the problem.
- please report the incompatible extension in the comments to this FAQ.

Tcl not supported in Komodo Edit

Question: 

Tcl syntax checking support seems to have been dropped in Komodo Edit 4.3. What's the deal?

Answer: 

The Tcl syntax checker used in Komodo IDE and previous releases of Komodo Edit is not open source, therefore we decided to remove it from the main build of Komodo Edit as of version 4.3 and provide it as a closed-source extension instead:

http://community.activestate.com/xpi/tcl-syntax-checker

Modifying the installed Komodo code

Question: 

For my Komodo installation, how do I change parts of the code?

Answer: 

This really depends upon what your looking at modifying. If your not sure, the best idea is to use the OpenKomodo svn and grok tools to first find the details of what you'd like to change:
http://svn.openkomodo.com/
http://grok.openkomodo.com/source/

Once you know what you'd like to change, you need to find where the corresponding file(s) reside inside your Komodo installation.

Python
Most of the Python code resides in one of two directories:

<komodo_install_dir>/lib/mozilla/components
<komodo_install_dir>/lib/mozilla/python/komodo

These files can be edited directly and the code changes will be automatically be included on the next restart of Komodo.

JavaScript, CSS and XUL
Most of the JavaScript, CSS and XUL code will be inside a ".jar" file (a type of zip file):

<komodo_install_dir>/lib/mozilla/chrome/komodo.jar
<komodo_install_dir>/lib/mozilla/chrome/xtk.jar

Which you can use an unzip tool to extract the sources from. Modification to these files can be done on the extracted files, but the modified files will need to be repackaged into the komodo.jar file to have any affect. Changes will be noticed on the next restart of Komodo.

Here is the example process to update one of the JavaScript files inside of the komodo.jar:

  • shutdown Komodo
  • unzip the "dialogs/alert.js" file from the komodo.jar
    unzip komodo.jar content/dialogs/alert.js
  • modify the JavaScript code as you like
  • repackage the modified file (use -u "update" zip flag)
    zip -u komodo.jar content/dialogs/alert.js
  • restart Komodo

Tools
For Windows, here are some links to free tools that provide zipping, patching and other utilities:
Zip/Unzip: http://www.info-zip.org/
Patching and other tools linux tools: http://sourceforge.net/projects/unxutils

Unit Testing in Komodo 4.3

Product: Komodo | tags: Perl PHP python ruby testing unit test

Komodo 4.3 offers an interface for unit testing in Perl, PHP, Ruby and Python. Unit tests can be defined globally, or within a project. Unit test output is displayed in the Unit Test Results tab in the bottom pane, where errors can be clicked to jump to the relevant file and line number.

Unit Testing Interface

Test plans can be global (Tools|Test Plans|Create New Global Test Plan... or project-specific (right-click on a project and select Create New Test Plan...).

  1. Give the test plan a useful name
  2. Select the language
  3. Set the directory to run the test command in (usually the base directory
    of a project).
  4. Specify any additional command line options (see below).
  5. Click 'OK' to save the test plan

To run the test plan, select it from the drop list in the Project
Unit Tests Results
tab.

The Project drop list shows a list of open projects containing test plans and a [top level] item for global test plans. The Test Plan drop list shows the test plans for the selected project.

Supported Frameworks by Language

  • Perl: Uses 'make test'. If no Makefile is
    present, it first runs 'perl Makefile.PL' to generate one before
    running 'make test'.
  • Python: Uses the unittest framework. You
    need to specify a list of files and/or directories to test.
  • PHP: Uses the PHPUnit framework. Set the
    test plan to point to the base directory of the project. The test harness will
    look for a subdirectory called tests.
  • Ruby: Runs 'rake'. If the default action of
    the Rakefile is to run tests, no command-line options are needed. If not,
    enter the appropriate target for rake (e.g. 'rake test').