chore: Remove trailing whitespace #129

Merged
Vectornaut merged 11 commits from glen/dyna3:noTrailingWhitespace into main 2025-11-11 00:47:41 +00:00
Owner

The rebase left lots of spurious commits (do you know how to avoid that?) but it is irrelevant in that the diffs remain just that all trailing whitespace is removed and carriage returns added at the end of files. So when this is squash-merged, the commit history will be clean. Thanks for reviewing.

The rebase left lots of spurious commits (do you know how to avoid that?) but it is irrelevant in that the diffs remain just that all trailing whitespace is removed and carriage returns added at the end of files. So when this is squash-merged, the commit history will be clean. Thanks for reviewing.
glen added 9 commits 2025-10-13 23:29:14 +00:00
Implements regulators for the Euclidean coordinates of Point entities,
  automatically creating all three of them for each added point entity. When
  such a regulator is set, it freezes the corresponding representation
  coordinate to the set point. In addition, if all three coordinates of a
  given Point are set, the coradius coordinate (which holds the norm of the
  point) is frozen as well.

  Note that a PointCoordinateRegulator must be created with a Point as the
  subject. This commit modifies HalfCurvatureRegulator analogously, so that
  it can only be created with a Sphere.

  A couple of prospective issues that should be filed in association with
  this commit:
  * The new coordinate regulators create redundant display information with
    the raw representation coordinates of a point that are already shown in
    the outline view.
  * The optimization status of these regulators together with HalfCurvature
    regulators (i.e., the ones implemented by freezing coordinates) is different
    from InversiveDistance regulators when an Assembly is unrealizable: the
    frozen-coordinate constraints will be "hard" in that they will be forced
    to precisely equal their set point, whereas the distance regulators are
    "soft" in that they can be relaxed from their set points in an effort to
    minimize the loss function of the configuration as compared to the values
    of the constraints. Perhaps at some point we should/will have a mechanism
    to specify the softness/hardness of constraints, but in the meantime,
    there should not be two different categories of constraints. Suppose we
    decide that by default that all constraints are soft. Then the optimizer
    should be able to search changing, for example, the radius of a
    curvature-constrained sphere, so as to minimize the loss function (for a
    loss that would therefore presumably have a term akin to the square of the
    difference between the specified and actual half-curvature of the sphere).
    For example, suppose you specify that the half-curvature of a sphere is 1
    (so it has radius 1/2) but that its distance to a point is -1. These
    constraints cannot be satisfied, so the optimization fails, presumably
    with the point at the sphere center, and the sphere with radius 1/2.
    So all of the loss is concentrated in the difference between the actual
    point-sphere distance being -1/2, not -1. It would be more appropriate
    (in the all-soft constraint regime) to end up at something like a sphere of
    half-curvature 1/√2 with the point at the center, so that the loss is split
    between both the half-curvature and the distance to the sphere being off by
    1 - 1/√2. (At a guess, that would minimize the sum of the squares of the
    two differences.)
This makes it simpler, from the programmer's perspective, to get the
name of an axis as a string slice and to format an axis name into a
string. To me, the matching method `Axis::name` seems more direct than
the explicit lookup table that it replaces, and I'm hoping that it will
be about as easy for the compiler to inline, or even easier.

Implementing `Display` enables us to hand an `Axis` to a string
formatter without any explicit conversion. It adds extra code in the
short run, but I'd expect it to simplify our code in the long run by
fitting into the conventions set by the Rust standard library.
Make the new code's formatting and error messages more consistent with
the previous code. I don't necessarily have a strong preference for the
previous conventions, but I do like stuff to be consistent.
This reverts commit adc60ac5c1. We decided
that it would be better for me to request formatting changes one by one.
chore: remove trailing whitespace, add CR at end of file
All checks were successful
/ test (pull_request) Successful in 3m41s
3635abc562
Member

I've done the following checks:

  • Skimmed through all the file diffs to confirm that the pull request only makes the intended changes of de-indenting blank lines and adding final carriage returns.
  • Spot-checked a few source files to confirm that they look okay.
  • Built dyna3 and played with it a little to confirm that it still runs as expected.
I've done the following checks: - Skimmed through all the file diffs to confirm that the pull request only makes the intended changes of de-indenting blank lines and adding final carriage returns. - Spot-checked a few source files to confirm that they look okay. - Built dyna3 and played with it a little to confirm that it still runs as expected.
Member

