[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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.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.

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

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




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