Code review fixes for the #432 loop-pin-labels feature:
- Fix loop rendering to use port indices instead of pin numbers
(pre-existing bug: non-sequential pins produced wrong diagram)
- Add duplicate label check to the ambiguity branch in resolve_pin()
- Prevent self-referencing loops (pin looped to itself)
- Fix activate_pin() type annotation to accept Optional[Side]
- Deduplicate pin resolution: Harness.connect() now delegates to
Connector.resolve_pin() instead of reimplementing the logic
- Add 21-test suite covering all resolution paths and error modes
Loops now accept pin labels (from pinlabels) in addition to pin
numbers, matching the behavior of the connections section. Labels
are resolved to pin numbers during __post_init__ via the new
Connector.resolve_pin() method, which handles ambiguity checking.
- Resolves#263 that describes warnings and weird loop drawing because
loop connected pins are hidden when hide_disconnected_pins=True.
- Activate loop pins as early as possible to enable correct counting of
connected pins when
connector.additional_components.qty_multiplier=populated.
- Check that loop pins actually exist before activating them.
- Use pin names instead of pin indices, until the last moment when generating the ports for the GraphViz nodes
- `Harness.add_mate_pin()` now uses pin names
- Remove unused `if is_arrow()` check from `Harness.connect()`
- Consolidate calling of `Connector.activate_pin()` to prevent subtle bugs
- Call it from `connect()` and `add_mate_pin()`
- No longer call it from `create_graph()`
- Misc. other tuning
If `show_wirenumbers` is omitted from a cable section, its value will be `None`. In that case, we want to choose a default based on whether this is a bundle or not.
If the user did specify `show_wirenumbers`, then its value will be `True` or `False`, and we want to respect that whether it's a bundle or not.
Bug: Failing to assign the default cable length unit when not present.
It was introduced in #198.
Fix: Test the correct cable attribute. This fix solves issue #205.
Using Any or str in type annotations might increase the need for extra
comments to explain the real valid values. However, such needs can be
drastically reduced with the help of semanticly named type aliases.
Each type alias have their legal values described in comments.
Actual validation might be implemented in the future.
This image, with an optional caption below, is displayed in the lower
section of the connector/cable node in the diagram - just above the
notes if present.
This solves the basic part of issue #27, and is a continuation of
PR #137 that was closed due to changes in the base branch.
- Shorten `part_number` to `pn`
- Shorten `manufacturer_part_number` to `mpn`
- Show `manufacturer` and `mpn` in a single cell of the node
- Replace `manufacturer` with `'MPN'`within the node if no manufacturer is specified.
- Rearrange order of P/N fields within node
`{pn} | {manufacturer}: {mpn}`
Closes#67.
- Allow defining arbitrarily long lists of alternating connectors and cables in a connection set.
- Start work towards removing 'ferrules' as special case, merging them with normal connectors
- Stramline auto-generation of simple, one pin connectors (ferrules, wire splices, ...)
