Enable CGI Apache2 (Debian et al)

C++ Server Side Web Development

CGI, the Common Gateway Interface is a simple way to write web applications. It is by no means the fastest and some may say that:

"If you're planning to write your web application in C++, it would be total waste to then interface it as CGI.

My suggestion would be to build it asynchronous using ASIO (Asynchronous I/O). With that you can build blazing fast web service (combine with nginx as a reverse-proxy and statics server for best effects); Combine that with template library like Wt and you're ready to serve tens of thousands request per second from a single server.

Whether this is practical alternative to dynamic language web framework is another issue." vartec 2013 

However, it is a simple way of demonstrating server side web development with a number of programming languages, including C++.

Install Apache2

To support websites built with C++ using the CGI requires webserver software capable of (which is all of them) and configured to enable (not all of them) execute code in a cgi directory.

Migrating to Bitbucket and turning my markdown frown upside down with Dillinger WYSIWYG and Cloudup image drop spot.

Check out my fancy markdown https://bitbucket.org/ifknot/liblog

Why move from GitHub to Bitbucket?

Bitbucket, similar to GitHub, is a web based GIT hosting service for your projects. It offers free private repositories with free private wikis on accounts of up to 5 users(!) and you can switch any repo public and back again anytime. So develop in private and publicise when you're ready. 

GitHub’s  free account doesn’t allow for private repos and their lowest paid option (for organizations) only allows up to 10 private repos. Bitbucket, on the other hand, offers unlimited private repos. 

It's easy to import directly from GitHub with the click of a button - well done Bitbucket.

What to move first?

I moved over liblog the logging software that I first blogged about way back in Jan 2014 but wanted to have a nice front piece for when I chose to make it public. This can be easily achieved using markdown in a README.md file pushed to the repo. 

Markdown frown. 

dillinger.io
Markdown is (quite) easy but slow to hand roll but with the excellent online WYSIWYG markdown editor Dillinger "Type some Markdown on the left... see HTML in the right" I found it pleasurable to work with and get some decent looking results.

Gratis image drop.

A free account on Cloudup gives you space to drop pics/vids/music/docs and have nifty short URLS to them for your markdown/blog/web

Fontastic! Meaningful programming ligatures with FiraCode

Fira Code: monospaced font with programming ligatures

Fira Code is an extension of the Fira Mono font containing a set of ligatures for common programming multi-character combinations. It is easy to install in OS X and works with Qt Creator.

I think I like it :)

Qt Creator 4.1.0 released

Qt Creator 4.1.0 Released!

From the Qt Blog via Eike Ziller:

https://blog.qt.io/blog/2016/08/25/qt-creator-4-1-0-released/

 How To Update:

1. Run the Maintenance Tool app (found inside your Qt folder).
2. Follow this (if you need to).
3. ?
4. Profit

Emergent Cascading Distributed Termination - Graceful shutdown for libfbp

Lets stop monkeying around with termination in FBP 

TL;DR Herein proposed Emergent Cascading Distributed Termination (ECDT) whereby the libfbp component, viewed as an isolated push down automaton(PDA)[1], either:

• Reaches its own internal accept/final state and, as part of removing itself from the execution model's purview,  closes all its connection(s).

or

• Reacts to the closed exception(s) thrown by its connections(s) and reaches its own alternative, or only in some cases, final state and, as part of removing itself from the execution model's purview,  closes all its remaining connection(s).

and so on.

Thereby gracefully, and yet unknowingly, cascading the closed connections through the program graph ensemble of components allowing each to reach their final state and spread the cascade.

In order to retain the fungibility and black-box isolation requirements of FBP a component's terminating behaviour must be both dependency inverted, from an OOP perspective, and non-cooperative from a CSP theory perspective. With these immutable axioms in hand how then might libfbp not only terminate but do so gracefully?

Buliding Blocks: Experimental proof for fast lock-free connections - Also plotly is cool!

Simplicity is the ultimate sophistication.

TL;DR  An experiment to show that a lock-free queue designed to service only a single producer and single consumer can complete 1B write-read transactions in less than a quarter (27%) of the time that a multiple producer and multiple consumer lock based queue will take. Further, replacing the modulus function with a bit mask leads to further performance gains (24%) and then using the different memory models appropriately results in yet more performance gains (18%), and very cool graphs can be drawn using plotly!

C++11 Variadic template factory member function fun! Building a FBP directed graph class.

photopin cc

Better by variadic design?

TL;DR The libfbp library needs a directed graph container for the ensemble of communicating components that makes FBP programming as easy and error free as possible. Achieving these goals by giving the directed graph class the responsibilities for creation, storage, lifetime and execution of its components and connections poses the challenge of how to implement generic factory methods that allow the creation of a zoo of unknowable components and connections?  C++11/14 variadic template metaprogramming to the rescue!

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.

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.

A CSP approach to FBP inter-component communication

photopin cc

Any portal in a storm!

TL;DR Sometimes maligned, C++ multiple inheritance allows an object to be 2 things at once—such as both an input port and an output port. In this way any would-be-component class that multiply descends from both fbp::input and fbp::output port classes has the is-a-relationship that enables it to be connected to any other so descended component. Neat huh?

