--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
A couple of days ago I posted an issue to the DrawFBP github repo suggesting that DrawFBP could be implemented using FBP principles. https://github.com/jpaulm/drawfbp/issues/11
From this origional suggestion a small discussion has arisen as to whether FBP is a good fit for implementing complex and dynamic GUIs.
Timothy Hobbs
I was not aware that noflo's ui was written using fbp. Is there an easy
way for me to visualize the diagrams? Like a viewer for fbp files or a
simple way to convert them to graphviz's dot format?
But in noflo's case, those diagrams actually explicitly exist
and can be algorithmicly rendered, whereas in the case of flex, the PR
diagrams are simply visualizations of the architecture drawn up using
powerpoint. As far as I can tell, there is no way to take an actual Flex
application and view it as a diagram without charting it out by hand
with pencil and paper.
Timothy
> * Clone the repo in http://app.flowhub.io/ and browse
I don't want to give a third party the ability to impersonate me on github so I'd have to create a new github account to do that. Of course, you can say that nothing malicious would happen, but to some extent that is a subjective matter. Maybe the marketing department would decide to create issuespam to promote flowhub :P. More importantly, it is permissions leakage and I need to be able to audit who has access to which services in order to maximize security.
When the dispatcher dispatches an event, where does the event get processed, it seems that the event flows to 6 different state/store nodes at once?
--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsubscri...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
--
In the NoFlo diagram there are 2 flows back from the right side back to the left, suggesting that the diagram can only be occupied by one user.
BTW Are we talking about Flex or Flux?!
Paul M.
This drags us into the old discussion about the differences between "classical" FBP and "FBP-like" - too long to go into here! I took a stab at describing the differences in http://www.jpaulmorrison.com/fbp/noflo.html , but it may well be out of date, as I haven't been following NoFlo closely. Henri, I can't remember if you ever sent me feedback on this...?
/Henri--
--
/Henri--
- a) your life-cycle diagram shows the control looping back to "started" from "finished" - I assume this is the same as the "classical" FBP life-cycle, where we call "started" "activate", and "finished "deactivate". Alternatively all of your Processes are "non-loopers" (components that return, and therefore deactivate, after processing an input IP)...? Since you are operating in JS, maybe this doesn't make a difference, as I believe you can use instance variables as working storage...? In Java and C# they're different, and I prefer not to mix them, so non-loopers lose their working storage (data local to the "execute" method)!
- b) if I remember correctly, when one component sends to a connection and another receives from that connection, NoFlo somehow turns that combination into a "call". Now I know I may not have understood that correctly - but how do Processes handle this?
Hi! And happy new year!On Fri, 13 Jan 2017 at 16:48 Paul Morrison <jpau...@gmail.com> wrote:- a) your life-cycle diagram shows the control looping back to "started" from "finished" - I assume this is the same as the "classical" FBP life-cycle, where we call "started" "activate", and "finished "deactivate". Alternatively all of your Processes are "non-loopers" (components that return, and therefore deactivate, after processing an input IP)...? Since you are operating in JS, maybe this doesn't make a difference, as I believe you can use instance variables as working storage...? In Java and C# they're different, and I prefer not to mix them, so non-loopers lose their working storage (data local to the "execute" method)!That diagram is for the whole network, meaning that you can re-start the network after it has finished by calling start() again.
For regular components, the normal operation is that we activate ("start") when reading input packets, and deactivate ("stop") when they call done(). The network is finished when all components have deactivated.Generator components control their own lifecycle a bit more and stay activated and sending packets until they decide to deactivate (usually by a packet to a "stop" port, or network.stop() is called.- b) if I remember correctly, when one component sends to a connection and another receives from that connection, NoFlo somehow turns that combination into a "call". Now I know I may not have understood that correctly - but how do Processes handle this?
Sorry! I missed the word "Network" in the diagram heading. You did say the component life-cycle was similar - I would say "process life-cycle" as "classical" FBP allows multiple instances of a component to run asynchronously with each other (BTW the JavaFBP implementation still has this confusion in the code!).
So IIUC a component decides how much data to read in, processes all of it, and then terminates. Does this mean that it has to read in all the data (potentially millions of IPs) before processing any of it? Or does the component read in some data, and is then reactivated when more data comes in? What you said below seems to imply this is how generator functions work...?
This question specifically has to do with how "send"/"receive" works under the covers... I'm not sure if you answered it, or if I didn't understand your answer... :-)
Henri,Is the capacity of the buffer configurable? i.e. can it be configured to hold, say, 2000 IPs?And when the buffer is full (eg. 2000 IPs pile up there...) will the sending component get into the
sending-block mode or any new IP sent would result in some IP "dropped" from the buffer?
Matt
--
Similar to https://en.wikipedia.org/wiki/Transputer ?
> So maybe hardware and software are also converging via FBP!
If Alan was thinking along more correct lines at one point, why did Smalltalk, and successive OO dialects go off the rails (no pun intended)?
Smalltalk-72 [Goldberg 1976] was similar in some respects to the Actor languages. In Smalltalk-72, an object's class was a process that repeatedly examined the object's message stream and then dispatched on the message. As the language evolved, message lookup was subsumed into the Smalltalk Virtual Machine for efficiency's sake and because deviations from case-style method dispatching were rare and usually hard to understand. Smalltalk-72 permitted more reflection than Smalltalk-80 because objects could manipulate the message stream.
Replacing user-defined message-handling with standardized method lookup was a success. It led to efficient Smalltalk implementations and a large body of reusable software. However, the power of the Actor language is needed to deal with parallelism and other aspects of modern applications. We believe that object-oriented systems should provide primitive facilities that allow actor-like objects to be constructed out of more rudimentary components. Thus, the full power of actors will only be used when appropriate.