kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/08/2014 02:44 PM, Dick Hollenbeck wrote:
> On 05/08/2014 02:18 PM, Dick Hollenbeck wrote:
>> On 05/08/2014 01:31 PM, John Beard wrote:
>>> On 08/05/14 15:53, Dick Hollenbeck wrote:
>>>>
>>>>> That's exactly what I mean - older versions of KiCad should be able to 
>>>>> ignore, but retain, unknown data.
>>>>
>>>> This sentence has two concepts in it.  One is fools gold, the other is poorly expressed.
>>>>
>>>> 1) An older kicad should load a data file that is has never seen before.
>>>
>>> Is this fools' gold? A PDF reader from 2005 would probably still load a
>>> PDF made by newer software, even if there are new features it cannot
>>> understand. It might say "You can't see the embedded 4D MegaContent
>>> (TM), upgrade to a version that support PDF spec v5.6 for that", but
>>> it will show you what it can. You'd be annoyed if it didn't, it would be
>>> like Flash needing the latest version to watch your video, without the
>>> excuse that is necessary to implement the latest and greatest DRM fad.
>>>
>>>> The motivation should be that you want the flexibility to solve a specific problem.
>>>
>>> The motivation is that I want the flexibility to add a field to a
>>> .kicad_mod file, that still allows someone else to read the footprint,
>>> if they don't *need* to know about that field. Currently, that will
>>> cause THROW_PARSE_ERROR(), and they get nothing.
>>>
>>>> But it should not name future proofing as the motivation, because you don't want to
>>>> upgrade.  That's the part that gives me conceptual grief.
>>>
>>> It's not because *I* don't want to upgrade, *I'm* to the one who's
>>> hypothetically extended some aspect of the footprint format for my own
>>> ends. It's because J. Random McTrunkBuild (or even his cousin,
>>> McDistroVersion) shouldn't need to recompile with a patch from me to
>>> read a footprint of mine which has my field "(user_sku 45443)" or
>>> "(jedec_ref "SOT45")" in it, when he doesn't need or care about that
>>> field.
>>>
>>> The current state is there no way for people (not intimately familiar
>>> with the .kicad_mod format) downloading a footprint now to know if it's
>>> compatible with their KiCad without loading the footprint and then
>>> guessing that the "Expected...." message means the footprint contains
>>> unknown fields, as opposed to being malformed.
>>>
>>> Forced recompiles are only free if your time is worthless and any
>>> problems caused by running bleeding-edge PCB software in production
>>> environments have zero cost.
>>
>>
>> Submit a patch.
>>
>> Hope it gets accepted.
> 
> 
> Since your interest is limited to the *.kicad_mod file.  You can use the mentioned DOM
> parser in your rewrite of the KICAD_PLUGIN::Footprint*() functions.
> 
> Please include comparative benchmarks with your patch submission.  If there's no
> appreciable performance hit, then you have a chance getting the patch accepted.


A)  After the s-expression is read into the boost::property_tree, this line of pursuit
would have code in it that looked a little like the EAGLE_PLUGIN.  See that for examples.


B) But it sounds like you prefer to loosen the grammar checking and stay with the
recursive SAX-like parser.  Jean-Pierre had written some code to skip nested s-expressions
somewhere.  But these were elements that began and ended with the parentheses.

( arbitrarily complex thing to skip with nested parens also )


The path down B) is going to be harder to get working and maintain.   You might simply
compile the DOM tester program in tools and play with it first, so you are well informed
on what that path entails.  I'm thinking A) might be a cleaner solution.  Because instead
of skipping information, you truly can ignore it as it resides in the DOM tree (i.e.
boost::property_tree).  There's a difference between skipping and ignoring.  Ignoring is
easier.  The DOM parser will still load it and hang it in the tree for you, but that's not
you skipping it, that is basic DOM support.