hi all,
i _suppose_ there is a bug in the gui code concerning the send/receives of toggles...
i attatched a part of an abstraction that produces this bug ... a |1( message is received, although no |1( message has been sent ...
if someone is interested in this behaviour, please check the attached patch / abstraction ...
to reproduce the bug to the following:
press "diag1_invert" press "vertikal" -> this results a message 0 to both "diag1_invert" and "vertikal" and a message 1 to "mitte_invert"
this is ok. but:
press "diag1" -> this results a message 1 to "mitte" that results a message 0 to all the other toggles ...
this behaviour is definitely wrong, since it should only have this specific behaviour if "vertical" is 1. i traced the sends and receives to the "vertical" toggle and it seems, there is a message |1(, coming from nowhere... (sorry, i'd like to be more detailed, but at the moment, i can't say more)
i could reproduce it on devel_0_37 / linux and on win (binary from hcs's latest installer)
i hope, someone can test the abstraction (and hopefully figure out, that it's a user bug)
cheers.... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i _suppose_ there is a bug in the gui code concerning the send/receives of toggles...
i attatched a part of an abstraction that produces this bug ... a |1( message is received, although no |1( message has been sent ...
if someone is interested in this behaviour, please check the attached patch / abstraction ...
to reproduce the bug to the following:
press "diag1_invert" press "vertikal" -> this results a message 0 to both "diag1_invert" and "vertikal" and a message 1 to "mitte_invert"
this is ok. but:
press "diag1" -> this results a message 1 to "mitte" that results a message 0 to all the other toggles ...
this behaviour is definitely wrong, since it should only have this specific behaviour if "vertical" is 1. i traced the sends and receives to the "vertical" toggle and it seems, there is a message |1(, coming from nowhere... (sorry, i'd like to be more detailed, but at the moment, i can't say more)
I added a [r sync-waende-vertikal-rec]->[print] and as hard as I try, there are only zeros coming into this. I would rule out, that the toggle is getting a 1 anywhere. Also when I remove the internal receiver and connect the [r sync-waende-vertikal-rec] to the toggle, I never get a 1. Which is natural, as there are only [0('s connected to everything that evaluates to "sync-waende-vertikal-rec". The only thing that *could* get a 1 outside a toggle is "sync-waende-mittei-rec" and "sync-waende-mitte-rec"
Other than that I still do not fully understand the flow of logic in that patch, which "feels" to be more complicated than it would have to be. At least the argument count of [sync/parse_sync1_12] makes me think: this is too much. (One would probably never write a C function which requires 13 arguments...)
I would recommend to factor out some of these, which would make user errors less likely (for starters remove redundancy like sync-waende-global as argument 13 everywhere.)
Frank Barknecht _ ______footils.org__
hi frank...
I added a [r sync-waende-vertikal-rec]->[print] and as hard as I try, there are only zeros coming into this. I would rule out, that the toggle is getting a 1 anywhere. Also when I remove the internal receiver and connect the [r sync-waende-vertikal-rec] to the toggle, I never get a 1. Which is natural, as there are only [0('s connected to everything that evaluates to "sync-waende-vertikal-rec". The only thing that *could* get a 1 outside a toggle is "sync-waende-mittei-rec" and "sync-waende-mitte-rec"
please don't explain the syntax of toggle or the _language_ pd!
just add a |r sync-waende-vertikal-send|->|print| and in parse_sync2_1 behind the |r $1-send| another print object ... (to make shure, do this in a running patch, don't save the abstraction)
inside the abstraction you will receive a |1( message from sync-waende-vertikal-send
Other than that I still do not fully understand the flow of logic in that patch, which "feels" to be more complicated than it would have to be. At least the argument count of [sync/parse_sync1_12] makes me think: this is too much. (One would probably never write a C function which requires 13 arguments...)
in fact, this patch _is_ more complicated ... i broke this out of a more complicated patch ... i deleted a huge stuff to make track down the problem ... and to make shure, there is not some kind of error, coming from somewhere else in the patch!!!
if you follow the logic of the abstraction, (parse_sync2_1) you will see, that if the second argument's send is 1 and $1-send (from the tgl), a message |0( will be sent to $1-rec (to the tgl). this will send the |0( to $1-send ... but there is the problem! ... the last message arriving at $1-sen is a |1(
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
please don't explain the syntax of toggle or the _language_ pd!
I never intended to do this, I was just intending to follow your problem description.
just add a |r sync-waende-vertikal-send|->|print| and in parse_sync2_1 behind the |r $1-send| another print object ... (to make shure, do this in a running patch, don't save the abstraction)
Okay, this is another problem, which wasn't clear from what you wrote in the first mail. "sync-waende-vertikal-send" is not what the toggle receives, it's what it sends. So the problem is a mysterious 1 that gets send, and it seems to get send by the toggle, as that's the only place such a send could be generated (as far as I see, which still might not be that far.
The 1 even can be exchanged to another number by seting the non-zero value of the vertikal-toggle to it. BTW: There is no need to add the [r sync-waende-vertikal-send] to the abstraction, it can be added to the main patch as well to show this behaviour.
This indeed is strange.
in fact, this patch _is_ more complicated ...
Oh, I'm sure it is. ;)
i broke this out of a more complicated patch ... i deleted a huge stuff to make track down the problem ... and to make shure, there is not some kind of error, coming from somewhere else in the patch!!!
Maybe we can find a way to make it even more simple up to the point, where the "bug" doesn't occur anymore, then look what was removed last.
if you follow the logic of the abstraction, (parse_sync2_1) you will see, that if the second argument's send is 1 and $1-send (from the tgl), a message |0( will be sent to $1-rec (to the tgl). this will send the |0( to $1-send ... but there is the problem! ... the last message arriving at $1-sen is a |1(
As I wrote above, I think, the problem is, to find where this non-zero value for the vertikal-toggle's send is coming from. And it get generated come when you toggle on "diag" then "vertikal" as well, as when you toggle on "diag_invert" and then "vertikal". See attached modifikation of the patch, which monitors sends and receives by prints.
As the toggle in my patch has no sends and receives anymore I'm still convinced, that the bug is not one in "tgl" but somewhere in the logic flow.
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
just add a |r sync-waende-vertikal-send|->|print| and in parse_sync2_1 behind the |r $1-send| another print object ... (to make shure, do this in a running patch, don't save the abstraction)
Okay, this is another problem, which wasn't clear from what you wrote in the first mail. "sync-waende-vertikal-send" is not what the toggle receives, it's what it sends. So the problem is a mysterious 1 that gets send, and it seems to get send by the toggle, as that's the only place such a send could be generated (as far as I see, which still might not be that far.
Forget what I wrote, I'm an idiot. *Of course* something gets sent, because it has to, when the tgl is clicked! Duh, brain mashed.
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Forget what I wrote, I'm an idiot. *Of course* something gets sent, because it has to, when the tgl is clicked! Duh, brain mashed.
Oh, and now I don't see anymore, where exactly the problem was?
Frank Barknecht _ ______footils.org__
Okay, this is another problem, which wasn't clear from what you wrote in the first mail. "sync-waende-vertikal-send" is not what the toggle receives, it's what it sends. So the problem is a mysterious 1 that gets send, and it seems to get send by the toggle, as that's the only
Forget what I wrote, I'm an idiot. *Of course* something gets sent, because it has to, when the tgl is clicked! Duh, brain mashed.
so what is wrong with a toggle sending things ? even though tim does not want to hear an explanation of toggle, i will give one here (just to clearify things)
if you send a float ("1") to a toggle via it's inlet, it will set it's state and send out the float to the outlet + to the send-label if you send "set 1" to a toggle, it will set its state and stop.
if you send a float to a toggle via a *receive*, it will set it's state and send out the float (to the outlet AND) to the send-label.
there is one (1) exception: if the send-label equals the receive-label the output is supressed (to avoid loops)
a "1" *is* sent to the "mitte"-button (as explained in the other mail), and it reacts accordingly.
mfg.asd.r IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Okay, this is another problem, which wasn't clear from what you wrote in the first mail. "sync-waende-vertikal-send" is not what the toggle receives, it's what it sends. So the problem is a mysterious 1 that gets send, and it seems to get send by the toggle, as that's the only
Forget what I wrote, I'm an idiot. *Of course* something gets sent, because it has to, when the tgl is clicked! Duh, brain mashed.
so what is wrong with a toggle sending things ?
Nothing, nothing is wrong with it. I just forgot that a toggle also sends to its sender, if it gets *clicked* like in the old days. ;)
Frank Barknecht _ ______footils.org__
thanks iohannes ... i think i figured it out ...
is it possible that a receive is working as a stack, not as a fifo?? i'm not sure, if i should like this or not, since it's can revert the order of excecution ... (i personally consider a fifo to be more logical)
frank: i have to appoligy for sounding rude in my earlier mail
cheers... tim
Yep, everything is depth-first throughout the Pd message system, except that individual objects (e.g., pipe) can operate FIFOs.
M
On Mon, Aug 23, 2004 at 01:05:35AM +0200, Tim Blechmann wrote:
thanks iohannes ... i think i figured it out ...
is it possible that a receive is working as a stack, not as a fifo?? i'm not sure, if i should like this or not, since it's can revert the order of excecution ... (i personally consider a fifo to be more logical)
frank: i have to appoligy for sounding rude in my earlier mail
cheers... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Yep, everything is depth-first throughout the Pd message system, except that individual objects (e.g., pipe) can operate FIFOs.
is the current behaviour of |pipe 0| or |delay 0| the intended? at the moment these objects reschedule the messages (and thus solve my problem). on the other hand there are people on this list (e.g. frank), who consider this as being a bug ...
i'm curious if it will be save to use it in further releases of pd or if you intend to change it ... personally, i'd prefer this behaviour in the specifications of these objects since it makes recursive patching _much_ easier ...
cheers... tim
I think I can't ever change that behavior without breaking thousands of patches. Beware though - if you try to "defer" something using a "delay 0" but if you're sending messages to someone else who's also trying to use delay 0 in the same way, it might be hard to figure out what order it all happens in. The "trigger" mechanism probably scales better to large patches.
cheers Miller
On Wed, Aug 25, 2004 at 10:37:50AM +0200, Tim Blechmann wrote:
Yep, everything is depth-first throughout the Pd message system, except that individual objects (e.g., pipe) can operate FIFOs.
is the current behaviour of |pipe 0| or |delay 0| the intended? at the moment these objects reschedule the messages (and thus solve my problem). on the other hand there are people on this list (e.g. frank), who consider this as being a bug ...
i'm curious if it will be save to use it in further releases of pd or if you intend to change it ... personally, i'd prefer this behaviour in the specifications of these objects since it makes recursive patching _much_ easier ...
cheers... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Tim Blechmann wrote:
hi all,
i traced the sends and receives to the "vertical" toggle and it
seems, there
is a message |1(, coming from nowhere... (sorry, i'd like to be more detailed, but at the moment, i can't say more)
hi. first i have to say that i do not understand your patch at all. i guess this is due to the stripping down from a more complex patch (as explained to frank) and to have no explanation at all what it is supposed to do.
"[1( coming from nowhere" is really a bit short; i guess you do not expect the message to be sent to "sync-waende-mitte-rec" (?)
i _suppose_ there is a bug in the gui code concerning the send/receives of toggles...
using explicit [s] and [r] instead of the gui-internals' gives me the same result (unless i am looking at the wrong things)
what is going on. pre) i hit the "diag1_invert" and then "vertikal"
press "diag1" -> "1" is sent to the second receive of the first (upper) "parse_sync2_1" in "aus_zwei_mach_eins" -> the selector fires (the left-hand operator of [&&] is "1" because of pressing the "vertical"-button before) -> .. send "0" to "sync_waende_vertical_rec" (does not do much, as the [&&] results in 0) .. send "0" to "sync_waende_diag_rec" (does not do much either) .. send "1" to "sync_waende_mitte_rec" (is this the [1( out of nowhere ??)
it's a user bug)
i think so
a lot of logic is going on between all those s/r-pairs, which is hard to track down especially when trigger-problems might occur.
tip: use [trigger] for explicitly defining when to send a message to [print] (e.g. what happens before things are [s]ent and what happens afterwards)
mfg.a.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
a lot of logic is going on between all those s/r-pairs, which is hard to track down especially when trigger-problems might occur.
tip: use [trigger] for explicitly defining when to send a message to [print] (e.g. what happens before things are [s]ent and what happens afterwards)
This probably is not (or not only) a trigger problem like we discussed here lately, but more: it could be a problem with various send/receives in various abstractions firing in a not clearly defined order - and this while letting the sender in the end loop back to itself. Very confusing and possibly dangerous.
Although there are triggers inside the abstraction as it should be, it's not clear, which of the sends inside which abstraction
So basically - at the danger of explaining the Pd language again and the syntax of abstractions ;) - we might be dealing with an "order of execution" problem on an advanced higher level. A very high level actually.
What I would do if this was my project, is to remove abstractions (literally "unrolling the loops") and see if the flow of the patch is still correct. Then later I would work on carefully abstracting out things again.
For starters it will probably be helpful to just replace the [r $1-send] in the abstractions by inlets and speak to those though triggers in a defined order. But as I still do not clearly understand what the patch *should* do in the end, it's hard to say if this will help.
Frank Barknecht _ ______footils.org__
hi
a lot of logic is going on between all those s/r-pairs, which is hard to track down especially when trigger-problems might occur.
This probably is not (or not only) a trigger problem like we discussed
true. i wast just searching for "order of execution" and couldn't find it in my head; so i was (confusingly) using "trigger-problem".
the other point was, that sometimes it is very important *where* you place the debugging [print]. putting a print immediately before and after a branch is executed (using e.g. [t a a a]) is often helpful in debugging such things.
my opinion of the patch (of which, as you say, we "still do not clearly understand what the patch *should* do in the end"), is probably best expressed with "to iterate is human, to recurse, divine" (and i do not think that recursion is an appropriate tool for the given problem (as i understand it))
mfg.a.sdr IOhannes