- 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
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:18When 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 8.5.1 % set p [open |./calcHelp r+] file6 % fconfigure $p -buffering none -blocking no % puts $p help % gets $p rotate setAngle setAxis inspectAxis lineCut bezierCut quit help % puts $p quit % eof $p 0 % 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.