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