[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Parts DB API
Peter,
I have been working on the scheme interface quite a bit recently. What
you are discussing is fairly similar to the area I am digging into.
As a bit of a back ground. The basic algoryth I use for reading in a
project is to.
Take the list of input files from the command line.
For each of these schematic files read the file and construct a list of
unique symbols that are needed for this page. Creat a page add it to the
toplevel list of pages. Take the list of unique symbols and compare it
to the toplevel list of symbols eliminate symbols that are already in
the toplevel unique symbol list. For the remaining new unique symbols,
create a complex object and add it to the toplevel list of complex
objects (this is the cache library) (This is when I would be tempted to
query a db for alternative pin deffinitions, additional attributes etc).
See if any of these new complex objects have a source attribute. If they
do and they arn't in the list of pages already read in add the file name
to the list of files needing to be read. Then get the next file name
from the list of unread files and repeat the above until the list of
unread file names is empty.
At this point the toplevel data structure has two lists.
A list of unique pages.
A list of unique complex objects.
The list of unique pages just has shells of complex objects (unless a
complex object was embedded) in which case the page has the complete
embedded complex object.
What I am struggling with now is the question of granularity.
In my version of the "traditional" (fixed algorythm as upposed to
scripted) netlister application that generates a flat netlist and then
uses scripts to export it, there is a single function.
s_toplevel_collect_nets(TOPLEVEL *this_tl);
This function's purpose is to
1) fill out the shells of the complex objects that are on each page.
basically find a shell object find the real one in the complex object
list and copy the real one into the shell, rotate, mirror, translate and
adjust for slots as needed.
2) Build the buses from out of the bus segments and complex objects bus
pins.
3) Build the nets from out of the net segments and complex object net
pins.
4) break the bus string up into a list of net strings.
At this point each unique page has a net list and a bus list.
This is where we can either start building a hierarchical based netlist
or build a flat netlist.
Getting back to the granulairty issue it sure wood be easy to have a
single scheme function that basically told the toplevel to run the
function.
s_toplevel_collect_nets(TOPLEVEL *this_tl);
But I think this deprives script builders of future flexibility.
We could create four functions to reflect the four steps of toplevel
collect nets.
s_page_collect_complex(tmp_page, this_tl->symbols, this_tl->busripper);
s_page_collect_buses(tmp_page, this_tl->symbols);
s_page_collect_nets(tmp_page, this_tl->symbols);
s_page_process_bus_names(tmp_page);
Looking inside the poorly named function "s_page_collect_complex" (I
named it) we find a function that on a single complex by single complex
object does the real work of filling out shells of complex objects.
OBJECT *s_page_get_real_symbol(GList *symbols, OBJECT *page_symbol)
This is the level of granularity that I have been thinking about taking
the scheme api down to. This would allow the script writer to fill out a
a single shell object with the real one.
Reading all of this I am not sure if I have added clarity or confussion
into the discussion.
Best Wishes,
Steve Meier
On Tue, 2007-12-18 at 22:05 +0000, Peter TB Brett wrote:
> On Tuesday 18 December 2007 21:18:21 Dave N6NZ wrote:
> > peter@xxxxxxxxxxxxx wrote:
> > > Hi folks,
> >
> > <snip>
> >
> > > What I would quite like to do is to implement something similar to what
> > > has been described, especially since I have found a major bug which only
> > > (yet another) serious component library API change will fix.
> >
> > Excellent!
> >
> > > - What you want the API to be able to do (requirements).
> > >
> > > - How you want the API to be implemented. Loadable modules? Scheme
> > > functions?
> >
> > I agree that this needs significant discussion and a design document
> > before going off to generate a lot of code. Probably also needs some
> > prototyped code before committing to a design.
> >
> > As to backward compatibility, currently my gafrc contains a
> >
> > (component-library "...")
> >
> > clause, so perhaps we allow multiple types of component library clause?
>
> We already do.
>
> Actually, it's (component-library directory_path library_name), but the second
> argument is optional. You'll see this optional second argument being used to
> good effect in the next gEDA release to make the bundled symbol libraries
> more accessible.
>
> > Old libs are found the old way, new ones accessed through different
> > interface.
>
> I would like the old libraries to be one possible example of the new
> libraries.
>
> > I know zero about scheme. So, I don't know if it has a built-in
> > database interface or not. But I assume that it either has one, or can
> > call out to external shared libraries written in <language of choice>.
> > Perhaps something like:
> >
> > (component-library-helper <name of user supplied scheme function> (
> > <function defined parameter list> ) )
> >
> > and then the user can supply a scheme function with a defined interface.
> > We could ship an fully implemented trivial function as an example. The
> > user supplied function could connect to a database perhaps, or simply
> > call out to a C function. Something like:
> >
> > (component-library-helper sql-component-lib (host "localhost:5555"
> > sqluser "gschem" sqlpw "g5ch3m" database "productionsymbols"))
> >
> > The Web 2.0 equivalent might be:
> >
> > (component-library-url "ftp://....";)
>
> Yes, that kind of thing. I'd like to have a common -- and briefer! -- prefix
> for component library functions. Perhaps "clib:"?
>
> Also, I like the idea of Scheme functions which call out to external programs
> to do the "heavy lifting". We currently do this, but have some problems with
> portability -- these are fixable, as long as it's worthwhile.
>
> > I would advocate for the data being cached locally, with a freshness
> > test done on startup. I like to travel with my laptop and work off
> > line. I'm sure the exact format/protocol of the library found at the
> > target of the URL deserves a discussion of it's own.
>
> Maybe we can find a way to make the cache plugable, so that people could use a
> database cache or flat file cache if they wanted... something to consider.
> Also, what would the semantics be for updating the cache? Would the user
> need to be warned that updates were taking place?
>
> > Seems to me that is extensible and backward compatible, and hopefully
> > contains enough parenthesis.
> >
> > Now, what should the chooser do?
> >
> > The component chooser should be able to work with the attribute editor
> > to present the user with drop down boxes populated with sensible
> > defaults in the attribute editor.
> >
> > It should be possible for attributes to be automatically added and
> > reconciled. I would like to be able to enter just the part number, and
> > have other attributes added/updated to reflect that. For example, in
> > my database the part number for a resistor is sufficient to specify both
> > value and footprint, so there should be a trigger mechanism that allows
> > the attribute editor to automatically update related attributes.
> > Obviously, there needs to be a switch to turn this off for cases where
> > this side effect gets in the way.
> >
> > Upon reflection, its clear to me that symbol definition, attribute
> > editing, and library access are all interrelated and we want to take a
> > holistic view from a user interface perspective.
>
> Which is just what I was saying. :) Could you describe some use cases? For
> instance, how would you want to search the library? How would you want to
> browse it? How would you want components' attributes to be updated,
> automatically, or on user request? How would you want conflicts to be
> handled?
>
> These are just a few of the questions that need answering.
>
> Peter
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user