noflo / noflo-strings

String Utilities for NoFlo
7 stars 13 forks source link

SendString generating extra null unpredictably ahead of its output #12

Closed jpaulm closed 10 years ago

jpaulm commented 10 years ago

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):

  0:null
  1:Joe 
  2:Mary 

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?

kenhkan commented 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?

jpaulm commented 10 years ago

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 .

jpaulm commented 10 years ago

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 .

bergie commented 10 years ago

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.