kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/15/2010 08:46 AM, Dick Hollenbeck wrote:
> On 12/15/2010 08:35 AM, Wayne Stambaugh wrote:
>> On 12/15/2010 8:49 AM, Dick Hollenbeck wrote:
>>> On 12/15/2010 06:19 AM, Brian Sidebotham wrote:
>>>> On 14 December 2010 22:49, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>>>>> I made some ,inor changes to clarify inherited vs base part and changed
>>>>> LPID names reflect local naming convention as suggested by Dick.
>>>>>
>>>>> Wayne
>>>>>
>>>>> On 12/14/2010 9:39 AM, Wayne Stambaugh wrote:
>>>>>> I know all of you've been on the edge of your seats waiting for the the new
>>>>>> part file format since Dick announced his plans to start working on the
>>>>>> distributed library.  So without further ado, attached is the preliminary copy
>>>>>> of the library part file specification.  Please take a look at it and make sure
>>>>>> I didn't forget anything.  I have tried to accommodate all of the previous
>>>>>> library discussions as best I could.  If I missed something, it wasn't
>>>>>> intentional so please let me know so I can revise the specification.
>>>>>>
>>>>>> Initially, I would like keep the discussion focused on what is missing and how
>>>>>> it should be implemented.  Please keep the discussion on semantics like "I
>>>>>> would rather use thickness instead of line_width" until after we've hammered
>>>>>> out all of the technical issues.
>>>>>>
>>>>>> Once we have a consensus, I will convert the document into a more formal format
>>>>>> similar to the current file specification documents and commit it to the
>>>>>> documentation repo since that is were the rest of Kicad's documentation resides.
>>>>>>
>>>>>> I know it's been a long time coming so thank you for your patience.
>>>>>>
>>>>>> Wayne
>>>> Hi Wayne,
>>>>
>>>> I just got a look through the doc. I have a few questions/observations for you:
>>>>
>>>> (1) If I browsed a library for a part which contains all of the parts
>>>> information below the line:
>>>> # This is an example of a dual input NAND gate A of a 7400.
>>>> in the document, does this mean that I would see all of the parts for
>>>> selection? i.e. dual_input_nand_a, dual_input_nand_b,
>>>> dual_input_nand_c, dual_input_nand_d, dual_input_nand_demorgan_a,
>>>> dual_input_nand_demorgan_b, dual_input_nand_demorgan_c,
>>>> dual_input_nand_demorgan_d, 7400, 74LS00, and SN74HCT00NSR
>>>>
>>>> I would have thought there would need to be a way in the syntax of
>>>> showing what was a selectable/finished part and what was merely a
>>>> "symbol" or partial part which should not be allowed to be entered
>>>> into the schematic directly.
>>> Brian,
>>>
>>> This is a good observation, about the readiness of a part.  (Don't mean to butt in,
>>> since you asked Wayne.)
>> Brian,
>>
>> Good catch.  I hadn't actually thought about that.
>>
>>> Three possible solutions to keeping a part off limits for instantiation:
>>>
>>> 1) Mark the part as not ready for prime time using Sweet.
>>>
>>> 2) The part parser is dancing through all these part body expressions.  Rather than
>>> the user saying in syntax that the part is not ready for primetime, it may be possible
>>> for the parser to reach such a conclusion and then reflect this in a class PART::state
>>> field, indicating that it is syntactically correct, but incompletely specified.
>> My preference would be solution 2.  If we change our minds as to what defines a
>> valid part, we only need to change that in the library code.  If we implement
>> it as a new part file element, we would have to change it in every part file.
>> It also creates additional syntax for the part file.  One of my primary goals
>> was to keep the part syntax as clean and readable as possible so I will be
>> reluctant to add anything that can be solved in code.  It should be easy enough
>> to have the librarian only display valid parts for inclusion into a schematic.
>>
>> Wayne
> Right, I should have given my 4th solution a number 4).  Definitely 2) is needed, and
> the good news is 2) and 4) are not mutually exclusive.  You could not implement 4)
> without 2).

Since the parts list is the origin of the BOM, we may need to have 4) also, other wise
folks will go to buy incomplete parts and get all confused.  :)

Worse yet, they may come back and ask us where to get those parts.