New DrawFBP release

461 views
Skip to first unread message

Paul Morrison

unread,
Feb 21, 2019, 10:05:13 PM2/21/19
to Flow Based Programming
Release v2.16.1 is now available on GitHub/drawfbp.  It has a couple of new functions, as well as having had a number of earlier problems corrected. 

The most important new functions are:

- Compile Java program, and

- Run Java program

DrawFBP is written in Java, so it is relatively easy for it to run Java networks - it could probably be enhanced to compile C#, as well...  Is there any interest?

Under the covers, DrawFBP now uses javaGeom, so the jar file for this has to be added to the Eclipse build path, or included in a classpath parameter for running as a DOS command.  This is described in


If anyone has ideas about how to package this better, I'd be glad to hear about it!

The latest release of DrawFBP is now available from Maven by entering


Finally, the Excise function has been slightly modified: external port attributes are now entered by modifying the External Port blocks, not the Enclosure block.


Paul Morrison

unread,
Feb 22, 2019, 9:53:08 PM2/22/19
to Flow Based Programming
Bug found in DrawFBP v2.16.1 in Compile function (thanks, Bob!).  I will be posting a fix shortly, which will be Release v2.16.2.

Apologies, and thanks for your patience!

Ged Byrne

unread,
Feb 23, 2019, 5:23:43 AM2/23/19
to flow-based-...@googlegroups.com
Hi Paul,

Wonderful news.  The release not the bug.  I look forward to downloading and giving it a try.  

It sounds like you are moving towards a full IDE.  Do you have any concrete plans in that direction?

Regards,


Ged

--
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.
For more options, visit https://groups.google.com/d/optout.

toivo...@gmail.com

unread,
Feb 23, 2019, 10:34:14 AM2/23/19
to Flow Based Programming
Hi, 

If IDE is a goal, I recommend using standard IDE and creating DrawFBP as plugin for IDE.

Creating IDE itself requires lot of work, it’s not worth the effort, I think. And later maintenance is nightmare.

For example creating Eclipse plugin is not very difficult. It requires initially fair amount of work.

But once you know how handle all quirks, its relatively easy.

And from now on you have all Eclipse features for free. Open source code from your DrawFBP, edit and save, no problem. Compile and run your flow, just few clicks. Debug, easy. Sync with Git or SVN, easy. Etc.


Thanks

Toivo

To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.

Alex Korshunov

unread,
Feb 25, 2019, 6:27:25 AM2/25/19
to Flow Based Programming
Great!

Paul Morrison

unread,
Feb 25, 2019, 11:01:17 AM2/25/19
to Flow Based Programming
Thanks for the encouragement, gentlemen! 

And Bob, I think I found your Save problem... for which many thanks!

Accordingly, I have upgraded DrawFBP v2.16.2 from pre-Release to a full Release.  I will do some more testing, and then put it up on Maven in the next few days...

Toivo, I like the idea of an Eclipse plugin - I will investigate that...  I assume that a) Eclipse is a very popular (the most popular?) Java development vehicle (at any rate I am fairly familiar with it, although not with plugins!), and b) that it runs in a variety of different environments...  If I start to dig into it, would you be willing to give me a hand occasionally?

One area I am still confused about is how Java packages work with the folder structure - e.g. the folder structure of the classes built by javac seem to be based on the package statement, not on the source folder structure.  So far I haven't been able to find a description of why this should be so - does Eclipse work like that too?

Thanks again - as always, feedback will be very welcome!

Paul Morrison

unread,
Feb 25, 2019, 11:24:18 AM2/25/19
to Flow Based Programming
Another packaging question:

Is there a cleaner way to incorporate javaGeom in the deliverables, compared with the way I describe in https://github.com/jpaulm/drawfbp/blob/master/README.md ...?

TIA

toivo...@gmail.com

unread,
Feb 26, 2019, 9:00:40 AM2/26/19
to Flow Based Programming

Hi Paul,


I am not Eclipse expert, but I will try to help you.


Eclipse is widely used, I use it under both Linux and Windows.


If you decide to create Eclipse plugin you have 2 options:


1. Download Eclipse IDE for Eclipse Committers

