StudioInfinity/dyna3
2
0
Fork 2
Code Issues 65 Pull requests 2 Projects 3 Releases 4 Wiki Activity Actions

feat: Point coordinate regulators #118

Merged
Vectornaut merged 9 commits from glen/dyna3:pointCoordRegulators into main 2025-10-13 22:52:03 +00:00
Conversation 27 Commits 9 Files changed 6 +4 -2
1 changed files with 4 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 6dbbe2ce2d - Show all commits

6
app-proto/src/assembly.rs
View file

@ -688,7 +688,9 @@ impl Assembly {
}
pub fn try_insert_element(&self, elt: impl Element + 'static) -> bool {
let can_insert = self.elements_by_id.with_untracked(|elts_by_id| !elts_by_id.contains_key(elt.id()));
let can_insert = self.elements_by_id.with_untracked(
Vectornaut commented 2025-10-11 01:44:20 +00:00
Outdated
Copy link

Flagging this as a potential mistake because it adds a new change to the pull request, rather than reverting one of the changes in commit c0e6ebf, and I don't see an obvious reason for this pull request to touch it. Could you confirm that this change was deliberate if it was, and revert it if it wasn't?

Flagging this as a potential mistake because it adds a new change to the pull request, rather than reverting one of the changes in commit c0e6ebf, and I don't see an obvious reason for this pull request to touch it. Could you confirm that this change was deliberate if it was, and revert it if it wasn't?
glen commented 2025-10-11 05:53:28 +00:00
Outdated
Copy link

Oh, when I was undoing, there was some exactly analogous line that was the other way, so it was easy just to falsely revert this. I will fix the mistaken non-reversion.

Oh, when I was undoing, there was some exactly analogous line that was the other way, so it was easy just to falsely revert this. I will fix the mistaken non-reversion.
|elts_by_id| !elts_by_id.contains_key(elt.id())
);
if can_insert {
self.insert_element_unchecked(elt);
}
@ -956,7 +958,7 @@ mod tests {
#[test]
Vectornaut commented 2025-10-11 01:51:37 +00:00
Outdated
Copy link

I'd indent this line by two tabs to match the convention you've used for other multi-line expressions. This won't affect the string, because the string continuation escape absorbs all subsequent whitespace, resuming the string at the next non-whitespace character.

I'd indent this line by two tabs to match the convention you've used for other multi-line expressions. This won't affect the string, because the [string continuation escape](https://doc.rust-lang.org/reference/expressions/literal-expr.html#string-continuation-escapes) absorbs all subsequent whitespace, resuming the string at the next non-whitespace character.
glen commented 2025-10-11 05:51:36 +00:00
Outdated
Copy link

Ah, didn't know that \ at end of line (a convention I hate, but apparently the only one available in this context) sucked up leading whitespace on the next line as well. Will do.

Ah, didn't know that \ at end of line (a convention I hate, but apparently the only one available in this context) sucked up leading whitespace on the next line as well. Will do.
#[should_panic(expected = "Subject \"sphere1\" must be indexed before \
inversive distance regulator writes problem data")]
inversive distance regulator writes problem data")]
Vectornaut marked this conversation as resolved
Vectornaut commented 2025-10-13 22:42:37 +00:00
Copy link

When I originally wrote this test, it bothered me that the identifiers sphere0 and sphere1 were assigned but never tested. The new, more informative indexing error message makes them part of the test, which is very satisfying.

When I originally wrote this test, it bothered me that the identifiers `sphere0` and `sphere1` were assigned but never tested. The new, more informative indexing error message makes them part of the test, which is very satisfying.
fn unindexed_subject_test_inversive_distance() {
let _ = create_root(|| {
let subjects = [0, 1].map(