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 <[email protected]>:
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
