X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Fri, 10 Jul 2015 05:35:22 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] why I parse sch: gnetlist, writing backends (Back
 annotation)
In-Reply-To: <201507092332.t69NWUEN006109@envy.delorie.com>
Message-ID: <alpine.DEB.2.00.1507100501200.6924@igor2priv>
References: <CAM2RGhTpfbqM7zNn72TBOjeL7B7LPT1PxSEU3+9aDdChFrPFTg AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1507090507530 DOT 6924 AT igor2priv> <alpine DOT DEB DOT 2 DOT 11 DOT 1507091329350 DOT 3444 AT nimbus> <559E86A4 DOT 3040109 AT ecosensory DOT com> <DC183265-AD4B-4707-970F-1EE5D3578126 AT noqsi DOT com>
 <201507091843 DOT t69IhGF6028321 AT envy DOT delorie DOT com> <6392CE1A-AFA0-4D62-979C-3F35786422BD AT noqsi DOT com> <201507092127 DOT t69LRHRC001744 AT envy DOT delorie DOT com> <559EFE69 DOT 1040601 AT zoot DOT drehmel DOT com> <201507092332 DOT t69NWUEN006109 AT envy DOT delorie DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



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