Generating the documentation from scratch left the benchmarks out.
Instead of trying to properly generate the documentation locally,
we now leave this to Travis CI and simply clone the proper version
of the documentation.
Otherwise, the external scripts would sometimes be blocked by browsers
because the protocol used to connect to the documentation wouldn't match
the protocol used to fetch external scripts.
Specifically,
(1) We now benchmark with fusion::list too
(2) We now document our methodology for forcing the evaluation of algorithms
Note that we still use `as_list` and `as_vector` to force the evaluation
of algorithms instead of using e.g. `for_each`. This is because we want
to compare apples with apples, and for this we need to get a sequence of
computed values, not only for_each over the view. The disclaimer in the
tutorial saying "Fusion might encourage a different design" takes care
of warning people about the fact that we're not necessarily using
idiomatic Fusion, but not need to benchmark unfairly to try to
account for that.
Note:
Since Boost.Build seems unable to feed markdown files to Doxygen,
we duplicate the tutorial.md file into tutorial.hpp. This is a
temporary solution only.
Note that no `norm` function is added for now, since the `norm` is not
tied to the specific Euclidean ring as explained in [1]. However, it
might be useful to enforce an arbitrary choice to be made for each
Euclidean ring. This could perhaps be added in the future.
Fixes#28
[1]: https://en.wikipedia.org/wiki/Euclidean_domain#Definition
The benchmarks/documentation were only ever updated from Travis, and it
is much simpler to do it directly in bash from Travis than to write it
in CMake as we did.
Also
- Add a Travis job without Boost
- Only test Boost 1.58.0 on one compiler, to reduce the size of the matrix
- Reorder the environment variables to prettify the Travis matrix
- Add a job to build on Clang trunk, but allow failures
The `models<>` machinery added unnecessary complexity for little benefit.
Also, this makes Hana's concepts syntactically closer to concepts lite,
which should contribute to making them easier to grasp at first sight.
This was annoying because
(1) We couldn't use the name hana:: from within the struct
(2) It requires one more instantiation unless you use the
`using hana = self` trick. But that trick makes something
that should be trivial to do slightly harder, and that is stupid.
Precisely,
1. Rename hana::_type to hana::basic_type, and document it
2. Rename hana::type<> to hana::type_c<>
3. Create and document the hana::type<> type
- Allow specializing models_impl with a forward declaration only
- Modularize remaining concept headers
- Include <boost/hana.hpp> in unit tests to ease the transition
- Add the core/dispatch.hpp header to reduce the number of boilerplate includes
Of the xxx_exactly variants, only drop_front_exactly is kept for now,
because it actually allows an optimization. The other ones did not
really provide a compile-time improvement, so they are removed.
This (large) commit introduces the following changes:
- Each algorithm lives in its own header
- The concepts are defined in the concept/ subdirectory. They define the
`models` metafunction, some explicit default implementations (like
Applicative::transform_impl), and they include all the algorithms
related to that concept.
- Removed the `until` method from Logical
- Removed the `drop_until` method from Iterable
- [minor] Added the detail::nested_to utility
Closes#160
This is done because the resulting macros are much more straightforward
to debug when a user makes a mistake. Also, it avoids pulling yet another
dependency.
Also added some general purpose macros in detail/preprocessor.hpp.
- Remove the preface entirely
- Move the current introduction to a "Description" section
- Move the "Quadrants of computation" to the "Introduction"
- Move the current "Motivation" section to the start of the "Introduction"
- Move the section on "Introspection" higher up in the docs
- Remove the "Concept" column in the Cheatsheet, and add links to each
individual algorithm instead.
- Add a rationale for unpack's name and parameter order
- Add `fold` and `reverse_fold` to the cheatsheet
- Mention the list of all headers in the tutorial
- Add an alphabetical index with everything in the library
- Precise that smaller is better in chart subtitles
- Add benchmarks for std::make_tuple and std::get
- Add an "Acknowledgements" section
- Rename Boost.Hana to Hana for now (not officially a Boost library)
- Partially write the section on "Introspection"
Fixes#46
I feel like the documentation now provides enough real world examples:
- switchAny
- Euclidean distance
- JSON generation (to be written)
- MPL reimplementation
- Merge section on Amphibian Algorithms with section on Algorithms
- Replace the `decayed` pseudo-code by `std::decay_t`.
- Rewrite and move section on type computations
- Add Appendix on the MPL implementation
