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/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
