On Aug 1, 2009, at 4:17 AM, r wrote: > On Fri, Jul 31, 2009 at 8:49 PM, A.Burinskiy<alexb...@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