Mail Archives: geda-user/2015/12/30/11:45:47
On Wed, 30 Dec 2015, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Wed, Dec 30, 2015 at 06:03:20AM +0100, gedau AT igor2 DOT repo DOT hu wrote:
> ...
>>
>> Now you will be hearing, for years, that I want gschem to find all
>> occurances of a net, by name, independent of how exactly it became a net. I
>> know you don't, but for one, I do find it an error in the design, in the way
>> gschem models the world.
>
> A while ago I started to reverse-engineer one schematic which I
> needed at work. I worked in a hurry and wrote not very function
> style (I'm still learning scheme) though working parser which
> creates schematic using something like a home-brew netlist
> [1]. (At least it worked in my two projects.) After my issue was
Cool, thanks!
I may misunderstand your words, but what I am looking for is not a script
that creates a schematics, but something that tells me where exactly a
connection is made in a set of existing schematics. I do not have a
netlist as input, I have a set of sch files and a question like "where
is U5, pin 1 connected to Vcc?". The output should be: gschem GUI panning
and zooming onto the spot where the connection is realized.
If your script can do this, please let me know how to load it in gschem.
If it can not, please don't invest time for advancig it for me: I already
have a working solution in C.
> solved, I lost interest to continue the work. Some time after that
> I was going to propose to look at it for your needs when we were
> discussing your back-annotation idea until recognized how much you
> hate scheme (still don't understand, why? move the first paren in
> function(x,y,z) to be at the beginning and you will have lisp form
> (function x y z)). There are some functions there which find all
> connections (without gnetlist and all C mess (glists, geda_lists
> and so on) involved). If you'll look at it, you'll find it is
> pretty simple (though some things might be done much simpler, and
> it contains inline and commit comments in Russian). That is the
> way I would change libgeda (leaving C accessors to functions and
> data available for C programmers).
I am more or less happy with my C implementation. I'd replace it with
something else only if that other thing offered more. What my C solution
doesn't handle at the moment is auto-crawling hierarchical desing and
understanding hierarchical refdes. I think this is the part where only a
gnetlist->gschem communication channel could solve the problem - or a
redesign of how much gschem should undrestand about the model it works on.
We indeed disagree on whether code should be in C or in scheme, and what
looks simple and what doesn't. Let's not revisit this topic, we won't
convince anyone about this.
- Raw text -