You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a consequence of #63, a composite component's subcomponents would not get unique names for their geometry coordinate systems if rendered directly to a Cell (i.e., if render! were called without build!, which replaces comp with geometry(comp) in references). Even prior to that, Path components would get turned into coordinate systems with the path's name, not the unique geometry name, and this would happen whether build! was called first or not.
This fix does a couple things to ensure different components get rendered as coordinate systems with unique names (whether build! is called or not). First, when we encounter a component while rendering to a Cell, we use its coordsys_name (unique by construction, usually name(geometry(comp))) rather than its (non-unique) name(comp) to name the Cell that holds its rendered elements and references.
This doesn't quite solve the Path problem because of the slightly hacky _geometry!(cs, path), which adds the path itself to an intermediate coordinate system path._geometry with a unique name. (We do this for some complicated and subtle reasons where I couldn't find a better solution.) So if we defined coordsys_name(path) = name(geometry(path)), then we'd still end up with a stack of two identically named Cells -- the wrapper from path._geometry, and (in its references) the one containing the path's rendered elements and references. To get around this, coordsys_name(::Path) checks whether path._geometry contains the Path already. If it does, then we use uniquename(name(path)) for the second cell. This is also a little hacky, but as long as we understand that this new function coordsys_name is meant only for this rendering context I don't see it causing any problems.
Fixed one more bug involving composite components holding multiple instances of another composite component (it was using its component name rather than a uniquename as a prefix), as well as related BasicComponent and BasicCompositeComponent issues. geometry(comp) should always return a CoordinateSystem with a unique name. Normally this is guaranteed by the constructor created by @compdef, but those two are manually defined. So we ensure that the BasicComponent's geometry field and a BasicCompositeComponent's _schematic.coordinate_system field (which are returned by geometry()) have unique names when the components are constructed (without affecting the component name itself).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As a consequence of #63, a composite component's subcomponents would not get unique names for their geometry coordinate systems if rendered directly to a Cell (i.e., if
render!were called withoutbuild!, which replacescompwithgeometry(comp)in references). Even prior to that,Pathcomponents would get turned into coordinate systems with the path's name, not the unique geometry name, and this would happen whetherbuild!was called first or not.This fix does a couple things to ensure different components get rendered as coordinate systems with unique names (whether
build!is called or not). First, when we encounter a component while rendering to aCell, we use itscoordsys_name(unique by construction, usuallyname(geometry(comp))) rather than its (non-unique)name(comp)to name theCellthat holds its rendered elements and references.This doesn't quite solve the
Pathproblem because of the slightly hacky_geometry!(cs, path), which adds the path itself to an intermediate coordinate systempath._geometrywith a unique name. (We do this for some complicated and subtle reasons where I couldn't find a better solution.) So if we definedcoordsys_name(path) = name(geometry(path)), then we'd still end up with a stack of two identically namedCells -- the wrapper frompath._geometry, and (in its references) the one containing the path's rendered elements and references. To get around this,coordsys_name(::Path)checks whetherpath._geometrycontains thePathalready. If it does, then we useuniquename(name(path))for the second cell. This is also a little hacky, but as long as we understand that this new functioncoordsys_nameis meant only for this rendering context I don't see it causing any problems.