kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Jeff,

There are several ways to do persistence.  It sounds like you are planning
to implement it as "save the state of all DRC markers", which is one way.
Another way would be to just save the exceptions (aka waived violations),
so closing and opening a board would not return the markers to view, but
re-running DRC would.

The choice of approach maybe impacts your questions.  If the goal is to
persist the entire state (i.e. someone can close and re-open PcbNew and
nothing is changed about the DRC markers), you obviously have to save a lot
more data and so the diff churn becomes more of a concern.  If you only
persist the "settings" in the form of waived violations, there shouldn't
really be a churn problem.

For ERC, I was always thinking that waived violations would have to be
stored in a project-local settings file rather than any one schematic file,
because ERC violations are not tied to a specific sheet.  It seems fine to
me to have this be a difference between ERC and DRC, though.

I personally do not think that I need the entire DRC state persisted across
runs for my workflow.  I just need DRC to produce the same results every
time it's run, and that includes persisting violations that I want ignored.
In regards to what ignoring means, the first option seems sufficient to
me.  I'll have to check some commercial tools to see if they actually store
more data, but I suspect not.
Usually when I mark DRC violations as ignored (in Altium, for example),
it's because I know there is a specific situation going on with a certain
item that is easier to ignore than to write a new rule against.
I don't use ignoring as a way of "bookmarking" where I am in a long list of
errors -- for that I just use clearing by type or by multi-selection.
Clearing (unlike ignoring) is not persisted in Altium.

@Wayne - If we do decide to put them in project storage rather than the
board file, I'll be moving them out of the project file to a dedicated file
along with everything else.  I'm fine with Jeff temporarily adding stuff to
the project file so as to not block him on the project settings work I'm
doing.

-Jon

On Tue, Mar 3, 2020 at 8:42 AM Jeff Young <jeff@xxxxxxxxx> wrote:

> Hi Henrik,
>
> On 3 Mar 2020, at 13:33, Henrik Hansen <Henrik.Enggaard@xxxxxxxxx> wrote:
>
> 1) As long as files with markers can be easily shared between people it is
> good.
>
> Why isn't "bloated diff" a problem for storing the markers in the project
> files?
>
>
> I don’t think people diff their project files, but I know some of them
> diff their board files.
>
>
> Would it make sense to have an option to not store the markers?
>
>
> That’s another option.
>
>
> 2) The second scenario of marking a specific error is the least
> surprising. How frequently will there be multiple errors of a certain type
> between the two same objects? That is a risky scenario, but it is hard to
> asses without knowing the chance.
>
>
> It’s not for multiple errors, but for running DRC again.  So if I mark
> “ignore pad to pad clearance between pads 1 and 7 of U22”, when I run DRC
> again it will still ignore it.  (The risk is that I might have moved them
> even closer together, and that while the first clearance violation was
> deemed acceptable, the second wouldn’t be.  Then again, if you want to
> check again you can delete your ignore list.)
>
> Cheers,
> Jeff.
>
>
>
> Best regards,
> Henrik
>
> On Tue, Mar 3, 2020 at 11:04 AM Jeff Young <jeff@xxxxxxxxx> wrote:
>
>> Part of the 6.0 DRC architecture is marker persistence.  This will allow
>> you to work your way through a large set of DRC violations, flagging those
>> that have already been checked as exceptions or some-such.
>>
>> Two questions:
>>
>> 1) Store markers in board file or project file?
>>
>> Board file is much easier (in fact currently zero-cost as it’s
>> implemented in my tree), but it may cause heartache in “bloated diff”
>> camp?  (Note that you can always press Delete All Markers when you’re done
>> with DRC, so you can choose to not have them in the board file.)
>>
>> 2) Should exceptions be of the form “ignore error type X between object Y
>> and object Z”, or “this specific error condition is a false-positive”?
>>
>> The first is more like a C++ #pragma.  The second is arguably “safer”,
>> but requires storing hashes of the entire data-state of objects Y and Z.
>> Likely expensive to calculate on large boards (and somewhat expensive to
>> implement).
>>
>> Cheers,
>> Jeff.
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>