I think, (caution danger) that an api that is limited manipulating the data structures in reasonable ways won't leave the database in an inconsistent state. For example, if the api allows you to add net segments to a schematic or add pins to a symbol and then limit you to asking the library to generate the nets instead of allowing you to directly add nets the nets would reflect the schematic and the symbols.
My guile api plan is. As I add guile functions I add to the documentation. 1) Support for guile scripts to read and write schematic files and symbol files. (Reading of schematic files is now complete) 2) writting of guile scripts for both the stock geda and my non-stock version. 3) function for displaying page structures. (completed) 4) Functions for controlling the swapping of symbols into schematic pages. (C code exists) 5) Support for retrieving and modifying attributes to guile. 6) Control of the netlister functions. Generate page level netlists and buslists. Generate project level flat netlists. 7) Fetching of nets or buses from the page or flat page. 8) Fetching of pins from a net 9) Fetching of parent devices from pins and as each step progresses document document document. I think that given a net list you should be able to ask each pin's parent about voltage limits. The net should know the expected voltage levels. Did we smoke? Similarily for signals I would like to ask about logic families do we all agree. How about asking if there is multiple drivers for a net? are they all tri-state? Please think about the types of questions you would ask the data structure? Where would the answers have to come from? pin, device, net? Thanks, Steve Meier p.s. I am palning on dropping my netlister which had a flow of read all schematic files and needed symbols run the netlister functions write the net out, in favior of my backnet program (look for a name change or suggest one) which will read in files based upon an input script, run a processing script and then write output files based upon an output script. The reading and writting of all files will be through more scripts. I think this will support a range of functions from, translating, updating, netlisting, embedding, back annotating and design rule checking. Dave N6NZ wrote: > Dan McMahill wrote: > >> From my point of view.... if libgeda and the scheme binding were >> expanded to let you have a really full featured database access via >> scheme, you could do all sorts of things. However, many of them may be >> specific to a particular person, project or company. >> >> You may decree, for example, that all instances have a company part >> number attribute filled in. You may only allow certain vetted symbols >> from heavy libraries in your design. Maybe you have a certain minimum >> grid size you refuse to go below. Maybe you want strict error checking >> of pin types. Perhaps you insist on each schematic having a certain >> sheet or every symbol having some specific attribute. >> >> I think there is no one size fits all or maybe even one size fits most >> solution. With a full API though, you can make it not too hard to >> implement most any check. >> > > Well said. I was trying ineptly to say the same thing, but you give a > very good list of examples. > > So, how far away is the code from having an API that allows full > functionality for data base access, with proper guards so that no API > call can leave the database in an inconsistent state? > > -dave > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
