Mail Archives: geda-user/2017/02/12/14:42:33
Roland,
On Sun, Feb 12, 2017 at 04:19:56PM +0100, Roland Lutz wrote:
> 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.
I mean hierarchical representation of a schematic. Something like
schematic-tree in my branch. The makedepend backend uses it.
>
> 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:
I remember your words about consensus on this list. Should I
reproduce them here?
>
> 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?
I posted an example of simple LaTeX backend on this list in summer.
I said 'partlist.scm', not 'partslist'.
>
> >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.
Oh, well.
>
> >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.
Even before my refactoring, gEDA Scheme API was able to reveal any
info you could use to make structures you need, and I used just
it. In my branch, all information available in gnetlist C code is
now available in Scheme. I don't understand your point
here. Anyway, you also had to write some API to make available
your data in xorn.
>
> 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.
About my intentions I've written several times last few days, so I
don't want to reiterate here. Besides, I've already stated clearly
that I won't work on geda-gaf in mainline any more.
>
> >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 think anything is wrong with this now, though I myself
wouldn't use gtk for configuration. I heard several opinions on
this and just don't bother yet.
> >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.
I didn't do anything in geda-gaf since September so you're off the point.
>
> >>>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.
Oh, thank you. First review my branch and find all the bugs
(<irony> tags omitted).
>
> >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.
>
Oh well.
And let's stop this "constructive" discussion.
--
Vladimir
- Raw text -