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

ico at vt.edu ico at vt.edu
Thu Dec 29 16:51:31 CET 2011


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
>





More information about the Pd-list mailing list