kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Current implementation:

1) persists only the exclusions
2) persists them in the project file as a { error_code, main_item_desc, main_item_uuid, aux_item_desc, aux_item_uuid } tuple

We can easily break them out if the project file is migrated to multiple JSON files for 6.0.

Should have something for people to play with tomorrow.

Cheers,
Jeff.


> On 3 Mar 2020, at 21:01, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
> On 3/3/20 3:59 PM, Jon Evans wrote:
>> Are you talking about temporary churn to project files?
>> In my opinion, I think during the 6.0 development cycle it's okay as
>> long as we stabilize by the time we cut a RC.
> 
> Churn.  But given that it only effects nightly builds, I can live with it.
> 
>> 
>> Again, in my opinion we should only persist the "ignore" rules, not
>> every marker, and if we take that approach, people won't be impacted
>> unless they use the ignore feature.
> 
> This is going to end up in the project file isn't it?  If so, then I
> have no issues with this.
> 
>> 
>> -Jon
>> 
>> On Tue, Mar 3, 2020 at 3:56 PM Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>> wrote:
>> 
>>    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>
>>    <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>
>>> <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx> <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>>> wrote:
>>> 
>>>      Hi Henrik,
>>> 
>>>>      On 3 Mar 2020, at 13:33, Henrik Hansen
>>    <Henrik.Enggaard@xxxxxxxxx <mailto:Henrik.Enggaard@xxxxxxxxx> <mailto:Henrik.Enggaard@xxxxxxxxx <mailto:Henrik.Enggaard@xxxxxxxxx>>
>>>>      <mailto:Henrik.Enggaard@xxxxxxxxx <mailto:Henrik.Enggaard@xxxxxxxxx>
>>    <mailto: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>
>>    <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>
>>>>      <mailto:jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx> <mailto: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 <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>          <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>>>>          Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>          More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>>> 
>>>>      _______________________________________________
>>>>      Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>      Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>      <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>>>>      Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>>      More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>> 
>>>      _______________________________________________
>>>      Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>      Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>      <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>>>      Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>>      More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
>>> 
>> 
>>    _______________________________________________
>>    Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
>>    Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>    <mailto: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