Re: gEDA-user: wishful UI

[John Doty <jpd@xxxxxxxxx>]

On Aug 14, 2010, at 2:44 AM, Peter TB Brett wrote:

> As I've said before, the Guile API in gschem is fundamentally broken, due
> to the way that the invisible state is stored and accessed.  It has
> inconsistent naming and calling conventions, and it's possible to write
> perfectly valid code that leaves the gschem instance in an inconsistent
> state.  This is partly because it was initially introduced just as a
> convenient way to specify options, keybindings and menu layout in a
> declarative manner, but has had some extra things bolted on in an organic
> manner. I've made a start on trying to build a more consistent Guile API,
> but it's been pretty hard going, and unfortunately for a number of reasons
> I don't have a huge amount of time for gEDA at the moment.
> 
> I don't know about the Guile API for gnetlist, but last time I checked it
> suffered from *some* of the same problems, but not nearly to the same
> extent.

I haven't encountered that sort of problem, but the gnetlist case is cleaner. The Guile layers query the front end, but they don't actually command it to change anything, so consistency issues shouldn't come up.

>  There's some problems with gnetlist backends -- for example, some
> of them are written in a non-tail-recursive style, which causes stack
> exhaustion on large designs, but that's not too difficult to fix.

Not important. The quick fix (make the stack bigger) is known and should be incorporated in the distributed system-gnetlistrc. The problem is a consequence of dropping a functional language into a procedural culture: it will continue to crop up as we get additional contributions of back ends (and hopefully plugins). The quick fix may be unaesthetic, but it doesn't cause additional problems.

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