Mail Archives: geda-user/2015/07/10/09:27:32
On Fri, Jul 10, 2015 at 05:35:22AM +0200, gedau AT igor2 DOT repo DOT hu wrote:
>
>
> On Thu, 9 Jul 2015, DJ Delorie wrote:
>
> >
> >>How do you think this mapping tool should get the data from the schematic -
> >>via a special scheme netlist script or by reading the schematic file itself?
> >
> >Nothing should read the schematic itself. I thought of two ways:
> >
> >1. The various tools that deal with attributes also know about
> > "implied" attributes, which are the result of database and ruleset
> > queries. Thus, in gschem's attribute window you'd have access to
> > the database as well as user-specified attributes. This lets the
> > user override the rules while still having the convenience of a
> > database.
> >
> >2. The netlister would need to feed its data into some sort of engine
> > that combines the specific attributes with implied ones, adds in
> > other external data and/or back-annotation data, and produce
> > whatever the backend needs.
> >
>
> Off topic: the other day I used gschem to draw diagrams. The idea goes like
> this: I have some graphical info like axis, scales and stuff as lines and
> text and I have the set of curves as nets. I translate the whole thing to
> 0;0 so sch coordinates are actual values.
>
> At the end I parsed the sch file directly to get the coords of line
> segments.
>
> This, and my past adventure with the text/xml/json/lihata gnetlist backends
> made me think over my gnetlist-issue again. I still think the best solution
> here would be:
>
> I'd like to see a gnetlist library written in pure C so it's easy to do
> bindings to whatever languages or tools. We already have a lot of parts of
> gnetlist in C... but unfortunately a some of the logics in scheme scripts.
> I'd totally decouple scheme from gnetlist, scheme scripts would only be an
> optional user of the lib.
>
> The thing I figured while working on that exporter backend was that the C
> library of gnetlist did not expose everything about the schematics in a
> consistent way. Rather it looked like a semi-random collection of specific
> lookups that evolved most probably on a "this thing is needed by my spice
> backend script" fashion. Like there is a
> "gnetlist:get-all-package-attributes" but for some reason it didn't really
> get me _all_ the attributes so I ended up using
> gnetlist:vams-get-package-attributes. I think vams is one of the backends
> that also needed a list of attributes and also got hit by the fact the
> default listing is filtered/altered.
>
> Furthermore I think the library should consists of 2 levels: a low level
> that does simple queries without much logics or filtering and a high level
> that lists connections for example.
>
> The low level should expose everything possible and let the user filter. It
> should show how exactly things are on the schematics. It doesn't do anything
> with "implied" attributes. If there are multiple components placed with the
> same refdes, each can be accessed independently so the user can query the
> attributes of each. The low level shall not be limited to pins and
> components and nets, but should be able to operatoe on
> all graphical elements, net segments, components, where the actual component
> is loaded from, etc. If I want to see on what coordinate a net ends, I
> should be able to.
>
> The high level should construct things that are not literally in the sch but
> can be calculated. It should have the logics for "anything that has the same
> refdes is merged into one by component", it should do the "implied"
> attribute magic, it should be able to calculate what's on the same net, deal
> with the meaning of pin attributes, etc.
>
> There should be a clear separation between the two levels so when someone
> uses. The high level calls should be generic and should often return lists
> or arrays of references to low level objects.
>
> So the answer to my own question in the subject: I sometimes parse sch
> directly not because that's the proper solution, but because instead of an
> endless recursion, I want a simple tool to be done, in a finite time frame.
>
> There is libgeda; I am not sure about the details but I guess I could use it
> to parse the sch for me, but then I'd need to do all the netlisting and
> higher level stuff manually.
>
> There is gnetlist; it can do both, but not in a generic way. If I need
> anything "unusual" (basically anything beyond accessing the most common
> attributes and an abstract list of connections) I either can't, or would
> have to write excessive amount of scheme or would have to write a C callback
> for scheme.
>
> Regards,
>
> Igor2
TL;DR
Have you ever tried to read 'info geda-scheme'?
- Raw text -