Sweet project - some questions

53 zobrazení
Přeskočit na první nepřečtenou zprávu

Dion Bridger

nepřečteno,
11. 4. 2021 12:42:5011.04.21
komu: Flow Based Programming
Hello everyone,

I come with some praise, a question, and some remarks for where there is apparent room for improvement.

I've just worked through the tutorial and read through some of the FBP documentation linked to from the FBP github page. This approach seems extremely close to something I've been /attempting/ to design for use in a complex embedded systems project, which will require the collection, analysis and integration of data streams from multiple physical sensors.

First, the praise: this seems like a highly promising approach, what documentation there is, is fairly clear and the FBP software worked without too much fuss.

Room for improvement: the UI of the visual FBP is quite clunky. It takes several mouseclicks to attach a class to a node, the arrows/nodes sometimes need to be jiggled around to get them to look straight, there is no easily inspectible list of available classes  ( that I could see ) - there is no way to check that a network is "well typed" ( that I could see ), the modal mouse behaviour is a bit clunky. These are all niggles but I think creating something that is slicker, would do a lot to accelerate adoption of this technology. That is something to which I may provide contribution of effort, if the community in general is keen on seeing a slicker user interface.

Also, getting the generated code to run was quite a pain - the tutorial instructions were a little unclear when it came to running the code - though they may be clear to someone who understands how projects in Java are set up. I ended up spending a lot of time bouncing around on StackOverflow to find out how to import a .jar file into NetBeans configured to use Gradle. Gave up and used Ant eventually. I understand that this is not necessarily the responsibility of the FBP community but once again this kind of thing forms an obstacle to adoption.

Finaly, my question. In the FBP standard wiki, there is the following segment:
"Initially FBP applications are static: once an application graph is started, it cannot add or remove nodes. Some implementations allow changing application structure at run-time, making it more flexible on one hand and less reliable on the other."
My question is -- does the Java implementation of FBP as it currently exists support dynamic updates of network topology? I think this is a key requirement for my use case, but is probably also a something that would provide a significant edge to a FBP system over alternatives, as it would reduce the friction in the update/run/debug cycle significantly.

Thanks for your time.
Yours,
Dion

Paul Morrison

nepřečteno,
11. 4. 2021 15:19:0211.04.21
komu: flow-based-...@googlegroups.com
Thanks for the praise, Dion! 

All  good points, and I'd love to have the user interface be a bit smoother!   I used Java Swing, but maybe there are newer technologies that are easier to use, and result in a slicker UX...! However, I want to stress that DrawFBP has been evolving for at least a decade and a half, and has a lot of function (probably not all working perfectly yet!).

DrawFBP is intended to be language-agnostic, so the idea is to do your design in English (or the language of your choice), and then fill in component or subnet names, refining the design progressively until all blocks are assigned.  It is hard for me to see how you could assign a component to a diagram block with fewer keystrokes, as components or subnets have to be selected, so it seems reasonable to walk a tree of directories (or folders in a jar file).

Re "well-typed" networks, I tried that in DrawFBP, but ran up against the problem of type-agnostic processes (like merge, sort, display, etc.)  in the middle of a network...  How do you check "across" such a component?  Suggestions would be welcome!

I have heard of NetBeans, but don't know what they are, or how they would fit in with this design technology - could you share your experience in this area with us?  I didn't use Ant either - would that make the setup easier?

Last point: JavaFBP subnets are currently static, but the architecture is set up so it would be pretty easy to add dynamic subnets to JavaFBP...  I describe this in Chapter 7 of the 2nd edition...  You might want to look at https://github.com/jpaulm/javafbp/blob/master/src/main/java/com/jpaulmorrison/fbp/resourcekit/examples/networks/TestInfiniteQueue.java - InfiniteQueue is in fact a subnet (static, but it could be dynamic in the future)!  Have fun!

Thanks again for the feedback!

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-progra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/7b2c5ce2-b843-4cf6-a0a1-4b3e9d38d27en%40googlegroups.com.

