Implementing a GUI such as the DrawFBP editor using FBP

[timtheli0n]

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. Paul requested that I move the discussion over here in order to allow others to take part. As my posts contained images, and I don't have good experiences posting images to google-groups, I will leave my initial posts on github for now, but if you'd like to engage in the discussion feel free to do so here.

Regards,
Timothy Hobbs

[Paul Tarvydas]

On 2017-01-03 03:53 PM, timtheli0n wrote:
> A couple of days ago I posted an issue to the DrawFBP github repo
> suggesting that DrawFBP could be implemented using FBP principles.

Here is a silent demo of something I showed in Hamburg ECLM09:

https://www.youtube.com/watch?v=8vZ8Pi32oMo

My approach is to consider IP's as short events, i.e. you don't get a
continuous stream. Given that the blocks are asynchronous and there can
be hardware-like race conditions, I put state-machines inside the
components (and use a diagram notation for them, too ; based on Harel's
seminal paper
http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf
; I drop concurrency from Harel's notation and use FBP for that ).

After 20+ years of using diagrams for code, I have *very* strong
opinions about what makes a good editor, e.g. it needs to be an emacs
for diagrams, every operation executable from the keyboard based on
point and mark (cyan and red crosshairs). I have posted the "atomic"
operations for such an editor to this newsgroup in the past (and if that
list is not on my blog bittarvydas.wordpress.com, I will put it there).

There are two very short papers on my github
https://github.com/guitarvydas/papers .

I believe that FBP is an architecting language and I feel that it would
be a very good idea to build the editor in FBP. I know that it can be
done with my fully-reactive variant (unfortunately, all versions are
OEM, not open source).

I'd be glad to discuss at length.

pt

[Paul Morrison]

Thanks, Tim!  I will get notified either way!  I don't recollect posting diagrams on the Google group being very slow - I mainly have trouble positioning them where I want!

Hope we get a hot discussion going!

Regards,

Paul M.

--
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.

[Henri Bergius]

Hi!

On Tue, 3 Jan 2017 at 21:53 timtheli0n <tim.t...@gmail.com> wrote:

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. 

It is certainly possible, after all, noflo-ui is built in NoFlo.

Here is the main graph, based on Flux-like event loop:

https://github.com/noflo/noflo-ui/blob/master/graphs/main.fbp

Facebook's Flux pattern claims inspiration from FBP:

https://facebook.github.io/flux/docs/in-depth-overview.html#content

> Flux eschews MVC in favor of a unidirectional data flow. When a user interacts with a React view, the view propagates an action through a central dispatcher, to the various stores that hold the application's data and business logic, which updates all of the views that are affected. This works especially well with React's declarative programming style, which allows the store to send updates without specifying how to transition views between states.

Timothy Hobbs

/Henri 

[timtheli0n]

Hi,

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?

I watched the lecture and read through the notes on the website you
linked to. Beyond that, I know nothing of flex. However, if I understood
correctly there is a real difference between noflo's use of the fbp
diagrams and flex's limitations on the direction of dataflow. Of course,
the PR managers for both products show potential users pretty looking
diagrams. 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.

BTW: Is there an orthodoxy around here with regard to top posting vs
bottom posting?

Regards,
Timothy

[timtheli0n]

Hi PT,

I understand correctly that your VF editor could be used to write an editor using FBP principles, however it was written using more ordinary programming techniques?

I have written some questions out which are specific to VF here:
https://groups.google.com/forum/#!topic/flow-based-programming/v-E7VV6p1Kk

Regards,
Timothy Hobbs

[Henri Bergius]

Hi,

On Wed, 4 Jan 2017 at 01:15 timtheli0n <tim.t...@gmail.com> wrote:

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?

Yep, two ways actually:

* Copy a FBP graph to https://noflojs.org/visualize/

* Clone the repo in http://app.flowhub.io/ and browse

For your convenience, here is a screenshot of the main graph (with some manual rearranging, since the autolayout didn't do a stellar job with this graph):

You can see how the user actions flow from view to dispatcher on to stores (blue lines), and how state changes flow from stores back to the view. 

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.

Yes, certainly! With traditional programming methods, architecture diagrams usually end up being stale the moment user opens a code editor.

 

Timothy

/Henri 

[timtheli0n]

Hi,

> Yep, two ways actually:
> * Copy a FBP graph to https://noflojs.org/visualize/

In chromium that gives me

Uncaught TypeError:
Cannot read property 'markDirty' of undefined
    at Constructor.renderGraph (the-graph-app.js:289)
    at Constructor.boundMethod [as renderGraph] (react.js:6069)
    at Constructor.<anonymous> (the-graph-app.js:261)

In the console and nothing gets shown. However, pressing the ? button does show a 3 node graph.

> * Clone the repo in http://app.flowhub.io/ and browse

""""

This application will be able to read and write all public repository data. This includes the following:

    Code
    Issues
    Pull requests
    Wikis
    Settings
    Webhooks and services
    Deploy keys
""""

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.

> You can see how the user actions flow from view to dispatcher on to stores (blue lines), and how state changes flow from stores back to the view.

When you are, for example, dragging a node with your mouse, what nodes know that the mouse button is down and which node is being dragged?

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? But perhaps it would be better for me to leave my questions untill I find a good way to view the code properly.

[Henri Bergius]

On Wed, 4 Jan 2017 at 13:16 timtheli0n <tim.t...@gmail.com> wrote:

> * 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.

Flowhub is an IDE, and so it needs to be able to talk to GitHub on your behalf.

But yes, if you want to only access public repositories, you _can_ use Flowhub with a throwaway GH account.

In case trust is in question, you may want to check out the company background: https://flowhub.io/about/

 

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?

That is actually a side effect of Flowhub being unable to visualize multiple connections to an addressable port separately:
https://github.com/noflo/noflo-ui/issues/14

The dispatcher is a router component that sends the IPs to one of the outbound connections based on bracket data.

/Henri 

 

[Paul Morrison]

Zhenyu, this discussion looks like it might be of interest to you too, as you discussed teaching React in any earlier note to me.

Regards,

Paul

--

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.

[Paul Morrison]

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...?

BTW In your last para but one, you refer to "flex", but I thought we are talking about "flux" - or did I miss something?!

Regards,

Paul

--

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.

[Paul Morrison]

My version of this - in the context of client/server, but it should apply to interactive apps as well - can be seen in the two diagrams at the bottom of https://github.com/jpaulm/javafbp-websockets/blob/master/README.md .  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.  However, it should be easy enough to support multiple users by "cutting" those two lines, but I don't know enough about NoFlo to know if other factors might make that difficult.

BTW Are we talking about Flex or Flux?!

Paul M.

--

[Henri Bergius]

On Thu, 5 Jan 2017 at 04:31 Paul Morrison <jpau...@gmail.com> wrote:

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.

 Depends a little bit on how the architecture is done. With Flux (and Redux), what flows back from view to dispatcher is "actions", then the stores manipulate application state based on these actions and send the updated state back to view.

This way, when user for example adds something to a TODO list, the views don't manipulate the actual list, but instead send packets like:

< createTodo

{ "task": "Buy milk" }

> createTodo

(in noflo-ui we use brackets to identify action type, so multiple payloads per action are possible, and components can work on action payload without having to need to know full application architecture).

This "action-based" flow back means it is also possible to support multiple users ... just allow the dispatcher to receive actions from multiple clients, and to transmit them between users. We're not really doing that in noflo-ui yet, but down the line would like to.

Another potential advantage is that you could persist the action history. If you have it starting from "state zero", you could recreate any state of the application by just re-playing actions from start to that point. This would give a very nice way to provide a full undo history.

 

BTW Are we talking about Flex or Flux?!

Flux. I think Flex was a typo.

 

Paul M.

/Henri 

[Henri Bergius]

Hi,

On Wed, Jan 4, 2017, 18:27 Paul Morrison <jpau...@gmail.com> wrote:

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...?

Regarding that, I just published a blog post describing the new component API in NoFlo:

http://bergie.iki.fi/blog/noflo-process-api/

Obviously not 100% classical, but get us a lot closer to there.

/Henri

[Paul Morrison]

Congratulations, Henri!  This is looking very interesting!

It's great that the various flavours of FBP seem to be converging - I am beginning to feel that we absolutely have to get FBP into the schools - the earlier the better!

Regards,

Paul

/Henri

--

[Paul Morrison]

That makes a lot of sense!  I was going to say that it sounds like this approach, and my simplest networks, don't really require the full asynchronous capabilities of "classical" FBP - but then I thought of the multiplexing we used in our Brokerage app (EB2).  As I say in https://github.com/jpaulm/javafbp-websockets/blob/master/README.md (and drawn in the last diagram), LoadBalance also has to be substream-sensitive.  In EB2 we also had a number of caches, both for performance, and to maintain consistency in things like stock prices - this might lead to more reusable components.

The new Process API should help with all of these - please keep us posted on how apps built using this work out (assuming this doesn't violate any confidentiality rules).

Best wishes for the New Year,

Paul M.

--

[Paul Morrison]

Hi Henri,

Happy New Year!  Hyvää uutta vuotta!

Couple of questions about the new Process API:

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

My diagram is at approx. 3:50 in https://www.youtube.com/watch?v=-AmzfhV2hIU .

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

Hope this makes some kind of sense!  Thanks in advance,

Paul M.

On Thu, Jan 5, 2017 at 4:35 PM, Henri Bergius <henri....@iki.fi> wrote:

/Henri

--

[Henri Bergius]

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? 

Every time a triggering inport receives a packet, it calls the component's process function. The process function checks preconditions by looking at the inport buffers, and can either:

* decide to not do anything (preconditions not met)

* reads packets from inport(s), causing activation

 

/Henri

[Paul Morrison]

On Friday, January 13, 2017 at 11:02:49 AM UTC-5, Henri Bergius wrote:

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.

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...?

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? 

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 Bergius]

Hi,

On Sat, 14 Jan 2017, 02:35 Paul Morrison, <paul.m...@rogers.com> wrote:

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!).

With the new Process API, NoFlo components can also be doing multiple async runs at the same time. When the first processing run starts (load goes from 0 to 1), the component is considered started, and once last one finishes (load drops to 0), the component is considered finished.

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...?

The component's processing callback decides. It can read a single IP, a full stream, or multiple of either per run, from any number of its inports.

What it doesn't read in that run will remain in the inport buffer until the component reads it.

New packets trigger the processing function so it can check whether the packets in the inport buffer(s) meet its firing pattern preconditions.

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

The actual sending is a normal JavaScript event that triggers the connected inport's callback function. The inport puts the new IP into its buffer and notifies component, again via a callback.

[Matthew Lai]

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?

Yours,

Matt

[Henri Bergius]

On Sat, 21 Jan 2017, 21:32 Matthew Lai, <mm...@sympatico.ca> wrote:

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?

Right now the NoFlo buffers are only limited by system memory.

Adding limits and backpressure is certainly something to consider down the line. Hasn't really been a consideration for things NoFlo is usually used for, though.

Matt

/Henri

[Paul Morrison]

Hi Henri,

This sounds like we are indeed converging!

Thanks also for the info about send/receive!   It actually sounds like a "gedankenexperiment" a colleague and I did some years ago, where we imagined a network of micromachines, where each input port had its own buffer in the owning machine.

"Each microprocessor would basically be running a single code loop which takes packets off one or more (fixed capacity) input queues in the microprocessor’s memory, does some processing, and writes zero or more packets out onto the outgoing wires. When a packet arrives on a microprocessor’s input wire, it triggers an interrupt, and the interrupt code stores the packet on the corresponding input queue."  "Flow-Based Programming, 2nd ed.", p. 314.

So maybe hardware and software are also converging via FBP!

--

[Ruud Steltenpool]

Similar to https://en.wikipedia.org/wiki/Transputer ? 

[Raoul Duke]

perhaps see also: the actor model; and/or Kay's meaning of "oo".

[Paul Tarvydas]

On 2017-02-28 10:25 AM, Ruud Steltenpool wrote:

Similar to https://en.wikipedia.org/wiki/Transputer ? 

 

> So maybe hardware and software are also converging via FBP!

Hardware was already concurrent (asynchronous) 40 years ago.

Transputers were fashioned after CSP, which IIRC, at the time did not hide peer components from one another.  The innards of a component can only refer to a component's ports, not other components.

Hiding peers and concurrency are features that make FBP very flexible.

pt

[Paul Morrison]

Interesting!  I notice Henri at PolyConf 14 gave Alan Kay credit for a "biological" model of OO, and then says wonderingly, "Then... somehow we got Java".  I was under the impression that the first people to come up with the indirect call mechanism were the Smalltalk folks, and I remember an article in Scientific American (?) describing this approach, although Smalltalk took these indirect calls and mangled them into character strings :-) , which made it even more horrible!   

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)?  See also my article at http://www.jpaulmorrison.com/fbp/oops.shtml .