(which contains Eclipse Plug-in Development Environment, in short PDE).


2. If you prefer to keep your current Eclipse, you can install PDE plugins separately.


Next, It might be useful to play little with plugin examples.

From Eclipse menu → New → Other… Plugin Development → Plugin-in Project → Next

Wizard will open, give some to project → Next → Next and choose one of the templates.


Eclipse have different kinds plugin-s with different functionality.


Usually all wanted functionality is implemented as set of plugins.

You may want to start with one plugin, which is probably some kind of Editor.

And add other plugins later.


When you start actually implement editor plugin, you need to choose which graphical framework you use. Eclipse itself uses SWT, but I understand you have already lot of code in Swing. Swing can used in Eclipse plugin also.

See

https://stackoverflow.com/questions/23675830/turn-java-swing-application-into-eclipse-plugin


Where are other alternatives as well, for example

https://www.eclipse.org/graphiti/


Also you can use JavaFX in Eclipse plugin.



>> Another packaging question:


Instead of

java -cp "javaGeom-0.11.1.jar;build/libs/drawfbp-2.15.10.jar" com.jpaulmorrison.graphics.DrawFBP


you can use something like (put all your jar files into lib subdirectory)


java -cp "lib/*" com.jpaulmorrison.graphics.DrawFBP

And in case of Eclipse plugin – all needed jars are packed in plugin.

Regards,
Toivo

Paul Morrison

unread,
Feb 26, 2019, 12:52:29 PM2/26/19
to flow-based-...@googlegroups.com
Many thanks, Toivo!  This way of invoking DrawFBP is much cleaner!  For releases in pre-Release status, we might have to use the old technique, though!

Did you see my question about packages and folder structure?  Any thoughts?

I'll definitely look at plugins!

TIA

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.

Ged Byrne

unread,
Feb 26, 2019, 3:31:02 PM2/26/19
to flow-based-...@googlegroups.com
Hi Paul,

The package and the folder structure should always match. The standard class loader will convert the full class name into a path to load the class.  

Here’s the description of the package model in the language specification. 

If you read the purple box in section 7.2 it gives the full details.  

if this simple organization were used on an operating system where the file name separator is /, the package name:
jag.scrabble.board

would be transformed into the directory name:

jag/scrabble/board

It’s possible to change this behaviour by implementing a custom class loader.  

Regards,


Ged

Paul Morrison

unread,
Feb 26, 2019, 4:16:34 PM2/26/19
to Flow Based Programming
Thanks, Ged!

This implies that you can never have a source module directly in the src\ folder...?  Or can you have modules that are not part of packages - i.e. with no 'package' statement?

TIA

Paul Morrison

unread,
Feb 26, 2019, 8:18:05 PM2/26/19
to flow-based-...@googlegroups.com
Looks like you can have small programs with no package statement!

Thanks, everyone!

Paul Morrison

unread,
Feb 27, 2019, 10:21:34 AM2/27/19
to Flow Based Programming
Release v2.16.2 now checks that the package statement in Java programs matches the folder structure.  It is now available on Maven Central.

Cheers,

Paul M.

Paul Morrison

unread,
Mar 16, 2019, 10:09:05 PM3/16/19
to Flow Based Programming
As you may have seen, I have decided to implement a first attempt at Compile and Run facilities in DrawFBP - first for Java, and then more recently for C#.  These are both working - at least for my test cases - using my latest release, v2.16.4.  The issues I am running into are all related to packaging, so I have sort of reached the limits of my knowledge of this for both Java and C#...  Toivo made a suggestion for packaging the more recent releases (for which thanks, Toivo), which works well for normal Releases, but IIUC requires pre-Release code to be treated differently, so feedback on that would be great (described in https://github.com/jpaulm/drawfbp/blob/master/README.md )!

For Java, I have separated the function of compiling (components and networks) from that of running networks.  The generated classes generate .class files in the 'bin' directory, if there is one.   If there isn't, the .class files go into the same folder as the corresponding source files (OK?).  

'Run' runs one of these classes, provided that it has a 'main' method.  Following the style of other DrawFBP functions, the user can specify one or more jar files for the program's build path (in addition to the JavaFBP jar file).

