Re: gEDA-user: Yet another netlister

["A.Burinskiy" <alexbour@xxxxxxxxx>]

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<alexbour@xxxxxxxxx>  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@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>    



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user