Add Splitter and Tee classes #62
Conversation
rtburns-jpl
force-pushed
the
splitter
branch
2 times, most recently
from
1ac68ce
to
4fb6249
Compare
|
on it. really cool, and thanks for the contribution! |
|
I added stubs for the pure python implementations of Tee and Splitter. This was just a warmup exercise, trying to figure out what's a reasonable workflow for collaborating on a PR. Would it be better to merge it in a new pyre branch and continue the work on the pyre repository, or stay here and have me push contributions to your fork? |
|
Cool, either works for me. Seems easier to just work on the PR branch as is, but let me know if any insufficiencies come up. I do like that we can discuss progress here as we work - it's like having a feature-specific discussion channel. |
|
Merged |
|
Thanks, looks good |
…ing its extraction from the file
… its value on read
…he {typed} relocation
…s in a form suitable for including in diagnostics
…s in a form suitable for including in diagnostics
…ss in a form suitable for including in diagnostics
Co-authored-by: Sebastiaan van Paasen <sebas.98vp@gmail.com>
Co-authored-by: Sebastiaan van Paasen <sebas.98vp@gmail.com>
…ists.txt}
Specifically, this change required:
1) prepending "tests" to all the tests paths, and
2) for compiled tests, manually specifying the directory of the products of the compilation to the {tests} subdirectory of the build directory. This step is now necessary and was previously done automatically by CMake in function {add_subdirectory}, which however required the subdirectory to contain a CMakeLists.txt.
…to generate benchmarks target names as well
…clude} directive (extensions) Specifically, this change required: 1) prepending "extensions" to all the paths, and 2) manually specifying the directory of the products of the compilation. See also rev. 2dae115.
…clude} directive (defaults)
…clude} directive (bin)
…clude} directive (packages)
…clude} directive (lib)
…in github workflow
…URCE_DIR} Thanks for the tip @rtburns-jpl !
…cleans up after itself
I like the idea of using a Tee for debugging - I can watch the messages in the terminal, but if I lose track and want to check something again I can go look in a file that stores those messages persistently.
But of course a Tee is just one instance of a more fundamental type of Device, a Splitter that appears to be a single Device interface-wise but actually forwards its contents, mapping inputs to any number of output Devices. In fact, the Tee specification is quite terse when phrased as a specific type of Splitter.
Let me know what you think, I'd like to know if I have the right understanding and am using appropriate abstractions here.