The 'package' clause has to match the top directory level(s) of the source code.

I have followed basically the same pattern for C#, with 'namespace' being treated the same way as Java 'package'.  The main difference is that my C# Compile compiles all the programs in a folder, and creates an .exe file with the same name as the folder...  Does this make sense?!

As we found with some of my previous problems, these tend to be caused by my being too familiar with the code, so it would also be great if experts in Java or C# respectively could do some testing of DrawFBP!

Toivo, I will look into Eclipse plugins next! 

Regards,

Paul M.

Paul Morrison

unread,
Mar 19, 2019, 11:24:56 AM3/19/19
to flow-based-...@googlegroups.com, Bob Corrick, Toivo Adams
Pre-Release versions v2.16.3 and v2.16.4 of DrawFBP have been deleted - sorry, people!  Release v2.16.5 has now been created, and is in pre-Release status.

This release now supports compiling and running C# programs.  If your program requires additional dlls, you can add them using the File/Add Additional Dll File function - this is analogous to the File/Add Additional Jar File function, delivered a few releases ago.

Currently there is no DrawFBP-supported way to delete jar or dll files from DrawFBP's list, but you can delete them manually by editing user.DrawFBPProperties.xml .  I will add a function to clear this in an upcoming release.

Feedback would be much appreciated!

Cheers,

Paul M.

Paul Morrison

unread,
Mar 24, 2019, 3:01:28 PM3/24/19
to Flow Based Programming
I was not too comfortable with Release v2.16.5, so I have upgraded to v2.16.6 - it is in DrawFBP Releases in pre-Release status.

Feedback would be appreciated!  (Try the Compile and Run features!)

Cheers,

Paul M.

Paul Morrison

unread,
Apr 20, 2019, 11:17:45 AM4/20/19
to flow-based-...@googlegroups.com, Bob Corrick, Toivo Adams
I would very much appreciate having some volunteers for testing my latest release of DrawFBP - v2.16.10. 

The main change, which might interest some of you, is that I am now generating.fbp notation (originally developed by Wayne Stevens, and adopted by NoFlo).  This is now being treated as a (mini-)language, on a par with Java and C#, rather than as a function under File.  Of course it does not support the newly implemented "Compile" and "Run" functions...

I have not put this release up on Maven yet, as Maven will not allow me to make small tweaks IIUC, so it needs a bit of testing before this happens.

As I have asked before, any ideas about packaging of DrawFBP would also be welcome - I'm currently using Toivo's idea about grouping multiple jar files in the 'lib' directory, but this does not readily support a "pre-Release" status...

Regards,

Paul M.



toiv...@gmail.com

unread,
Apr 21, 2019, 6:39:07 AM4/21/19
to Flow Based Programming
Hi Paul,

You can pack all your jar files to one ‘fat’ jar file.
Maven will do this for you, but you need to add instructions to Maven pom file.
Also Gradle can build fat jar.

https://stackoverflow.com/questions/19150811/what-is-a-fat-jar

Maybe this helps you?

Regards, 
Toivo
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.

Paul Morrison

unread,
Apr 21, 2019, 4:26:47 PM4/21/19
to flow-based-...@googlegroups.com
Thanks, Toivo, that sounds great!  Wish me luck building a fat jar!

To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

unread,
Apr 22, 2019, 2:14:54 PM4/22/19
to flow-based-...@googlegroups.com
Hi Toivo,

I have successfully created a "fat jar" ...  and it seems to work!  So far so good!  Many thanks!

Now in https://stackoverflow.com/questions/19150811/what-is-a-fat-jar , they talk about doing it in Maven (starting with "<pluginrepositories>") - can I just put this (maybe using some other syntax) into the writeNewPom in build.gradle?  Probably dumb question!  I confess I don't really understand how Gradle talks to Maven!

Thanks in advance,

Paul

On Sun, Apr 21, 2019 at 6:39 AM <toiv...@gmail.com> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

toiv...@gmail.com

unread,
Apr 24, 2019, 7:01:38 AM4/24/19
to Flow Based Programming

