Software development approaches
Tcl is a "late-binding dynamic" programming language, which is fancy way of saying that everything happens at run time. Unlike C, C++, Java, and C#, for example, there is no explicit compilation. You can think of JeeMon as a system which understands Tcl source code directly, and which loads files as is.
This is the same as with Lua, Python, Ruby, Perl, and a whole slew of other "scripting languages". It could be summarized as: not having to compile code.
This has many implications for how software development takes place.
The other aspect which matters in this context, is that JeeMon applications are often intended to run forever: a web server accessed via a browser, interfacing with a variety of physical computing devices, performing all sorts of one-shot and periodic background tasks, and interacting with the outside world in real-time.
The traditional approach of an edit - compile - run - test - debug - quit cycle is not always practical here. But fortunately, there are several alternatives.
Command line
Although the edit ... quit cycle is often not suitable, this still works well for some cases, such as using JeeMon as a command-line tool, or writing a small test case to develop some new code in isolation. The simplest way to do so is to create a source file such as "myprog.tcl" with commands that need to be run, and then the whole thing stops again as the end of the script is reached.
For this, you can use any programmer's editor and the command line, using:
jeemon myprog,tcl
By inserting "puts" comands (or "Log" calls) in your code, you can have it report what's going in, and generate results on the standard console output. This is the classical terminal / shell / command-line model. It works fine.
TkCon
TkCon is a Tclk/Tk script written by Jeff Hobbs, which creates a GUI-based terminal window with a range of features that make interactive use much more convenient: command completion, command history, copy and paste, scrollback, and multiple interpreters each running in their own window - to name a few.
Using TkCon is simple: download a copy of it, which is a single file called ... "tkcon.tcl", and then you can launch it from JeeMon using the command:
jeemon tkcon.tcl
Apart from minor differences such as fonts, this works identically across Windows, Mac OSX, and Linux - which in itself is already a nice advantage if you need to work on a variety of systems.
TkCon w/ attach
But that's really just scratching the durface of what TkCon can do. One very useful feature is that TkCon can act as console for another process running JeeMon (if that pricess has been set up properly). This means that you can have a long-running JeeMon system (web server, home automation system, whatever) and use a separate TkCon process to temporarily hook into it and act as console almost exactly as if it had been started with such a console in the first place.
To do this, the long-running process needs to be set up to allow access:
Console start 7171
This creates a listening socket, which accepts incoming TkCon sessions on port 7171. Now at any point in time, a separate TkCon can "attach" to the long-running process (see the "Attach To..." item in TkCon's "Console" menu).
It allows you to look inside a process and be inside that process, and since it's based on sockets, these attached sessions also work across the network. One use of this would be to launch TkCon locally on your desktop, and then attach to a small Linux box elsewhere, running JeeMon - such as perhaps that always-on home automation server.
Note that this lets you do just about anything - i.e. not only viewing current variables, but even changing theur value, calling any proc in anny namspace you want, and even add or re-define code in the running process.
For some cases, this sort of debugging capability can be incredibly useful, because you don't have to stop the process. So you could look at it from inside to investigate why it's not functioning as expected in one specific aspect.
Peek
Another mechanism I've been slowly expanding over the years is based on peeking inside a running process through the web browser. All it takes is to load the Peek rig using the following line and peeking will be enabled:
Jm needs Peek
Now the web server - which is presumably already being used bt the application itself - will also respond to request URLs of the form "/peek" (and "/peek/..."). The peek-demo example in JeeRev shows a minimal example of this approach.
With Peek, you get access to all the variables, arrays, procs, objects, namespaces, and much more. This is only for inspection, but it's great for investigating a running process because a lot of information is available with just a few mouse clicks in the browser. Furthermore, you can save bookmarks of specific explorations and quickly get back to that information later on.
Live re-loading
One of the newer techniques introduced to JeeMon, is to allow reloading source code in a running project. This is one of the benefits which came from the introduction of modular file-based "rigs. There are limits to this approach, but the idea is that you can launch a long-running process which loads a whole bunch of source code from file, and then later edit a rig's source file and have it re-loaded into the running process.
This differs fundamentally from the "TkCon w/ attach" approach described earlier, in that changes end up where they should, i.e. in the source code as well as in the running process, whereas direct changes via an attached TkCon process will only change the running process. When stopped and re-started, the original unmodified source code will be loaded again.
There is a case to be made for both - sometimes you just want to try out something, i.e. briefly add a quick check or print out a value, and sometimes you want to make changes which are intended to become permanent, i.e. further development.
Live reloading is performed by calling the following command:
Jm reloadRigs
(note that you could type this into an attached TkCon, if you wanted to)
Reloading is fairly optimized: only changed source files get reloaded, and only if they have already been loaded, so reloading efficiency is mostly proportional to the amount of change, not the total size of all source code.
But the real trick is that this live reloading will automatically be done at the start of each page refresh in the web browser (at least in development mode). So if your long-running process has a bug, and you know exactly how to fix it, then all you need to do is edit the rig's source file, save it, and hit "refresh" in the browser.
The productivity gains from this mechanism cannot be overstated. It feels almost like editing a live application. This gain comes from the fact that you don't have to leave your current context - no matter where you are in your application (i.e. on some page in its web server) - simply edit, save, refresh, and the change will be in place.
There are some very subtle limitations with live reloading. As of Nov 2011, the most tricky issue seems to be that code changes don't always lead to all the right bits and pieces being replaced (html page templates being re-generated, for example). That's why traditional starting and stopping is still needed, especially when applying large changes all over the place.
But for simple tweaking tasks, which often end up taking a lot of time, live reloading works great.