0
I Use This!
Activity Not Available

Project Summary

A chart is a dataflow program written in a piping style. Where UNIX might call for 'a | b | c', we write 'a b c'; we show nodes, but edges are implicit. Semicolon is a parallelization operator; it represents the copying of the input data: in 'nodeA (nodeB ; nodeC) nodeD' user input passes into nodeA; nodeA's emissions are sent both to nodeB and to nodeC; their emissions are merged and sent to nodeD, the emissions of which are produced as output.

The data, as it passes from the left to the right, is called a flow. The flow is split by a semicolon and merges at the end of scope. A flow contains many named channels. One channel carries a single data element, of any type. Strictly, a channel is a contract between nodes that emit on it and nodes that listen to it, defining how data will be passed. A stream is a unity, so any channel may be a stream. (In the present implementation, every channel is a stream.)

Nodes are reentrant and stateless, substantiated on the arrival of input. Because a stream is a unity, the node maintains state until the end of the stream, but this behavior is incidental -- the node is persistent due only to the data's persistence.

If a node ignores a channel, that channel will continue past it to be connected where it is needed. Renaming and namespacing operators are proposed to help prevent name collisions. An entire flow can be namespaced into a single channel, and a node can be executed within the context of a single channel.

A chart is a valid node. That is, if we have: chart1='nodeA (nodeB ; nodeC) nodeD' and chart2='node1 chart1 node2', this latter is equivalent to chart2='node1 nodeA (nodeB ; nodeC) nodeD node2' by a simple substitution rule.

Future work:

The Python implementation of a chartrunner is meant to allow immediate use of a chartrunning system and to be changed easily as experience dictates. There is no plan to use channels as anything but streams, but distributed computing will be supported. To distribute a chart, the full (net-unaware) program can be shared. Each machine can automatically produce a networked version of the chart by replacing a subset of nodes with networking nodes. 'a (b ; c) d' might become 'a net d' on one machine and 'net (b ; c) net' on another; alternately, 'a net' on one machine, 'net (b ; c) net' on a second, and 'net d' on a third. In each case, the 'net' keyword must be fully qualified with address and protocol.

Charts can be interpreted in one of two styles: the imperative style (presently in use) and a declarative style. In the declarative style, a node represents both a test of a relationship and a fix if that test should fail. This differs from the imperative style in its keeping of state; state is maintained on the channels (not in the nodes) and changes in state propagate through the chart as dataflow. Such an approach might be appropriate for application programming, and particularly for user interface.

If channels carry access locks then a chart takes on an imperative procedural style. This way of thinking may help programmers transition to use of a distributed methodology. It also suggests the possibility of a purely chart-based language.

Tags

awesome chart programminglanguage python research

In a Nutshell, chartrunner...

 No code available to analyze

Open Hub computes statistics on FOSS projects by examining source code and commit history in source code management systems. This project has no code locations, and so Open Hub cannot perform this analysis

Is this project's source code hosted in a publicly available repository? Do you know the URL? If you do, click the button below and tell us so that Open Hub can generate statistics! It's fast and easy - try it and see!

Add a code location

MIT License
Permitted

Commercial Use

Modify

Distribute

Sub-License

Private Use

Forbidden

Hold Liable

Required

Include Copyright

Include License

These details are provided for information only. No information here is legal advice and should not be used as such.

This Project has No vulnerabilities Reported Against it

Did You Know...

  • ...
    use of OSS increased in 65% of companies in 2016
  • ...
    compare projects before you chose one to use
  • ...
    in 2016, 47% of companies did not have formal process in place to track OS code
  • ...
    data presented on the Open Hub is available through our API

 No code available to analyze

Open Hub computes statistics on FOSS projects by examining source code and commit history in source code management systems. This project has no code locations, and so Open Hub cannot perform this analysis

Is this project's source code hosted in a publicly available repository? Do you know the URL? If you do, click the button below and tell us so that Open Hub can generate statistics! It's fast and easy - try it and see!

Add a code location

Community Rating

Be the first to rate this project
Click to add your rating
   Spinner
Review this Project!
Sample ohloh analysis