kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/3/20 8:59 AM, Jon Evans wrote:
> 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.

I'm just wondering about the impact to CVS users of adding them to the
project file.  I'm not sure if it's an issue or not.

> 
> -Jon
> 
> On Tue, Mar 3, 2020 at 8:42 AM Jeff Young <jeff@xxxxxxxxx
> <mailto:jeff@xxxxxxxxx>> wrote:
> 
>     Hi Henrik,
> 
>>     On 3 Mar 2020, at 13:33, Henrik Hansen <Henrik.Enggaard@xxxxxxxxx
>>     <mailto: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
>>     <mailto: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
>>         <mailto: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
>>     <mailto: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
>     <mailto: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
>