NationTech/harmony
5
0
Fork 2
Code Issues 37 Pull Requests 16 Actions Packages Projects Releases 1 Wiki Activity

feat: harmony-cli v0.1 #8 #9

Merged
taha merged 23 commits from harmony-cli into master 2025-04-19 01:13:40 +00:00
Conversation 5 Commits 23 Files Changed 8 +312 -4
7 changed files with 312 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 508ca3352d - Show all commits

5
harmony_cli/src/lib.rs
View File

@@ -53,10 +53,9 @@ pub async fn init<T: Topology + std::fmt::Debug + Send + Sync + 'static>(
johnride commented 2025-04-18 14:34:24 +00:00
Review
Copy Link

So much better. I think there are more Rust idiomatic ways to handle that with Slices or something but it's good enough :

  • Clear, easy to read and understand
  • Relatively flat, not too much nested ifs and fors
  • Leveraging functional Rust, usually makes for more robust code easily

Now though you should at least reverse the map and filter calls so scores don't all get cloned for nothing.

In general you always filter your ensemble before processing.

So much better. I think there are more Rust idiomatic ways to handle that with Slices or something but it's good enough : - Clear, easy to read and understand - Relatively flat, not too much nested ifs and fors - Leveraging functional Rust, usually makes for more robust code easily Now though you should at least reverse the map and filter calls so scores don't all get cloned for nothing. In general you always filter your ensemble before processing.
let scores = maestro.scores();
let scores_read = scores.read().expect("Should be able to read scores");
let scores_read_vec: Vec<Box<dyn Score<T>>> =
scores_read.iter().map(|s| s.clone_box()).collect();
let filtered: Vec<&Box<dyn Score<T>>> = scores_read_vec
let filtered: Vec<Box<dyn Score<T>>> = scores_read
.iter()
.map(|s| s.clone_box())
.filter(|s| s.name().contains(&args.run))
.collect();