[Ruud Steltenpool]

Transputers ran Occam (based on CSP), that DID hide peer components according to http://www.eg.bucknell.edu/~cs366/occam.pdf#page=5 I think.

[John Cowan]

On Tue, Feb 28, 2017 at 8:04 PM, Paul Morrison <jpau...@gmail.com> wrote:

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

Here's a passage from a 1989 paper that accounts for it, I think:

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.

Remember that Smalltalk was born on highly constrained hardware, and in order to run efficiently had to be stripped to the bone.

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

The penguin geeks is happy / As under the waves they lark

The closed-source geeks ain't happy / They sad cause they in the dark

But geeks in the dark is lucky / They in for a worser treat

One day when the Borg go belly-up / Guess who wind up on the street.

[Paul Morrison]

Thanks, John, that makes a lot of sense.   The second paragraph you quote reminds me of Ellis and Gibbs' comment in their paper in “Object-Oriented Concepts, Databases, and Applications”, ACM Press, Addison-Wesley (1989):

“Although we foresee that object-oriented programming, as we know it today, is close to its deathbed, we foresee tremendous possibilities in the future of active object systems [my italics].... Vive l’objet actif.”

[Paul Tarvydas]

On 2017-02-28 08:33 PM, Ruud Steltenpool wrote:
> Transputers ran Occam (based on CSP), that DID hide peer components
> according to http://www.eg.bucknell.edu/~cs366/occam.pdf#page=5 I think.

Yes, you are right, my recollection is wrong.

On page 17, the final PAR is the parent "net". They pass channels as
formal parameters to the spawned proc's, which constitutes the hiding
(the formal parameters, channels, are the ports on the outside of a
component).

pt