I was going to say that if they’re now a copy we could simplify the draw code a
bit.
But I see Wayne has already done that. :)
Cheers,
Jeff.
> On 12 Dec 2019, at 08:57, Jonatan Liljedahl wrote:
>
> On Thu, Dec 12, 2019 at 12:01 AM Wayne Stambaugh wrote:
>
>> Now that the LIB_PART of the SC
On Thu, Dec 12, 2019 at 12:01 AM Wayne Stambaugh wrote:
> Now that the LIB_PART of the SCH_COMPONENT is no longer a pointer link
> but an actual copy of the library symbol, any change to the underlying
> library symbol will result in stale pin map pointers.
I'm just curious to know, since I'm no
Hi Jon,
That's kind of what I thought. I will track down every where in the
code where we call UpdateSymbolLinks() and to a full connectivity graph
rebuild. It's ugly but at least there will be no stale item pointers.
We really should only be calling UpdateSymbolLinks() on schematic load,
symbol
Hi Wayne,
I can't look at the code this minute, but I think you basically have it
right. This call is quite expensive so if we can not trust the pin map to
be valid, we'll probably want to come up with some way to make a targeted
update so that we don't incur the computation time of a full recalcu
I'm guessing this is primarily a question for Jon but maybe someone else
can answer my question. My recent symbol inheritance merge revealed
that the connection graph code has a serious fragility issue. This
comment in the updateItemConnectivity function raised a red flag:
// Assumption: we don'
5 matches
Mail list logo
