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: * How do I write Tcl programs? * How do I run Tcl programs? * How do I debug Tcl programs? * Where do I find useful Tcl or Tk widgets? * How do I compile Tcl, Tk, or some extension? 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: 1. Start up a text editor. 1. Write your Tcl code. 1. Save the Tcl code to a file. 1. Start up a Tcl interpreter. start loop 1. Using the Tcl 'source' command, source in the Tcl code. 1. Invoke Tcl procedure, if your Tcl code file doesn't already do that. 1. If the program works as expected, you are done. Exit loop 1. Otherwise, edit the Tcl code. Perhaps add puts statements, or some other type of debugging code. 1. Clear out interpreter, deleting old variables, etc. 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 [http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD696.PDF] or perhaps this [http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD991.PDF]? ---- 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. ---- Tcl has a one great future that in standard pure tcl-console is very cumbersome to use and for ready tcl-scripts is not nessesary. 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 programing known from compiled languages that is: 1. edit your script in editor 1. run it 1. show if it crashes or work good 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-programer do it. The people who know '[Smalltalk]' know how powerfull environments can one build by using introspection posibbility of program-language. The most Tcl-IDE copy the IDEs-functionality from compiled languages as [C],[C++],[Java]. They bring some benefits in editing source and manage the programm files. [XotclIDE] is the new IDE that tries to work as Smalltalk envirorments. XotclIDE-user does not manage some 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 optionaly saved on the flow in version-control database. ---- ''[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. ---- 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 it 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...'' [AET] '''Tkcon endorsed''', but tips and tricks yes, please, a must. I used Tkcon on Linux just to try out code, only recently realising the significance of all the good stuff it has. It is a workmans 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. 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 CNTRL-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 CNTRL-Home Shift-CNTRL-End CNTRL-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'''. ---- [Category Dev. Tools]