We are the makers of a Prolog language development system that runs on a variety of Windows and Unix platforms. Prolog differs from conventional programming languages in that it is non-procedural and rule-based. It has built-in search and pattern-matching capabilities--so programs run forwards looking for a match, then backwards on failure or to find additional matches. And, unlike other Prolog implementations, we specialize in embedding Prolog modules in conventional (procedural) languages and tools such as Java, C++, .NET, Delphi and Web servers.
Our existing IDE dates from the early 90's and was showing its age. So last year we started thinking seriously about a replacement. We wanted an IDE that would run on multiple platforms, and we wanted to support all the modern conveniences.
The question was how to do that without a budget of the likes of Microsoft or Borland? When we learned of Eclipse, we were immediately intrigued. Eclipse offered:
Eclipse also allowed our users to develop both parts of their application using the same IDE. That is, they could develop the user interface in Java or C++ and an intelligent logic-base and/or rule-base in Prolog without ever leaving Eclipse.
There were also some downsides:
On balance, clearly an Eclipse-based IDE would offer many more features than we could ever hope to build from scratch. But, could we get Eclipse to adapt to a Prolog developer's needs for building components in a non-procedural programming language, and at what cost?
The prototype also clearly demonstrated the 80-20 rule. 80% of the work could be done in 20% of the time and vice versa. So, how did we go about building the prototype, and ultimately our Amzi! Eclipse IDE?
Start by downloading the "Eclipse SDK" and the "Example Plug-Ins". This includes everything you need to run Eclipse as a user, write Java programs, and develop your own plug-ins (the PDE, Plug-in Development Environment).
To start Eclipse development, you can either open one of the example plug-ins, or you can create your own plug-in from scratch. We recommend you try the former first.
If you want build an entire IDE, you will probably have many extensions organized into multiple plug-ins. A group of related plug-ins that is installed and work together is called a feature. Typically the user view of a feature is called a perspective, which is an arrangement of tools, menus and views that are tailored for a specific development task. A view is a window that provides its own menu and buttons and performs a specific task (e.g., editor, outline, task list).
We built an Eclipse feature and perspective for Prolog, and we created extensions to the built-in Debugger perspective for debugging Prolog components. Our extensions are:
You can see the extensions marked with an asterisk in the screen shot of the Prolog perspective (see Figure 1).
It has taken about 6 months of full-time effort to develop our Prolog perspective and debugger extensions for Prolog code. What follows below are insights we gained along the way.
An Eclipse extension takes one of three forms:
You can start your development work in a single plug-in. In fact, you can put all of your extensions in just one plug-in. However, if you are building a large number of extensions, chances are you will need and want multiple plug-ins to do this. This is because Eclipse loads plug-ins as they are needed by the user. So you don't want to fill up memory and delay the user to load a bunch of code that is not needed. For this reason, most developers put at least their debugger in a separate plug-in (some also split the debugger user interface from the internal debug model).
If you start with a single plug-in, you will find the 'refactor' command makes it very easy to rename and move classes between plug-ins when you need to split into multiple plug-ins or re-organize your architecture.
Also, plug-ins must be in a strict hierarchy (this may not be documented anywhere), so your user interface plug-in can call your debug plug-in, but not vice versa. This is an important point when choosing a structure for your extensions (see how Java, C++, and COBOL organize theirs).
The current Java Editor example is top-notch and includes keyword coloring among its many features. It illustrates almost everything you might want to have in your own editor. This is because the Eclipse folks have been moving functionality from the Java Development Tool into the base product. Changing the keyword list was quite easy, we simply built a function that calls Prolog to find out what the current system predicates are.
Some of the other features are more difficult to add or modify, especially breakpoint setting/clearing. In these cases, experiment carefully as it takes a long time to grasp the subtle interactions between the various editor functions and the code that provides the implementations.
Associated with the editors is the outliner. Our source file outline view provides a tree of the Prolog predicates (see Figure 2). For us, the parser was very easy to build because Prolog can parse Prolog in only a few lines of code. If your outliner is tree-based and the parser isn't too hard to create, you will find an outliner very easy to build from the Property Sheet example.
Once the outline was complete, the cross-reference view was easily built as it is also tree-based. Again, it was easy to adapt our existing command-line cross-referencing tool (written in Prolog) to be callable from Eclipse (see Figure 3).
As to adding your additional preferences and pages, the only difficulty is that there are two ways to make them, and most of the existing tools (Java, C++, COBOL) use the old way. So read the article "Simplifying Preference Pages with Field Editors" to see if you can use the new way, which will save much effort. Also see the ReadmeTool sample that has a Preferences Page.
Again the examples provide a New Project Wizard and a PropertySheet. The builder interface (IncrementalProjectBuilder) is straightforward to implement. The article "Project Natures and Builders" is very helpful. Eclipse also has a marker facility that lets you create entries on the Tasks View for each compile/link error. Each marker is optionally associated with a file and a line number. We also create 'problem' tasks when our outline or cross reference parser finds syntax errors in a source file. The article "Mark My Words: Using markers to tell users about problems and tasks" describes this facility very well.
So to build an Eclipse view for our interpreter, we needed a calling interface that redirects the user input and output. Getting that to work under Eclipse, though, was another story. Eclipse is very picky about what threads can access the user interface (understandably so). This meant that although our interpreter could run in another thread (so as to not lock up the rest of Eclipse) it has what we could only term as a nasty set of callbacks and synchronized buffers.
The other major challenge for the interpreter and the runtime is Eclipse's launch mechanism. A new article, "We Have Lift-off: The Launching Framework in Eclipse" would have saved us countless hours. But, our architecture caused us problems nonetheless. Eclipse makes the assumption that for launch, a Java Process will be created to run an executable file.
However, since our Prolog is embeddable within Java (and other languages), many of our users never create an operating system executable file that can be run in this way. Instead we call our Prolog virtual machine directly from Java. This led to a number of days struggling with threads. The difficulty is that while Java Processes can be killed, Java Threads cannot. So reliably notifying a thread that it is time to end was most difficult in an environment with input/output being redirected. We implemented a stop button, control-break key and handled view closing.
Also, the Eclipse launch mechanism is overkill for many situations. It is very powerful because it lets you specify all the parameters needed to run a program. But, Prolog has very few requirements in this area. So we also built "Launch Shortcuts" that directly run a Prolog project in the interpreter, debugger or runtime. To make this work, requires automatically building an Eclipse launch configuration on the fly.
Our best advice is to start with the debug model (see org.eclipse.debug.core.model in the Eclipse documentation. We found a newsgroup article that got me started by explaining the following:
The top-level is a DebugTarget. When you launch a debug session you create a DebugTarget in a new thread. DebugTargets own Processes and Threads (you must have at least one of each). Threads own StackFrames. StackFrames own Variables and their Values, and Registers and Memory Blocks. If you create a DebugEventListener and BreakpointListener then you can watch how Eclipse interacts with your debug model implementation.
The biggest problem we faced with the debugger, and Eclipse, is our desire to highlight the currently executing line of code with either a different icon (not possible) or a different color. We needed to do this because Prolog can be in one of four different states on each line of code (call, fail, redo and exit). We received some excellent help from another developer as well as the Eclipse developers directly (on the mailing lists). Although we did get it to work, we unfortunately have to open a new editor window. But, we've put in our enhancement requests, and this is something they have already implemented for the next release.
As a side note, we did consider attempting a change to the Eclipse source code and submitting it to the developers for possible inclusion in a future release. But then existing Eclipse users could not install our Prolog extensions until that new release was available, so we decided against this.
Out of the sixmonths of development, about half have been used for the debugger. However, the good news is once you've built a source level debugger, getting it to work remotely is a piece of cake as Eclipse is designed perfectly for this.