@Wayne, did you have any thoughts on this iteration? > On 20 Mar 2018, at 10:22, Jeff Young <j...@rokeby.ie> wrote: > > Oh, and I don’t think this materially alters the support equation: we already > have to deal with hand-edited boards, so what’s in the file is never > guaranteed to be something Kicad put there. > >> On 20 Mar 2018, at 10:19, Jeff Young <j...@rokeby.ie >> <mailto:j...@rokeby.ie>> wrote: >> >> Hi Seth, >> >> The original version spit out log entries for skipped elements. This >> version follows the XML/browser convention of silently ignoring. Even >> though this isn’t an XML format, I think we need to recognise that we live >> in an XML world and XML processing conventions set expectations. >> >> The patch strictly checks everything for round-tripping so that there is no >> data loss. The pad stuff is really a separate issue: it was meant to be >> loose only during development and then tightened up, but the tightening step >> was forgotten. Since we don’t store pad stuff we don’t understand, it has >> to be tightened. In short: if you can round trip stuff you don’t understand >> then do so; otherwise throw. >> >> Certainly one use case is opening boards from future versions. If you edit >> them, then you’re at your own peril. This behaviour is common enough that I >> believe it is well understood (although we should obviously mention it in a >> version-check dialog). >> >> Another use case is 3rd-party tools (which might even be written as Python >> plugins) that want to carry their own stuff around in the board. These >> might even be processing/manufacturing instructions that don’t have any >> visual expression in Kicad anyway. >> >> Cheers, >> Jeff. >> >> >>> On 19 Mar 2018, at 22:51, Seth Hillbrand <seth.hillbr...@gmail.com >>> <mailto:seth.hillbr...@gmail.com>> wrote: >>> >>> Hi Jeff- >>> >>> A few questions on how you are implementing this: >>> >>> 1) How does the user know what was skipped? I can imagine team members >>> with different versions getting into difficulty, especially if the features >>> being skipped change the board layout. >>> >>> 2) You are removing strict checking for most of the board but you are >>> adding strict checking for pad options. What's the difference? >>> >>> 3) If we keep these options around but don't allow editing/removing, don't >>> we run into a risk of generating a really wonk-y board that only looks >>> wonky in a newer version of KiCad but looks fine in an older version? For >>> example, imagine we implement rounded corners as a parameter and then a >>> user with an older version of KiCad edits and saves the board. The rounded >>> corner is only visible in KiCad 6 but the user in KiCad 5 can edit the >>> board to look right to her only to have her colleague use KiCad 6 and see >>> the track violating DRC. I think that might be counter-intuitive for users >>> but maybe there's a way around it. >>> >>> In general, if I understand the use-case, this is to allow users to open >>> newer boards in older KiCad versions? Is there another use case? >>> >>> I think I can see clear to this for options like the 3d-model offset where >>> it could be either inches or mm but there isn't a difference in the actual >>> layout. Allowing general unrecognized options would seem to open up a worm >>> can in terms of support as in "Please post the KiCad version and the file >>> version in order to figure out the problem." >>> >>> -S >>> >>> >>> >>> 2018-03-18 9:46 GMT-07:00 Jeff Young <j...@rokeby.ie >>> <mailto:j...@rokeby.ie>>: >>> OK, for your guys’ (re)viewing pleasure, a patch which losslessly >>> round-trips stuff it doesn’t understand. >>> >>> >>> >>> >>>> On 16 Mar 2018, at 19:15, hauptmech <hauptm...@gmail.com >>>> <mailto:hauptm...@gmail.com>> wrote: >>>> >>>> While i would still like to see this (my) shim go in, I agree with wayne. >>>> Until/unless a less brittle approach is used for the parser, it's better >>>> to signal a problem painfully and maintain the integrity of the file. >>>> >>>> I have to admit that when i first heard the s-expressions idea I assumed >>>> that the intention was to use a lisp like virtual machine for loading and >>>> maintaining design data. I've used vm's for data storage before (lua and >>>> python), and it's great. Parsing is free and you can jam in functions and >>>> other data when needed. >>>> >>>> >>>> >>>> On 17 Mar 2018 07:17, "Jeff Young" <j...@rokeby.ie >>>> <mailto:j...@rokeby.ie>> wrote: >>>> Hi Wayne, >>>> >>>> Patch reverted. >>>> >>>> However, I think your concern is misplaced. If we want to prevent >>>> dataloss (ie: from reading a 6.0 file into 5.0), then we should warn the >>>> user based on the version string (and give them a chance to say “I still >>>> want to open”). >>>> >>>> But either way, actually failing to read the file leaves the user in a >>>> pickle (especially when it’s easy enough for them to try out a nightly >>>> that may very well be ahead of their stable). >>>> >>>> (And for that reason I think it’s important to put it into 5.0, as >>>> otherwise it won’t help until we start making 7.0 file format changes.) >>>> >>>> Cheers, >>>> Jeff. >>>> >>>> > On 16 Mar 2018, at 18:00, Wayne Stambaugh <stambau...@gmail.com >>>> > <mailto:stambau...@gmail.com>> wrote: >>>> > >>>> > Jeff, >>>> > >>>> > Please revert this patch. Any changes to the board file parser and/or >>>> > formatter need to be discussed before the changes are committed. It has >>>> > been the intention that the board parser be pendantic by design to >>>> > prevent data loss by ignoring unknown formatting. Allowing anything >>>> > outside of the expected formatting in the board file is not something >>>> > that I want to introduce without some discussion. Even should we decide >>>> > to accept this patch, I would prefer we put it off until v6. >>>> > >>>> > That being said, the patch fails to build on windows with following >>>> > error: >>>> > >>>> > C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp: In >>>> > member function 'void PCB_PARSER::parseUnknown()': >>>> > C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp:1269:12: >>>> > error: request for member 'LogText' in '__acrt_iob_func(2)', which is of >>>> > pointer type FILE* {aka _iobuf*}' (maybe you meant to use '->' ?) >>>> > stderr.LogText( msg ); >>>> > ^~~~~~~ >>>> > >>>> > Cheers, >>>> > >>>> > Wayne >>>> > >>>> > On 3/16/2018 1:08 PM, Jeff Young wrote: >>>> >> Perhaps somewhat germane to this discussion I have removed the >>>> >> strict-format nags from the PCB parser. It now logs warnings to stderr >>>> >> but otherwise ignores structures it doesn’t understand. >>>> >> >>>> >> I’m not sure that helps hauptmech much as if the file is subsequently >>>> >> written the unknown markup will be lost, but I thought I’d mention it. >>>> >> >>>> >> Cheers, >>>> >> Jeff. >>>> >> >>>> >>> On 7 Mar 2018, at 20:12, hauptmech <hauptm...@gmail.com >>>> >>> <mailto:hauptm...@gmail.com>> wrote: >>>> >>> >>>> >>> Hi Thomasz, >>>> >>> >>>> >>> I hope I'm able to address you concerns. I'm stuck using kicad stable >>>> >>> in many situations. I brought clearances up for discussion last July >>>> >>> but no one moved on it, nor are they required to. Clearance management >>>> >>> is a major pain point for me so I wrote a fix. This patch will let us >>>> >>> (me and the people I collaborate with) work using version 5, but open >>>> >>> and close files written with a version patched with clearance handling >>>> >>> code. >>>> >>> >>>> >>> I believe that code exactly like this will go into version 6. Getting >>>> >>> it in earlier makes a huge difference to me, so I'm submitting it. >>>> >>> >>>> >>> On 07/03/18 23:30, Tomasz Wlostowski wrote: >>>> >>>> Hi hauptmech, >>>> >>>> >>>> >>>> I'm sorry but IMHO we can't accept your patch: >>>> >>>> - it changes the file format while we are already in feature freeze. >>>> >>>> This is a way too big change to accept for the V5. >>>> >>> >>>> >>> This patch simply adds tokens to the file format. No clearance data is >>>> >>> saved for files that use the netclass only. Files without clearance >>>> >>> tokens continue to remain without them. >>>> >>> >>>> >>> Yes it is a backward compatible file format change, but it does no >>>> >>> harm to V5 files already in the wild. >>>> >>> >>>> >>>> - we are planning to overhaul the clearance/design rules system in V6. >>>> >>>> Storing the clearance *DIRECTLY* for each track segment/via will >>>> >>>> conflict with any more sophisticated design rule management system. >>>> >>>> >>>> >>> I'm glad you are planning this. I am sure that regardless of the >>>> >>> sophistication of the rule system, you will store clearance directly >>>> >>> for exactly the same reason that track width is stored directly now. >>>> >>> There are always exceptions to the rules. >>>> >>> >>>> >>> If kicad choose a direction that does not store clearances per item, >>>> >>> then it is easy to rip these few lines back out. >>>> >>> >>>> >>> Did this answer your existing concerns about this patch? Are there any >>>> >>> other concerns you have about this patch? >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Mailing list: https://launchpad.net/~kicad-developers >>>> >>> <https://launchpad.net/~kicad-developers> >>>> >>> Post to : kicad-developers@lists.launchpad.net >>>> >>> <mailto:kicad-developers@lists.launchpad.net> >>>> >>> 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@lists.launchpad.net >>>> >> <mailto:kicad-developers@lists.launchpad.net> >>>> >> 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@lists.launchpad.net >>>> > <mailto:kicad-developers@lists.launchpad.net> >>>> > 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@lists.launchpad.net >>>> <mailto:kicad-developers@lists.launchpad.net> >>>> 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@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> 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@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> 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 > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
