Updated 2012-09-02 15:10:43 by RLE

by JMG

Purpose: Tools and Hints to use Eclipse Platform as an integrated IDE for Tcl development.

NEM 29 Sep 2006: Mikhail Kalugin is apparently working on a Tcl plugin for Eclipse. See EclipseDLTK.

DKF 9 Jan 2007: JACL can also be used with Eclipse. See instructions further down this page for more info.

RMSB Why should we use a bloated IDE like Eclipse to develop in Tcl? I thought the point to develop in Tcl and other "agile", lightweight languages (call it scripting if you're in the mood) was exactly to avoid stupid and redundant bloated development environments like Java ones....

I refuse to use anything more bloated than XEmacs... :)

Look at it this way: why should someone who has chosen to do all their development in Eclipse be denied the ability to use Tcl in the work environment of their choice?

RLH thinks out loud: I guess if you already used Eclipse for Java, then it would benefit the developer to be able to develop using Tcl in Eclipse. "One IDE to rule them all," and all that rot. I prefer something lightweight, myself. On the other side, every other dynamic language has a plugin for Eclipse, why not Tcl as well?

EL The reason to have an IDE is to be aware of growing projects and to handle them better. Sure Vi (my favourite) might be sufficient for a project with 20,000 lines of (i)tcl code integrated with 10,000 lines of C code, but with an IDE like eclipse, a Code browser and template generator, syntax highlighting and code completion, jumping inside the code and so on - you can just better handle this project.

That said, there is no really good IDE for (i)tcl - probably because many Tcl'ers think that a simple editor is enough. Eclipse is an almost ready IDE, and provides a very sophisticated plugin architecture for its extension. So an (i)tcl IDE could be made with less effort simply by defining a plugin. Regarding "bloated" - nowadays machines have usually enough memory and CPU speed to run a Java based IDE. Java is not slow anymore, as is Eclipse.