Hi Paul,

 

I don’t know Gradle.

 

I use Maven and in pom file it looks like

 

                .    .    .

 

       <build>

           <plugins>

 

              <plugin>

                   <groupId>org.apache.maven.plugins</groupId>

                   <artifactId>maven-assembly-plugin</artifactId>

                   <version>3.1.0</version>

                   <configuration>

                       <descriptorRefs>

                           <descriptorRef>jar-with-dependencies</descriptorRef>

                       </descriptorRefs>

      

                   </configuration>

                   <executions>

                       <execution>

                           <id>assemble-all</id>

                           <phase>package</phase>

                           <goals>

                               <goal>single</goal>

                           </goals>

                       </execution>

                   </executions>

                     </plugin>

       

            </plugins>

       </build>

 

Regards, 

Toivo

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.

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

unread,
Apr 24, 2019, 11:11:20 AM4/24/19
to Flow Based Programming
Thanks, Toivo.  However, I may have to look for other solutions...?  I just read https://product.hubspot.com/blog/the-fault-in-our-jars-why-we-stopped-building-fat-jars by Jonathan Haber, and he lists a number of issues with fat jars, including size.  My fat jar is about 8 Megs!  His product SlimFast may be a solution... if I can fit it into my environment!

I did try to use Ray Holder's gradle-one-jar, but haven't been able to get it working yet!

Regards,

P.

ComFreek

unread,
Apr 24, 2019, 1:26:51 PM4/24/19
to Flow Based Programming
I have been following the discussion and have just read it more in-depth. 

Am Dienstag, 26. Februar 2019 15:00:40 UTC+1 schrieb toivo...@gmail.com:

[...]


Eclipse is widely used, I use it under both Linux and Windows.


According to [1], IntelliJ IDEA is at least equally widely used and some sources even claim Eclipse's death. Do note that I did not research about IntelliJ IDEA's death claims, so my comment might be biased.
In any case, I would advise designing the GUI for the plugin in a IDE-agnostic way.


John Cowan

unread,
Apr 24, 2019, 2:00:52 PM4/24/19
to Flow Based Programming
I don't think you have anything to worry about.  In that article, there are 100,000 classes with all dependencies in place, and gobs of changes by a whole herd of engineers.  DrawFBP is pretty much at the opposite extreme.  What doesn't work for them should be just fine for you.

To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

For more options, visit https://groups.google.com/d/optout.

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

toiv...@gmail.com

unread,
Apr 24, 2019, 2:47:02 PM4/24/19
to Flow Based Programming
Hi Paul,

I agree, a fat jar is not always the best solution.
It’s sometimes convenient but often not worth of the trouble.

Glad you have analyzed your needs and are seeking better solution.
We learn step by step and this is a never ending endeavor.
But this is fascinating.

Regards, Toivo

toiv...@gmail.com

unread,
Apr 24, 2019, 3:37:41 PM4/24/19
to Flow Based Programming
Hi ComFreek,

I have nothing against other IDE’s, and I respect IntellJ IDEA very much.
Just I am familiar with Eclipse and there I work and ecosystem I follow, Eclipse is widely used.

IDEA might be have even more user base – I don’t know.

Any modern IDE is very complex piece of software and need large user base and community to survive.
I am confident Eclipse as this today. Don’t know what happens after ten years.

Anyway creating IDE plugin is not a simple task.
It’s not easy for Eclipse and I suspect it’s not much easier for IDEA.
(it’s only for professionals, like Paul Morrison is)
It requires a lot work and willing to solve all kind of problems.

plugin in a IDE-agnostic way – good advice, but this requires additional resources.
I suspect Eclipse and IDEA plugins (and other IDE’s plugins) are very different.
So abstracting a IDE-agnostic way would not be easy.
Paul Morrison is not able do this alone, so volunteers are needed.

Just my thoughts.

Regards, 
Toivo

Paul Morrison

unread,
Apr 27, 2019, 2:59:15 PM4/27/19
to Flow Based Programming
Hi Toivo,

Rather to my surprise I seem to have put working copies of DrawFBP, complete with its dependency on javaGeom2D, both on Maven and in the latest release of DrawFBP on GitHub - v2.16.12.

