Alright, I have just pushed the patch.
Cheers,
Orson
On 05/18/2018 08:47 PM, Wayne Stambaugh wrote:
> You patch seems like a reasonable approach as an interim fix. Go ahead
> and merge it when you get a chance.
>
> Cheers,
>
> Wayne
>
> On 05/18/2018 10:52 AM, Maciej Sumiński wrote:
>> How ab
You patch seems like a reasonable approach as an interim fix. Go ahead
and merge it when you get a chance.
Cheers,
Wayne
On 05/18/2018 10:52 AM, Maciej Sumiński wrote:
> How about my patch? I do not dare to go for the ultimate solution right
> now, but is it acceptable as a stop gap measure for
Le 18/05/2018 à 17:35, Kristoffer Ödmark a écrit :
> I think another stop gap measure is to have the ERC handle this, but
> otherwise I am for Orson's patch.
This is also my opinion.
And Orson's patch is very acceptable.
>
> Better a defined bad behavior than an undefined random behavior is my
I think another stop gap measure is to have the ERC handle this, but
otherwise I am for Orsons patch.
Better a defined bad behavior than an undefined random behavior is my
opinion :)
On Fri, May 18, 2018, 16:53 Maciej Sumiński wrote:
> How about my patch? I do not dare to go for the ultimate so
How about my patch? I do not dare to go for the ultimate solution right
now, but is it acceptable as a stop gap measure for v5?
Cheers,
Orson
On 05/18/2018 03:28 PM, Wayne Stambaugh wrote:
> The suggestions made are all good and valid but I think to some extent
> there will always be some ambigui
The suggestions made are all good and valid but I think to some extent
there will always be some ambiguity. Users being users will make
mistakes filling in field data which will cause issues when annotating
and generating the netlist. In complex designs with lots of multiple
units symbols it's no
Hi Orson,
The problem should become less prevalent over time: for 6.0 I plan on fixing
the multi-sheet undo issues so that we can update all units in unison. (Of
course that still fails if you edit before annotating as we then don’t know
which units go with which.)
But I agree that anytime we
On 18.05.2018 11:14, Maciej Sumiński wrote:
Hi,
Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item
Hi,
Recently I have found out that the netlist exporter uses an algorithm
that for multiunit components uses non empty field values from the last
processed unit [1]. The problem is that the processing order depends on
the order of the units in the item list, so completely random.
Instead, I propo
9 matches
Mail list logo