My experience with other people and what they think about Tcl: Most new developers are scared by Tcl when they encounter: 1. that the language is not object oriented by default (which is a different problem) and 2. that there are no tools available for supporting fast and comfortable development, except some small programs in the ActiveState TclDevKit (but they don't even think about a license for the DevKit, if they dont get started with Tcl at all). There are even no really good commercial editing tools, Komodo is the only one I know - and this one is better suited for Python and Perl as it seems. So, new developers don't get to the advantages of Tcl because they are put back already at the beginning of their Tcl experience by simple things like a comfortable development environment. I will try to start a plugin project that makes Eclipse a suitable Tcl IDE. Lets see how far I can push it...

RLH 2005-7-8: So is Komodo an IDE or are we talking free only?

JH 2005-07-08: Komodo is certainly an IDE. You can set up projects, it has a very handy toolbox, customizable menu and toolbars, and all sorts of fancy editing features. I am curious why EL would say that Komodo favors Python or Perl though. Komodo supports Tcl at the same level as the other ActiveState supported dynamic languages. It has edit-time syntax checking, debugging, tooltips, etc.

EL 2005-07-09: JH, I am missing support for a few Tcl specific features in Komodo. E.g. it has no Itcl support, I mean the code browser is not aware of Itcl classes (at least I couldn't find this property). That is a big drawback IMHO, since I am programming in Itcl rather than in pure non object oriented Tcl. It would be good as well to have a templating system for Tcl libraries, according to the TEA standard together with a directory/source browser for the whole package - like it is done in Eclipse for Java packages (kind of: mouse click on "new tcl package" and the stub directory structure for a TEA conform extension is generated). Probably a plugin system similar to the one of Eclipse would be of advantage to implement such features in Komodo...

IL 2005-07-16: I like Eclipse for Java, because it removes the tedium of the language, for instance, remembering the exact name of the package you want imported, or catching compiler errors pre-compiler, auto-generating the ubiquitous getters and setters; this is all the crap Java makes you do that Eclipse erases. With that you can focus on development, which is nice. Tcl however, doesn't suffer from those problems ;) I'm torn on this, I suppose a Tcl project could be drawn up to give you some flexibility with namespace/package/proc managing, auto-completion, that type stuff, but I wonder if anyones application is really so unmanageable that it needs such an IDE...

[ppcx] 2005-11-28: So, is there a Tcl plugin for Eclipse? Another reason to have one is for someone (like me) who does not know Tcl but wants to make changes (specifically changing the app from using mysql to either postgresql or Oracle) but wants/needs help with the details of Tcl.

CL claims the short answer is, "No", and invites ppcx to raise the question either in clt or the Chat, where he's more willing currently to field it. I frankly can't imagine any realistic future in which someone makes the investment in Eclipse to enable it to manage the change in datamanager binding described. We're probably all better off just talking ppcx through his specific situation.

IL 2006-2-15: can I take back what I said? :) Eclipse does some fancy things I think the tclers might like. (These are examples from the Java playbook).

  1. command autocomplete, - start typing "string" (and it pops in match, first, etc)
  2. procedure autocomplete, - the eclipse IDE can also find your own code, and prep it for autocomplete as well
  3. make available generic templates, or define new ones.
  4. setup build scripts - (imagine "build" button for creating packages, removing tedium etc.)

now, I'm not saying these are necesary for Tcl development, but these are definitely some nice to haves. I might try starting one of these things as a learning tool for myself since I work a lot in Eclipse. I don't know how easy it is to extend these features to another language, but isn't investigation part of the fun? :)

DKF 20060215: We'd need a little bit better introspection for that. Right now, although you have good introspection of some things, it's tricky to find out other things consistently (e.g. the only way to get a list of subcommands of a command is to guess from the human-readable error message).

RS 2006-03-24: Here is a "partial parser" that extracts subcommands from an error message, if it has a typical pattern:
 proc options cmd {
   if [catch {$cmd xxxxx} res] {
      if [regexp {bad option "xxxxx": must be (.+)} $res -> opts] {
         string map {", or " " " , ""} $opts
      } else {return -code error $res}
 % options string
 bytelength compare equal first index is last length map match range repeat replace tolower toupper totitle trim trimleft trimright wordend wordstart
 % options fiul
 invalid command name "fiul"
 % options file
 atime attributes channels copy delete dirname executable exists extension isdirectory isfile join link lstat mtime mkdir nativename normalize owned pathtype readable readlink rename rootname separator size split stat system tail type volumes writable

Tested to work with file, info, interp, namespace, package,string, winfo, wm

PT Anyone who has started working on it and needs any help ?? Please post a site here.

Jacl and Eclipse edit

During Jan, 2007, Patrick Finnegan posted a HOWTO for running Jacl with Eclipse as an external tool [1]. I'll include his notes here, so that as refinements are found, they can be incorporated.

It's now possible to run JACL with the Eclipse IDE as an external tool.

Installation Instructions

1. Install Java.
Download the java runtime from http://www.java.com and install on your machine.

2. Download JACL
Download the JACL 1.4.0 jaclBinary140.zip binary from http://sourceforge.net/projects/tcljava/

3. Extract the binary.
Extract jaclBinary140.zip to a local directory e.g. C:\Downloads\jacl\jaclBinary140\jacl140\lib\tcljava1.4.0.

4. Install the jar files.
JACL enable the Java runtime by copying the JACL jar files from the extract directory to the ext directory of the java install. The JACL jar files will be dynamically loaded by the JVM at runtime, e.g. copy the following jar files from C:\Downloads\jacl\jaclBinary140\jacl140\lib\tcljava1.4.0 to C:\Program Files\Java\jre1.5.0_10\lib\ext.
         itcl.jar jacl.jar janino.jar tcljava.jar tjc.jar

5. Test the installation by starting an interactive shell.
         C:\>java tcl.lang.Shell
         % # enable Java commands.
         % package require java
         % # get local ip address.
         % java::import java.net.InetAddress
         % puts "My IP Address is: [[java::call InetAddress getLocalHost] getHostAddress]"
         My IP Address is:

6. Install Eclipse.
Download Eclipse from www.eclipse.org and install to a local directory. If there is more than one java runtime installed on machine ensure the one used by Eclipse has the Jacl jar files in its ext directory.

7. Install Eclipse Tcl Plugin.
Download the Eclipse Tcl plugin from http://www.eclipsedltk.org/ and install into Eclipse. Simply follow the standard plugin installation procedure and copy the eclipse directory in the zip file over the eclipse install directory.

8. Create a Tcl project.
Start Eclipse and create a Tcl Project: File → new → other → Tcl Project. Create a Tcl file called quickTest.tcl in the project: File → new → other → DLTK Tcl → Tcl File. Add the following commands to quickTest.tcl then save.
         clock format [clock seconds]
         package require java
         puts "current directory is [java::call System getProperty user.dir]"
         java::import java.net.InetAddress
         puts "My IP Address is: [[java::call InetAddress getLocalHost] getHostAddress]"

9. Configure JACL as an external tool.
Create a new external tool: Select run → external tools → external tools. Double click on program. Set the following parameters.
Java installation directory. E.G. C:\Program Files\Java\jre1.5.0_10\bin\java.exe
working directory
${container_loc} - This resolves to the folder location of quickTest.tcl in Eclipse.
tcl.lang.Shell ${resource_loc} ${resource_name} - resolves to the location of the selected tcl file which in this case is quickTest.tcl.
Close the dialog.

10. Select and run quickTest.tcl.
Click once on quickTest.tcl to highlight. From the top menu select run → external tools → jacLShell. Do not right click → runas. The following is written to the Eclipse console.
         current directory is C:\EclipseWorkSpaces\JaclScripts\testScripts
         My IP Address is:

11. And the whole point of this exercise is…
Well it's really code management and the convenience of having Jacl and Java packages in the same workspace.

DKF posted to comp.lang.tcl, as a follow-up:

I advise putting double quotes around ${resource_loc} and ${resource_name} because their expansion might have spaces in (especially ${resource_loc} if you're keeping your Eclipse workspace below "My Documents"...)

RS 2007-03-09: [2] reports: "Eclipse released the code from the Eclipse Dynamic Languages Toolkit Project, which is designed to simplify the job of using Eclipse software to write applications in Python, Ruby and Tcl. The first release, available now, supports Tcl."

I decided to publish my scripts to let Eclipse interact with tkcon and tkinspect using comm. It works for me in a (Debian) GNU Linux / Eclipse 3.3 environment.

Create a new project in Eclipse or place the send.sh and send.tcl files in same directory somewhere on filesystem.

File: send.sh
 TKCON="/usr/bin/tkcon ~/.tkcon_opts"
 TKINSPECT="/usr/bin/wish /home/ready/Workspace/toolib/build/tkinspect/tkinspect.tcl"
 fuser -n tcp $TKCONPORT >/dev/zero 2>/dev/zero
 if [ $? -eq 1 ]; then
   cat > ~/.tkcon_opts <<EOF
 package require comm
 ::comm::comm config -port $TKCONPORT
   $TKCON &
   sleep 1
 fuser -n tcp $TKINSPECTPORT >/dev/zero 2>/dev/zero
 if [ $? -eq 1 ]; then
   cat > ~/.tkinspect_opts <<EOF
 package require comm
 ::comm::comm config -port $TKINSPECTPORT
 ::comm::comm connect $TKCONPORT
   sleep 1
 exec /usr/bin/tclsh "$(dirname $0)/$(basename $0 .sh).tcl" "$*"

You have to configure the path variables for tkcon and tkinspect. And dont forget to set chmod to 755.

File send.tcl
 package require comm
 ::comm::comm config -port 54320
 set tkcon 54321
 set tkinspect 54322
 if {$::argc > 0} {
   foreach file $::argv {
     if {[catch {
       set fp [open $file]
       set data [read $fp]
       close $fp
     } ret]} {
       puts "file $file doesnt exist"
       return -code error
     if {[catch {
       ::comm::comm send $tkcon eval $data
       ::comm::comm send $tkcon puts \"eclipse([comm::comm self]) -> $file\"
       ::comm::comm send $tkinspect .main0 set_target $tkcon comm
     } ret]} {
       puts "$ret"
       puts "tkcon ($tkcon) failed parsing $file"
     } else {
       puts "tkcon ($tkcon) parsed $file"
 } else {
   puts "no command line argument passed"

Configure a new external tool in Eclipse as following:
> tkcon
working directory
${resource_loc} - resolves currently selected file'.
common tab
(x) Launch in background
common tab
(x) Allocate Console

Feel free to improve it. Greets, ready

The server here: http://www.eclipsedltk.org/ no longer seems to be responding - davidw.

DKF: IIRC, they've gone more official. See http://www.eclipse.org/dltk/ instead.

There is some discussion on dltk at Eclipse Europa TCL Editor (DLTK project). This and the eclipsedltk page should eventually be merged...