Hi John, Constructive comments below, but first I thought I'd get this out of the way..
>From my point of view, you often seem to treat people here with a less respect than they deserve. I get the impression you think of the gEDA developers as being ignorant, blinkered, or incapable directing the future design and architecture of the suite. You also persist in repeating the same design choices you have chosen to make as the panacea for everyone else's work. I really hope this can stop. Your input has proved valuable on many occasions, and it would be useful for us to gain from your insight rather than develop the predilection to dismiss your emails as "yet another rant from JPD". I already find myself having to skip them over for later reading, as they often disrupt a thread's natural flow. Your humorous email sign off suggests that you are aware of the problem, but not willing to adjust the courtesy of your replies. We are smart enough to understand a well reasoned design trade-off, and would likely respond better to that than yet another proclamation of why what we have suggested is wrong, or inadequate. I'll humour you with a reply below.. On Mon, 2011-01-17 at 05:31 +0900, John Doty wrote: > On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: > > > I want to see all connectivity code move into libgeda, and > > flattening be optional. > > Connectivity is precisely the kind of thing that should not be in > libgeda. I (and all other gEDA developers I've talked to) disagree. > The connectivity model depends on the application of the schematic. Not really, it just depends on whether we are talking about the same thing. I suspect not. I was not thinking of of assigning the "data-type" (for want of a better word) of nets, width, whatever. gschem can front schematic entry for various flow based or signal based topological connectivities, where nets might report block interconnections, mathematical relations, pipe-work, whatever. In all these cases, the useful output from libgeda / gschem is the topology / connectivity of the instantiated modules / symbols. The model I was assuming was that the exact topology of "nets" in gschem is unimportant. It is a common model, but my proposal of handling connectivity in libgeda doesn't _require_ that assumption if it is unwanted. > Right now, gEDA basically only supports a topological model. This > prevents it from expressing most geometric properties of the > connections: parasitic inductances and resistances, high current net > segments, single point grounds, etc. A related limitation that some > wish to relieve is the fact that busses are mere graphical decoration. One could still wish to query libgeda for a connectivity list or graph for a given design. IMO, it is silly to pretend that nets should be treated as components with parasitic inductance or resistance. For that to be meaningful, one would have to match the topology of one's schematic to the physical layout they wished to simulate. Even with that said, the idea warms to me slightly - and I still cannot see how "connectivity" in libgeda conflicts with your suggestion. Granted, each junction node would have to be treated explicitly in the graph.. and nets themselves would have to become component entities in the list, rather than flattened - but it is still completely possible. In effect, you look on a view where a "net" in gschem becomes a two ported component with properties, a peer to other symbols representing components such as "resistor", "n-mos FET", etc. _Connectivity_ still exists, and libgeda could usefully contain routines to extract that. > There cannot be a single correct way to address these issues because > the appropriate connectivity model depends on the capabilities of > other tools in the flow, not just gschem/gnetlist, as well as the > needs of the project. I don't see anything which can't be handled as above. > There are other places where the core code implements semantics that > are useful in common cases but not universal. Gah, yes - The best example I can think of is that I'd love to get rid of slotting from the core. (Along with all the pinseq nastiness). I've taken steps to put that code at arms length from the rest of libgeda and gschem, so it is not so interwoven with the rest of the suite. I assume you won't have noticed that though, especially because the majority of the changes are in my repo.or.cz branches (it has other issues needing fixing before it can merge). > Consider for a moment a dual opamp.... [snip] I'm familiar with the problem. > Now consider hierarchy... [snip] I'm familiar with the problem. > It would be very useful to have better standards for the intended > meaning of the various attributes, but that won't help the problem of > writing universal code to interpret them. The translation to pcb, > SPICE, BOM, etc. will remain target and project dependent. Helper > functions for common cases are very desirable, but they must not be > "wired-in" to the core code. Better standards could lead to better > helpers, though. A similar situation exists with busses, where we'd > like to make the graphics meaningful, but still face the problem of > implementing that meaning downstream using a variety of tools in a > variety of flows. I think we agree here. (80% at least) > The common theme is that the core code in libgeda, gschem, and > gnetlist implements semantics that one might think are universal, but > in fact differ among different flows. At some point, we must define what is our universal set of semantics. I expect it will be far smaller than most packages, but there is no point in letting the suite die a death just because "we" are unable to commit to some design decisions. If you want a really small set of semantics, you might try "ms-paint" for drawing schematics. It doesn't even constrain you to straight lines, and boring colours. gnetlist doesn't handle .bmp import though, sorry. That was unfair though. (Yes... I do grumpy sarcasm from time to time). > The existing semantics are excellent for creating designs that are > exportable to a wide variety of printed circuit layout back ends. They > are also good for simulation schematics, ASIC schematics, and symbolic > circuit analysis (but nonportably: these schematics must be > constructed specifically for the downstream tool). This is a > spectacular achievement, but these same semantics block expansion of > capability and extension of portability of schematics because they are > "wired-in", difficult to bypass when they aren't appropriate. You forgot one. Schematics for the sake of beautiful printed schematics - as documentation. Schematic (or strictly, PS or PDF export of it) is the output, not a netlist ;) > Stephan's diagnosis and suggested treatment in > http://www.seul.org/pipermail/geda-user/2010-December/051273.html Yes, that was good. It is a principle I try to follow when writing code, and is the direction I'm slowly going in with PCB's rendering code. It is also what naturally falls out from the connectivity code I suggested for libgeda, but to be fair - most of the design details are still in my head - so you could be forgiven for not reading my mind on those. Overall, if you take one thing from this email John, it is that giving us the benefit of the doubt would be nice. You might be worried every time we suggest some change - but if you were to have a little faith, you might be pleasantly surprised at the quality of results which we can achieve. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
