Dr. Dobb's Tcl-URL! - weekly Tcl news and links (Dec 10)

sheila miguez herndon

unread,

Dec 9, 2004, 10:08:05 PM12/9/04

to

QOTW: "... everything that's happened in Office since about 1995 has been
more or less user interface churn. " -- Joel Spolsky, former Excel program
manager
http://www.salon.com/tech/feature/2004/12/09/spolsky/index2.html

"I still think the best *general* advice to newbies is to get comfortable
with Tkcon." -- Roy "debugger free for 5 years" Terry

To Kick off this week's Tcl-URLs, discussions on GUI management:

Thanks to Arjen Markus for his report from the Wiki(s):
We are well on our way into December now and the Wiki continues
showing its usual potpourri of subjects ... So here we are, picking
a haphazard bouquet!

Functional programming
- Going back to - perhaps - the source, Richard Suchenwirth reports
about John Backus - <http://wiki.tcl.tk.13125>. It is but one page
on the subject of functional programming ...

- With all the attention for implementing functional programming in Tcl,
one might forget a functional programming language needs a GUI toolkit
too - <http://wiki.tcl.tk/13109> presents one

- There is nothing truly magic about it, but you might think it is,
TclMagick does wonderful things to your pictures -
<http://wiki.tcl.tk/9775>

Random numbers
- Every so often people need a random number or two - and there are many
ways to produce them. The problem is there are only a few good ways.
<http://wiki.tcl.tk/13120> discusses this exotic realm.

- Every so often people don't need random digits trailing at the end of
their results. Will BigFloat be a solution to push these renegades
over the edge? <http://wiki.tcl.tk/13107> promises at least more
digits!

Old friends
- An update for an old scripted widget: enter dates according to your
own conventions - <http:/wiki.tcl.tk/3019>

- A game was lost and this led to ... the same game! Find this
resurrected solitaire on <http://wiki.tcl.tk/13092>

Everything Tcl-related you want is probably one or two clicks away in these
pages:
The "Welcome to comp.lang.tcl" message by Andreas Kupries
http://www.purl.org/net/tcl-welcome

The Tcl Developer Site is Tcl's "home base".
http://www.tcl.tk

Larry Virden maintains a comp.lang.tcl FAQ launcher.
http://www.purl.org/NET/Tcl-FAQ/

The Tcl Developer Xchange is a highly organized resource center
of documents and software with provisions for individuals to
maintain references to their own software:
http://www.tcl.tk/resource/
The TDX sponsor, ActiveState, also keeps info to convince your
boss Tcl is a good thing
http://www.tcl.tk/scripting/

The Tcl'ers Wiki is a huge, dynamic, collaboratively edited repository
of documentation, examples, tutorials and pontifications on all things
Tcl.
http://wiki.tcl.tk/0
For the ideal overview of the topics about Tcl most likely to
interest a newcomer, see "Arts and Crafts ..."
http://wiki.tcl.tk/969

ActiveState maintains binaries distribution and development tools
http://www.activestate.com/Tcl
along with a Cookbook of Tcl recipes
http://aspn.activestate.com/ASPN/Cookbook/Tcl

Cameron Laird tracks several Tcl/Tk references of interest
http://phaseit.net/claird/comp.lang.tcl/

Cetus Links maintains a Tcl/Tk page with verified links
http://www.cetus-links.org/oo_tcl_tk.html

"Yahoo! Groups" archives comp.lang.tcl.announce posts
http://groups.yahoo.com/group/tcl_announce/

Previous - (U)se the (R)esource, (L)uke! - messages are listed here:
http://www.ddj.com/topics/tclurl/
An alternative is
http://groups.google.com/groups?oi=djq&as_q=+Tcl-URL&as_ugroup=comp.lang.tcl

Suggestions/corrections for next week's posting are always welcome.

To receive a new issue of this posting in e-mail each Monday, ask
<cla...@phaseit.net> to subscribe. Be sure to mention "Tcl-URL!".
--
Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and
sponsor the "Tcl-URL!" project.

lvi...@gmail.com

unread,

Dec 10, 2004, 7:54:19 AM12/10/04

to

According to sheila miguez herndon <tcl...@phaseit.net>:
:"I still think the best *general* advice to newbies is to get comfortable

:with Tkcon." -- Roy "debugger free for 5 years" Terry

