Re: gEDA-user: Yet another netlister
On Sat, 15 Aug 2009 09:24:54 -0600, John Doty wrote: Again: Do you seriously believe that a decent backend should care about the order the user has entered symbols in gschem? If so, please give an example case. No it should not. Fine. So there is no reason to shout at me if I intend to hide this kind of information. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 17, 2009, at 11:51 AM, Kai-Martin Knaak wrote: On Sat, 15 Aug 2009 09:24:54 -0600, John Doty wrote: Again: Do you seriously believe that a decent backend should care about the order the user has entered symbols in gschem? If so, please give an example case. No it should not. Fine. So there is no reason to shout at me if I intend to hide this kind of information. That's not the issue. It's that you intend to further complicate the code that hides attributes. That code should instead be removed from the front end. The more complex you make the front end, the harder it will be to properly factor gnetlist. 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
Re: gEDA-user: Yet another netlister
On Sat, Aug 15, 2009 at 5:12 AM, al davisad...@freeelectron.net wrote: A netlister needs to work for all symbols. No exceptions. Why? Should it work even for symbols without models or incompatible models (e.g. verilog RTL in an analog AC simulation)? For Spice format, you can go nuts with all of the special cases. There are ways to control it, but you can't fix it completely. This means the netlister cannot have explicit knowledge of any particular symbol. Well, currently it has. I would actually prefer it the other way around, so that some particular symbols (especially primitive devices) had explicit knowledge of a netlist format. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Saturday 15 August 2009, r wrote: On Sat, Aug 15, 2009 at 5:12 AM, al davisad...@freeelectron.net wrote: A netlister needs to work for all symbols. No exceptions. Why? Should it work even for symbols without models or incompatible models (e.g. verilog RTL in an analog AC simulation)? You cannot possibly know about all possible symbols that may be created in the future. So, the netlister cannot have explicit knowledge of them. It must work in general. For Spice format, you can go nuts with all of the special cases. There are ways to control it, but you can't fix it completely. This means the netlister cannot have explicit knowledge of any particular symbol. Well, currently it has. I would actually prefer it the other way around, so that some particular symbols (especially primitive devices) had explicit knowledge of a netlist format. You cannot possibly know about all possible netlist formats a symbol might be used for. A netlister for an irregular output format might need to key on some attribute to decide what to do, but this is not the symbol itself. You could define an attribute that identifies special properties, and the netlister could key off of that. How about a special_target attribute, where you could specify special treatment. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 13, 2009, at 6:15 PM, Kai-Martin Knaak wrote: On Sun, 09 Aug 2009 17:43:07 -0600, John Doty wrote: You mean, the behavior of a netlister should depend on the order of components in the *.sch file? Please give an example if you seriously think so. No. The order isn't the issue. Yes, it is. Currently gnetlist behaves differently on multi symbol components depending on order in the *.sch file. This is the bug my patch fixes by ordering the internal representation of the netlist. Merely a *symptom*. Not the actual disease. The issue is that the front end should not arbitrarily restrict which attributes the back end gets to see. Ensuring a non-ambiguous internal order of components does not hide any attributes. Please stop implying, that it does. You are changing one arbitrary attribute selection procedure into another. It isn't that you're hiding anything: it's the API that hides them. We need to fix that API. Changing what goes on behind it fixes only your symptom. But remember that neither you nor I can anticipate what information a future back end might need. Don't focus narrowly on specific scenarios. Again: Do you seriously believe that a decent backend should care about the order the user has entered symbols in gschem? If so, please give an example case. No it should not. But the problem isn't the *order*. The problem is that which attribute to give the back end is *arbitrary*. It should not be. 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
Re: gEDA-user: Yet another netlister
On Saturday 01 August 2009, A.Burinskiy wrote: And, finally, me, as a user, will not be happy to change the script each time I add new symbol! Good thing you mentioned it. Unfortunately, the Spice format is very irregular, so dealing with it is pure hell. That is one of the reasons for moving to later formats such as Spectre, Verilog, and VHDL as netlist formats. The Spectre format should also be considered depricated, leaving Verilog and VHDL as netlist formats. Whether you (collectively) like it or not, this is the industry trend, and gEDA is not in a position to buck the trend, and can benefit by running ahead of everyone else. In conversation last week with the creator of the Spectre format, he commented on why it is the way it is, and why we shouldn't use it, and use Verilog or VHDL format instead. Either of those choices are regular, easy to parse, and provide for named ports that are not order dependent. A netlister needs to work for all symbols. No exceptions. For Spice format, you can go nuts with all of the special cases. There are ways to control it, but you can't fix it completely. This means the netlister cannot have explicit knowledge of any particular symbol. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sun, 09 Aug 2009 17:43:07 -0600, John Doty wrote: You mean, the behavior of a netlister should depend on the order of components in the *.sch file? Please give an example if you seriously think so. No. The order isn't the issue. Yes, it is. Currently gnetlist behaves differently on multi symbol components depending on order in the *.sch file. This is the bug my patch fixes by ordering the internal representation of the netlist. The issue is that the front end should not arbitrarily restrict which attributes the back end gets to see. Ensuring a non-ambiguous internal order of components does not hide any attributes. Please stop implying, that it does. But remember that neither you nor I can anticipate what information a future back end might need. Don't focus narrowly on specific scenarios. Again: Do you seriously believe that a decent backend should care about the order the user has entered symbols in gschem? If so, please give an example case. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
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. 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. 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 be solved. 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
Re: gEDA-user: Yet another netlister
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. 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 ? Rather then full blown language? Guile too complex for this simple task. 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! be solved. 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 Alex. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
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
Re: gEDA-user: Yet another netlister
John, It is not a big deal to write a parser. The big deal is creating meaningful language. Flexible enough, yet not overloaded with features, transparent and logical, understandable not only for designer, but to end user too. My problem is that I'm newbee for the PCB. Just started using commercial tool. And already very happy with that Over years I was busy with IC design and IC layouts. My last PCB design was shortly after graduation. So, I do have little knowledge of PCB community needs. I wrote netlister for IC community (or beeing precise - for me). If you could give me a hint on lang. semantic that would be usefull, I will gladly write parser. I think that gnetlist implementation is too heavy and not flexible enough. It depends too much on device= attr. For example, to determine whether something is netlistable or not it is enough to see whether it has isDef(refdes) (device!=none). /*In reality I do some more checks*/, rather then writing semantic for each individual device. Special case - in/out terminals of subcircuit, that should parse there names to subcircuit nets... etc (One of the reason I decided to hardcode backend). Attributes could be filtered out, rather then verified against valid list one by one, as its done on gnetlist. All this little things allows to avoid extensive backend programming, when introducing new very simple device cause Guile/Schem study Lets work on some universal netlister that will be accepted by both IC and PCB communities? Alex. On 08/10/2009 07:57 AM, John Doty wrote: 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. ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 10, 2009, at 9:46 AM, A.Burinskiy wrote: John, It is not a big deal to write a parser. The big deal is creating meaningful language. Don't need to create a language, plenty of those around. Just need to choose one that won't frighten the timid. And need a set of functions. Flexible enough, yet not overloaded with features, transparent and logical, understandable not only for designer, but to end user too. My problem is that I'm newbee for the PCB. Just started using commercial tool. And already very happy with that Over years I was busy with IC design and IC layouts. My last PCB design was shortly after graduation. So, I do have little knowledge of PCB community needs. Look at what the existing gnetlist back ends do. I wrote netlister for IC community (or beeing precise - for me). If you could give me a hint on lang. semantic that would be usefull, I will gladly write parser. What, deprive me of the fun part? ;-) I think that gnetlist implementation is too heavy and not flexible enough. It needs refactoring. But it's still radically flexible as is. It depends too much on device= attr. Hardly at all. There aren't even any firm conventions on what to put there. Now the spice-sdb back end does look at device= by default, and that can cause some problems, but Stuart put in the --nomunge option at my request. Thanks, Stuart! For example, to determine whether something is netlistable or not it is enough to see whether it has isDef (refdes) (device!=none). /*In reality I do some more checks*/, rather then writing semantic for each individual device. Special case - in/out terminals of subcircuit, that should parse there names to subcircuit nets... etc (One of the reason I decided to hardcode backend). Attributes could be filtered out, rather then verified against valid list one by one, as its done on gnetlist. All this little things allows to avoid extensive backend programming, when introducing new very simple device cause Guile/Schem study You're confusing things that violate your aesthetic preferences with barriers. Get with the program. Lets work on some universal netlister that will be accepted by both IC and PCB communities? It's called gnetlist. If tired old grey haired astrophysicist like me can design both PCB's and IC's with it, shouldn't real designers be able to do that too? 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
Re: gEDA-user: Yet another netlister
On Sat, 01 Aug 2009 10:16:07 -0600, John Doty wrote: Just about any language works naturally on Unix these days, Not quite. C can draw on a host of system functions and libs that no other environtment variables, inter process communication via dbus and the various ways to interact with the system logs are just some of them. This infrastructure is one of the reasons why there are special obstacles when building geda/pcb for windows. For me that's not the issue: the issue is that you're putting yet another gnetlist behavior out of reach of back end control. You mean, the behavior of a netlister should depend on the order of components in the *.sch file? Please give an example if you seriously think so. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 9, 2009, at 3:19 PM, Kai-Martin Knaak wrote: For me that's not the issue: the issue is that you're putting yet another gnetlist behavior out of reach of back end control. You mean, the behavior of a netlister should depend on the order of components in the *.sch file? Please give an example if you seriously think so. No. The order isn't the issue. The issue is that the front end should not arbitrarily restrict which attributes the back end gets to see. In this case the arbitrary selection is based on order, but it's the arbitrariness that's the problem. not the order. A back end that processes hierarchy on its own should see all of the source= attributes. A more sophisticated BOM than we have might usefully choose from multiple manufacturers' part numbers. But remember that neither you nor I can anticipate what information a future back end might need. Don't focus narrowly on specific scenarios. Let the back ends decide what they need to see. Don't hard wire decisions in the front end code. In this case, remove the arbitrary selection from the hard wired code and put it in the middle layer, where the back end can bypass it as needed. This kind of flexibility is gEDA's greatest strength. DO NOT DAMAGE IT. Don't hard wire anything new. Instead, let's improve it, move the decisions to the middle layer and back ends. 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
Re: gEDA-user: Yet another netlister
John, Do you mean that one day source= attribute is reference to schematic, another day it is something else? 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? 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. Alex. On 08/09/2009 04:43 PM, John Doty wrote: On Aug 9, 2009, at 3:19 PM, Kai-Martin Knaak wrote: For me that's not the issue: the issue is that you're putting yet another gnetlist behavior out of reach of back end control. You mean, the behavior of a netlister should depend on the order of components in the *.sch file? Please give an example if you seriously think so. No. The order isn't the issue. The issue is that the front end should not arbitrarily restrict which attributes the back end gets to see. In this case the arbitrary selection is based on order, but it's the arbitrariness that's the problem. not the order. A back end that processes hierarchy on its own should see all of the source= attributes. A more sophisticated BOM than we have might usefully choose from multiple manufacturers' part numbers. But remember that neither you nor I can anticipate what information a future back end might need. Don't focus narrowly on specific scenarios. Let the back ends decide what they need to see. Don't hard wire decisions in the front end code. In this case, remove the arbitrary selection from the hard wired code and put it in the middle layer, where the back end can bypass it as needed. This kind of flexibility is gEDA's greatest strength. DO NOT DAMAGE IT. Don't hard wire anything new. Instead, let's improve it, move the decisions to the middle layer and back ends. 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 -- Alexander Burinskiy IC design San Jose, CA, 95129 (408)230-3458 (cell) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Fri, Jul 31, 2009 at 8:49 PM, A.Burinskiyalexb...@gmail.com wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ I will have a closer look at it later. Thanks. I'm a bit puzzled that all of you tend to choose C/C++ for implementing your tools. Netlisters are expected to be extendable by their end users but such a low level implementation language together with a build environment is a significant obstacle to it. It is not a theoretical dispute - I've been trying to extend Anthony's spnet and I soon got tired of doing text processing in C. Please treat this as my private suggestion only: would you or Anthony consider rewriting your tool in Perl, Python or some other major scripting language? So far only gnetlist tries to employ some higher level language (guile) for processing the netlist but it suffers form other problems (guile itself is not very mature and gnetlist architecture is hardcoded in C, which is why it is so hard to add the hierarchy support to it). Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 1, 2009, at 4:17 AM, r wrote: On Fri, Jul 31, 2009 at 8:49 PM, A.Burinskiyalexb...@gmail.com wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ I will have a closer look at it later. Thanks. I'm a bit puzzled that all of you tend to choose C/C++ for implementing your tools. Netlisters are expected to be extendable by their end users but such a low level implementation language together with a build environment is a significant obstacle to it. Yep. All those gnetlist back ends, and the ease of writing another if you need it, constitute gEDA's greatest strength. It is not a theoretical dispute - I've been trying to extend Anthony's spnet and I soon got tired of doing text processing in C. Please treat this as my private suggestion only: would you or Anthony consider rewriting your tool in Perl, Python or some other major scripting language? So far only gnetlist tries to employ some higher level language (guile) for processing the netlist but it suffers form other problems (guile itself is not very mature Hmm, I think Guile is fine for gnetlist's purposes. A minor problem has been backward compatibility, leading to dependency hell. The people who package the distros have this under better control than they did a few years ago. Python has similar problems. The real problem, I think, is that many people get phobic when they see all those parentheses. But, really, Guile is easy to learn and easy to use. and gnetlist architecture is hardcoded in C, Yes. Too much is hardcoded into the front end. The front end even gets in the way of the back end's access to command line options. Back ends can't see hierarchy. Back ends can't see all attributes. Now, a lot of back ends don't need to see all that stuff, but that's what the interface layer (gnetlist[-post].scm) is for: simple back ends can get the filtered info, trickier ones can reach around to the front end and get the data they need. The current implementation doesn't exploit the capabilities of the interface layer very well. The front end needs to be trimmed back to the minimum, and the logic moved to the interface layer. Hmm. In the gnetlist case, the minimum for the hard-coded part is nothing: why bother with C at all? which is why it is so hard to add the hierarchy support to it). Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 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
Re: gEDA-user: Yet another netlister
Hi R, I thought about implementing some language for netlist and after all I decided to go with plain C++ and get rid of using device attribute unless it is absolutely necessary (such as input/output pin) and give more strength to user symbol definition relying on the fact that end user knows what [s]he does. After all, each symbol translated into very fixed semantic (Refdes node1 node2 name attributes ...). Major problem - if syntax of gschem files will be changed, then gschem may loose compatibility with all previously collected works! Thus, if gschem will change format of output files it will change it in compatible way or being more strict - only on incremental way. In this case it would not be hard to make incremental adds to the code, if algorithm itself is flexible and transparent enough (C++, pcb/spice output formats, flattening/hierarchical some keys in config file). If you think of adding more flexibility I will be more than glad to change the code. Speaking more about netlisters. Scriptising netlister - adding language inside language (you translate from .sch lang. to .net lang. using script) will force netlister to be more hardcoded (that is what happened with gnetlist, is not it?) instead of expectations to make more flexible semantic. And, finally, me, as a user, will not be happy to change the script each time I add new symbol! In one word - I made my life easier choosing C++ without Perl or whatever. I think that definite advantage of using script will have tool that involves highly interactive tasks, for example analyzing result of simulation using waveform viewer, layout creation tool, PR Even for schematic entry - I doubt that scriptising schematic capture tool will help! Regards, Alex. On 08/01/2009 03:17 AM, r wrote: On Fri, Jul 31, 2009 at 8:49 PM, A.Burinskiyalexb...@gmail.com wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ I will have a closer look at it later. Thanks. I'm a bit puzzled that all of you tend to choose C/C++ for implementing your tools. Netlisters are expected to be extendable by their end users but such a low level implementation language together with a build environment is a significant obstacle to it. It is not a theoretical dispute - I've been trying to extend Anthony's spnet and I soon got tired of doing text processing in C. Please treat this as my private suggestion only: would you or Anthony consider rewriting your tool in Perl, Python or some other major scripting language? So far only gnetlist tries to employ some higher level language (guile) for processing the netlist but it suffers form other problems (guile itself is not very mature and gnetlist architecture is hardcoded in C, which is why it is so hard to add the hierarchy support to it). Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, Aug 1, 2009 at 2:49 PM, A.Burinskiyalexb...@gmail.com wrote: I thought about implementing some language for netlist and after all I decided to go with plain C++ and get rid of using device attribute unless it is absolutely necessary (such as input/output pin) and give more strength to user symbol definition relying on the fact that end user knows what [s]he does. After all, each symbol translated into very fixed semantic (Refdes node1 node2 name attributes ...). I don't think this is necessary. Sure, some tools (e.g. from Cadence) provide a simple embedded language that can be used by a designer to interact with the netlister (typed attributes, pPar(), iPar(), arithmetic functions etc.) but that's not what I meant (although it would be nice to have). Major problem - if syntax of gschem files will be changed, then gschem may loose compatibility with all previously collected works! Thus, if gschem will change format of output files it will change it in compatible way or being more strict - only on incremental way. In this case it would not be hard to make incremental adds to the code, if algorithm itself is flexible and transparent enough (C++, pcb/spice output formats, flattening/hierarchical some keys in config file). If you think of adding more flexibility I will be more than glad to change the code. I'm not sure if I understand you correctly. Yes, accessing the data files directly is a bit dangerous from API stability point of view. Ideally, libgeda would provide anyone interested with a set of functions for accessing the design and traversing the hierarchy. The benefit of this would be: 1. API abstraction, 2. The same logic and configuration would be used by gEDA tools. Speaking more about netlisters. Scriptising netlister - adding language inside language (you translate from .sch lang. to .net lang. using script) will force netlister to be more hardcoded (that is what happened with gnetlist, is not it?) instead of expectations to make more flexible semantic. And, finally, me, as a user, will not be happy to change the script each time I add new symbol! No, that's not what I meant. I just suggested that the whole netlister, as it is now, could be ported to an interpreted language, so that it was easier to understand and modify for a person who didn't write it. The extendability would be useful (although not required) for writing a library of complex components. Think about checking certain attributes if they hold legal values for a given process, precalculating MOS ad,as,pd,ps parameters, modifying netlist for monte-carlo simulations. You can consider these very heavy components designed for a given technology. In one word - I made my life easier choosing C++ without Perl or whatever. I think that definite advantage of using script will have tool that involves highly interactive tasks, for example analyzing result of simulation using waveform viewer, layout creation tool, PR Even for schematic entry - I doubt that scriptising schematic capture tool will help! Scripting is one thing, writing the tool in a scripting language is another. If performance is not a concern I would prefer to have a tool written in a scripting language so that I can change/extend it easily. This is what opensource is about after all. It doesn't mean that people can't do this with a tool written in C++ but the amount of work involved is far greater (downloading the source code, compilers, library headers, using the tool chain etc.) especially for people who are not programmers in their day jobs. Thanks again for writing the tool! Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, Aug 1, 2009 at 2:37 PM, John Dotyj...@noqsi.com wrote: Hmm, I think Guile is fine for gnetlist's purposes. A minor problem has been backward compatibility, leading to dependency hell. The people who package the distros have this under better control than they did a few years ago. Python has similar problems. I'm actually a big fan of functional languages so you don't need to convince _me_ to Scheme. ;-) The real problem, I think, is that many people get phobic when they see all those parentheses. But, really, Guile is easy to learn and easy to use. Well, I see several other problems here as well: 1. Guile (as a Scheme implementation) is not particularly well supported, this leads to dependency hell and missing/incomplete wrappers for modern libraries (like gtk2 - not really a problem for gnetlist but an issue for gschem and others), 2. Scheme being a simplistic language. Both Perl and Python come with regexps and easy to use and versatile container types to name a couple of useful features. 3. Scheme not being a main stream language (often misinterpreted as a parentheses problem). This makes code written in Scheme not easier to extend than one written in a primitive but well known language. So, from pragmatic POV, I am OK with moving from Guile to something more practical. and gnetlist architecture is hardcoded in C, Yes. Too much is hardcoded into the front end. The front end even gets in the way of the back end's access to command line options. Back ends can't see hierarchy. Back ends can't see all attributes. Now, a lot of back ends don't need to see all that stuff, but that's what the interface layer (gnetlist[-post].scm) is for: simple back ends can get the filtered info, trickier ones can reach around to the front end and get the data they need. The current implementation doesn't exploit the capabilities of the interface layer very well. The front end needs to be trimmed back to the minimum, and the logic moved to the interface layer. Hmm. In the gnetlist case, the minimum for the hard-coded part is nothing: why bother with C at all? Fully agree. The only exception is that part of functionality (reading and interpreting gEDA file formats) could be abstracted out in a form of libgeda library (still the netlister doesn't need to be written in C/C++, just libgeda itself). Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, 01 Aug 2009 11:17:10 +0100, r wrote: I'm a bit puzzled that all of you tend to choose C/C++ for implementing your tools. like ist, or not, C is the lingua franca of computer science. I have yet to meet an IT professional, who has never written any C code. In addition, C is the natural programming language of a unix-like system. Installing a build environment is a no-brainer in these times of software distros. Not too long ago, the preferred way to distribute geda and friends was by source and build locally. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 1, 2009, at 9:21 AM, r wrote: Well, I see several other problems here as well: 1. Guile (as a Scheme implementation) is not particularly well supported, this leads to dependency hell and missing/incomplete wrappers for modern libraries (like gtk2 - not really a problem for gnetlist but an issue for gschem and others), 2. Scheme being a simplistic language. Both Perl and Python come with regexps and easy to use and versatile container types to name a couple of useful features. 3. Scheme not being a main stream language (often misinterpreted as a parentheses problem). This makes code written in Scheme not easier to extend than one written in a primitive but well known language. So, from pragmatic POV, I am OK with moving from Guile to something more practical. Perhaps not Guile, but we're going to have to keep Scheme around for a long time, because all those back ends are important. It's not that there's a lot of code in them, but they embody a great deal of research into just what each format needs (often the product of reverse engineering). And in the particular case of spice-sdb, Stuart has produced really good documentation. Those who want to improve SPICE netlisting would be well advised to read and understand that first. 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
Re: gEDA-user: Yet another netlister
On Aug 1, 2009, at 10:03 AM, Kai-Martin Knaak wrote: On Sat, 01 Aug 2009 11:17:10 +0100, r wrote: I'm a bit puzzled that all of you tend to choose C/C++ for implementing your tools. like ist, or not, C is the lingua franca of computer science. I have yet to meet an IT professional, who has never written any C code. In addition, C is the natural programming language of a unix-like system. Just about any language works naturally on Unix these days, the exceptions being proprietary languages that aren't on the table here anyway. Installing a build environment is a no-brainer in these times of software distros. Not too long ago, the preferred way to distribute geda and friends was by source and build locally. For me that's not the issue: the issue is that you're putting yet another gnetlist behavior out of reach of back end control. There are too many of those already. 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
Re: gEDA-user: Yet another netlister
On Sat, Aug 1, 2009 at 5:09 PM, John Dotyj...@noqsi.com wrote: Perhaps not Guile, but we're going to have to keep Scheme around for a long time, because all those back ends are important. It's not that there's a lot of code in them, but they embody a great deal of research into just what each format needs (often the product of reverse engineering). Fair enough. What Scheme implementation will be used? And in the particular case of spice-sdb, Stuart has produced really good documentation. Those who want to improve SPICE netlisting would be well advised to read and understand that first. Thanks for your gnetlist tutorial, BTW. It was an interesting read. Improving backends is easy (well, relatively easy). What's hard is fixing the front-end so that it provides full design information to back-ends (including hierarchy and parameters, of course). I also think that the best way to do it is to implement this functionality in Scheme (so that all front-end data structures are naturally available to back-ends) but it is still OK to have this functionality in a compiled core provided it doesn't hide design information from its back-ends. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Aug 1, 2009, at 11:45 AM, r wrote: On Sat, Aug 1, 2009 at 5:09 PM, John Dotyj...@noqsi.com wrote: Perhaps not Guile, but we're going to have to keep Scheme around for a long time, because all those back ends are important. It's not that there's a lot of code in them, but they embody a great deal of research into just what each format needs (often the product of reverse engineering). Fair enough. What Scheme implementation will be used? I have no preference. I'm actually pretty happy with Guile. For all its annoyances, it has served us well. And in the particular case of spice-sdb, Stuart has produced really good documentation. Those who want to improve SPICE netlisting would be well advised to read and understand that first. Thanks for your gnetlist tutorial, BTW. It was an interesting read. More to come. Watch this space. Improving backends is easy (well, relatively easy). What's hard is fixing the front-end so that it provides full design information to back-ends (including hierarchy and parameters, of course). I also think that the best way to do it is to implement this functionality in Scheme (so that all front-end data structures are naturally available to back-ends) but it is still OK to have this functionality in a compiled core provided it doesn't hide design information from its back-ends. Agreed. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 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
gEDA-user: Yet another netlister
Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ Thanks, Alex. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Fri, 31 Jul 2009 12:49:57 -0700, A.Burinskiy wrote: I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ The README seems to imply, that this netlisters primary use is to provide input for gnucap. Are there plans to output pcb format, too? ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
Wow another netlister, that makes 4 now? gnetlist spnet gnetman ynetlist At least gEDA users have plenty of choices now. On Fri, Jul 31, 2009 at 12:49 PM, A.Burinskiyalexb...@gmail.com wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ Thanks, Alex. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
Actually there is option for ynetlist -g{pcb,spice}. I do output for
PCB, but it is a very first cut. I do not know output format that I have
to use. Try this option, type
ynetlist -gpcb filename.sch
Then send me comments and I will correct output to be the right one.
Please let me know tool that you are going to use with pcb format, may
be I will be able to dig from that side to find what I have to put into
output file.
Alex.
On 07/31/2009 02:46 PM, Kai-Martin Knaak wrote:
On Fri, 31 Jul 2009 12:49:57 -0700, A.Burinskiy wrote:
I created yet another netlister for gschem. Netlister supports flattened
or hierarchical netlist, handles slotting and global net names. Will be
glad to hear any feedback. The source located in:
http://sourceforge.net/projects/ynetlist/files/
The README seems to imply, that this netlisters primary use is to provide
input for gnucap. Are there plans to output pcb format, too?
---(kaimartin)---
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
Actually only one: gnetlist could be found from gEDA site. All others have to be tested and if it suits purpose offered for download from gEDA site. On 07/31/2009 03:45 PM, Anthony Shanks wrote: Wow another netlister, that makes 4 now? gnetlist spnet gnetman ynetlist At least gEDA users have plenty of choices now. On Fri, Jul 31, 2009 at 12:49 PM, A.Burinskiyalexb...@gmail.com wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ Thanks, Alex. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
A.Burinskiy wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ I hate to complain when someone is contributing something which may be useful, but I have to wonder if netlister efforts could be better spent in fixing the various issues people have with gnetlist instead of inventing many more netlisters Here is my concern. The gEDA community isn't all that large and there are fairly limited resources for it. Having multiple netlisters seems to just produce the problem of too many places for identical bugs to creep in and spreading people too thin. Is there anyone who has tried all 4 netlisters and would be in a position to maybe make a table that somehow gives a sane comparison between the 4? That might be a useful way to help identify areas in each that need work. Oh, lets not even think about how much work is caused if gschem needs to update its file format and there are N different parsers out there. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
Dan, No doubt, we need someone to identify week and strong parts of various netlisters and choose one-two for support. As to me, I was trying gnetlist and spnet (I was unaware of gnetman). Non of them did worked fine for me. That was a reason I wrote netlister for myself, then consider that it will be good to offer it for community. Yes, it will be pain if gschem format will be changed. And one good change is adding reference to library for instantiated symbols. It will stick each project to a particular list of libraries, as it is done in commercial CAD tools. Thanks, Alex. On 07/31/2009 04:42 PM, Dan McMahill wrote: A.Burinskiy wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ I hate to complain when someone is contributing something which may be useful, but I have to wonder if netlister efforts could be better spent in fixing the various issues people have with gnetlist instead of inventing many more netlisters Here is my concern. The gEDA community isn't all that large and there are fairly limited resources for it. Having multiple netlisters seems to just produce the problem of too many places for identical bugs to creep in and spreading people too thin. Is there anyone who has tried all 4 netlisters and would be in a position to maybe make a table that somehow gives a sane comparison between the 4? That might be a useful way to help identify areas in each that need work. Oh, lets not even think about how much work is caused if gschem needs to update its file format and there are N different parsers out there. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
