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
Le 2012-01-23 à 14:00:00, Hans-Christoph Steiner a écrit :
if {[string index $cmd_from_pd end] eq \\} {
::pd_connect::pd_readsocket $cmd_from_pd
}
if {[catch {uplevel #0 $cmd_from_pd} errorname]} {
This is very wrong, because pd_readsocket calls itself recursively N
times,
On Feb 7, 2012, at 3:37 PM, Mathieu Bouchard wrote:
Le 2012-01-23 à 14:00:00, Hans-Christoph Steiner a écrit :
if {[string index $cmd_from_pd end] eq \\} {
::pd_connect::pd_readsocket $cmd_from_pd
}
if {[catch {uplevel #0 $cmd_from_pd} errorname]} {
This is very wrong,
Le 2012-02-07 à 16:09:00, Hans-Christoph Steiner a écrit :
This code has totally changed,
I know, it was just in case you wanted to know. Your most recent mail
didn't mention this bug (though it did say that you had removed the
recursion).
Le 2012-01-23 à 18:57:00, mescali...@gmail.com a écrit :
moreover, one should not trust [info complete] as an oracle knowing
exactly where a Tcl command ends and another begins. it just checks for
unbalanced brackets/quotes [1].
Right. But if only reading complete lines, then a trailing
On Jan 23, 2012, at 12:41 AM, Mathieu Bouchard wrote:
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
Quick guess; the socket itself (at the OS level) has a fixed buffer size
and if the sending process exceeds it it is suspended until the receiving
process eats at least some of it.
On Jan 23, 2012, at 12:45 AM, Mathieu Bouchard wrote:
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
There's not much way around this. One possibility (if indeed this is a
serious efficiency issue) would be for Pd to append a done message to each
batch up tcl to up-send.
That's
Le 2012-01-22 à 21:54:00, Miller Puckette a écrit :
On Mon, Jan 23, 2012 at 12:45:09AM -0500, Mathieu Bouchard wrote:
That's called a newline... not preceded by a backslash. The thing
with fconfigure -buffering line is that it doesn't care about
backslashes, whereas eval does, and if you use
On Mon, Jan 23, 2012 at 6:41 AM, Mathieu Bouchard ma...@artengine.ca wrote:
If you remove the [info complete] bracket from pd_readsocket, there are
these intermittent Tcl stacktraces causes by messages from 'pd' to 'pd-gui'
that get split in the wrong spot.
yes, [info complete] is a
On Jan 23, 2012, at 12:42 PM, Mathieu Bouchard wrote:
Le 2012-01-22 à 21:54:00, Miller Puckette a écrit :
On Mon, Jan 23, 2012 at 12:45:09AM -0500, Mathieu Bouchard wrote:
That's called a newline... not preceded by a backslash. The thing
with fconfigure -buffering line is that it doesn't
On Jan 23, 2012, at 12:54 AM, Miller Puckette wrote:
On Mon, Jan 23, 2012 at 12:45:09AM -0500, Mathieu Bouchard wrote:
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
There's not much way around this. One possibility (if indeed this
is a serious efficiency issue) would be for Pd to
Ok, I think I nailed it with lots of help from #tcl on freenode. It not
only seems to fix the intermittent problem, but also seems to be a bit
faster, due to using Tcl properly. I attached the patch I just
committed to pd-extended. The while {[info complete]} loop did a lot of
extra work
I've been trying to debug this really annoying issue. The [info
complete] look in pd_readsocket was causing some drastic slowdowns on
some GUI objects like Scope~, making them unusable. If you remove the
[info complete] bracket from pd_readsocket, there are these intermittent
Tcl stacktraces
Quick guess; the socket itself (at the OS level) has a fixed buffer size
and if the sending process exceeds it it is suspended until the receiving
process eats at least some of it. The receiving process is thus handed a
truncated buffer.
There's not much way around this. One possibility (if
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
Quick guess; the socket itself (at the OS level) has a fixed buffer size
and if the sending process exceeds it it is suspended until the receiving
process eats at least some of it.
AFAIK, that's 4k or 8k for «unix» type (pipe or fs socket)
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit :
There's not much way around this. One possibility (if indeed this is a
serious efficiency issue) would be for Pd to append a done message to
each batch up tcl to up-send.
That's called a newline... not preceded by a backslash. The thing
As it stands right now, there are new-lines in the middle of certain tcl
commands sent from Pd, so if newline were it, I'd have to go chase down all
the pretty-printing newlines in the Pd code and delete them. That might
actually might work; I'd only be worried taht some extern was throwing up
17 matches
Mail list logo
