Closed jpaulm closed 10 years ago
Hi @jpaulm ! null
is actually the default value in case no string has been specified. And because SendString
literally substitutes each incoming packets with the provided string, it makes sense that you have the third incoming string dropped when you have null
as the first out packet.
I'm guessing that you have some components upstream that are feeding to the in port first before it feeds to the string port. It does look like there may be some abstraction leak here... Is there any chance you could construct a minimal graph that would reproduce this behavior?
Thanks, Ken - so it really is a timing problem... I'll try to figure out why. This would also explain why the problem went away for a while, and then came back!
Regards,
Paul
On Sat, May 17, 2014 at 11:16 PM, Kenneth Kan notifications@github.comwrote:
Hi @jpaulm https://github.com/jpaulm ! null is actually the default value in case no string has been specified. And because SendStringliterally substitutes each incoming packets with the provided string, it makes sense that you have the third incoming string dropped when you have null as the first out packet.
I'm guessing that you have some components upstream that are feeding to the in port first before it feeds to the string port. It does look like there may be some abstraction leak here... Is there any chance you could construct a minimal graph that would reproduce this behavior?
— Reply to this email directly or view it on GitHubhttps://github.com/noflo/noflo-strings/issues/12#issuecomment-43430311 .
But what does SendString do???! I can't find any documentation, and when I look inside, there is all this strange group stuff - where does it get the group info - and what does it use it for?
Sorry to keep bothering you - I'm taking you at your word, you see! :-)
Best regards,
Paul
On Sat, May 17, 2014 at 11:16 PM, Kenneth Kan notifications@github.comwrote:
Hi @jpaulm https://github.com/jpaulm ! null is actually the default value in case no string has been specified. And because SendStringliterally substitutes each incoming packets with the provided string, it makes sense that you have the third incoming string dropped when you have null as the first out packet.
I'm guessing that you have some components upstream that are feeding to the in port first before it feeds to the string port. It does look like there may be some abstraction leak here... Is there any chance you could construct a minimal graph that would reproduce this behavior?
— Reply to this email directly or view it on GitHubhttps://github.com/noflo/noflo-strings/issues/12#issuecomment-43430311 .
Now SendString doesn't send if it doesn't have a string: 7f6f6f0d5dbe78194cb1c6e13bdd4b0bdf8d9de3
Slightly longer term we might change this to use the new helpers from noflo/noflo#166 to be smarter about when to send and what.
It seems to me that SendString is generating a null ahead of its output... unpredictably. It was doing it quite consistently until I modified the diagram - then it stopped doing it... then when I reconfigured the diagram, it started doing it again. So, why would SendString change from generating an extra null to not doing it, and then to doing it again, when the network is reconfigured?
I added a component which prefixes a number in front of the output line, and got the following output (when the null was happening):
Additional information: the 'string' port is receiving 3 character strings; the 'in' port is receiving 3 HTMLLIElements; the 'out' port is emitting a null, followed by the first 2 strings, dropping the third.
Flowhub note: when I click on the output connection from SendString, I don't see the (naked) null string - there should be some indication, e.g. a special icon.
PS Where is SendString documented?