Conversation
twelho
left a comment
twelho
left a comment
There was a problem hiding this comment.
Very good start! Just a couple of nits/questions (and of course this needs rebasing). The CUE descriptions look quite clear even though I don't have enough experience in the language yet to properly review them.
There was a TODO for supporting hierarchical/nested sheets, so if those aren't supported yet, we need to get them working before this can be utilized in full.
It might also be valuable to build a specialized CUE binary (there was some Go tool to do this IIRC) with the required functionality built in, writing stuff to a temporary directory and execing a binary in $PATH isn't very integrated (but fine for now).
| key: "footprintLibrary" | ||
| op: "Equals" | ||
| values: ["Capacitor_SMD"] | ||
| } | ||
| }, _tmpl_resistor & { | ||
| class: "resistor" | ||
| }, _tmpl_resistor & { // shunt_resistor extends all the properties of resistor | ||
| class: "shunt_resistor" |
There was a problem hiding this comment.
There's now identifiers in camel case (footprintLibrary) and snake case (shunt_resistor) here, do we want to establish some convention for this?
| #Policy: { | ||
| shunt_resistor: { | ||
| labels: { | ||
| extra: shunt: "true" |
There was a problem hiding this comment.
This "inline" syntax looks interesting, but I guess it's valid CUE
There was a problem hiding this comment.
Yes, it is valid CUE, and pretty handy in quite a lot of cases actually.
| } | ||
| } | ||
| capacitor: attributes: Value: { | ||
| comment: string | *"This is a capacitor :D!" |
There was a problem hiding this comment.
Just out of curiosity, is the | operator commutative?
| // where both the class-defined requirements and defaults are merged with the set values of | ||
| // the component | ||
| // This file depends on common.cue | ||
| // TODO: Figure out how to deal with multiple nested schematics |
There was a problem hiding this comment.
Nested schematic support is quite important, those are already heavily used in Racklet.
| // The user-defined #Classifiers object specifies how various attributes are labels | ||
| // can be used to classify a component to belonging to a class. |
There was a problem hiding this comment.
There's something wonky with this sentence, "attributes are labels can be used"?
| const CUE_COMMON_BYTES: &'static str = include_str!("cue/common.cue"); | ||
| const CUE_MAP_BYTES: &'static str = include_str!("cue/map.cue"); | ||
| const CUE_MAP_FILE: &'static str = "map.cue"; | ||
| const CUE_REDUCE_BYTES: &'static str = include_str!("cue/reduce.cue"); | ||
| const CUE_REDUCE_FILE: &'static str = "reduce.cue"; | ||
| const CUE_POLICY_SCHEMA_BYTES: &'static str = include_str!("cue/policy_schema.cue"); | ||
| const CUE_POLICY_SCHEMA_FILE: &'static str = "policy_schema.cue"; |
There was a problem hiding this comment.
TIL that one can import a file into the binary at compile time with a single macro.
|
This will need some rebasing now that #16 moved the |
luxas
changed the title
|
Rebased and ready to merge, pending a re-review @twelho |
|
I'll merge this now to unblock @chiplet, I'll fix any feedback in follow-ups in future PRs |
3 participants
This makes the classifier use CUE for all policy-related things. It is good enough for our needs and lets us classify components, set default attributes and labels for components once classified, and enforce validation on fields set in KiCad.
I will still need to rebase this PR slightly.
cc @twelho @chiplet