Re: gEDA-user: How to deal with single/dual parts?

[John Doty <jpd@xxxxxxxxx>]

On Nov 18, 2009, at 3:06 PM, Peter Clifton wrote:

> On Wed, 2009-11-18 at 20:53 +0000, Peter Clifton wrote:
>> On Wed, 2009-11-18 at 18:57 +0100, Stephan Boettcher wrote:
>
>>> I think I'd prefer flexible mechanism instead of multiple mechanism
>>> doing almost the same.
>>
>> Fine, condemn us to the status quo - where gEDA has no ability to
>> identify potential gate-swaps automatically, (or pass them to the  
>> layout
>> tool to do so).
>
> <Peter C went temporarily crazy with his rather over-exaggerated  
> reply,
> no personal offence was meant - I just got rather frustrated with the
> situation...>

No offense taken. These are difficult issues. I hope you take no  
offense either: I will repeat that gEDA is a wonderful, superior  
toolkit, and you've been a major contributer to it. Thank you again!

>
>
> I'm not condemning gEDA for wanting to retain ultimate flexibility,  
> nor
> the requirement that gEDA must be kept capable of driving nearly _any_
> work-flow.. that is good.
>
> I'm not to bothered that this means we need to think _really_  
> carefully
> before hacking features into gschem / libgeda - certainly not allowing
> them to detract from, or break valid work-flows. Yes, it slows down  
> the
> addition of new features - but that is probably good too.
>
> What really pains me - is that development has pretty much stagnated -
> because we can't seem to get _anything_ new into the suite to help
> provide basic functionality other packages take for granted.

1. gEDA is fundamentally *superior* to those packages.

2. The design of gEDA is such that the flow-dependent stuff should be  
implementable and implemented via scripted modules. So, we can have a  
set of modules for hobbyist-scale projects, and a different set for  
VLSI, for example. We are already using this to wonderful effect on  
the backside of gnetlist (basic functionality that *we* take for  
granted, but that the other guys don't have). We have internal  
scripting with Guile, external scripting with bash, make, perl,  
whatever you like.

The file formats are decently documented and very friendly to  
textutils-style processing. There are some trivial annoyances when  
using the gEDA tools in scripts, e.g. gschem needs to connect to an X  
server, but basically gEDA's design and implementation are very  
friendly to external scripting. More basic functionality we take for  
granted, but the other guys don't have.

But we are not exploiting Guile very well anywhere except in the  
gnetlist back ends. libgeda and the tools perhaps don't expose the  
needed functionality, and exactly what *is* exposed isn't documented.

3. The functionality you're talking about *isn't* basic: it's  
specialized. Treating it as basic will damage gEDA's flexibility.  
That will make it ever harder to get new things into the suite,  
increasing your frustration forever.

> Sorry, John, but libgeda needs to know (in conjunction with specialist
> behavioural modules, which could be work-flow dependant), what the
> circuit _means_ at a netlist level.

Where libgeda falls down is in putting that information in a form  
accessible to "specialist behavioral modules".

I'd like to be able to attach attributes containing estimated  
parasitics to net segments and have a module expand them. Hard to do  
that if the meaning of the circuit at the netlist level is wired into  
libgeda.

I imagine a future pcb that understands things like single point  
grounding and split ground planes. Things that go beyond network  
theory. I'd like to be able to represent such things in gschem, and  
export the data to an augmented "netlist".

I imagine a module that makes things like the symbols in the IEC  
60417 library whose "pins" are really ports useful for more than  
graphics. But the lines that connect there aren't networks.

>
> If we defer EVERYTHING to gnetlist time,

gnetlist is not the only scriptable tool in the suite.

> we might as well give up trying
> to make the schematic editor help the user with back / forward
> annotation, live cross-probing to other tools, whatever - since the
> problem can't be explicitly defined.

But every feature added to libgeda makes it *more* difficult to get  
gEDA to work with other tools in general. So if you try that path, it  
will get more frustrating to you as you go down it. This is unless  
you really only want to support a small project/hobbyist flow, my  
great fear.

>
> I agree we need to keep the current flexibility, but I think the
> architecture design needs to be revisited.

Yes. We need refactoring. We need to document just what's exposed to  
the Guile layer, and then provide what's missing. I suspect this  
means *deprecating* some current libgeda functionality, putting  
interfaces at lower level, and moving functionality to the Guile layer.

> You can't pretend that the
> meaning of every single attribute can be left unspecified until  
> gnetlist
> time.

No, but I *can* ask that the "specialist behavioral modules" provide  
that. And I can assert that this is the only path that can preserve  
gEDA's flexibility while still providing the features you want to  
add. As well as the very different ones I want...

> If you do, gschem is forever condemned to do nothing more
> sophisticated than edit graphics.

But it's good at that. And it's a bit more: it's good at representing  
topology in a way that's accessible to both humans and programs. It's  
also good at relating arbitrary data to topology via attributes. If  
you wire in "meaning" at a low level, it will cease to be a good  
graphics editor. Quit taking gEDA's superior design for granted. Please.

>
> Best wishes (+ angry ranting)

Best wishes, indeed. No anger here, just concern.


John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user