X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:subject:message-id:mail-followup-to:references
         :mime-version:content-type:content-disposition:in-reply-to
         :user-agent;
        bh=ruxijVreHg503TKbQk/G5C7bE7Rk3jRddR4rZCZg5ac=;
        b=qzmUlu5RoY/Jf3XMIITNOpYNJOEg+yxFXSxw7cQShx6OjJPtKbqYXufT+5Ia3Q+O75
         pGwIctyz17JcF+XSDLDBUrWxwR9VwHdF7Os/Imi1Uk/FSsvnhfjbi1T0LC5rWxy4bU9y
         h1/cvEwM/Zb4C2EehoSWFsn1qKpD6qRaArouTKG/HH9MQbdZ4iCH9V9axjqwmb874qUn
         DCrAJbZ+Cc5WECuHIBXsEp2LQ6sE3ZD2H0H19S76/voJK+RPWAjumYTNMPY8c/NkoPji
         uKGgUs8C9JCidaiz/zgHbDHpmOanjuCYmdv0DyeB7mnBR+KS1UDXCzX3xXUTnB0MyWZf
         UDbw==
X-Received: by 10.152.203.233 with SMTP id kt9mr17695533lac.99.1436534814990;
        Fri, 10 Jul 2015 06:26:54 -0700 (PDT)
Date: Fri, 10 Jul 2015 16:26:51 +0300
From: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] why I parse sch: gnetlist, writing backends (Back
 annotation)
Message-ID: <20150710132650.GA15876@localhost.localdomain>
Mail-Followup-To: geda-user AT delorie DOT com
References: <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>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1507100501200 DOT 6924 AT igor2priv>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1507100501200.6924@igor2priv>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 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'?