SDR 21 May 2006

Interested to find out if there any convertors from Pascal code to Tcl code available.

I have some Pascal code that needs to be converted to Tcl and maybe I should learn Pascal code, but I'm too lazy (and not smart enough) for that.

Larry Smith You may find run to be some help. In the example you will find a demo of a pascal-like translator for Tcl that, with some work, might be just what you want.

I would assume any automatic conversion of code would be riddled with problems, but if the code is converted to Tcl I can then find the bugs easier.

Any suggestions?

AM (22 may 2006) I do not know enough of Pascal to help out, but I have experience with similar translations from Fortran. My strategy would be:

  • Replace all the keywords by their Tcl equivalents (use [string map] for that)
  • Convert the assignments (a=b and the like) to set-statements, using [regsub]
  • Find other general edits that take very little Tcl code to implement
  • Edit the resulting code manually

If there is no automatic conversion tool, and that is very likely the case, then the above steps at least get rid of the more tedious bits of conversion.

aa I think Pascal is among the easiest languages to read. If it's not been made unreasonably complex by the programmer, you basically need only to know that begin and end surround blocks of code. My suggestion is to do it the "right" way: look at what the Pascal code is intended to do and write new Tcl code to do the same thing. Tcl has rather different strengths from Pascal, so a direct translation is probably not going to be the best route.

Lars H: I agree with aa, but thought I should mention that one of my long time programming projects involves a translator from Pascal (actually Web, which is a pascal-with-preprocessor) to C, which I of course want to code in Tcl. The current (June 2005 -- May 2006) state is that it can tokenise everything and parse definition parts, but not statement parts (except to see where they begin and end). If you seriously don't want to do it the right way (as aa explained) then you might want to write me a line.

FM : Maybe this link should be obvious here : Like C, Pascal can access to a tcl interpreter, see .

wdb Being mainly a Tcler, I prefer to outsource number-crunching to some compiled language. I like Pascal more than C (because it is closer to a scripting language). I intend to do it via pipes. How can Tcl detect that a program connected via pipe is crashed?

(2 days later) wdb again -- Principally seen, communication Tcl <-> FreePascal via Fifo works if you care that write operations in FreePascal should be done explicitly with writeln(stdout, str), then don't forget to do a flush(stdout) after each output line. (Additionally, I got some other weird misbehavings, but that's another subject.)

(another day later) wdb -- First test proves that it's worth the efforts. Calculate cutting fractions of two bezier curves, where curveCutCurve is written in pure Tcl, and bezierCutBezier just calls external calcHelp via Fifo:

% time "curveCutCurve {10 10 10 100 100 100 100 10} {60 60 60 150 150 150 150 60}" 10
257056.4 microseconds per iteration
% time "bezierCutBezier 10 10 10 100 100 100 100 10 60 60 60 150 150 150 150 60" 10
14284.4 microseconds per iteration

(Not to mention that the external version is not only faster but also more reliable, as I identified and worked-around a pitfall if curves differ in magnitude.)

AK - 2010-06-17 15:37:18

When the remote end of an unnamed pipe (made via open|) crashes, then the pipe should get EOF. It might also get SIGCHILD, however I am unsure how Tcl is handling that signal. It might be the error message thrown when trying to read/write the pipe.

wdb Thanks for the hint. No eof on read operations, but error on write operations:

% info patchlevel
% set p open |./calcHelp r+
% fconfigure $p -buffering none -blocking no
% puts $p help
% gets $p
rotate setAngle setAxis inspectAxis lineCut bezierCut quit help 
% puts $p quit
% eof $p
% gets $p
% puts $p help
error writing "file6": broken pipe

More precise: with option -blocking no, an action gets $p varname writes empty string to varname and returns value -1 -- in both cases: external app is "still thinking" or is "died quietly". It would be preferable to detect which of both is the case.