|
|
Boost-Commit : |
From: stipe_at_[hidden]
Date: 2007-11-09 15:50:35
Author: srajko
Date: 2007-11-09 15:50:34 EST (Fri, 09 Nov 2007)
New Revision: 40972
URL: http://svn.boost.org/trac/boost/changeset/40972
Log:
version 0.8.0
Text files modified:
sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk | 67 +++------------------------
sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk | 95 ++++++++++++++++++++++++++++++++++-----
sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk | 44 +++++-------------
sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk | 35 ++++++++++---
4 files changed, 130 insertions(+), 111 deletions(-)
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk 2007-11-09 15:50:34 EST (Fri, 09 Nov 2007)
@@ -1,6 +1,6 @@
[article Dataflow
[quickbook 1.4]
- [version 0.1]
+ [version 0.8.0]
[authors [Rajko, Stjepan]]
[copyright 2007 Stjepan Rajko]
[purpose Generic dataflow lirary providing support for data producers,
@@ -67,6 +67,7 @@
[template instantiator[] [link dataflow.signals.components.generic.instantiator instantiator]]
[template modifier[] [link dataflow.signals.components.generic.modifier modifier]]
[template storage[] [link dataflow.signals.components.properties.storage storage]]
+[template timed_storage[] [link dataflow.signals.components.properties.timed_storage timed_storage]]
[template counter[] [link dataflow.signals.components.properties.counter counter]]
[template junction[] [link dataflow.signals.components.flow.junction junction]]
[template multiplexer[] [link dataflow.signals.components.flow.multiplexer multiplexer]]
@@ -124,32 +125,6 @@
[import ../example/VTK/support.hpp]
-Dataflow is a generic library for [WikiDataflow] programming using various data
-transport mechanisms. It also has layers of support for
-two data transport mechanisms - one is based on
-[BoostSignals], and the other (experimental and currently broken) is based
-connections made through
-simple object pointers, with support for using [BoostPhoenix2]
-actors for data processing.
-
-The two data transport mechanisms are implemented in the [DataflowSignals]
-and [DataflowPhoenix] layers. The idea behind providing a generic dataflow
-library is that other data transport mechanisms can be easily adapted for
-use with the library.
-
-[warning Dataflow is not a part of the Boost libraries. It is being developed
-as a part of the Google Summer of Code program. The original proposal (for
-the Signal Network library, which became the Dataflow library)
-as well as some status updates can be found on the
-[@http://svn.boost.org/trac/boost/wiki/soc/2007/SignalNetwork GSoC page].]
-
-* If you would like some more information about why one would want to connect
- objects into a dataflow network, read about
- [link dataflow.introduction.dataflow Dataflow programming in C++].
-* If you'd like to try out the library
- * keep in mind that the interface is subject to change
- * Read [how_to_use how to use this library and the documentation].
-
[include introduction.qbk]
[include concepts.qbk]
@@ -183,10 +158,13 @@
* I have started ASCII visual diagrams in the documentation.
* Examples still need to be expanded and integrated more.
-[* Jake Voytko suggested having master table of [BoostDataflow] components
- describing their use, adding instructions on linking with the library.]
+[* Jake Voytko suggested having master table of [DataflowSignals] components
+ describing their use, adding instructions on linking with the library,
+ and other suggestions on improving the documentation.]
+
* A master table has been added to the [components] page.
-* I have started a [link dataflow.introduction.link linking] instruction page.
+* I have started a [link dataflow.introduction.download Downloading and Linking]
+ instruction page.
[* Tobias Schwinger indicated that the library could be used for pulling rather than pushing data.]
@@ -202,7 +180,7 @@
[* Paolo Coletta suggested a "video_generator >>= ( effect1 && effect2 ) >>= image_sum" - like syntax that
would allow parallel processing of signals (identified as the "join" pattern by Yigong Liu)]
-* I have started to implement thread-related components in [timed_storage] and [mutex].
+* I have started to implement thread-related components in [timed_storage], [mutex] and [condition].
More sophisticated threading components, control and syntax to follow.
[* Yigong Liu suggested enhanced support for common network topologies, such as mesh. ]
@@ -231,33 +209,6 @@
[endsect]
-[section:download Download and Changelog]
-
-Please keep in mind that this code is a prototype and far from the finished product. I am learning
-as I go, and any feedback on improving the implementation is very welcome.
-
-GSoC Development version (*latest*) \[located in the Boost sandbox /SOC/2007/signals\]
-
-* converting documentation to boostbook, using Boost.Build
-
-Proposal for Boost / Google SoC version \[[@signal_network.zip download]\]
-
-* finished the signals::socket_sender and signals::socket_receiver components
-
-Draft proposal for Boost / Google SoC version
-
-* changed the file and namespace structure
-* implemented a file-iteration based mechanism for arity-dependent classes
-* changed the operators used
-* signal_link is now signals::filter and does not need to know it's descendant's type
-* implemented signals::junction, signals::selector, signals::storage, signals::timed_generator,
- signals::mutex, signals::chain, signals::function classes
-
-Original request for interest version available as attachment to
-[@http://lists.boost.org/Archives/boost/2007/02/116869.php]
-
-[endsect]
-
[endsect]
[include future.qbk]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk 2007-11-09 15:50:34 EST (Fri, 09 Nov 2007)
@@ -1,5 +1,32 @@
[section:introduction Introduction]
+Dataflow is a generic library for [WikiDataflow] programming using various data
+transport mechanisms. It also has layers of support for
+two data transport mechanisms - one is based on
+[BoostSignals], and the other (experimental and currently broken) is based
+connections made through
+simple object pointers, with support for using [BoostPhoenix2]
+actors for data processing.
+
+The two data transport mechanisms are implemented in the [DataflowSignals]
+and [DataflowPhoenix] layers. The idea behind providing a generic dataflow
+library is that other data transport mechanisms can be easily adapted for
+use with the library.
+
+[warning Dataflow is not a part of the Boost libraries. It is being developed
+as a part of the Google Summer of Code program. The original proposal (for
+the Signal Network library, which became the Dataflow library)
+as well as some status updates can be found on the
+[@http://svn.boost.org/trac/boost/wiki/soc/2007/SignalNetwork GSoC page].]
+
+* If you would like some more information about why one would want to connect
+ objects into a dataflow network, read about
+ [link dataflow.introduction.dataflow Dataflow programming in C++].
+* If you'd like to try out the library
+ * keep in mind that the interface is subject to change
+ * Read [how_to_use how to use this library and the documentation].
+
+
[section:dataflow Dataflow programming in C++ - motivation and advantages]
The [WikiDataflow] programming paradigm is based on interconnected
@@ -309,7 +336,7 @@
[endsect][/how_to_use]
[section Examples]
-[section:new_layer Implementing support for a new mechanism]
+[section:new_layer Implementing support for a new mechanism (VTK)]
This example shows how to implement support for a particular mechanism.
Our victim is [VTK], a 3D visualization toolkit, which uses a data pipeline
@@ -406,7 +433,7 @@
With the pair of [ProducerPortConcept] and [ConsumerPortConcept] registered, we
can make them [ConnectableConcept] and/or [OnlyConnectableConcept].
All we need to do is specialize the implementation for the appropriate
-categories:
+[PortTraits]:
[vtk_connect_impl_algorithm]
@@ -478,11 +505,11 @@
[heading Next]
[link dataflow.introduction.examples.new_layer.producermap
- Setting up a ProducerMap]
+ Setting up a KeyedPort]
[endsect][/filter]
-[section:producermap Setting up a ProducerMap]
+[section:producermap Setting up a KeyedPort]
Sometimes, components can produce (or consume) multiple types of data.
For example, [vtkMapper] objects can produce data for [vtkActor] objects,
@@ -491,9 +518,9 @@
the same as connecting a [vtkMapper] to another [vtkAlgorithm].
To accomodate such situations, the Dataflow library provides
-[ProducerMapConcept]s, which are similar to [ProxyProducer]s but
-the [ProducerPortConcept] they delegate to is keyed on the category of
-[ConsumerPortConcept] they are being connected to.
+[KeyedPortConcept]s, which are similar to [ProxyPortConcept]s but
+the [PortConcept] they delegate to is keyed on the
+[PortConcept] they are being connected to.
[vtk_mapper_producer]
@@ -520,9 +547,8 @@
use pointers to class types rather than class types themselves. So, with what
we have done so far, we can do `connect(*cone, *coneMapper)` but not
`connect(cone, coneMapper)`. To provide support for pointers, we
-simply make them adhere to the [ProxyProducerConcept] and,
-[ProxyConsumerConcept], and delegate the functionality to the object they
-point to.
+simply make them adhere to the [ProxyPortConcept] concept, and delegate the
+functionality to the object they point to.
[vtk_support_pointer]
@@ -578,7 +604,52 @@
[endsect][/examples]
-[section:linking How to link]
+[section:download Downloading, building and linking]
+
+[heading Downloading]
+
+I am currently preparing this library for submission for a Boost review. The
+latest version is located in the
+[@http://svn.boost.org/trac/boost/browser/sandbox/SOC/2007/signals Boost sandbox].
+
+Version 0.8.0 -
+ \[[@http://www.boost-consulting.com/vault/index.php?direction=&order=&directory=Dataflow& available in the Boost vault]\]
+
+* post-GSoC version
+* generic dataflow support layer with tests and examples
+* Dataflow.Signals layer (fusion-based implementation) with tests and examples
+* VTK example
+* quickbook docs
+
+[/Proposal for Boost / Google SoC version \[[@signal_network.zip download]\]
+
+* finished the signals::socket_sender and signals::socket_receiver components
+
+Draft proposal for Boost / Google SoC version
+
+* changed the file and namespace structure
+* implemented a file-iteration based mechanism for arity-dependent classes
+* changed the operators used
+* signal_link is now signals::filter and does not need to know it's descendant's type
+* implemented signals::junction, signals::selector, signals::storage, signals::timed_generator,
+ signals::mutex, signals::chain, signals::function classes
+
+Original request for interest version available as attachment to
+[@http://lists.boost.org/Archives/boost/2007/02/116869.php]
+]
+
+[heading Building]
+
+The library comes with Boost.Build Jamfiles for all examples, tests, and docs.
+As long as your BOOST_ROOT environment variable is set, you should be able
+to build each one of those by going to the appropriate directory and
+running bjam.
+
+The library itself is header only, and requires no linking. However, parts
+of it depend on boost libraries which do need to be built and linked (see
+the linking information below).
+
+[heading Linking]
The generic Dataflow support layer is header-only, and relies only on other
Boost header-only libraries (MPL, enable_if, and small parts of fusion).
@@ -590,6 +661,6 @@
([mutex] and [condition]) are dependent on [BoostThread], which has to be
linked as well.
-[endsect][/linking]
+[endsect][/download]
[endsect][/introduction]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk 2007-11-09 15:50:34 EST (Fri, 09 Nov 2007)
@@ -180,13 +180,16 @@
[endsect][/port]
[section ProxyPortTraits]
+
+
[endsect][/proxyporttraits]
[section ProxyPort]
-A type `PP` is a ['[ProxyPortConcept]] if specifies the proxied producer
-type, and if objects of the proxied type can be retreived from objects of
-[ProxyPortConcept] type. If the proxied producer type is a valid
+A type `PP` is a ['[ProxyPortConcept]] for a mechanism `M` and port category `PC`
+if it specifies a [ProxyPortTraitsConcept] for that mechanism and port category.
+
+If the proxied port type is a valid
[PortConcept], then 'PP' satisfies the [PortConcept] requirements
in the same way.
@@ -202,30 +205,11 @@
[table
[[Name] [Expression] [Result Type] [Semantics]]
[
- [Proxy Port Category]
- [`proxy_producer_category_of<PP>::type`
- [footnote `namespace boost::dataflow`]]
- [Any type]
- [
- The category of the proxy producer, used for tag forwarding.
- ]
- ]
- [
- [Proxied Port Type]
- [`proxied_producer_of<PP>::type`
- [footnote `namespace boost::dataflow`]]
- [Any type]
- [
- The proxied producer type.
- ]
- ]
- [
- [Proxied Port]
- [`get_proxied_producer(pp)`
- [footnote `namespace boost::dataflow`]]
- []
+ [Proxy Port Traits]
+ [`proxy_port_traits_of<PP>::type`]
+ [[ProxyPortTraitsConcept] type.]
[
- Retrieves a reference to the proxied producer object.
+ The traits of the proxy port.
]
]
]
@@ -241,13 +225,9 @@
[heading Notes]
-To define a new [ProxyPortConcept] class type, it is sufficient to define
-member typedefs `proxy_producer_category` and `proxy_producer_for`,
-and member function `get_proxied_producer`.
-
[heading Examples]
[endsect][/proxyport]
-[section PortMap]
-[endsect][/port_map]
\ No newline at end of file
+[section KeyedPort]
+[endsect][/keyed_port]
Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk (original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/rationale.qbk 2007-11-09 15:50:34 EST (Fri, 09 Nov 2007)
@@ -10,14 +10,31 @@
can work on improving the information that is out there (on Wikipedia, etc.)
* I chose /component/ to refer to a processing element of a dataflow network,
because the term has no prior (to my knowledge) C++ meaning.
-* In differentiating components that output data from those that input data,
- I originally thought about using "input component"
- and "output component". However, I realized that "input" and "output"
+* In differentiating ports that output data from those that input data,
+ I originally thought about using "input"
+ and "output". However, I realized that "input" and "output"
switch depending on perspective - from the perspective
- of a component, it is "output" if it outputs data, but from the perspective
- of a corresponding connection, that same component is the
- "input". A better choice might be /producer/ and /consumer/ as they don't
- suffer from the same problem. Perhaps "provider"
- would be more accurate, and there is a precedent for this nomenclature.
+ of a port, it is "output" if it outputs data, but from the perspective
+ of a corresponding connection, that same port is the
+ "input". A better choice seemed to be /producer/ and /consumer/ as they don't
+ suffer from the same problem.
-[endsect]
\ No newline at end of file
+[heading Implementation choices]
+
+* Among various tag dispatch conventions, I chose to go with functor templates
+ because of relative simplicity as well as integration with boost::result_of.
+ Using a function might be another good alternative (as suggested
+ [@http://www.boost.org/more/generic_programming.html#tag_dispatching here]),
+ but might be problematic where the result type is not fixed (and in the
+ future all of the operations will probably be modified to return a value
+ where appropriate.
+* Port operations (as parts of [BinaryOperableConcept] and
+ [UnaryOperableConcept] concepts) have been rolled into a single class
+ template with the operation selected by type because all of these operations
+ share [ProxyPortConcept] and (for [BinaryOperableConcept]) [KeyedPortConcept]
+ resolution. [ComponentOperableConcept] operations have been implemented
+ the same way for consistency.
+
+[endsect]
+
+
\ No newline at end of file
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk