Conversation
The aim is to make it easier to add and maintain individual features. Common options have been refactored into separate classes for reuse.
|
@glopesdev was this the integration you had in mind for new tools?
|
@bruno-f-cruz Happy to create a namespace for particularly complex commands requiring many helper classes. An alternative is to create a separate library for the command backend and then add it as a dependency (e.g. I am going to do this with the reflex generator).
In principle not opposed to any dependencies, since this will be a self-contained dotnet tool, so it will be deployed and run completely independent from any bonsai project dependency, etc. But let's discuss the details on the benchmarks and reflex generator PRs. |
|
Sounds good. I guess the best way to go about this is to expose a single method (e.g.: https://github.com/harp-tech/Harp.Benchmark/blob/bb0529326aee7a12ab9b33d2dfeec573f8bbd2ac/src/Harp.Benchmark/Program.cs#L43) as the entry point of the tool and create a single command subclass in this repository that wraps it? |
This PR adds a new tool to run hardware tests of Harp devices against the Harp protocol specification.
The main features:
benchmarkcommand:dotnet run --project Harp.Toolkit benchmark --port COM3 --report here.html--verboseflag)