Recently I decided to try out the combination of EPIC & Eclipse as an IDE for Perl development. My only other previous experience of IDEs was a little bit of Visual Studio, and the cut down VS that appears when editing VBA macros. After a little bit of experimentation, the experience of using Eclipse and EPIC has turned out to be quite liberating. At the point that I started working with it, I could have used a dummies quick start guide that didn't assume I was using Java, so this node details my 'getting started' experiences.


To start with I installed Eclipse 3.0.0 from my SuSE 9.2 CDs. It didn't take much playing with installing plugins to decide that this was a mistake - so step 1 is to obtain the latest stable version of Eclipse from - at the time of writing that's 3.1.2. At present I'm using Eclipse 3.1.2 on Windows 2000 pro.


Step 2 was to obtain EPIC. The latest stable version of EPIC is 0.3.0, dated July 2004, and I recommend against it. Most of the useful functionality seems to be unimplemented or broken with recent versions of Eclipse. I installed v0.3.12 from, and so far have had little trouble. If you want to be able to see the contents of local variables during debugging, you'll also need PadWalker.

There are two ways of installing Eclipse plugins: 1) copy a folder containing all the required code into \eclipse\plugins\, or 2) using 'help', 'software update'. EPIC installs the latter way, as there are license terms to agree.

Getting started

The next step is to start using Eclipse. I already had a folder on my windows box with a structure like this:

/-code /-App1 /-App2 /-shared

Eclipse starts up and asks where to put your workspace. After a little experimentation, I decided that the workspace should be c:\code, with all my code still in situ.

I wanted to work on app1, so I created a perl project (new->project->perl project) called App1, and Eclipse associated the project with the existing folder - so all my code was already in the project.


Perspectives are Eclipses window bundles and layouts for different languages/purposes. The perspective select button appears at the top right. Use a java perspective, and you'll get windows useful for java coding (object explorers, class hierarchy etc). Choose the perl perspective, and you get a rather less cluttered set of windows with a project explorer down the left, list of use'd modules etc.

CVS integration

So far so good, but the code was checked into Visual Sourcesafe, so I needed to check it out before working on it. Back to the plugin list. I downloaded the VSS plugin from, unzipped the file, copied org.vssplugin_1.6.1 to my \eclipse\plugins folder, and restarted Eclipse.

Once eclipse reloaded, I right clicked on the project 'App1' in the 'Navigator' view, selected 'Team', and then 'share project', and selected the VSS wizard. The wizard led me through identifying my VSS database and providing the authentication details. One to watch for though - you need to provide a path within your VSS database to the project you're interested in. Once this process is complete, files can be checked in and out by right clicking in the 'Navigator' view and selecting the 'team' submenu.

The experience is very much the same with subversion - you need the subclipse plugin from, but the wizard is accessed the same way, and checking files in and out is the same. A particularly neat facility IMO is the little subwindow that appears at the bottom of your eclipse window marked 'checked out files'. Having a list of the files that are checked out, and being able to check them back in quickly when heading home in the evening is handy, and a nice change from the very unfriendly VSS gui.

Back to eclipse

The script is now checked out, and double clicking the file in 'Navigator' opens the file in the perl editor pane (note that if you open a file that has already been associated with the repository, it will be read only. If you start typing, eclipse will ask if you want to check the file out). Code is highlighted correctly, EPIC spots when you are dealing with packages and offers a list of the functions/methods. If there's something wrong with the syntax or use/require list a red cross will appear at the beginning of the faulty line, and also on the files icon in the Navigator.

A warning will appear as a yellow triangle with an exclamation mark - both this and the error cross will display the error/warning on mouseover.

Running & debugging

Next you want to run the script you're working on. Click on the run icon on the toolbar, and you will be faced with a dialogue. You need to create a run configuration for this script. Give the configuration a sensible name ('scriptname_on_testdb' for example). Specify the project that the script is in, and the script name. Finally, specify any command line parameters, and click on 'run'. Your script runs and the output appears in the console pane below the editor pane. This seems to me a little claggy, since the whole list of run configs in your workspace appears, regardless of whether the project is open or not. After a while you'll probably end up with quite a large list.

Debugging is just as simple - your run configuration doubles as a debug configuration. Right click to the left of a line of code and put in a breakpoint, then click on 'debug' in the toolbar. The script will execute, stop at the breakpoint, and the debug views (debug, local variables) will appear alongside the 'task' view at the bottom of the screen, along with buttons to step, step into or over loops, stop execution etc.

I get a mysterious error on windows 2000 when eclipse goes to construct the debug window, but it doesn't seem to interfere with the usage.

I've yet to really get to grips with the facilities the debugger offers, but this much has proved enough to start with.

Other bits

A couple more handy facilities - the perl expression view, during debugging, will allow you to write perl commands that will run in the current context of the executing script. The rather neat perl regexp view will allow you to debug expressions by typing the expression in the top box, and the string to match against in the bottom, then execute the expression. These can both be reached from 'window', 'show view', 'other', 'epic'. The Task list can be populated by including a #TODO comment in your code, or manually by clicking in the box.

One thing I do find rather handy is the ability to take a copy of a workspace from the Windows box at work, pop it on my pen drive and take it home and (some slight fiddling with paths etc in the run configs & some growling about CVS aside) use it on my linux box at home with all the configuration intact.


On my work windows machine Eclipse is dog slow - I mean *really* slow - real time code checking and running the debugger are both pretty nasty. On my similarly spec'd linux box, it's pleasantly quick. Spec on both is 2ghz-ish processor and 256MB ram. TBH, I think the difference lies in the very large amount of resident software on the work machine (virus scanners etc) rather than an OS difference.

Hopefully this will prove useful to others getting started with Eclipse & EPIC, & maybe save someone a little of the trial and error approach.

Update I'm still finding interesting things about Eclipse & EPIC. Until I get around to re-editing this post into the form of a tutorial, I'll add useful bits in updates.


The EPIC editor allows you to create templates. I tend to use these for defining a comment block, e.g. for the beginning of a new script or a new function. Once you've created a template, type the first few letters of its name and "ctrl space" and it will fill in the block. Variables (defined with ${varname}) can be tabbed through when you invoke the template. Templates can also be imported/exported via XML, allowing you to share new templates with colleagues or your home machine.


Using the stable Subversion plugin with Eclipse 3.2 caused me lots of unnecessary cursing. Use the 1.1.x version, from That has support for the file:// url type, as well as not crashing ;-).

To import an already existing project from SVN, right click in the navigator and choose 'import'. From 'other', select 'checkout projects from SVN'.


For the first couple of days on the shiny new laptop, Eclipse was a nightmare. It crashed or ran *really* slowly. This turned out to be a VM problem - Debian installs the cacao JVM. Once I installed a Sun JVM, it was fine.

'make test'

If you're working on a module, create an 'external tools' configuration with a location of '/usr/bin/make', a working directory of '${project_loc}' and an argument of 'test', and you can perform a 'make test' with the click of a button.


"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".