On Aug 10, 2009, at 8:19 AM, A.Burinskiy wrote: > On 08/10/2009 06:03 AM, John Doty wrote: >> On Aug 9, 2009, at 9:59 PM, A.Burinskiy wrote: >> >> >>> John, >>> >>> Do you mean that one day source= attribute is reference to >>> schematic, >>> another day it is something else? >>> >> >> No, I mean that many back ends need to see a flat netlist, while in >> the future others will need to see the hierarchy. The ones that need >> to see the hierarchy will need to see the source= attributes. All of >> them. >> >> > If I'm correct source= has the same meaning regardless flat or > hierarchical netlist.
I agree. But how it's to be *processed* depends on the needs of the netlist back end. It'd be nice, for example, to have a gnetlist back end that can extract the dependency graph for a hierarchical design. In the past, my tool for doing that has been a Japanese grad student. ;-) >>> We have to stick to some reasonable >>> meaning of all attributes, at list to be able to exchange libraries >>> and >>> collect our work over the years, isn't it? >>> >> >> Yes. That's one reason I recommended you master the documentation for >> spice-sdb before writing another SPICE netlister. >> > I think I'm getting closer to what you mean, but not yet there. I > think > about expanding routin for some back end, but still thinking what > lang. > I should use for that. May be simpliest would be something like > printf %refdes %net %attr ? Anything less flexible than gnetlist is undesirable. But perhaps you could create a gnetlist back end that accepts a simplified "program" to deal with simple cases. We already have one of these, the "bom" back end. > Rather then full blown language? Guile too > complex for this simple task. Guile complex? Oh, come on. But maybe I should write a Logo parser to put atop it. Been years since I wrote a parser for a programming language, but it's not hard, especially for a language as simple as Logo. Difficult to complain that a language third graders can learn is complex, although third graders are often more receptive to new ideas and more resourceful at applying them than many "professionals" ;-) But the important thing to understand is that we have a big investment in Guile. All those gnetlist back ends are important assets. And their existence shows how effectively gEDA empowers people who have a skosh of resourcefulness. > Any way the most critical for me now is > waveform viewer. I found that existing few do not fit the purpose, and > I'm dealing with that. If you convince me I will do two tasks in || - > and will write backend. >> >>> Talking about ynetlist: it has exactly front, inner, and backend. I >>> call >>> it component/net collection, symbol elaboration, output netlist. By >>> modifying only output I may create any netlist. But yet I do not >>> see a >>> reason why user should mangle with programming.... It is programmer >>> responsibility to cover all needs. >>> >> >> I absolutely and emphatically disagree. Users cannot count on >> programmers to solve the right problems. Programmers are masters of >> technique, but the most important knowledge needed to make a >> successful program is understanding of the *application*. Users need >> to take that responsibility. >> >> It's similar to writing a scientific paper: a scientist must be the >> main author. A technical writer is very useful in the process, but >> not central. Programming is an essential enabling skill, similar to >> technical writing. Everybody should have a reasonable level of >> competence here. Specialist programmers are there to help produce the >> highest quality product, not to choose how to address the problem to >> > > In commercial world it is absolutely true, and I 100% agree with you. > But we are in Open source domain. Main difference? Right! In Open > Source > World the programs are written by end users! Yes. And the success of gnetlist shows how empowering it is to end users. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user