X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sun, 12 Feb 2017 16:19:56 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] gnetlist chaos
In-Reply-To: <20170212122649.GD11686@localhost.localdomain>
Message-ID: <alpine.DEB.2.11.1702121538030.2881@nimbus>
References: <D0E30DB4-3ADF-415C-A95E-B58F09AE054D AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1702111609100 DOT 25113 AT nimbus> <CAJXU7q_ogjTmEOjruGJ3od-GYdv_gef0X_yc7Fne1q6kDu1xrg AT mail DOT gmail DOT com> <20170212090109 DOT GA450 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1702121039420 DOT 2050 AT nimbus>
 <20170212102807 DOT GB30751 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1702121203520 DOT 2781 AT nimbus> <20170212122649 DOT GD11686 AT localhost DOT localdomain>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
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 Sun, 12 Feb 2017, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via 
geda-user AT delorie DOT com] wrote:
> Do you already have support of hierarchy in your version?

What do you mean with "support of hierarchy"?  If you are referring to the 
fact that the Scheme API doesn't allow access to the hierarchy information 
in the netlist, this no longer applies as backends can now access the full 
information available to the netlister.

Backends using the legacy Scheme API obviously won't benefit from that 
unless the API is changed, something which I wanted to avoid unless there 
was some from of consensus to do that.  It wouldn't be hard, though, as 
the API is cleanly contained in one file:

https://github.com/rlutz/xorn/blob/master/src/python/geda/netlist/guile.py

> Could you provide us with analog of the partlist module I wrote in
> spring (now developed further in my branch)?

You introduced a lot of changes in the files, so it is hard to see what 
actually changed.  In what way is the output of the partslist backend now 
different than before?


> On Sun, Feb 12, 2017 at 12:37:15PM +0100, Roland Lutz wrote:
>> On Sun, 12 Feb 2017, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via
>> geda-user AT delorie DOT com] wrote:
>>> What were incompatible changes you're complaining about?
>>
>> For example adding a second, conflicting entry point for the netlister. 
>> If your goal is actually, as you claim, to make the netlisting 
>> functionality available from Scheme, you could add a binding for a simple 
>> function which constructs a Netlist object and assigns it to the_netlist.
>
> I have already done this in my version.

You have not done that.  Instead, you chose to modify the old code to 
patch some extra entry point onto that.

> And it took not much effort to just reflect C netlist in Scheme.  And 
> you could do the same writing Python bindings for libgeda, but you 
> prefer another way.

That's exactly the point.  Doing it the simple way isn't much effort, but 
it's wrong for several reasons: it still requires the netlister to be 
invoked from inside a gEDA/gaf application, it still only exposes those 
parts of the netlist information for which you bothered to write an API, 
and the code would still need a severe cleanup.

If your intention is to have a better Scheme API or a way to invoke the 
netlisting functionality from Scheme, just build on the current version of 
gEDA/gaf.  It allows you to do so really easily.


> As gschem GUI is based on gobjects and gtk, Peter Brett has used 
> appropriate functions to accomodate it to all our GUI- and 
> non-GUI-tools, which use gobjects.

Again, that's the point.  Doing so causes all kinds of problems for GUI or 
command-line programs which do not use GObjects, effectively forcing every 
tool which wants to read gEDA files to use GObjects.

> I don't want to undermine your work. I've not even dig deep into it 
> because of lack of time. I just cannot support two parallel code bases.

Then don't do it.  If you don't have the time to understand the existing 
code, you shouldn't be doing incompatible changes to a deprecated version 
of the codebase instead.

>>> The most easy way as I see it is rewriting two these program as Scheme 
>>> modules and I've already did it with gsymcheck and published the 
>>> branch on github a year ago.
>>
>> I don't think rewriting gnetlist is a good idea.
>
> You've actually did that, IIUC.

I did not.  If you don't believe me, check out the code I first posted on 
this list in 2015.  It is still much closer to the C code (even most 
function names were still unchanged) and reproduces the exact same output, 
but it already has most of the structure the code now has.

> And just your statement that your code is better says nothing to me, 
> especially after I had many problems with it.

You continue to state that but can't give me a reproducable example, so I 
can't take your claim serious.