It is axiomatic in Hoare's CSP theory[1][2][3] that the internal states of a Component are invisible to its environment and communication between processes can only take place at one of two unidirectional input and output channels. Most common variants[4] of CSP approach the two channel restriction problem by describing communication at multiple named unidirectional channels such that each CSP event m.t consists of two  parts: m the channel name and t the message content. Thus for a process that engages in event t via channel m and then behaves as process P is denoted:

m.t -> m.P

In order for libfbp to be CSP compliant then, the only communication that an fbp::component can engage in is via its named input and output ports. Assuming it is possible to build any functional FBP program using libfbp  then there is no reason that CSP compliance should be sacrificed, and with it the opportunity to use process calculus to prove program correctness. With this goal of CSP compliance in mind, what then is the best way to implement port only based communication?

Compile-Time Brittle Run-Time Robust Static Type Safe FBP Connections

photopin cc

A bit of C++ untyped-to-typed separation template magic...

TL;DR You can have your cake and eat it! With collections of non-typed connectable classes static_cast to the typed template connection<T> interface opens up a world of ways of connecting together components!

The design decision to construct libfbp as a strictly type safe implementation of FBP is primarily aimed ensuring that no operation leads to undefined behaviour. 

Unfortunately there is an implementation dichotomy between being able to create a typed first-class FBP connection object and freely pass around such connections as the arguments in generic functions that manage those connections or the collections that store them.

A CSP approach to FBP Information Packets

What exactly are we delivering here?

TL;DR Don't look now the CSP event is the FBP IP, the FBP IP is the std::unique_ptr.

The real world has put a significant crimp on my programming of late but I have had plenty of time to think about things, so this post is rather theory heavy and code light.

The axiomatic processes of CSP Theory have been implemented as FBP Components here, here and here; but what of the FBP Information Packet (IP) - does it have a CSP equivalent?

A CSP approach to FBP Components: #3 RUN the livelock component #4 CHAOS the unpredictable component

Just because you're doing something doesn't mean everything is going well!

TL;DR The CSP process RUN represents livelock[1] and the entirely unpredictable mix of livelock and/or deadlock[2] is represented by the CHAOS process. Despite the difficulty in detecting these 2 worse case scenarios they are embodied as libfbp components.

The distributed deadlocked component that is failing to progress can be detected[2] by limiting the amount of time that a component will tolerate failing to progress. A much harder situation detect is one of livelock where a component will engage in any Information Package (IP) without making any meaningful progress. Harder still to detect is that chaotic component which can either engage in any IP or refuse to engage in any IP - it is in a superposition of livelock and deadlock!

A CSP approach to FBP Components: #2 SKIP success component.

Successful termination.

TL;DR  The next primitive CSP process to emulate in libfbp is SKIP for successful termination.

Given that the theory of Communicating Sequential Processes (CSP) is not a programming language but rather a mathematical notation for process algebra, nevertheless, there are a number of concurrent programming languages based on CSP; for example occam and Ada .

A CSP approach to FBP Components: #1 STOP the broken component.

Handling the broken component.

TL;DR FBP originates from the unashamedly pragmatic narrative tradition of software development and, consequently, lacks any mathematical semantics. The Theory of CSP is proposed not only as mathematical semantics for FBP but also a basis for its design and implementation. (Which I discuss at length in my Masters Thesis.)

As previously discussed here, it is clear that FBP falls into the Message Passing Model (MPM) of concurrency models. Further, message passing between isolated processes is a rudimentary description of not only FBP but also of Sir Tony Hoare's Communicating Sequential Processes (CSP)[1].

libfbp component interface

One Interface to rule them all, One Interface to find them,
One Interface to bring them all and in the Scheduler bind them
In the Land of Execution Models where the Programs lie.

TL;DR A PXM API for the libfbp PPM Components whereby; the underlying execution service can view each Component as an enqueuer of message requests[1] composed of C++11 function<void()> types behaving as functors[2]. 

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. 

Stuff about C++11 that I like... #1 Inherited Constructors

Inherited constructors make life easy.

Depending on your mood the (counter)intuitive scope behaviour of class members such that ordinary scope rules apply to class members. In particular, a member of a base class is not in the same scope as a member of a derived class.[1]

Static variables in template class results in smart enqueuer-dequeuer pattern.

Decorator pattern[1] tricks to reduce queue dependency

TL;DR this one simple trick for static member initialization in a class template[2].

The original rather dumb enqueuer and dequeuer used the shared_queue class to track their counts and close the underlying queue accordingly. Giving them each their own static count makes the shared_queue wrapper redundant and usage more intuitive, but how to initialise the static variable was a brief head scratcher...

Part (2/2): Active Objects for Asynchronous Logging.

Contra-auguste Active Object

TL;DR It's just an slightly better (imho) implementation of Sutter's Dr. Dobbs 2010 articles [1][2]

As per Lavender & Schmidt's article[3] Sutter's implementation is a further refinement of the integrated scheduler variant of their original pattern removing, as it does, altogether the proxy and scheduler relying on direct message passing between client and scheduler. 

Indeed Sutter's scheduler (his Active class) contains the message queue as a private composition -which is too much integration. Too much because it forces the client to be aware of the scheduler which as an unnecessary, and avoidable, level of dependancy that binds the scheduler to the client.

The client need only be aware of the tail of the activation queue and, hence, the has-a-relationship with the message queue can be broken out of the scheduler for a more naturally component orientated approach that facilitates scheduler fungibility. Further, the scheduler need only be aware of the head of the activation queue.