Do you know whether we can also apply this style to the YAML files that specify our Forgejo actions? If you're not sure, I can try it out later by running continuous integration locally.

Do you know whether we can also apply this style to the YAML files that specify our Forgejo actions? If you're not sure, I can try it out later by [running continuous integration locally](https://code.studioinfinity.org/StudioInfinity/dyna3/wiki/Continuous-integration#running-in-a-docker-container-using-forgejo-runner).
Author
Owner

@Vectornaut wrote in #129 (comment):

Do you know whether we can also apply this style to the YAML files that specify our Forgejo actions? If you're not sure, I can try it out later by running continuous integration locally.

I believe so. Do you want me to make that change as part of this PR? I am equally willing to just wait until we have some reason to touch the YAML files. Up to you, let me know.

@Vectornaut wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/pulls/129#issuecomment-3396: > Do you know whether we can also apply this style to the YAML files that specify our Forgejo actions? If you're not sure, I can try it out later by [running continuous integration locally](https://code.studioinfinity.org/StudioInfinity/dyna3/wiki/Continuous-integration#running-in-a-docker-container-using-forgejo-runner). I believe so. Do you want me to make that change as part of this PR? I am equally willing to just wait until we have some reason to touch the YAML files. Up to you, let me know.
Member

Do you want me to make that change [to the Forgejo actions] as part of this PR?

Yes: I'd rather do the reformatting in this dedicated PR than add noise to an unrelated PR. I just confirmed that the reformatted YAML files work when I run CI locally, so this should be an easy addition.

> Do you want me to make that change [to the Forgejo actions] as part of this PR? Yes: I'd rather do the reformatting in this dedicated PR than add noise to an unrelated PR. I just confirmed that the reformatted YAML files work when I run CI locally, so this should be an easy addition.
glen added 1 commit 2025-10-14 19:43:09 +00:00
chore: remove trailing whitespace outside of app-proto/src as well
All checks were successful
/ test (pull_request) Successful in 3m41s
b89fa02f52
Author
Owner

OK, I have now removed trailing whitespace throughout the repository, except within the engine-proto Julia code, with which I have not really concerned myself. (If you would like me to do it there as well, just let me know, but I have no opinion either way.)

OK, I have now removed trailing whitespace throughout the repository, except within the engine-proto Julia code, with which I have not really concerned myself. (If you would like me to do it there as well, just let me know, but I have no opinion either way.)
Vectornaut approved these changes 2025-11-10 22:27:47 +00:00
Vectornaut left a comment
Member

Aside from the change to the original prototype mentioned below, I've checked that all of these changes preserve behavior and appearance.

Aside from the change to the original prototype mentioned below, I've checked that all of these changes preserve behavior and appearance.
notes/theory.md Outdated
@ -24,2 +24,3 @@
"But still I would consider it all more or less doable. One should very precisely think about a doable scope.
I think three things are essential for the math no matter what you exactly plan.
I think three things are essential for the math no matter what you exactly
plan.
Member

Why was the space between "exactly" and "plan" changed to a line break? The change looks weird to me, so I want to make sure it was intentional.

Why was the space between "exactly" and "plan" changed to a line break? The change looks weird to me, so I want to make sure it was intentional.
Member

This change seems to have leaked in from pull request #128. Fixed in commit fbf7729.

This change seems to have leaked in from pull request #128. Fixed in commit fbf7729.
Vectornaut marked this conversation as resolved
src/index.html Outdated
@ -8,4 +8,2 @@
</body>
</html>
Member

If you'd like me to test this change, please tell me how to serve the original prototype. I'd be willing to accept this change without testing it, though, because we're not using the original prototype anymore, and the change seems very unlikely to affect the application's behavior.

If you'd like me to test this change, please tell me how to serve the original prototype. I'd be willing to accept this change without testing it, though, because we're not using the original prototype anymore, and the change seems very unlikely to affect the application's behavior.
Member

During our meeting, @glen confirmed that there's no need to test.

During our meeting, @glen confirmed that there's no need to test.
Vectornaut marked this conversation as resolved
glen added 1 commit 2025-11-11 00:36:58 +00:00
fix: remove spurious linebreak
All checks were successful
/ test (pull_request) Successful in 3m47s
fbf7729d6b
Vectornaut merged commit 6c3a48fb52 into main 2025-11-11 00:47:41 +00:00
Sign in to join this conversation.
No description provided.