Both can be downloaded, and run just by double-clicking on their jar files.

Both seem to work, but the Maven copy is much smaller than the GitHub version!  So I assume that the Maven version somehow gets its knowledge of javaGeom from somewhere else, e.g. Maven itself...?

What is strange is that I used a technique described in https://stackoverflow.com/questions/35654812/publish-custom-jar-output-with-gradle#  , which allows you to do

     gradle fatJar uploadArchives

which makes me wonder why the jar on Maven isn't "fat"!

Anyway, I seem to have a technique that works in both cases, so I guess I shouldn't worry too much - it just seems a bit strange...!  If you feel like looking at DrawFBP, it is at

Thanks for your help!

Paul M.


On Wednesday, April 24, 2019 at 2:47:02 PM UTC-4, toiv...@gmail.com wrote:
Hi Paul,

Paul Morrison

unread,
Nov 28, 2019, 9:55:55 AM11/28/19
to Flow Based Programming
Thanks for the kind words, Toivo!  I am beginning to suspect that I am losing my programming "chops" - but at any rate I seem to have v2.18.6 of DrawFBP working - https://github.com/jpaulm/drawfbp/releases/tag/v2.18.6 .   It is also now on Maven - just click on the Maven "shield" in https://github.com/jpaulm/drawfbp/blob/master/README.md and select "download" and "jar".  I am still using the "fatJar" concept, but the jar file is a lot smaller (around 1.3 Mb) - I realized I was hauling in a couple of massive libraries, resulting in considerable "bloat"!

DrawFBP also can now compile and execute Java and C# FBP networks.  You might want to try out the Concordance app in C# : change language in DrawFBP to C# and (assuming you have downloaded https://github.com/jpaulm/csharpfbp) compile and run TestCases/Concord/Concordance.cs . - it's kind of fun!

Thanks also, Bob (Corrick) for all your hard work testing it, and to all of you who made suggestions!

I now realize that DrawFBP is the tool I wish I had 50 years ago, when I first started working with data flows!  DrawFBP has been evolving steadily since I first put it up on SourceForge (no longer active there!), and closely supports the concepts of classical FBP.  It is a multi-level diagramming tool, and does not require that implementation component names be filled in, so you can do stepwise refinement on your design, filling in existing components gradually into the diagrams.

Here is a quick summary of what DrawFBP can do:

    Variety of block types, including "Initial IP", Report, File, Legend (text with no boundary), External ports (for subnets), Human (!)
    Top-down design supported - although bottom-up is also supported (blocks can be placed on the diagram and connected, and class names filled in later)
    Display subnets in separate tabs
    Convert portion of diagram to subnet ("excise")
    Specify connection capacity
    "Automatic" ports
    Checking for valid port names
    Indicate "drop oldest" attribute for given connection
    Generate complete networks in Java, C#, JSON, or .fbp notation
    Pan, zoom in/out
    Drag portion only of diagram (using Enclosure block)
    Choose fonts (fixed size and variable size, indicating support for Russian, Hindi (Devanagari), and Chinese)
    Change font size
    Structured Help facility
    Export diagram as image
    Print diagram
    Drag blocks, sections of diagram (using "Enclosure"), heads or tails of arrows; create or drag bends in arrows
    "Grid" positioning on/off
    Extra arrowhead (one per arrow)
    Compile and Run Java programs
    Compile and Run C# programs
    As of v2.18.1, File Chooser now displays date and time on non-jar items, and entries can be sorted by name (ascending) or by date/time (descending)

Enjoy!

paul tarvydas

unread,
Nov 29, 2019, 9:38:52 AM11/29/19
to flow-based-...@googlegroups.com


On Nov 28, 2019, at 9:55 AM, Paul Morrison <paul.m...@rogers.com> wrote:

I now realize that DrawFBP is the tool I wish I had 50 years ago, when I first started working with data flows! 



I strongly agree.

I think that diagrams express something that cannot be easily expressed as textual code (e.g. the structure of the graph.  Yes, it is possible to write textual versions of *small* graphs, but drawing diagrams allows such graphs to scale to new heights, beyond what is reasonable in textual code).

