Mail Archives: geda-user/2017/02/12/10:21:57
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.
- Raw text -