On 10/2/2010 11:13 AM, Dick Hollenbeck wrote: > On 10/01/2010 03:42 PM, Wayne Stambaugh wrote: >> Since the discussion has died down on the library structure. Here is a recap >> of the discussion. >> >> 1) The current concept of component will be replaced by symbol which is the >> graphical representation of a component. >> >> 2) The current concept of aliases will be replaced by component which will >> contain it's own fields but can share a symbol with other components to save >> memory. >> >> 3) Symbols may be shared among all components within a library definition. >> In >> other words, symbols will not be shared across libraries. >> >> 4) Merge the separate document file (.dcm) information into the new library >> file format. >> >> 5) Drop support for creating components with alternate body styles >> (DeMorgan). >> >> 6) Library files will be S expressions using richio. >> >> 7) Proper copy/paste should be added to the library editor to simplify >> library >> creation. >> >> 8) Improve component browsing (drag & drop?) for adding components to >> schematics. >> >> >> I will volunteer to complete the following: >> >> 1) Refactor component library objects to support the new library structure >> while maintaining backwards compatibility for reading the current file >> format. >> >> 2) Write the code to read from and write to the new file format. >> >> 3) Make writing new file format a build option until it is ready for >> production. >> >> 4) Back up current format library files to user_defined_file_name.lib and >> user_defined_file_name.dcm when saving library to new file format. >> >> 5) Create a separate library user_defined_file_name.lib when libraries are >> found containing alternate body styles (DeMorgan). >> >> 6) Merge the footprint list into the FOOTPRINT field and the data sheet >> definition string to the DATASHEET field in the new library structure. >> >> 7) Update the component editor to reflect the changes to the new library >> structure. >> >> I will not be adding the copy/paste to the library editor or changing the >> component browser as part of this. My goal is to get this done by >> Thanksgiving >> so I want to keep the task reasonable. >> >> Before I submit the new file format document for comment, would you prefer a >> more readable but larger file format: >> >> ( arc >> ( start_point 1000 1000 ) >> ( end_point 1500 1500 ) >> ( start_angle -45.0 ) >> ( end_angle 45.0 ) >> ( unit 2 ) >> ( line_width 1 ) >> ( fill_type none ) >> ) >> >> or a less readable but more compact file format: >> >> ( arc ( 1000 1000 ) ( 1500 1500 ) -45.0 45.0 2 1 unfilled ) >> >> Let me know and I will make the necessary changes to the file format >> document. >> > > > I think in order for the file to achieve one of the main objectives that > is driving the change, we need to achieve the "self documenting" > objective. If the new file is self documenting, then a person should > never have to refer to a separate "grammar document" to understand what > the file is presenting. He may need a grammar document to write the > file, but not to read it. > > So between the two choices you have given, I'd prefer the first choice, > by far. There is a region in the middle however, and this is > approached by having conciseness in the keywords. For example you could > shorten start_point to:
I prefer the more verbose style as well for readability. > > a) start_pt or > b) start # if it's obviously a point I have no objections to abbreviates as long as they are clear. > > But if we go too far in this direction we end up where we started, with > single character mysteries and numbers without any introductory keyword. > > In rare cases a single character could be meaningful, but you have to > wonder: (x 12.3) (y 20.9) when this will be true. A "point" could be > understood to have an x and a y and that x comes before y, for example. > > Overall I have been very impressed with the choices made in the specctra > dsn spec. There could be small keyword oriented building blocks that > you might find helpful in there. I'm guessing this is online somewhere. I'll take a look at it and see what parts of it make sense for what we are trying to do. Wayne > > Dick > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
