A simplified libfbp component and a general purpose work-stealing, back-off threadpool to get things going.

photopin cc

Sucked into a general purpose threadpool!

TL;DR To paraphrase Thoreau "Decouple, decouple, decouple!" the clumsy component that needed to take a dequeuer is simplified to a virtual interface PPM API facilitating generalisation for PXMs. There's also a threadpool PXM so that FBP can run out of the box.

As previously stated the primary strategic goal here is that the libfbp implementation of Flow-Based Programming (FBP) as a Parallel Programming Model (PPM), though the FBP paradigm is a lot more more than simply a PPM, should be agnostic to its underlying Program eXecution Model (PXM) but must, never-the-less, provide an Application Programming Interface (API) that remains versatile in its implementation. 

In an effort to achieve this goal the original component here was overly complex and took on too much of the scheduling burden the simplified component presents a single virtual operator()() member function that returns a component*. The API contract is simple, the returned component* points to the next component to be executed and a returned value of null_ptr removes the component from the execution pipeline.

Template Metaprogramming is cool! Using C++11 template overloading to make sense of queue behaviour.

photopin cc

Metaprogramming putting meat on the bones.

TL;DR Using an enumerated type as a behaviour selector at compile time by using template overloading[1] to select either total or partial queue access[2] behaviour whilst maintaining the same queue ADT interface 

The libfbp design goal is for a uniform queue interface as per the prescribed Abstract Data Type definition here using only enqueue and dequeue access class functions instead of having separate class function method calls for either partial or total access behaviour i.e. to get rid of try_enqueue and try_dequeue.

Back from 2 weeks all inclusive Gran Canaria

Went to Gran Canaria this is the infinity pool and one of the all inclusive bars... "What time is it?" "It's Caipirinha time!"

Stuff about C++11 that I like... #2 Delegating Constructors

photopin cc

Delegating constructors is cool.

TL;DR With C++11 you can kiss goodbye to some 'init' method function shared between constructors or copying and pasting between your constructors.

#libfbp freenode IRC

photopin cc

#libfbp IRC

The Future of Programming - Bret Victor / July 30, 2013 DBX Conference

Ged Byrne clued us into this one over at the Google Flow-Based Programming group:

Here is an entertaining talk: http://worrydream.com/dbx
The presenter, Bret Victor, has a simple conceipt: it's 1973.  He looks at all the amazing ideas that were coming together and shows the obvious direction of programming.
He highlights how absurd, no tragic, it is that programming is where it is today.  
I love this line: "we can rely on the computers getting faster.  What we can't rely on is people changing the way they think."
Regards,

Ged

It's all good but for me the best bit starts at 22:05

Mathematical Semantics for FBP - Describing Fundamental FBP Program Types

photopin cc

A glittering treasure of mathematical semantics for FBP or fool's gold?

TL;DR Examples of using mathematical semantics for FBP by combining (named channel) Theory of CSP and Graph Theory to describe 3 fundamental FBP program graph types which can form the basis for both reasoning about experimenting with libfbp programs.

As I have argued so far here, here, here, here, here and here, my overarching proposition in searching for a useful mathematical description for Flow Based Programming is that an FBP network of black box processing components that communicate information packets via one-way connections can be modelled as a directed graph of communicating sequential processes.

But how might such a model be usefully applied to reasoning about FBP and what might a fundamental FBP program be?

In searching for fundamental classes of FBP programs is it worth trying to define programmatic identities that can be compared both within and across implementations to reason about a class of FBP programs?