Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Does Tcl support recursion

433 views
Skip to first unread message

maura.m...@gmail.com

unread,
Jun 8, 2006, 7:01:46 AM6/8/06
to
The problem I'm trying to solve is to add a new feature to the existing
GUI to allows users to arbitrarily rescale the currently displayed
histogram data.
I've just found out that the histogram data, accessed by the CERNLIB
interface, are still in the priogram memory after displaying.
Renormalizaing the data is a trivial task. But redrawing the whole
thing (the colors-bar mapped to the dara range decades = powers of 10,
and the color mapped histogram data) is not trivial to me.
I'd like to avoid duplicating all the code that takes care of
generating the color bitmap out of the histogram data and the color bar
showing the color-mapped decades.
Since the user enters the new normalization value in the textvariable
field associated to an ENTRY, it would be easier, thanks to all your
explanations, to detect such a normalization change by sensitizing the
textfield and go from there. But the GUI I'm dealing with has a button
labelled "Draw:" that the user has to click on in order to finalize any
new entered value. Therefore my supervisor wants me to stick to this
pre-existing logic. The problem is that the Draw button is associated
to a command that launches the "draw_camvas" procedure which is called
from different contexts, not just from histogram data visualization
only.
But "draw_canvas" is also the main procedure I have to use to redraw
the histogram color-map.
I'm wondering whether in Tcl I can do something like:

proc_A --> call proc_B --> call proc_A

obviously playing carefully with some status flag to avoid an endless
loop ...

Thank you in advance for your help.

Maura

suchenwi

unread,
Jun 8, 2006, 7:10:10 AM6/8/06
to
Yes (up to a os-dependent maximum depth, on Windows roughly 500). See
http://wiki.tcl.tk/recursion

George Petasis

unread,
Jun 8, 2006, 7:28:20 AM6/8/06
to suchenwi
O/H suchenwi έγραψε:

According to the Tcl manual, by default the recursion limit is 1000.
Can be changed from the C level, with Tcl_SetRecursionLimit.

George

Eckhard Lehmann

unread,
Jun 8, 2006, 7:30:09 AM6/8/06
to

maura.m...@gmail.com wrote:
> The problem I'm trying to solve is to add a new feature to the existing
> GUI to allows users to arbitrarily rescale the currently displayed
> histogram data.
> I've just found out that the histogram data, accessed by the CERNLIB
> interface, are still in the priogram memory after displaying.
> Renormalizaing the data is a trivial task. But redrawing the whole
> thing (the colors-bar mapped to the dara range decades = powers of 10,
> and the color mapped histogram data) is not trivial to me.
> I'd like to avoid duplicating all the code that takes care of
> generating the color bitmap out of the histogram data and the color bar
> showing the color-mapped decades.
> Since the user enters the new normalization value in the textvariable
> field associated to an ENTRY, it would be easier, thanks to all your
> explanations, to detect such a normalization change by sensitizing the
> textfield and go from there. But the GUI I'm dealing with has a button
> labelled "Draw:" that the user has to click on in order to finalize any
> new entered value. Therefore my supervisor wants me to stick to this
> pre-existing logic. The problem is that the Draw button is associated
> to a command that launches the "draw_camvas" procedure which is called
> from different contexts, not just from histogram data visualization
> only.
> But "draw_canvas" is also the main procedure I have to use to redraw
> the histogram color-map.

Sure, Tcl supports recursion - but it seems to me that it is not what
you're looking for...

I'd recommend to create a second callback that does the preprocessing
so that [draw_canvas] can be called safely. Then, call [draw_canvas]
from there:

proc process_parameters {} {
...
draw_canvas
}

This is the new callback for the Draw button.


Eckhard

suchenwi

unread,
Jun 8, 2006, 7:54:26 AM6/8/06
to

George Petasis schrieb:

> According to the Tcl manual, by default the recursion limit is 1000.
> Can be changed from the C level, with Tcl_SetRecursionLimit.

SuchRich@KSTBWP74[/etc/frip]504:tclsh
% proc f x {puts $x; f [incr x]}
% f 1
1
...
872
873
too many nested evaluations (infinite loop?)
% interp recursionlimit {} 10000
10000
1
...
879
880
too many nested evaluations (infinite loop?)

So 500 was wrong, but on Win XP there are limits that can't be just
reconfigured.

Cameron Laird

unread,
Jun 8, 2006, 7:50:28 AM6/8/06
to
In article <1149764506.5...@c74g2000cwc.googlegroups.com>,

maura.m...@gmail.com <maura.m...@gmail.com> wrote:
>The problem I'm trying to solve is to add a new feature to the existing
>GUI to allows users to arbitrarily rescale the currently displayed
>histogram data.
.
.

.
>But "draw_canvas" is also the main procedure I have to use to redraw
>the histogram color-map.
>I'm wondering whether in Tcl I can do something like:
>
> proc_A --> call proc_B --> call proc_A
>
>obviously playing carefully with some status flag to avoid an endless
>loop ...
.
.
.
While Tcl is utterly cheerful about recursion, the diagram
you have above usually indicates that a wise refactoring is
nearby, one that transforms the design into

proc_A' -> proc_B' -> proc_A0

where A' and A0 partition the old A.

George Petasis

unread,
Jun 8, 2006, 8:24:12 AM6/8/06
to suchenwi
O/H suchenwi έγραψε:
Not just windows, but in all operating systems there are limits
regarding the stack size of the application. The exact numbers depend
on how the OS configures these limits (i.e. in my XP professional
installation, I don't reach the limits you mention but slightly
lower...). I think there is a small discussion about this in the manual.
You have to increase the stack size if you plan to perform recursion of
such depth.

George

Donal K. Fellows

unread,
Jun 8, 2006, 10:34:37 AM6/8/06
to
suchenwi wrote:
> Yes (up to a os-dependent maximum depth, on Windows roughly 500). See
> http://wiki.tcl.tk/recursion

There are two limits. One is imposed by the Tcl interpreter and can be
configured to any depth you like using [interp recursionlimit], but the
other is imposed by the Tcl core to stop the C stack from blowing up and
the app from dumping core. Raising that limit depends on twiddling OS
parameters, and not on things you can change easily from Tcl...

Donal.

0 new messages