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

Simplify the realization triggering system #105

Merged
glen merged 6 commits from Vectornaut/dyna3:reactive-realization-cleanup into main 2025-07-31 22:21:34 +00:00
Conversation 2 Commits 6 Files changed 4 +6 -5
1 changed files with 6 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 2bae8d3df9 - Show all commits

11
app-proto/src/engine.rs
View file

@ -1,7 +1,10 @@
use lazy_static::lazy_static;
use nalgebra::{Const, DMatrix, DVector, DVectorView, Dyn, SymmetricEigen};
use std::fmt::{Display, Error, Formatter};
use web_sys::{console, wasm_bindgen::JsValue}; /* DEBUG */
/* DEBUG */
#[cfg(not(feature = "dev"))]
use sycamore::prelude::console_log;
// --- elements ---
@ -167,10 +170,8 @@ impl ConfigSubspace {
/* DEBUG */
// print the eigenvalues
#[cfg(all(target_family = "wasm", target_os = "unknown"))]
console::log_1(&JsValue::from(
format!("Eigenvalues used to find kernel:{}", eig.eigenvalues)
));
#[cfg(not(feature = "dev"))]
console_log!("Eigenvalues used to find kernel:{}", eig.eigenvalues);
glen marked this conversation as resolved Outdated
glen commented 2025-07-26 15:42:11 +00:00
Outdated
Copy link

What does this #-directive do? Not compile the next line if this is not a "dev" compile? Why do we not want to log the eigenvalues on a dev build? More likely I am misunderstanding the meaning here...

What does this #-directive do? Not compile the next line if this is not a "dev" compile? Why do we not want to log the eigenvalues on a dev build? More likely I am misunderstanding the meaning here...
Vectornaut commented 2025-07-28 17:24:19 +00:00
Outdated
Copy link

What does this #-directive do? Not compile the next line if this is not a "dev" compile?

Correct, if you replace "not compile" with "only compile" (I think this was a typo, based on your next sentence) and "line" with the various language constructs that attributes can be applied to.

Why do we not want to log the eigenvalues on a dev build?

Short answer

The eigenvalue logging is part of the function ConfigSubspace::symmetric_kernel, which currently runs at the end of every realize_gram call. This messes up the formatting of the Cargo examples, which are built with the dev feature.

If we want to add eigenvalue logging to the example output, we'd have to reorganize the Cargo examples a little bit, which seems a bit outside the scope of this pull request.

Now that we have a diagnostics panel, it seems more useful to plot the eigenvalues there than to log them to the console, so this logging code's days should be numbered. As we discussed during our last meeting, I'm planning to experiment with a new implementation of ConfigSubspace::symmetric_kernel this week. If we adopt a new implementation, it will be a good opportunity to replace the console logging code with a diagnostics panel plot.

More context

On the main branch, the eigenvalue logging uses the console::log_1 function from the web-sys crate, which can only run in a browser. It's therefore confined to WebAssembly builds using the following attribute:

#[cfg(all(target_family = "wasm", target_os = "unknown"))]

Since the examples typically aren't built for a WebAssembly target, they don't include the eigenvalue logging code.

This pull request seemed like a good opportunity to switch to Sycamore's more flexible console_log macro, which works both inside and outside the browser. I've been gradually replacing console::log_/* number */ calls with console_log calls throughout the codebase. The eigenvalues now can be logged in the Cargo examples, but I decided to keep the eigenvalue logging out of the examples to preserve existing behavior.

> What does this #-directive do? Not compile the next line if this is not a "dev" compile? Correct, if you replace "not compile" with "only compile" (I think this was a typo, based on your next sentence) and "line" with the [various language constructs](https://doc.rust-lang.org/reference/attributes.html#r-attributes.allowed-position) that [attributes](https://doc.rust-lang.org/reference/attributes.html) can be applied to. > Why do we not want to log the eigenvalues on a dev build? #### Short answer The eigenvalue logging is part of the function `ConfigSubspace::symmetric_kernel`, which currently runs at the end of every `realize_gram` call. This messes up the formatting of the Cargo examples, which are built with the `dev` feature. If we want to add eigenvalue logging to the example output, we'd have to reorganize the Cargo examples a little bit, which seems a bit outside the scope of this pull request. Now that we have a diagnostics panel, it seems more useful to plot the eigenvalues there than to log them to the console, so this logging code's days should be numbered. As we discussed during our last meeting, I'm planning to experiment with a new implementation of `ConfigSubspace::symmetric_kernel` this week. If we adopt a new implementation, it will be a good opportunity to replace the console logging code with a diagnostics panel plot. #### More context On the main branch, the eigenvalue logging uses the `console::log_1` function from the `web-sys` crate, which can only run in a browser. It's therefore confined to WebAssembly builds using the following attribute: ```rust #[cfg(all(target_family = "wasm", target_os = "unknown"))] ``` Since the examples typically aren't built for a WebAssembly target, they don't include the eigenvalue logging code. This pull request seemed like a good opportunity to switch to Sycamore's more flexible `console_log` macro, which works both inside and outside the browser. I've been gradually replacing `console::log_/* number */` calls with `console_log` calls throughout the codebase. The eigenvalues now *can* be logged in the Cargo examples, but I decided to keep the eigenvalue logging out of the examples to preserve existing behavior.
glen commented 2025-07-28 19:18:02 +00:00
Outdated
Copy link

It feels to me as though we are using compile time directives to make a runtime choice about logging, because by coincidence we don't want logging in the examples which happen to be our only non-dev builds at the moment. That mechanism doesn't seem fitted to the purpose. Could we select logging or not in another way? Or just cut this particular logging altogether if we don't really need it anyway?

It feels to me as though we are using compile time directives to make a runtime choice about logging, because by coincidence we don't want logging in the examples which happen to be our only non-dev builds at the moment. That mechanism doesn't seem fitted to the purpose. Could we select logging or not in another way? Or just cut this particular logging altogether if we don't really need it anyway?
Vectornaut commented 2025-07-28 21:20:13 +00:00
Outdated
Copy link

I'm fine with dropping the eigenvalue logging now and replacing it with a diagnostics panel plot later—either in a stand-alone pull request or as part of a pull request that revises ConfigSubspace::symmetric_kernel.

I'm fine with dropping the eigenvalue logging now and replacing it with a diagnostics panel plot later—either in a stand-alone pull request or as part of a pull request that revises `ConfigSubspace::symmetric_kernel`.
Vectornaut commented 2025-07-29 08:07:06 +00:00
Outdated
Copy link

I've dropped the eigenvalue logging code (in commit eafb133) and filed an issue (#106) to remind us to replace it.

I've dropped the eigenvalue logging code (in commit eafb133) and filed an issue (#106) to remind us to replace it.
// express the basis in the standard coordinates
let basis_std = proj_to_std * &basis_proj;