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 +12 -5
2 changed files with 12 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 27edbfb010 - Show all commits

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

@ -127,7 +127,7 @@ pub trait Element: Serial + ProblemPoser + DisplayItem {
} }
impl Debug for dyn Element { impl Debug for dyn Element {
fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), fmt::Error> { fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
glen marked this conversation as resolved Outdated
glen commented 2025-10-09 15:04:31 +00:00
Outdated
Copy link

This change is irrelevant to this PR so we really oughtnt do it but no big deal I guess.

This change is irrelevant to this PR so we really oughtnt do it but no big deal I guess.
Vectornaut commented 2025-10-10 06:28:05 +00:00
Outdated
Copy link

I'd be fine with leaving it out of this pull request. I made it because this pull request implements Display for Axis using the terser fmt::Result convention, and I wanted the previous implementation of Debug for dyn Element to look consistent.

I'd be fine with leaving it out of this pull request. I made it because this pull request implements `Display` for `Axis` using the terser `fmt::Result` convention, and I wanted the previous implementation of `Debug` for `dyn Element` to look consistent.
glen commented 2025-10-10 17:30:27 +00:00
Outdated
Copy link

like I said, no big deal either way, resolving.

like I said, no big deal either way, resolving.
self.id().fmt(f) self.id().fmt(f)
} }
} }
@ -511,10 +511,18 @@ impl ProblemPoser for HalfCurvatureRegulator {
} }
#[derive(Clone, Copy, Sequence)] #[derive(Clone, Copy, Sequence)]
pub enum Axis {X = 0, Y = 1, Z = 2} pub enum Axis { X = 0, Y = 1, Z = 2 }
impl Axis { impl Axis {
glen marked this conversation as resolved Outdated
glen commented 2025-10-09 15:06:43 +00:00
Outdated
Copy link

I generally prefer to punctuate code as one would text, when possible. Can we remove the two extraneous spaces you just added here? They don't seem to improve readability (as we are all used to no space between brackets and content).

I generally prefer to punctuate code as one would text, when possible. Can we remove the two extraneous spaces you just added here? They don't seem to improve readability (as we are all used to no space between brackets and content).
Vectornaut commented 2025-10-10 06:01:39 +00:00
Outdated
Copy link

This spacing convention is widely used in Rust code, and it's recommended in the Rust style guide:

For a single-line block, put spaces after the opening brace and before the closing brace.

I like it a lot, and I've used it in hundreds of places in the dyna3 source code. If you're adamant about changing it, I'd prefer to do it throughout the source code in a formatting-only pull request.

This spacing convention is widely used in Rust code, and it's [recommended](https://doc.rust-lang.org/beta/style-guide/expressions.html#blocks) in the Rust style guide: > For a single-line block, put spaces after the opening brace and before the closing brace. I like it a lot, and I've used it in hundreds of places in the dyna3 source code. If you're adamant about changing it, I'd prefer to do it throughout the source code in a formatting-only pull request.
glen commented 2025-10-10 17:29:48 +00:00
Outdated
Copy link

We don't have to fix it now. I don't care at all about the Rust style guide, it's an assembly of weird rigidities from my point of view (what business does a language have semi-enforcing snake_case identifiers? I thought typography reiterating semantic category went into the trashbin with Perl a decade or more ago...). I very much like the convention of punctuating code as close as possible to regular text. I get it that you are used to these spaces that look very extra to me. We'll figure out how to resolve this at some point. No need to spin our wheels on it at the moment.

We don't have to fix it now. I don't care at all about the Rust style guide, it's an assembly of weird rigidities from my point of view (what business does a _language_ have semi-enforcing snake_case identifiers? I thought typography reiterating semantic category went into the trashbin with Perl a decade or more ago...). I very much like the convention of punctuating code as close as possible to regular text. I get it that you are used to these spaces that look very extra to me. We'll figure out how to resolve this at some point. No need to spin our wheels on it at the moment.
👍 1
pub const NAME: [&str; Axis::CARDINALITY] = ["X", "Y", "Z"]; fn name(&self) -> &'static str {
Vectornaut marked this conversation as resolved Outdated
Vectornaut commented 2025-10-03 20:51:33 +00:00
Outdated
Copy link

The associated constant Axis::N_AXIS, which is defined by hand here, has the same value as the associated constant Axis::CARDINALITY, which is defined automatically when we derive the Sequence trait. I'd recommend removing N_AXIS and using CARDINALITY in its place. I'm confident that CARDINALITY is currently 3, because I get a compilation error if I replace it with a value different from 3 in the definition of Axis::NAME.

The associated constant `Axis::N_AXIS`, which is defined by hand here, has the same value as the associated constant [`Axis::CARDINALITY`](https://docs.rs/enum-iterator/latest/enum_iterator/trait.Sequence.html#associatedconstant.CARDINALITY), which is defined automatically when we derive the `Sequence` trait. I'd recommend removing `N_AXIS` and using `CARDINALITY` in its place. I'm confident that `CARDINALITY` is currently 3, because I get a compilation error if I replace it with a value different from 3 in the definition of `Axis::NAME`.
glen commented 2025-10-04 23:50:41 +00:00
Outdated
Copy link

Done in latest commit

Done in latest commit
👍 1
match self { Axis::X => "X", Axis::Y => "Y", Axis::Z => "Z" }
}
}
impl fmt::Display for Axis {
Vectornaut marked this conversation as resolved Outdated
Vectornaut commented 2025-10-10 06:41:24 +00:00
Outdated
Copy link

Whoops, here's a formatting mistake from the revision I made. I should've just written

impl Display for Axis

and changed the relevant use expression as follows:

- fmt::{Debug, Formatter}
+ fmt::{Debug, Display, Formatter}

Would you mind including that change in your next round of revisions?

Whoops, here's a formatting mistake from the revision I made. I should've just written ```rust impl Display for Axis ``` and changed the relevant `use` expression as follows: ```diff - fmt::{Debug, Formatter} + fmt::{Debug, Display, Formatter} ``` Would you mind including that change in your next round of revisions?
glen commented 2025-10-10 15:24:31 +00:00
Outdated
Copy link

Yes of course, and this makes sense.

Yes of course, and this makes sense.
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
f.write_str(self.name())
}
} }
pub struct PointCoordinateRegulator { pub struct PointCoordinateRegulator {

3
app-proto/src/components/outline.rs
View file

@ -6,7 +6,6 @@ use web_sys::{KeyboardEvent, MouseEvent, wasm_bindgen::JsCast};
use crate::{ use crate::{
AppState, AppState,
assembly::{ assembly::{
Axis,
Element, Element,
HalfCurvatureRegulator, HalfCurvatureRegulator,
InversiveDistanceRegulator, InversiveDistanceRegulator,
@ -123,7 +122,7 @@ impl OutlineItem for HalfCurvatureRegulator {
impl OutlineItem for PointCoordinateRegulator { impl OutlineItem for PointCoordinateRegulator {
fn outline_item(self: Rc<Self>, _element: &Rc<dyn Element>) -> View { fn outline_item(self: Rc<Self>, _element: &Rc<dyn Element>) -> View {
let name = format!("{} coordinate", Axis::NAME[self.axis as usize]); let name = format!("{} coordinate", self.axis);
view! { view! {
li(class = "regulator") { li(class = "regulator") {
div(class = "regulator-label") // for spacing div(class = "regulator-label") // for spacing