This advice would be easier to do if the old timers would write up
some examples of how they use tkcon to debug. I've yet to figure out
the trick, and I've been using Tcl for more than 10 yrs...

--
<URL: http://wiki.tcl.tk/> MP3 ID tag repair < http://www.fixtunes.com/?C=17038 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >

cne...@nycap.rr.com

unread,

Dec 10, 2004, 8:23:57 AM12/10/04

to

> This advice would be easier to do if the old timers would write up
> some examples of how they use tkcon to debug. I've yet to figure out
> the trick, and I've been using Tcl for more than 10 yrs...

Isn't it amazing how we all keep certain blind spots? I can spend
hours programming hundreds of lines of Tcl with all sorts of wonderful,
language-specific nuance and yet certain things I just don't try or I
have to refer to documentation to get straight.
.
. Chris

Jeff Hobbs

unread,

Dec 10, 2004, 11:57:10 AM12/10/04

to lvi...@gmail.com

lvi...@gmail.com wrote:

> According to sheila miguez herndon <tcl...@phaseit.net>:
> :"I still think the best *general* advice to newbies is to get comfortable
> :with Tkcon." -- Roy "debugger free for 5 years" Terry
>
> This advice would be easier to do if the old timers would write up
> some examples of how they use tkcon to debug. I've yet to figure out
> the trick, and I've been using Tcl for more than 10 yrs...

I know I wrote up a post about various debugging tools to some
list (or clt) or wiki at some point ... I think the wiki. I've
already forgotten where though. :/

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

lvi...@gmail.com

unread,

Dec 10, 2004, 12:38:37 PM12/10/04

to

According to Jeff Hobbs <je...@removethis.activestate.com>:

:lvi...@gmail.com wrote:
:
:> According to sheila miguez herndon <tcl...@phaseit.net>:
:> :"I still think the best *general* advice to newbies is to get comfortable
:> :with Tkcon." -- Roy "debugger free for 5 years" Terry
:>
:> This advice would be easier to do if the old timers would write up
:> some examples of how they use tkcon to debug. I've yet to figure out
:> the trick, and I've been using Tcl for more than 10 yrs...
:
:I know I wrote up a post about various debugging tools to some
:list (or clt) or wiki at some point ... I think the wiki. I've
:already forgotten where though. :/

Good tip - after reading your msg, I checked http://wiki.tcl.tk/tkcon and
found that some kind soul copied the info over there.

Ramon Ribó

unread,

Dec 10, 2004, 12:56:19 PM12/10/04

to

Hello,

I am also a fan of Tkcon as it is really useful for fast tests. Also,
sometimes
the best debugging technique is the so-called "John Wayne style", filling
the
code with "puts" and print what is happening inside your code.

