This release marks another step towards pyre 2.0 with a complete makeover of `libjournal`. The C++ library has been reimplemented from scratch, and many features have been added. Some of this work was part of the interim v1.10.0 release; you can find an outline of those changes in the release notes. Since then
- `pyre::journal` has new manipulators that can inject color into the output, associate a user defined code with a message, control the indentation level of subsequent output, and specify the marker to place on the left margin to help identify `journal` output
- the `verbosity` level was renamed to `detail`; the former may be the familiar name historically given to this feature by a multitude of unix tools, but it has been pointed out that it is unnecessarily judgmental. Some backwards compatibility is retained, but the name is now marked deprecated and will be removed in v2.0.
- the `bland` formatter was added; it displays just the injected text with no decoration or message metadata
- there is now a `help` channel that uses the `bland` formatter, intended for building help screens with minimal distractions
- the visual layout of messages generated by the C++ library and the python package had some inconsistencies; these have been fixed, the output is cleaner, and it looks the same regardless of the engine that generated it
- the python bindings provide `report`, a new channel method that renders a sequence of strings; the most interesting aspect of this is that `report` will accept a generator, so output can now be gathered while traversing hierarchical data structures
In other news:
- `pyre.config` now has `yaml` support; configuration files with the `.yaml` suffix are processed using `pyyaml`, if it is available. They are higher priority than the built in `.pfg` files. Please note that the `` character is a comment in `yaml`, so certain `pyre` expressions that use URI syntax and have embedded ``s must be placed in quotation marks
- the configuration cascade in `pyre.components` has improved significantly. Applications can now register a naming service so that components that are created implicitly can get custom names, components get unique ids using `libuuid` that can persist across sessions, and the life cycle event hooks have been streamlined. Protocols have much more say on how their implementers are discovered and instantiated
- `pyre::memory` got `stack`, a new storage strategy that uses `std::array` for storage; it is free of dynamic memory allocations so it is fast, but it is only appropriate for relatively small objects. It is really meant to be used to represent tensors of small rank, but it can be composed as the `cell_t` of a `pyre::grid` to store arbitrarily large tensor fields. More of this in the next release.
Notable housekeeping tasks include
- the move of the CI system to GitHub actions, motivated by the fact that the `pyre` travis bucks ran out. Currently, the new CI system checks both `mm` and `cmake` builds with five different compilers, two versions of python, and three different build targets. It is much more thorough. I am grateful to GitHub and Microsoft for making this possible -- and free.
- the retirement of the `eoan` docker images, as the basis image is no longer available; they were replaced by `hirsute` images. The generation of these images was streamlined a bit, but it still mostly a copy-and-paste job. There must be a better way to generate the `Dockerfile`s...
And finally, `merlin` is coming...