When used as "compile-on-the-fly", embedding critcl::cproc and critcl::ccode code blocks in a tcl script and then simply running the script, the C-code typos and errors may generate a critcl error message, but this does not stop the tcl script from continuing to run.
This can be quite disorienting, because it often shows itself as an "error" in some unrelated tcl proc, or points to an error in another critcl::cproc, not the one with the error. If the script pops up large graphical windows, or generates a lot of text output, the C compiler error, if any, is obscured or scrolled off. I think the default behaviour should be to terminate the script, and not generate an error message on the console and continue the tcl script.
Under wish it could become a pop-up, to be dismissed, but even there I think a better policy is to stop tclsh/wish with a console error. Warning messages from compiler could be handled differently, but not the error messages of failure to compile/link in ~/.critcl.
When used as "compile-on-the-fly", embedding
critcl::cprocandcritcl::ccodecode blocks in a tcl script and then simply running the script, the C-code typos and errors may generate acritclerror message, but this does not stop the tcl script from continuing to run.This can be quite disorienting, because it often shows itself as an "error" in some unrelated tcl proc, or points to an error in another
critcl::cproc, not the one with the error. If the script pops up large graphical windows, or generates a lot of text output, the C compiler error, if any, is obscured or scrolled off. I think the default behaviour should be to terminate the script, and not generate an error message on the console and continue the tcl script.Under
wishit could become a pop-up, to be dismissed, but even there I think a better policy is to stop tclsh/wish with a console error. Warning messages from compiler could be handled differently, but not the error messages of failure to compile/link in ~/.critcl.