But many times, a real debugger permmits to save a lot of time to arrive
to
the same solution. It is just to spend the (short) time necessary to get
used to
the program. Try RamDebugger (http://wiki.tcl.tk/RamDebugger) or another
of the debuggers in http://wiki.tcl.tk/8637 and play a little bit with it.

Roy, I'd like that some day you could change your name to:

Roy "after 5 years I've seen the light in debugging" Terry

Regards,

--
Ramon Ribó
http://gatxan.cimne.upc.es/ramsan

<lvi...@gmail.com> escribió en el mensaje
news:cpc69r$eu1$1...@srv38.cas.org...

Cameron Laird

unread,

Dec 10, 2004, 4:08:04 PM12/10/04

to

In article <7rlud.4274778$A6.13...@telenews.teleline.es>,

Ramon Ribó <ram...@cimne.upc.es> wrote:
> Hello,
>
> I am also a fan of Tkcon as it is really useful for fast tests. Also,
>sometimes
>the best debugging technique is the so-called "John Wayne style", filling
>the
>code with "puts" and print what is happening inside your code.

.
[serious and
pertinent points]
.
.
I feel a cultural insight coming on: Ramon (where are the
accents on this keyboard? That's a question for me, not
you), do you have an exegesis for that rubric? Does "fill
the source with [puts]" remind you of Duke's crude philo-
sophy, or verbal style, or ...?

Frank Pilhofer

unread,

Dec 10, 2004, 6:29:33 PM12/10/04

to

lvi...@gmail.com <lvi...@gmail.com> wrote:
>
> This advice would be easier to do if the old timers would write up
> some examples of how they use tkcon to debug. I've yet to figure out
> the trick, and I've been using Tcl for more than 10 yrs...
>

Not exactly a debugging tool, but one of my favorite tools for rapid
prototyping are the "Reload" and "Refresh" features that I add to all
of my Tcl software. Bound to keys of my choice, they look like,

proc Reload {} {
source $::argv0
}

proc Refresh {} {
foreach widget [winfo children .] {
destroy $widget
}
SetupUI
RebuildUI
}

So, if I notice a bug in my code, I can fix it in an external editor,
and hit the "Reload" button. If that bug involves the user interface,
I hit the "Refresh" button to destroy and recreate the main toplevel
window.

For this to work,

- UI setup must be done in a proc "SetupUI", rather than on "global"
level.

- Global state must be protected against "Reload", so that it is not
re-initialized; e.g., protected by

if {![info exist ::init]} {
# initialize state
}
set ::init 1

- There must be a proc "RebuildUI" that populates the UI from the
global state.

Neither of this is hard to achieve, and it helps tremendously. This
way, you don't have to re-start your software from a cold state after
noticing and fixing a problem.

Of course, there are some cases where Reload/Refresh doesn't help,
like if the global state is corrupted, but as a developer, you will
be aware of that, and that's where interaction via Tkcon comes in.

Have fun,

Frank

--
Frank Pilhofer ........................................... f...@fpx.de
Today, money still talks. Trouble is, you have to increase the
volume a lot! - Alfred E. Neuman

David N. Welton

unread,

Dec 10, 2004, 6:36:55 PM12/10/04

to

Frank Pilhofer <f...@fpx.de> writes:

> lvi...@gmail.com <lvi...@gmail.com> wrote:
> >
> > This advice would be easier to do if the old timers would write up
> > some examples of how they use tkcon to debug. I've yet to figure out
> > the trick, and I've been using Tcl for more than 10 yrs...
> >
>
> Not exactly a debugging tool, but one of my favorite tools for rapid
> prototyping are the "Reload" and "Refresh" features that I add to all
> of my Tcl software. Bound to keys of my choice, they look like,
>
> proc Reload {} {
> source $::argv0
> }
>
> proc Refresh {} {
> foreach widget [winfo children .] {
> destroy $widget
> }
> SetupUI
> RebuildUI
> }

Yes, this is indeed a cool trick. You can use it for server software
as well. You have something like this:

while {1} {
source mainfile.tcl
}

and mainfile.tcl contains all the server code. All you have to do to
reload things is include a special command that triggers the vwait (or
whatever else mainfile.tcl waits on) - at that point, mainfile.tcl
evaluation stops and control returns to the endless loop, which loads
up your mainfile again.

There is an example of this in the tcllib example code for the irc
package. You can change and reload the code without ever
disconnecting the system from the internet.

--
David N. Welton
Personal: http://www.dedasys.com/davidw/
Apache Tcl: http://tcl.apache.org/
Free Software: http://www.dedasys.com/freesoftware/
Linux Incompatibility List: http://www.leenooks.com/

Ramon Ribó

unread,

Dec 11, 2004, 6:08:16 AM12/11/04

to

Cameron,

The name "John Wayne style" for this type of debugging is not my invention.
I just took
it from somewhere. I think it refers to the idea that this kind of debugging
is crude, not
at all sophisticated, even primitive, but effective. At least as effective
as making the
badness dissapear by just killing all the "bad guys", like in western
movies.

Regards,

--
Ramon Ribó
http://gatxan.cimne.upc.es/ramsan

"Cameron Laird" <cla...@lairds.us> escribió en el mensaje
news:6hfp82-...@lairds.us...

keithv

unread,

Dec 11, 2004, 10:38:09 AM12/11/04

to

Frank Pilhofer wrote:
> Not exactly a debugging tool, but one of my favorite tools for rapid
> prototyping are the "Reload" and "Refresh" features that I add to all
> of my Tcl software.

I do the exact same thing except that I have the reload code
reset the state of the world back to its original state. It
deletes all child windows, resets images, fonts, bindings, etc.
and cleans up global variables and procedures. This way I don't
need any special coding conventions.

The code to reset the console can be found at
http://mini.net/tcl/RestartingATkconApplication.

Keith

Jeff Hobbs

unread,

Dec 11, 2004, 11:26:21 AM12/11/04

to keithv

keithv wrote:

Now that tkcon has tabbed consoles, I'd say the easiest is to
create another tab, delete the current tab, and go on with
what you were doing - pristine state (modulo tkcon basics)
guaranteed! :)

