kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 15 December 2010 13:49, Dick Hollenbeck <dick@xxxxxxxxxxx> 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.)

No problem, I'm sure the more heads the better!

> 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.

This sounds very elegant, and a neat solution! As Wayne pointed out
this means the definition of what constitutes a complete part can be
decided upon later and can be subject to change as and when.

Best Regards,

Brian.