Purpose: to provide a forum where developers accustomed to an integrated development environment (IDE) can share tools that provide them an environment suitable for development.
I hope established Tcl developers, as well as people learning to program Tcl the first time, update/add to this page information they find useful.
There have been times when users (particularly from the Windows development arena) come to the Tcl community perplexed as to how to get started.
Some of the issues they face are:
Tcl (and Tk) in their purest form (that is to say, either the source or perhaps executable form from the http://tcl.sf.net/ project) comes with minimal development aids. It is expected that the user will either already have a suitable set of tools for performing text editing, etc. or that you are willing and able to download various tools.
The standard development cycle for Tcl programs (that one plans on keeping) might be summarized:
start loop
end loop
Pretty discouraging state of the art, isn't it? Not much better than the old card punch days.
CL thinks it's important to say that it's not just that Tcl/Tk is defective in failing to integrate an IDE in the way someone coming from Delphi or Visual C++ might expect. Tcl/Tk programming is different from programming in those other languages, and has less need for an IDE. At some point in your Tcl programming career, try working with the language "on its own terms". Many of the most experienced Tcl developers find that a more satisfying approach than use of an IDE.
These comments are specific to Tcl in its technical development as of 2002 (say).
Very tangential, but deep, is Edsger Dijkstra's manifesto against "pictorialism".
This one [L1 ] or perhaps this [L2 ]?
However, it is only fair to ask in response if one could be more clear about what you mean when you say try working with the language "on its own terms"'.
What I have seen is that people who have years of experience typing in printf statements in C, etc. do not always appreciate the value of an fully interactive debugging environment with the ability to modify code dynamically during the execution of the program and then continuing, for example. For that matter, people used to using vi or some other vanilla text editor may not appreciate the value of syntax coloring, statement completion, etc.
DKF: Note that in really complex deployment environments (for example on a webserver where you don't have direct login access, though that's really not the most complex thing by a long country mile), setting a breakpoint in an IDE is of no use whatsoever. This is again true when you're hunting dynamic time-related faults. I also find that breakpoints tend to be of significantly less use with Tcl; they let you inspect things that you can trivially do without an IDE (the Tcl language core is much more stable than the average C or C++ program) and for that matter with Tcl I don't tend to make that sort of mistake so often.
LV One of the places where I most frequently have need for something more sophisticated than puts statements is in trying to help debug event based programming - with lots of events triggering all sorts of actions, with trying to figure out why some binding does what it is doing - and where the code is located - I find things to be very difficult to debug. I suspect that I would find multi-threaded applications to be difficult to debug as well.
Tcl has one great feature since the standard pure tcl-console is very cumbersome to use and for ready tcl-scripts is not necessary. It is the introspection capabilities of tcl. In tcl it is possible to redefine the procedure from the console and show it again on the console with ['info body procname']. In the fact the way of programming known from compiled languages that is:
can be with tcl easier. In tcl there is no need to reload all scripts and build runtime program-context after every program error but normal tcl-programmer do it.
The people who know Smalltalk know how powerful environments one builds by using the introspection possibility of the programming language. Most Tcl IDEs copy their IDEs functionality from compiled languages as C, C++, or Java. They bring some benefits in editing source and manage the program files.
XotclIDE is a new IDE that tries to work as Smalltalk environments. The XotclIDE user does not manage tcl-scripts, but views the tcl-interpreter-state and modifies it iteratively; all this by using tcl-introspection. At the end of programming-session the state of interpreter can be saved as tcl-packages. The interpreter-state can be optionally saved on the fly in a version-control database.
Also TclTalk is using introspection to present the interpreters state. Not supporting any OO extension yet, this IDE bets on namespaces for the purpose of encapsulation and tclkit as a basis for persistance of changes (image based computing). Tcltalk lets you replace its startup routine by your own to spawn itself to disk as a new starkit.
DKF - When people start moving beyond just coding their Tcl programs using Tcl and ready-built extensions, i.e. by creating their own extensions in C or some other compiled language, it is a good idea to add introspection code while you are at it. It isn't really all that difficult, and it makes debugging and interactive use so much easier.
LV Sounds like this concept would make a great page, or series of pages, demonstrating techniques.
Recently on comp.lang.tcl, Cameron Laird suggested that we should add to an appropriate wiki page something to the effect of:
"When you ask, 'which IDE is good?', and a bunch of bearded myopes give you answers like, 'emacs', understand that they're probably trying to be friendly. Their culture regards this as encouraging and supportive behavior. Eclipse and Visual Studio only make them furrow their brows, and they sincerely want to help you to a happier path." And so on.
Me, I edit more files with "cat >..." than Word and its relatives."
I admire that a full blown IDE is not necessary with Tcl. However, software development iterations lacks efficiency when using an editor and a Tcl interpreter as separate apps in the OS environment. I personally prefer an IDE to have an editor which allows it to start the script under edit and also allows me to update procs on the fly. For this purpose I'm using an editor written in Tcl. The write-debug iterations are very efficient. Just another thought: In ancient years there was BASIC, on Commodores and Apples and so on. The interpreter also provided a (simple) integrated program editor. Programs were started with the "run" command. It was this sort of working environment which I expected when I started with Tcl about 2 years ago. This thought hopefully explains another possible cause of "perplexing", when developers familiar with former interpreters come into touch with Tcl (indeed, I expected this in the beginning) --- RJM.
NEM I'd highly recommend tkcon for this sort of interactive development. The "edit" command allows you to pop up a simple text editor to edit proc definitions and then send them back to the interpreter. The hyper-linked errors, debugging facilities and attach to socket/interp etc are also very useful features which speed up development no end. The editor provided seems fairly basic, and it would be great if you could hook up your own favourite text editor for this, but everything works pretty well anyway. More support for saving procs to a file would be good too. RJM I checked the edit feature of tkcon. Its advantage is the integration with tkcon. I'll try to hook up my own (which is actually a modified ML (see Tcl Editors) ).
LES lifts his eyebrows and mumbles: hmm... Tkcon surely could use a little tips and tricks documentation...
LV Note that the tkcon page itself contains tips about using the tool. This is, in fact, the best way for wikis like this to grow. Keep the information relevant to a tool together, rather than spreading it all over the site.
AET Tkcon endorsed, but tips and tricks yes, please, a must. I used Tkcon on Linux just to try out code, only recently realizing the significance of all the good stuff it has. It is a workman's tool written by the tool users, so is visually unimpressive but tremendously useful. http://www.rhichome.bnl.gov/People/johannes/ActiveTcl8.4.3.0-html/tkcon/index.html has the (easily missed) admonition "Please read the following pages carefully . . ". The following URLs (except the screenshot) are vital and should be included for reference through a help menu from within the app.
I'll just give an example of an editing session. I am a rank amateur, so it's very simple (under Windows).
Start tkcon. I drag'n'drop tkcon.kit onto a tclkit.exe. Within tkcon, navigate to the development folder (note the nifty name completion using TAB!).
cd e:/y/z
Open the script (name completion again!)
edit myscript.tcl
Now I can leave that open while I mess with the script. Run the script
source myscript.tcl
I have put 'idebug break' at the end of each proc, so I can stop and see what's happening.
idebug on
To activate it. Now let's see where we are . . .
info command at::*
gives me only the procs in my namespace (defined as 'at' in the application) Now I run a proc that I'm working on. I double L-click on the LISTING (!) to select it, then middle button pastes it into the command line. Hit Enter. Oops. Tcl tells me that arguments should be supplied to the proc. I try again, adding the args. The proc runs.
V
Dumps the names and contents of all the variables for inspection.
q
quits idebug, and the proc returns its result. If there is an error, it is displayed, and I can L-click on it for a stack trace. Read and dismiss it with a CTRL-D.
R-click on the proc name (anywhere it shows on the command line) and choose view procedure
from the pop-up menu. An editor opens with only the proc and I make a correction. I save it back to the tkcon interactive session
ALT-S,S
and try it again, alternating between the editor and Tkcon until it's right. When I'm done, I go to the proc edit session, copy the contents
CTRL-Home Shift-CTRL-End CTRL-Insert
and paste it into the script window, overwriting the old proc select the old proc
Shift-Insert
Try not to forget to File>Save as to update the original script.
The delight of this is that the whole caboodle fits on a floppy disk, complete with developed scripts. Great for on-site scripting. The editor could do with some more features, but otherwise FANTASTIC.
Sarnold Just a word to mention that there are nice IDEs for writing programs in Tcl. In particular, see ased, which include tkcon, frink (a syntax checker) and works with Windows and Linux.
Ari: I was so frustrated that there is no basic IDE for TCL that I wrote two very basic BATCH files that will get the trick done.
You can accomplish the same thing by running a fraction of this code every time in the run command but I figured this might get the job done especially if you are a beginner and just playing around with "Hello World" TCL application. Though this program isn't much it can be really helpful to those newbies like myself.
Hard-coded file
Rem This program will run any TCL file in the "Programs" folder through a DOS IDE of the ActiveTCL machine Rem Note: Filename must be hard coded into this BATCH file Rem Create command line that will read this file: Rem "C:\...\Programs\<file name>" Rem Run it in here: Rem "C:\Tcl\bin\tclsh85.exe" Rem And then wait under you press enter to exit @echo off cls ECHO Program begins here... ECHO "<------------------>" ECHO. ECHO. Rem Set the file name of target TCL file to run Set filename=hello.tcl Rem Target TCL Engine Rem Example: Using ActiveTCL Set engine=c:\Tcl\bin\tclsh85.exe Rem Start folder where TCL file is located Set folderpath=C:\...\Programs\ Rem Run the TCL program via the engine %engine% %folderpath%%filename% ECHO. ECHO. ECHO "<------------------>" ECHO Program ends here... Rem Waiting for user to press a key to quit Pause
Passing parameter in RUN or command prompt
Rem This program will run any TCL file in the "Programs" folder through a DOS IDE of the ActiveTCL machine Rem Note: Must include filename in the the argument therefore it must be run in a command prompt (or Run) Rem Example: Run the code by going into command prompt and typing "TCLRun.bat hello.TCL" Rem Create command line that will read this file Rem "C:\...\Programs\<file name>" Rem Run it in here: Rem "C:\Tcl\bin\tclsh85.exe" Rem And then wait under you press enter to exit @echo off cls ECHO Running: %1 ECHO Program begins here... ECHO "<------------------>" ECHO. ECHO. Rem Target TCL Engine Rem Example: Using ActiveTCL set engine=c:\Tcl\bin\tclsh85.exe Rem Start folder where TCL file is located Set folderpath=C:\...\Programs\ Rem Run the TCL program via the engine %engine% %folderpath%%1 ECHO. ECHO. ECHO "<------------------>" ECHO Program ends here... Rem Waiting for user to press a key to quit Pause
Enjoy!
AMG: I suggest associating *.tcl files with tclsh85.exe.
aricb: I second that suggestion. Also, if you haven't tried using Tcl interactively, you should. See An Interactive Approach to Experimenting with Tcl for more info. In an interactive Tcl session, you can load a saved script using the [source] command.
Mysund - 2014-05-21 07:28:25
I personally find the lack of IDE a huge advantage. When i develop in Tcl/Tk, i use notepad for smaller things, and notepad++ for more complicated stuff. A simple trick that i find very usefull is to add a binding (e.g. bind <Control-r> "source main.tcl") in the end of the main source file, to a source command that reloads the main file. Obviously i start the main source file with destroying any toplevels, close any open files and sockets. Another trick i use is to add another binding (e.g. bind <Control-l> "console show") for showing the console, so when the program is running, i can access the console, inspect variables, check status of files sockets, see any debugging/log statement, that i left in the program/script.