[PD] [PD-announce] pd 0.43-1 test7 (!) available

[matteo sisti sette]

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
On Dec 27, 2011 10:42 PM, "Miller Puckette" <msp at ucsd.edu> wrote:

> 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111227/a99bf7ef/attachment.htm>