Also, if one draws a diagram that doesn't have underlying code, one can use the diagram as a "spec" and ship it to a remote dev to get implemented.

A diagram editor, like DrawFBP, can sanity-check a diagram to see that it is self-consistent.  This, IMO, is better than white-boarding diagrams of systems.

pt

Paul Morrison

unread,
Nov 29, 2019, 4:17:03 PM11/29/19
to flow-based-...@googlegroups.com
Makes sense, Paul!  It might be interesting to come up with a short list of possible sanity checks... - they could be added progressively...

Also, I agree about diagrams without underlying code - I often get the impression that people don't realize that you have to be able to support this to enable top-down design.  This is just as important as bottom-up - if not more so!

--
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/147725DA-DE6A-4309-B7C5-5AC7B7B7159D%40gmail.com.

Paul Morrison

unread,
Dec 14, 2019, 10:38:07 AM12/14/19
to Flow Based Programming
Working on a suggestion (not sure whose it was, but thanks anyway!) for a visual compare facility, I have just promoted v2.19.0 of DrawFBP: https://github.com/jpaulm/drawfbp/releases/tag/v2.19.0 .  The compare facility makes a guess at which blocks and arrows have been added or deleted... and/or some changes.  As with most compare facilities, there may be spurious or missed indications, but with feedback from users, I hope to refine this as time goes on...! 

I have moved to a new intermediate release level (2.19) because this release also has an integrated Help facility (another good suggestion), so that it is no longer necessary to download a separate Help jar file.  I have not combined the JavaFBP jar file with the DrawFBP one because DrawFBP was designed to be language-agnostic - you can generate both Java and C# networks, compile and run them, under DrawFBP.  It does play better with JavaFBP (you can display the ports on a JavaFBP component or subnet), but it is pretty open-ended wrt language support, and we will probably be adding new ones in the future.

As always, I would appreciate feedback!

Cheers,

Paul M.

On Friday, November 29, 2019 at 4:17:03 PM UTC-5, Paul Morrison wrote:
Makes sense, Paul!  It might be interesting to come up with a short list of possible sanity checks... - they could be added progressively...

Also, I agree about diagrams without underlying code - I often get the impression that people don't realize that you have to be able to support this to enable top-down design.  This is just as important as bottom-up - if not more so!

On Fri, Nov 29, 2019 at 9:38 AM paul tarvydas <paulta...@gmail.com> wrote:


On Nov 28, 2019, at 9:55 AM, Paul Morrison <paul.m...@rogers.com> wrote:

I now realize that DrawFBP is the tool I wish I had 50 years ago, when I first started working with data flows! 



I strongly agree.

I think that diagrams express something that cannot be easily expressed as textual code (e.g. the structure of the graph.  Yes, it is possible to write textual versions of *small* graphs, but drawing diagrams allows such graphs to scale to new heights, beyond what is reasonable in textual code).

Also, if one draws a diagram that doesn't have underlying code, one can use the diagram as a "spec" and ship it to a remote dev to get implemented.

A diagram editor, like DrawFBP, can sanity-check a diagram to see that it is self-consistent.  This, IMO, is better than white-boarding diagrams of systems.

pt

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

David Lannan

unread,
Jan 6, 2020, 7:20:31 PM1/6/20
to Flow Based Programming
Wow. This is awesome Paul. Its been nearly 18 years since I wrote (what turns out) a FBP kernel and 3D rendering system :)
After completing it, I found out about FBP and bought your book and was impressed. Imho, the concept is one of the key missing design concepts in software architecture. When I made mine, I was stunned at how easy it was to extend and improve. I ended up making three different 'Render" modules DX8, DX9 and OpenGL all able to switch live when running. It was great fun at the time and its been years since I even thought about it. 
Seeing you still releasing this awesome system has re-invigorated my own interest. I hope to be less of a lurker, and help out where possible. 

I read below on the IDE note. On Linux, OSX and Windows Visual Code is becoming heavily utilised - Id love to tackle a C++ FBP, with a VSCode visualiser :)  .. will start investigating this week.