Arjen Markus

unread,

Dec 13, 2004, 3:26:22 AM12/13/04

to

"Ramon Ribó" wrote:
>
> Cameron,
>
> The name "John Wayne style" for this type of debugging is not my invention.
> I just took
> it from somewhere. I think it refers to the idea that this kind of debugging
> is crude, not
> at all sophisticated, even primitive, but effective. At least as effective
> as making the
> badness dissapear by just killing all the "bad guys", like in western
> movies.
>

Sometimes, especially if the bug is hiding in a loop with several
hundreds
or thousands iterations, it is the only practical solution.

A worse case that comes to mind was one where the same static variable
was not really, truly the same in the various subroutines - a dirty
trick caused by static and dynamic libraries being mixed in the wrong
way. My only method of solving that one was to print all pointers at
several locations in the program and then stare at the printout in awe!

But, I agree, an interactive debugger often helps and then it seems
a more elegant tool.

Regards,

Arjen

lvi...@gmail.com

unread,

Dec 13, 2004, 7:56:31 AM12/13/04

to

According to Frank Pilhofer <f...@fpx.de>:
: So, if I notice a bug in my code, I can fix it in an external editor,

:and hit the "Reload" button. If that bug involves the user interface,
:I hit the "Refresh" button to destroy and recreate the main toplevel
:window.
:
: For this to work,
:
:- UI setup must be done in a proc "SetupUI", rather than on "global"
: level.
:
:- Global state must be protected against "Reload", so that it is not
: re-initialized; e.g., protected by
:
: if {![info exist ::init]} {
: # initialize state
: }
: set ::init 1
:
:- There must be a proc "RebuildUI" that populates the UI from the
: global state.

You also have to make certain that you have a way to destroy anything
that the functions need to create - widgets, etc. - in a way that they
can then be recreated. But that's obvious I guess. Just not trivial.

tony summerfelt

unread,

Dec 24, 2004, 2:57:30 PM12/24/04

to

On Fri, 10 Dec 2004 at 17:56 GMT, Ramon Ribó <ram...@cimne.upc.es> wrote:

> the program. Try RamDebugger (http://wiki.tcl.tk/RamDebugger) or another

could be i'm missing something really obvious...

whenever i try to debug a program with ramdebugger 4.4 (usking tcl/tk
v8.5a1)

hitting F11 for 'step' runs the tcl script to the end...

--
http://home.cogeco.ca/~tsummerfelt1

Daniel South

unread,

Dec 26, 2004, 6:27:58 AM12/26/04

to

tony summerfelt wrote:
| On Fri, 10 Dec 2004 at 17:56 GMT, Ramon Ribó <ram...@cimne.upc.es>
| wrote:
|
|| the program. Try RamDebugger (http://wiki.tcl.tk/RamDebugger) or
|| another
|
| could be i'm missing something really obvious...
|
| whenever i try to debug a program with ramdebugger 4.4 (usking tcl/tk
| v8.5a1)
|
| hitting F11 for 'step' runs the tcl script to the end...

You need to set a breakpoint at the start of your script.

--
Daniel South

Ramon Ribó

unread,

Dec 27, 2004, 3:56:33 AM12/27/04

to

Hello,

Some advices for debugging.

Before doing a "next" or "step" you must stop the debugging. Normally
by setting a breakpoint somewhere in your code. Then, the proc to enter
with the "step" should be in a file that you have loaded inside RamDebugger.

Regards,

--
Ramon Ribó
http://gatxan.cimne.upc.es/ramsan

"tony summerfelt" <snow...@hotmail.com> escribió en el mensaje
news:Kw_yd.792$Y_4.2...@read2.cgocable.net...

tony summerfelt

unread,

Jan 1, 2005, 2:19:20 PM1/1/05

to

On Mon, 27 Dec 2004 at 08:56 GMT, Ramon Ribó <ram...@cimne.upc.es> wrote:

> Before doing a "next" or "step" you must stop the debugging. Normally
> by setting a breakpoint somewhere in your code. Then, the proc to enter
> with the "step" should be in a file that you have loaded inside RamDebugger.

ah, that was probably in the docs which is why i missed it :)

thanks for everyone's answers...

--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org