paul tarvydas

nepřečteno,
11. 4. 2021 16:05:2311.04.21
komu: 'Alex Kelley' via Flow Based Programming
Hi Dion,

> My question is -- does the Java implementation of FBP as it currently exists support dynamic updates of network topology?

If I may, I think that you are asking the wrong question.

1) I think that you are asking "does this system come with the stuff I want built-in?".

versus asking:

2) "After learning to use this, can I build anything I want? Can I just plug software components together?"

The beauty of using pluggable concurrent components is that you can plug together a solution to anything you want.

That's the Holy Grail of software development.

#1 usually boils down to something you don't really want - if it's already built-in, then it was designed by someone else for someone else's problem, not your problem.

pt


appendix:

call return spaghetti: https://guitarvydas.github.io/2020/12/09/CALL-RETURN-Spaghetti.html

dynamic anything is bad: https://guitarvydas.github.io/2021/03/06/Dynamic-Anything-is-Bad.html

holy grail: https://www.youtube.com/watch?v=6BwyYxiCvs8&t=2s

The Mars Pathfinder disaster - https://www.rapitasystems.com/blog/what-really-happened-software-mars-pathfinder-spacecraft (NASA encountered the inconvenient truth about using the synchronous paradigm for embedded system design).

further musings: https://guitarvydas.github.io/ and https://www.youtube.com/channel/UC2bdO9l84VWGlRdeNy50fIg

Ruud Steltenpool

nepřečteno,
11. 4. 2021 16:50:0211.04.21
komu: Flow Based Programming
Dion,

For graphical design of FBP networks would the interaction below make sense as a base?
-finger1 down
-speak name of sending process to define
-finger2 down
-speak name of channel to connect processes
-finger1 up
-speak name of receiving process to define

I've been meaning to prototype that for years and properly dive into FBP to see if it makes sense and if it could be a UX that doesn't slow my thoughts down much, but keeps my Flow.
After Christmas my youngest goes to school, maybe then. My sort of personal slightly longer reminder: https://github.com/steltenpower/MultiTouch-FlowBasedProgramming

Hope the above is in some way helpful anyway (I'm mostly the occasional lurker here, far from active, far from an expert)

Paul Morrison

nepřečteno,
11. 4. 2021 19:05:2011.04.21
komu: flow-based-...@googlegroups.com
Brilliant, Ruud! 

I would be fascinated to see a prototype - maybe http://www.ling.helsinki.fi/~gwilcock/Tartu-2003/L7-Speech/JSAPI/Recognition.html would help!

However....  bear in mind that we have users from all over the world, speaking different variants of English (or Dutch, or ...) - even people from different parts of the UK often can't understand each other!  ☺

Cheers,

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-progra...@googlegroups.com.

Paul Morrison

nepřečteno,
11. 4. 2021 19:22:2511.04.21
komu: flow-based-...@googlegroups.com
I love the Pathfinder story!  The diagram in the article reminds me of a multithreading program I wrote for the IBM 650 in about 1961...  Just round-robin scheduling, but it worked pretty well - the problem being that data accesses were so slow relative to processing speed that I was able to have 6 "threads" running interleaved!

Cheers!

PS If they had used Boost, it might have prevented this problem...  😉

--
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-progra...@googlegroups.com.

Ruud Steltenpool

nepřečteno,
11. 4. 2021 22:55:3711.04.21
komu: Flow Based Programming
Speech is not directly used for commands in this case, 'only' for naming, which means a recognition error doesn't stop you. Fix things whenever you like (especially if you keep the tiny audio fragments). In theory I could draw something, whisper something Dutch in the ear of my 3-yr old (who still misses about 4 sounds) to repeat to the computer expecting english and it still wouldn't be completely useless (to me). Of course it would be more work to do the renaming so others can read it.
If any of the 3 elements in such a 'sentence' is already defined you don't need to speak 'm, so recognition even less needed there.
Odpovědět všem
Odpověď autorovi
Přeposlat
0 nových zpráv