Le 2012-01-23 à 13:31:00, Hans-Christoph Steiner a écrit :
The problem isn't related to sys_gui not enforcing full Tcl commands since the breaks don't happen along the lines of sys_gui command contents.
I know that sys_gui doesn't enforce it, but that's not what I'm trying to say. I'm saying that it would be good if sys_gui could send extra data such as \0 terminators or size-of-upcoming command so that you don't need to run [info complete] at all in the tcl process.
A TCP connection doesn't have actual breaks. This means that if you want breaks, you have to add them. Currently, the breaks have to be guessed by a combination of parsing and supposing that the OS's breaks will eventually match an end-of-statement before the RAM starts swapping or before the CPU goes quadratic. That's why I'm thinking about less implicit ways of ending statements.
The only time I've seen a problem is when the commands are broken in the middle of a sys_gui post.
And there are several ways to fix that, and I was speculating about one that we aren't usually thinking about, but that might save the effort of running [info complete] multiple times on the same data and any other kludges we have to combine it with so that [info complete] does the job, and other funny side-effects of an [info complete]-based strategy...
the funny little detail is that when it breaks in the middle of a Tcl command, it is always exactly at the 48kb mark. exactly.
This most probably has to do with the size of the buffers in the TCP lasagna of the Linux kernel or OSX kernel. Each OS has its own sizes, and in some of them, it's tunable, if you know how (either by playing with /proc or /sys, or by recompiling something with a modified config.h, if you're not lucky).
A direct pipe (the pipe() command, no port number ; or a /tmp socket-file) has usually a different buffer size, iirc. In any case, you can't really rely on the buffer size being anything in particular, but the way it is now, it may affect Pd, especially in certain tough situations.
Some OS setting I guess, or default, or whatnot. The -buffering on the sender side only controls when Tcl pushes data into the OS. It doesn't prevent the OS from packaging things as it likes
Yeah, [fconfigure -buffering] is FOR OUTPUT ONLY. (If I said anything else, it's a mistake). However, [fconfigure -buffersize] controls the size of both the input and output buffers.
An input buffer is always required for using [gets], but is not when using [read]. This is because it's extremely inefficient to look for a newline when the OS doesn't allow you to «unread» data. I'm talking about user-space buffers (the OS does the buffering it wants to have, but you don't have direct access to it).
Hans-Christoph Steiner thommey: that seems doable, better than running [info complete] each time, I suppose <Gotisch> i guess i didnt know what i was talking about again
The thing with the \ is that it's not sufficient, because you also have to count the braces, and braces can be backslashed. (This corresponds to a mistake that I made in a previous mail.)
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC