From: Davy on
Hi all,

I use NC-Sim Tcl command (like "stop") and found Tcl script is
white-space sensitive. And I have to wait for the Tcl report error in
run time and time-consuming. Can I debug/lint the Tcl script before run
all the simulation? Thanks!

Or is there something like Perl's "use strict" and "use warnings" in
Tcl? That I can write robust Tcl file in NC-Sim.

Thanks!
Davy

From: Peter Spjuth on
> I use NC-Sim Tcl command (like "stop") and found Tcl script is
> white-space sensitive. And I have to wait for the Tcl report error in
> run time and time-consuming. Can I debug/lint the Tcl script before run
> all the simulation? Thanks!
>
> Or is there something like Perl's "use strict" and "use warnings" in
> Tcl? That I can write robust Tcl file in NC-Sim.

Even if I don't use NC-Sim (we have ModelSim) I recognise your problem.
To help me check simulation and synthesis scripts before I start a long
run I wrote a Tcl syntax checker which later became "Nagelfar".

You can find it at http://nagelfar.berlios.de

/Peter

From: Davy on

Peter Spjuth wrote:
> > I use NC-Sim Tcl command (like "stop") and found Tcl script is
> > white-space sensitive. And I have to wait for the Tcl report error in
> > run time and time-consuming. Can I debug/lint the Tcl script before run
> > all the simulation? Thanks!
> >
> > Or is there something like Perl's "use strict" and "use warnings" in
> > Tcl? That I can write robust Tcl file in NC-Sim.
>
> Even if I don't use NC-Sim (we have ModelSim) I recognise your problem.
> To help me check simulation and synthesis scripts before I start a long
> run I wrote a Tcl syntax checker which later became "Nagelfar".
>
[snip]
Hi Peter,

I notice "Naturally Nagelfar expects the coding style of its author so
if you do things differently, you may get false errors. "

Can you recommend the coding style used by Nagelfar?

Thanks!
Davy

> You can find it at http://nagelfar.berlios.de
>
> /Peter

From: Donal K. Fellows on
Svenn Bjerkem wrote:
> Tcl is developed a bit different than perl scripts since perl scripts
> are compiled before they are run. Tcl scripts are evaluated in a two
> pass algorithm (first time substitution then execution) and so you can
> generate code dynamically which cannot be checked by a static linter.

Actually, most of your script is compiled. (It's just a few parts that
aren't compiled these days, not that you can see the seams.) But the
exact nature of what faults are detectable is different between the two
languages; Tcl's dynamism is deeper rooted which makes for different
trade-offs, one of which being that syntax checking at compile time is
much harder.

> The most common mistakes with missing spaces and braces and linefeeds
> are an indication that one have to practice more with pure Tcl to get a
> grip on the language.

Tcl programmers are much more likely than Perl programmers to use the
language interactively. It's a large part of what makes for the
difference in styles, since we usually prototype our code much earlier
in the development process. Tcl scripts (or at least my Tcl scripts)
tend to be distillations of interactive sessions. :-)

Donal.
From: suchenwi on
Davy schrieb:

> I have download a ActiveState Tcl tool. TkCon seems to be a
> line-by-line Tcl interprator. Do you mean enter the line of code to
> TkCon? Then run, and copy them out?

It's a very quick and convenient way to test. For instance, here's
transcript of a short tclsh session in which I wanted to look at error
message formatting:
% namespace eval foo {}
% proc foo::f x {expr {$x/0}}
% proc foo::g x {f $x}
% g 42
ambiguous command name "g": gets glob global
% foo::g 42
divide by zero
% set errorInfo
divide by zero
while executing
"expr {$x/0}"
(procedure "f" line 1)
invoked from within
"f $x"
(procedure "foo::g" line 1)
invoked from within
"foo::g 42"
% exit
But you can of course also edit script files, and run them like this:
$ tclsh myfile.tcl

> You mention a way to define a dummy proc to emulate the core function
> in something like NC-Sim. But it seems the core function has a lot of
> input. Shall I emulate all the input and output?

For a first shot, just to get something running, you can use the "args"
argument to a proc that will contain all its arguments:

proc myMain args {puts "called myMain with [llength $args] args";
return 42}

For refined testing, you then can go analyze what came in in the
arguments, and return something more interesting...

> PS, IMHO, I like Perl more than Tcl :)
Matter of taste, of course...