Re: gEDA-user: multi-part symbol support

[John Doty <jpd@xxxxxxxxx>]

On Jul 28, 2009, at 4:16 PM, Kai-Martin Knaak wrote:

> On Tue, 28 Jul 2009 15:16:26 -0600, John Doty wrote:
>
>>> It  would make a *.sch file even
>>> less selfcontained.
>>
>> Well, I don't think of .sch files as self contained anyway.
>
> Others do. Different work-flows ...
>
>
>>> So the information should be included in the schematic.
>>
>> That's a potential barrier to reuse.
>
> Not, if the information is included via embedded symbols.

That's an even worse barrier to reuse, analogous to embedding header  
file contents in your C code.

In the breadboard, the bypass caps may be through hole, in the  
prototype 0805, and in production 0402. If you've embedded symbols or  
attached footprint attributes, you can't reuse schematics from one  
phase in the next without massive editing. But if that information is  
in a custom bypass.sym, that's the only thing you need to change  
between phases. The schematics themselves are reusable, and you only  
have to make the change in one place.

And then there's the next project...

> (Yes, I know, you don't like embedding)
>
>
>>> Require, that every attribute is unique within the set of symbols  
>>> with
>>> the same refdes.
>>
>> Breaks the current usage of source=.
>
> No.
> Attribute unification applies to the internal netlist after subsheet
> symbols have been resolved to whatever the subsheet contains.

True, but that's a bug, too.

>
>
>> Might break custom flows, too.
>
> Hardly.
> Current gnetlist already returns exactly one value for every  
> attribute of
> a set of symbols with the same refdes. If more than one part of a  
> multi
> part symbol contains the same attribute, gnetlist simply picks the  
> first.
> The supposed requirement only removes the current uncertainty which
> attribute will be returned.

True. It would have to be some other tool, like a Perl script that  
grinds schematics. "Little harm".

>
>
>> Well, that whole approach is incompatible with schematic reuse, at  
>> least
>> the way I do it.
>
> You can do everything exactly as you do now if you don't use list_of
> attributes. Even if you do, the proposed changes don't affect the
> schematic at all. It affects the symbols.
>
>
>> In most cases it's more sensible to put the footprint
>> in the project symbol, not attach it in the schematic.
>
> I don't propose to attach the footprint, or any other attribute  
> anywhere
> else than to the symbols.

That's not the issue. Why attach the footprint to the symbol at all?  
Attached attributes are a barrier to reuse. At least in my flows, the  
footprints for common components are project/phase dependent.

>
>
>>> What would be a sensible syntax for lists of values?
>>
>> Scheme syntax.
>
> scheme syntax in attribute values <frowns>

Never fight the paradigm. Scheme is what we use. And it's very simple.

>
>
>> the back end can trivially parse this with (read) without
>> evaluation from a string port.
>
> And it will act in an intransparent, user unfriendly way in case of
> errors. Just like gschem already does, when it runs into problems with
> the config files. Silently failing to read the rest of the file  
> made me e
> scratch at my head more than once. Generalized syntax comes at a  
> price.

Handling errors of that sort in Scheme code is easy. Wrap the (read)  
in a (catch) that reports the error. Another good reason to do this  
in the back end.


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