kicad-developers team mailing list archive
Mailing list archive
Re: exploiting human readability
On Oct 5, 2010, at 19:26 PM, Brian Sidebotham wrote:
> On 5 October 2010 15:33, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> I get paid to brainstorm, so brace yourself.
>> Continuing with library brainstorming, the following is put on the table
>> for consideration and eventual evaluation. Brace yourself, this is out
>> of the box. Open up your mind before proceeding.
>> Remember the HTML editors which let you view HTML source and the
>> resultant GUI presentation at the same time? One panel has the html
>> source, another shows you its effects. The following concepts use that
>> UI paradigm. Use the source Luke, use the source.
>> A library is not a library file:
>> The concept of a *library file* is gone. There are none. The concept
>> of a library can still exist but it is a RAM resident concept. Each
>> component that we traditionally think of residing in a *library file* is
>> actually in its own file on disk in a directory (or repo or schematic).
>> A library is only built in RAM during the loading of a collection of
I think this would be great. Does this mean we get 3 sorts of files?
symbol, footprint and part-files?
(symbol, e.g., a resistor,
component, e.g., a 10k 5% resister of .25W with footprint R025W
Part-files can be project specific or general. Parts can be created automatically when needed and in the simples form only has 2 include-lines (and perhaps a part-number, e.g., R1). You could add lines if you want gate-swapping.
>> Loading components:
>> The act of loading components utilizes the notion of inheritance and
>> classical file inclusion like the C++ #include. Let's go back an
>> understand inheritance thinking about Java. In a Java virtual machine
>> each class definition container has a method table. That table is
>> initially populated with methods from the base class. As the base class
>> is extended some of those methods are overloaded (replaced) with ones
>> from the derived class in the internal method table. Additional fields
>> can be introduced in derived classes also, into what is a field table
>> for that class. Now lets move that conceptual model to a component.
>> Lets assume we have a pin table, and a graphics table. We give a
>> component the ability to inherit from: 1) a base code fragment, or 2)
>> symbol or 3) component. In this case you can do pin additions, or pin
>> modifications, pin swapping, in the same way you can overload a Java
>> class's method table. Pins can be overloaded or replaced, and graphical
>> primitives can be inherited and extended.
Would we really need base-symbols and base-footprints? Meaning, do we want symbols that are derived from other symbols? Why not flatten all symbols and footprints? I *think* this would be much easier to use and maintain.
A part would be "derived" from both a symbol and a footprint, and you can overload some parts (e.g., which NAND to use in the 74LS00). Symbols could already be linked to footprints, such that when you select a symbol you get a list of footprints (you should be able to override this).
>> The magic happens during the loading phase of the S-expressions, so that
>> the "built up" component is fully assembled in RAM by using pieces from
>> various places "out there", while *loading*.
>> If desired, the various pieces can be ear-marked with their origins in
>> full recognition of the existence of inheritance. One might do this
>> only to facilitate graphical editing of a derived component, although if
>> the grammar is sweet enough, textual editing may be enough for all
>> editing of derived components.
>> Re-loading is simply done by clicking a "parse" or "show" button. The
>> the parser reloads the source stream and does file inclusions as called
>> for. A portion of that source stream comes from the textual UI panel.
>> Inherited portions come from a library (which is now a RAM resident
>> concept only).
>> (component SOMENAME
>> # inherit is like C++'s #include
>> (inherit SOMEOTHERNAME WHERE)
>> (pin 12 ... WHERE...ORIENTATION)
>> (pin 13 ... WHERE...ORIENTATION)
>> (pin 14 ...)
>> Pin 12 and 13 are provided here and they are overloads because 12 and 13
>> have already been defined in SOMEOTHERNAME. So this could be the means
>> of a *pin swap*. However pin 14 is new, since SOMEOTHERNAME did not
>> have one, so this is an extension. In one example we see both a)
>> overloading and b) extension.
>> This example would be a new SOMENAME component, and its graphics are
>> fully inherited from SOMEOTHERNAME, and can be extended here, but not
>> overloaded in any way that I can think up.
>> Where do they come from? and component versioning:
>> The ability to reference an external component by a GUID (globally
>> unique ID) of some kind lets you pull in components from anywhere in the
>> world. A GUID inherently needs to respect versioning. That is to say,
>> if you make an edit to a component that somebody else depends on, you
>> still have to provide the original version also.
>> Enter the version control system. Since each component and component
>> source code fragment exists in its own file, a source code control
>> system is used to house these files, and they can be accessed by using a
>> SCCS repo, file name and version number, over the Internet, or locally.
>> One possibility for this is to build a tcp socket oriented bridge into
>> Bazaar's access API, which I assume lets you access any version of any
>> archived file. Only one such server is needed for the "kicad supplied
>> libraries". Behind the scenes the bridge/server simply uses launchad's
>> bazaar based repo.
>> The loading of code fragments from afar need to be cached in RAM, so the
>> concept of a *library* does not go away. A library is a RAM container
>> that caches those things coming from afar in order to enhance speed.
>> But remember, kicad supplied libraries are essentially "read only" (for
>> all but those with the generating scripts). So putting them under SCCS
>> and in launchpad as a primary place of dwelling is reasonable for those
>> with Internet access. Others could check out the library branch.
I think we should not code a VCS into kicad, but let the user choose which one to use. However, it makes sense to host one in SVN on launchpad.
>> I can have this coded by Tuesday, given enough incentive. (I'm just not
>> going to say which Tuesday.)
> Includes would be awesome, and I think that having the source +
> graphical split would work very well.
> Some descriptors could be very generic. For example I first draw a
> generic op-amp package which results in a purely graphical symbol.
> Then I can create a set of components which include the graphical
> items from the symbol, and maybe do some pin mapping, footprint
> selection and include some spice parameters.
> Just thinking of future expansion and the possibility of using Spice
> simulation in KiCad, variable substitution might be nice to include
> the relevant spice parameters depending on what the user sets the
> value field to in the schematic.
> Assuming that variable substitution is evaluated between pairs of % symbols:
> (component QUANDOPAMP
> (inherit QUADOPAMPSYMBOL)
> (inherit SPICE%Field:Value%)
> So in the above, when I edit the value field in the schematic, the
> relevant spice parameters are included for the op-amp that I'm using
> (provided that the spice parameters can be found of course!) This
> would make evaluating different components really easy.
> Intelligent Components
> This opens up a thought that you can do evaluation on components
> properties. A single resistor component could translate to several
> different parts in a schematic depending on the field values.
> For example, a generic resistor could set its own footprint field
> depending on the power field:
> (component RESISTOR
> (inherit ANSIRESSYBOL)
> (field Footprint
> (option 0.25W (footprint 025WRES) )
> (option 0.5W (footprint 050WRES) )
> (option DEFAULT (footprint 025WRES) )
I am not sure if this kind of intelligence does any good. Perhaps it does in another example, but I am not a great fan of a tool choosing the "best" option for me, because a lot of times it is simply wrong.
> I'm not sure this would be valid syntax, but hopefully you get the
> idea. Set the resistor power in eeschema and the footprint will be
> selected semi-automatically. Obviously more options can be inherited
> or inserted if the source of the component is available to edit.
> Possibly, we could have an equivalent of a switch statement in the part.
> I think inheritance could open up a world of possibilities...
> Best Regards,