http://qs321.pair.com?node_id=572235

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.

Eclipse

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 http://www.eclipse.org - at the time of writing that's 3.1.2. At present I'm using Eclipse 3.1.2 on Windows 2000 pro.

EPIC

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 http://e-p-i-c.sf.net/updates/testing, 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

[download]

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

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 http://sourceforge.net/projects/vssplugin/, 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 http://subclipse.tigris.org/, 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.

Performance

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.

Templates

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.

Subversion

Using the stable Subversion plugin with Eclipse 3.2 caused me lots of unnecessary cursing. Use the 1.1.x version, from http://subclipse.tigris.org/update_1.2.x. 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'.

Debian

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".

Replies are listed 'Best First'.
Re: Getting started with Eclipse & EPIC
by TedYoung (Deacon) on Sep 11, 2006 at 15:08 UTC
    Good writeup! I love Eclipse for Java code, but there has always been one missing feature that has kept me off of it for Perl; you cannot edit files directly off a server through S?FTP. There is an FTP plugin, but it requires you to have everything setup up locally, and then indicate, individually, when to upload a file back to the server.

    Ted Young

    ($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)
[reply]
[d/l]
Re: Getting started with Eclipse & EPIC
by kwilliams (Sexton) on Sep 12, 2006 at 01:33 UTC

    Thanks for this writeup. The main trouble that keeps me away from EPIC so far is its script-centric approach. Most (almost all) of my Perl development is on modules and their test suites, and I haven't found a good way to wedge that model into EPIC in a way that lets me work efficiently on things.

    Has anyone else figured out a good solution for that? I think it might require a custom builder that invokes ExtUtils::MakeMaker or Module::Build to get things built in blib/ and knows how to invoke tests properly, etc.

     -Ken

[reply]
      Hi

      I'm running Eclipse 3.2 and EPIC 0.5.6. It seems that you can specify a custom external builder (not that I've ever done it).
      • Highlight your project
      • Right-click, select properties
      • Select "Builders" from the left column
      • turn off the "Perl Auto Builder" (ignore warning)
      • Click "New"
      • Select "Program" from list of "Ant build" and "Program"
      • Define an external program to run your build.
      The external program may have to be another perl script that takes as its arguments the project directory or something. Eclipse exports a number of variables such as ${build_loc} that are defined when the builder runs that point to the filesystem location where the project resides.

      The downside is that the output of the build goes to the console, not to a build-specific view in Eclipse as it would with Java, but it may be a starting point.

      - j

[reply]
[d/l]
      Yeah, I also think EPIC is useless in complex projects until there will be a way to setup custom builder (using perl, not java, please! :)).

      In addition to perl modules there a lot of other "build environments" which require support from IDE even for syntax checking. Just two examples:

      1. html templates with perl code inside (especially one which use custom html templating system :))
      2. small files with pieces of perl code designed to be eval'ed in some preconfigured environment: config files, web site parsers, etc. etc. etc.

      Also EPIC must support all 'advanced' perl features like attribute handlers - debugger in version 0.4.0 just die when try to open any (script which use) perl module which use Perl6::Export::Attrs (recommended in PerlBP book). (It dies in INIT{} block, so maybe this bug isn't related to attribute handlers, but INIT{} blocks is another advances perl feature which must be supported.)

      BTW, just for fun, I notice very cool bug in EPIC bugtracking system: trying to check syntax of this script 

      BEGIN { 1 while 1 }

      [download]
      if fork many perl processes which use 100% CPU and never kill them. :)
[reply]
[d/l]
        debugger in version 0.4.0 just die when try to open any (script which use) perl module which use Perl6::Export::Attrs
        Fixed in 0.4.10/0.5.7.
[reply]
Re: Getting started with Eclipse & EPIC
by mercutio_viz (Scribe) on Mar 13, 2007 at 21:59 UTC

    Some may prefer to go with EasyEclipse, which comes prebuilt with various plug-ins. The LAMP distro is ready to rock. I've been using the LAMP setup for the past week or so and the more I use it, the more I like it.

    -MC

[reply]
Re: Getting started with Eclipse & EPIC
by Anonymous Monk on Aug 26, 2008 at 13:15 UTC
    How to use perl modules while usig epic for coding in perl ? Any Suggestion
[reply]
      I find: 

      use strict;
use warnings;
use mymodule;

      [download]

      works tolerably well for me ;-). Seriously - I don't understand your question. You use modules the same way when you write code in EPIC/Eclipse as you do any other time. Could you explain what you mean?

      --------------------------------------------------------------

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

[reply]
[d/l]

Back to Meditations