Integrate engine into application prototype #15
@ -208,16 +208,16 @@ pub fn AddRemove() -> View {
|
|||||||
},
|
},
|
||||||
on:click=|_| {
|
on:click=|_| {
|
||||||
let state = use_context::<AppState>();
|
let state = use_context::<AppState>();
|
||||||
let args = state.selection.with(
|
let subjects = state.selection.with(
|
||||||
|sel| {
|
|sel| {
|
||||||
let arg_vec: Vec<_> = sel.into_iter().collect();
|
let subject_vec: Vec<_> = sel.into_iter().collect();
|
||||||
(arg_vec[0].clone(), arg_vec[1].clone())
|
(subject_vec[0].clone(), subject_vec[1].clone())
|
||||||
}
|
}
|
||||||
);
|
);
|
||||||
let rep = create_signal(0.0);
|
let rep = create_signal(0.0);
|
||||||
let active = create_signal(true);
|
let active = create_signal(true);
|
||||||
state.assembly.insert_constraint(Constraint {
|
state.assembly.insert_constraint(Constraint {
|
||||||
args: args,
|
subjects: subjects,
|
||||||
rep: rep,
|
rep: rep,
|
||||||
rep_text: create_signal(String::new()),
|
rep_text: create_signal(String::new()),
|
||||||
rep_valid: create_signal(false),
|
rep_valid: create_signal(false),
|
||||||
@ -233,8 +233,8 @@ pub fn AddRemove() -> View {
|
|||||||
for (_, cst) in csts.into_iter() {
|
for (_, cst) in csts.into_iter() {
|
||||||
console::log_5(
|
console::log_5(
|
||||||
&JsValue::from(" "),
|
&JsValue::from(" "),
|
||||||
&JsValue::from(cst.args.0),
|
&JsValue::from(cst.subjects.0),
|
||||||
&JsValue::from(cst.args.1),
|
&JsValue::from(cst.subjects.1),
|
||||||
&JsValue::from(":"),
|
&JsValue::from(":"),
|
||||||
&JsValue::from(cst.rep.get_untracked())
|
&JsValue::from(cst.rep.get_untracked())
|
||||||
);
|
);
|
||||||
|
@ -21,7 +21,7 @@ pub struct Element {
|
|||||||
|
|
||||||
#[derive(Clone)]
|
#[derive(Clone)]
|
||||||
pub struct Constraint {
|
pub struct Constraint {
|
||||||
pub args: (usize, usize),
|
pub subjects: (usize, usize),
|
||||||
glen marked this conversation as resolved
Outdated
|
|||||||
pub rep: Signal<f64>,
|
pub rep: Signal<f64>,
|
||||||
glen marked this conversation as resolved
Outdated
glen
commented
Let's get into a habit of using full words in interfaces/public property names. Looking at this, I don't know if "rep" is a representation, the number of repetitions, something that is being reported, or what... Please rename this suite of properties. Thanks! Let's get into a habit of using full words in interfaces/public property names. Looking at this, I don't know if "rep" is a representation, the number of repetitions, something that is being reported, or what... Please rename this suite of properties. Thanks!
Vectornaut
commented
I've replaced I've replaced `rep` with `lorentz_prod` in all the `Constraint` field names (commit 5839882). We can streamline the names later if they get too unwieldy.
|
|||||||
pub rep_text: Signal<String>,
|
pub rep_text: Signal<String>,
|
||||||
pub rep_valid: Signal<bool>,
|
pub rep_valid: Signal<bool>,
|
||||||
@ -94,11 +94,11 @@ impl Assembly {
|
|||||||
}
|
}
|
||||||
|
|
||||||
pub fn insert_constraint(&self, constraint: Constraint) {
|
pub fn insert_constraint(&self, constraint: Constraint) {
|
||||||
let args = constraint.args;
|
let subjects = constraint.subjects;
|
||||||
let key = self.constraints.update(|csts| csts.insert(constraint));
|
let key = self.constraints.update(|csts| csts.insert(constraint));
|
||||||
self.elements.update(|elts| {
|
self.elements.update(|elts| {
|
||||||
elts[args.0].constraints.insert(key);
|
elts[subjects.0].constraints.insert(key);
|
||||||
elts[args.1].constraints.insert(key);
|
elts[subjects.1].constraints.insert(key);
|
||||||
});
|
});
|
||||||
}
|
}
|
||||||
|
|
||||||
@ -119,9 +119,9 @@ impl Assembly {
|
|||||||
self.constraints.with_untracked(|csts| {
|
self.constraints.with_untracked(|csts| {
|
||||||
for (_, cst) in csts {
|
for (_, cst) in csts {
|
||||||
if cst.active.get_untracked() && cst.rep_valid.get_untracked() {
|
if cst.active.get_untracked() && cst.rep_valid.get_untracked() {
|
||||||
let args = cst.args;
|
let subjects = cst.subjects;
|
||||||
let row = elts[args.0].index;
|
let row = elts[subjects.0].index;
|
||||||
let col = elts[args.1].index;
|
let col = elts[subjects.1].index;
|
||||||
gram_to_be.push_sym(row, col, cst.rep.get_untracked());
|
gram_to_be.push_sym(row, col, cst.rep.get_untracked());
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -154,10 +154,10 @@ pub fn Outline() -> View {
|
|||||||
let c_state = use_context::<AppState>();
|
let c_state = use_context::<AppState>();
|
||||||
let assembly = &c_state.assembly;
|
let assembly = &c_state.assembly;
|
||||||
let cst = assembly.constraints.with(|csts| csts[c_key].clone());
|
let cst = assembly.constraints.with(|csts| csts[c_key].clone());
|
||||||
let other_arg = if cst.args.0 == key {
|
let other_arg = if cst.subjects.0 == key {
|
||||||
cst.args.1
|
cst.subjects.1
|
||||||
} else {
|
} else {
|
||||||
cst.args.0
|
cst.subjects.0
|
||||||
};
|
};
|
||||||
let other_arg_label = assembly.elements.with(|elts| elts[other_arg].label.clone());
|
let other_arg_label = assembly.elements.with(|elts| elts[other_arg].label.clone());
|
||||||
view! {
|
view! {
|
||||||
|
Loading…
Reference in New Issue
Block a user
constrains
would work for me, as wouldappliesTo
. Totally open to other choices.usize
s are some sort of references to elements. If a primitive type is being used with semantic baggage, typedef it or something like that so that you can write e.g.,pub constrains: (ElementHandle, ElementHandle)
Again, I am open to other options for the name to use; "ElementRef" would be fine, or you may have another idea. A big part of why to do this is to make development easier should it become convenient to use a different primitive type to encode a reference to an element.
I've switched to
subjects
(in commited1890b
), as in the phrase "[...] subject to the constraint that [...]." Is that a fitting name? I like to name non-boolean variables with nouns, rather than prepositional verbs like "applies to."Right now, there's only one kind of element (a sphere) and one kind of constraint (fixing the generalized angle between two spheres), so the
Element
andConstraint
structures are written pretty narrowly. As we extend dyna3 to more general problems, I'm planning to generalizeElement
andConstraint
as needed—maybe by turning each of them into a trait implemented by a bunch of different structures.Done as soon as I update the PR (in commit
ced001b
). I've chosenElementKey
andConstraintKey
, since the Rust collections I've seen tend to use the language of keys and values.