Note that in the big i ve mentioned (which i still have to check whether it is fixed in test7) it‘s not that the whole gui stops responding: only one or a few families of gui elements (e.g. all toggles or all aliders, not alwaya the same ones) stop reaponding to mouse interaction and updating while others keep working fine, and things like editing, movimg around object boxes, etc keep working fine. I dont know whether this is in contrast or not with Miller‘s hipothesis on the source of the issue
I believe the difference between 0.42 and 0.43 is that the C code in 0.42
actually spat each 'line' of TCL, separately, to the interpreter, whereas
in 0.43 entire batches of TCL script get fed to the interpreter as a block.
The 0.42 code wasn't airtight (checked for newlines at which {'s were
balanced with }'s - this happened to work for all the TCL that Pd generated,
but one could construct valid tcl code that gave false positives.) So I'm
not in favor of 'fixing' 0.43 to work like 0.42 in this aspect. But I sure
would like to be able to tell the interpreter to bull through if any individual
statement failed - it won't fix any bugs but could make it less catastrophic
when they manifest themselves.
cheers
Miller
>
> 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
>
>
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list