On Dec 26, 2011, at 3:42 PM, Mathieu Bouchard wrote:
Le 2011-12-26 à 15:31:00, Miller Puckette a écrit :
Doesn't seem to work -- 'catch' grabs control Ok but there's no way to get control to go back to the script. Also no way to figure out how far down the script the interpreter got. There's gotta be a way to do this but I can't find it.
What's wrong with using $errorInfo ? Pd 43 already looks at that variable at least once.
The 'catch' is already in place in Pd 0.43 in pd_connect::pd_readsocket, and that is indeed what is printing out the Tcl error dump that started this discussion.
As for whether pd-gui stops working after an error or not, I think this is a behavior of the Tcl interpreter, not Pd 0.43 or Pd 0.42. In both Pd 0.42 and 0.43, fatal errors stop the Tcl interpreter. Try sending a message with "{" in it. In both Pd 0.42 and 0.43, the Tcl interpreter will print an error message for non-fatal errors and then continue to execute the next commands.
About the bug report, that particular bug report shows a bug where Tcl commands are being split in the middle of the line, causing incomplete commands to be executed. The Tcl error dump that Cyrille posted in this thread is not the same error at all. Cyrille's error shows a complete Tcl command, but the ".x235b3d0.c "canvas does not exist. So Cyrille's error is like the errors that are triggered by the christchurch GOP that were fixed for 0.43-1test7.
On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:
when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"
.hc
Access to computers should be unlimited and total. - the hacker ethic