Congratulations again Paul. This is truly awesome stuff. Imho, I think FBP will become a big deal for massive data streaming.

Paul Morrison

unread,
Jan 7, 2020, 2:07:40 PM1/7/20
to Flow Based Programming
Hi Toivo and others,

The sequence of posts seems a bit confusing, but hopefully you all have gathered that I managed to build a fat jar that contains both javaGeom2D and javaHelp  and takes up about 1.3 M.  I have also managed to get this onto Maven, by using a sort of hack:  my gradle fatJar task stores its result in DrawFBP-x.y.z.jar , but the gradle build for Maven normally rebuilds the jar (not fat!) so I had to add "-x jar" to the "uploadArchives" task invocation (right word?), so that gradle doesn't clobber my nice fat jar!

I also registered this with renovate, so if the version numbers of javaGeom2D or javaHelp ever change, they will generate PRs (pull requests) automagically!

Thanks to everyone for their help,

Regards, and wishing you all a happy 2020!

Paul M.

Paul Morrison

unread,
Jan 7, 2020, 4:47:10 PM1/7/20
to Flow Based Programming
Thanks for the kind words, David!

As I am discovering, the user experience is tough to get right... or at least pretty good!  And we all have different mental paradigms!  Witness all the different visual diagramming styles that people have come up with!  Looking forward to seeing your visualizer (if that's the right term)!

Best regards,

Paul M.

David Lannan

unread,
Jan 7, 2020, 7:11:47 PM1/7/20
to Flow Based Programming
Hi Paul, 
I didnt build a visualiser for my original one (that was back in early Win95 days :) ). But I like what people have been doing here and would love to get involved. One thing I did a little differently is when I built mine (I called it Deity :) ) I built more of an OS/kernel system and all the components/modules were dll's - which on Windows resulted in a massive amount of pain for me. So I developed my own "DLL" format which allowed instanced dll's for duplicate modules with differing stream connectivity.
But I think fundamentally its the same model. I come from old PLC programming world where INPUT->PROCESS->OUTPUT was how they all worked and it seemed odd there wasnt a similar paradigm in general software.
What I like about the visual design the most, is that it can expressively show the execution of a program. This is rare these days to be able to see a complete components execution system. 
Anyway.. rambling... look forward to digging around and helping out. I'll be putting up my old system on github if people are interested. I think it still builds and runs (which is rare too..).
Good work again Paul, and others, this is really motivating. Ive always 'believed' in this design, almost to a religious level.. I would love to help it continue.

Paul Morrison

unread,
Jan 7, 2020, 9:12:54 PM1/7/20
to flow-based-...@googlegroups.com
Interesting!  I have been around long enough that I remember HIPO charts (short for hierarchical input process output model) - see https://en.wikipedia.org/wiki/HIPO_model . They looked very pretty once they were finished, but you had to use a lot of paper and erasers.. so eventually not so pretty!  The concept was great, but pencil and paper are not so great when you have to make changes!  Why are our tools always good for system creation... and lousy for maintenance?!

Your help will be very welcome!

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/20545e02-c302-40b4-b36b-fc455fcf6e70%40googlegroups.com.

David Lannan

unread,
Jan 8, 2020, 11:29:18 PM1/8/20
to Flow Based Programming
Ahh HIPO - no, this was more rudimentary than that :) .. Ladder Logic, which was based around electrical control systems for conveyors, process plants etc (circa 1995) 

ladderlogic.png

The image shows in Windows cmd - but we were running on special Texas Instrument DOS styled computers. It never looked that good - should have taken photos, I couldnt find an example sadly. 

And they ran the GM Holdens conveyor systems, paint plants, waste treatment plants and robots (yes robots in early 90s). I was lucky enough to have spent most of my electrical apprenticeship working on these systems. It taught me alot about state, process flow and the consideration of strong safety systems for programming.

Anyway.. sounding old.. :) .. have started looking at the Cpp implementation. And I have put my old system up online - sort of still runs.

https://github.com/dlannan/deity

To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.

David Lannan

unread,
Jan 9, 2020, 1:03:32 AM1/9/20