Re: gEDA-user: gEDA just hit SlashDotOrg

[John Doty <jpd@xxxxxxxxx>]

On Aug 13, 2009, at 7:31 PM, Kai-Martin Knaak wrote:

> On Wed, 12 Aug 2009 13:50:09 -0500, John Griessen wrote:
>
>> John Doty was thinking of aiming high in the thread named multi-part
>> symbol support when he offered to help with some scheme/guile  
>> coding to
>> keep the intended flexibility level of gschem/gnetlist up where it  
>> is.
>
> His way of dealing with the order bug would mean patching each and  
> every
> back-end. Talk about efficient coding.


NO, NO, NO. You haven't paid attention to what I said. None of the  
back ends would need patching. Wrap the new API in a middleware  
function in gnetlist.scm to get the old API. Put your rules into that  
wrapper.

I will never propose changing gnetlist in a way that will require  
back end modification. The back ends are a major asset.

>
>
>> Kai-Martin and DJ didn't seem to care about lost flexibility.
>
> Not true. There is no loss of flexibility implied by the proposed
> ordering. So there is nothing to care about.

It makes the needed refactoring of gnetlist harder, because it's in  
the wrong place. Why not do it right? We can collaborate.

>
> Internal ordering does not hide any attributes from the backend.  
> The only
> information it hides, is information on the order the symbols were  
> added
> to the schematic.  This is something, no decent backend should ever  
> care
> care about.

The API hides all but the first attribute it sees. That's the  
problem. Changing the ordering does not fix the problem.

>
> Heck, the *.sch format itself already hides many details of user input
> from the netlister.

Not the issue. The issue is that the gnetlist front end hides much of  
what is present in the .sch format from the back end. It is  
undesirable to have more hard-wired behavior in the front end: that  
just makes the refactoring to fix this problem harder.

Many back ends, of course, are already getting all they need, so the  
information hiding they benefit from is useful. But that should be  
moved to the convenience functions in gnetlist.scm, so that back ends  
(and future middle modules: BOM-centric design will require a layer  
between the front end and back end) can get all the information they  
need.

> There is no information on deletes symbols. The time
> and date a symbol has been added is lost. There is no hint who added a
> specific item. There is no history whatsoever. So there is a huge  
> loss of
> information. However, this is a good thing as it keeps the *.sch files
> from bloating. (Ever wondered why protel or eagle files are so big?)
> It also is in accordance with the principle of least surprise. The
> meaning of schematic is defined by its contents, not by its history.

History is what cvs or git are for. Isn't it great how gEDA  
interoperates?

>
> The order of symbols in the *.sch is a remnant of the input related
> information mentioned above. There is no reason to pass this  
> information
> to the backends.

Peter, you understand the issue. Maybe you can explain to Kai-Martin.

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