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

[Hans-Christoph Steiner]

The "paragraph mode" is not the cause of the freezes as far as I have
seen, it just highlights the situation when there are bugs.  I think we
should first discuss fixing the bugs before changing the current mode of
operation.  

As for the fixes in pd-l2ork, it would be great to have them in vanilla.
 Could you refactor them against vanilla and submit them to the bug
tracker?  Then they can be reviewed and included.

.hc

On Thu, Dec 29, 2011, at 10:51, ico at vt.edu wrote:
> The challenge remains, though, regardless of the approach. If a  
> particular call was called and it shouldn't have, parsing it out as  
> part of a paragraph or a line makes no difference performance-wise,  
> but it sure does make a world of a difference in terms of gui (or  
> parts of it) becoming unresponsive, since when the parser is in the  
> "paragraph mode" one will lose up to entire paragraph instead of a  
> single line (which in this case would not have any effect since the  
> line should've never been called). This is the part I was originally  
> referring to in terms of porting forward. If you look at the pd-l2ork,  
> it has much more detailed sanity checks for individual calls inside C  
> to make sure those calls are needed at all in the first place. Once  
> they are identified, you can wrap them in their own catch inside tcl  
> code (it that is indeed where they are being called)...
> 
> As for sanity checks, I don't think that really makes anything better  
> per se beyond whatever user enters manually via message to pd since  
> the 0.42 code already checks for sanity of those messages in its syntax.
> 
> The only time I encountered tcl breaking in core code of the 0.42  
> branch was as part of the network code (please note I mention here  
> vanilla as I haven't checked all the externals for proper behavior).  
> And if you ever tried debugging that you probably noticed just how the  
> tcl breaks. Namely, you could clearly see how one message inside  
> buffer was asynchronously overwritten midstream by another ending up  
> in a garbled output. Now, I know from our previous correspondence that  
> socket data incoming from a netreceive object apparently should output  
> in sync with the main loop, yet this problem was persistent until I  
> changed how the netreceive object behaves. In pd-l2ork all netreceive  
> sockets schedule received output as part of the guiqueue rather than  
> directly pushing the message out of an outlet no matter when it  
> receives it (or whenever suggested scheduler tells it to read from the  
> socket). This problem network-wise was much more apparent when there  
> was a heavier network traffic, while it almost never happened in low  
> throughput situations.
> 
> Long story short, I have not had gui freeze in pd-l2ork for over a  
> year now and so far I see no benefit in switching into a "paragraph  
> mode" as even if there is a huge performance benefit, the potential  
> penalty is the return of the gui freeze which renders any such  
> performance gains useless.
> 
> Quoting Hans-Christoph Steiner <hans at at.or.at>:
> 
> >
> > That is definitely true.  It is possible to make pd-gui execute  
> > line-by-line by setting the buffering on the socket to be  
> > per-newline, then reintroducing the logic that used to be in the C  
> > code.  But I think its faster to have Tcl parse, compile, and  
> > execute the code in larger blocks, but I don't have any data to back  
> > that up.
> >
> > .hc
> >
> > On Dec 27, 2011, at 1:37 PM, Miller Puckette 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
> >>>
> >>>
> >
> >
> >
> > ----------------------------------------------------------------------------
> >
> > Computer science is no more related to the computer than astronomy  
> > is related to the telescope.      -Edsger Dykstra
> >
> >
> >
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->  
> > http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
>