Re: gEDA-user: wishful UI

[John Doty <jpd@xxxxxxxxx>]

On Aug 14, 2010, at 10:51 AM, Peter TB Brett wrote:

> On Sat, 14 Aug 2010 10:01:44 -0600, John Doty <jpd@xxxxxxxxx> wrote:
> 
>> 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.
> 
> I'm sorry, but I think we're going to have to agree to disagree on this
> point.  I believe that we should actually fix the problems, and enjoy the
> increased performance, rather than whack band-aids on them and pretend
> they're not there.

If you're going to make that argument, you need to be quantitative: how much increased performance? There isn't much to be had, I think. For my current large design (24 top level schematics plus 14 hierarchical schematics), gnetlist with the drc2 back end needs the increased stack to avoid crashing. Even so it only takes 2.2 seconds, while with efficient back ends it needs 1.4 seconds (on my MacBook). So with this large design, the time to be saved is at most 0.8 seconds per drc2 run.

> 
> In my opinion, gnetlist backends and (eventually) plugins that get accepted
> into the gEDA repository should be written to work on arbitrarily large
> designs.

I agree, but I think they already do for all practical purposes. It seems to me that the only barrier to doing designs with hundreds of schematic pages is my limited human capacity.

>  If that means that contributors need to learn how to think
> functionally, so be it.  There are plenty of excellent resources on the web
> to help with programming efficiently in Lisp-like languages.  I'd never
> seen Lisp-like syntax before I started hacking on gEDA, and if a Bear of
> Very Little Brain like myself can learn it, why shouldn't others be able
> to?

There is a specific problem with tail recursion in Guile: its optimization only works in certain special cases. To be sure, these are pretty common cases, but the user needs a bit of extra knowledge to guarantee that tail recursion will actually be optimized.

The point of scripting is to put the power of the toolkit in the hands of those with specific problems to solve. You as a developer cannot accurately anticipate what these problems are. Some users already perceive Guile to be a barrier here: do we really want to put extra unnecessary restrictions on their use of it? A big stack isn't a problem.

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