Re: gEDA-user: multi-part symbol support

[John Doty <jpd@xxxxxxxxx>]

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

> On Tue, 28 Jul 2009 17:29:32 -0600, John Doty wrote:
>
>>> 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.
>
> If you don't like embedding, don't do it.
> But please don't preach your work-flow as the only way to go.
> I didn't say whether, or not I like, or do embedding.

If you like embedding, do it.
But please don't misrepresent what it accomplishes.

If I want to send a self-contained schematic to somebody, I use  
embedding. But such a thing is very difficult to reuse as part of a  
different design.

>
> BTW, I just noted, that symbols cannot be unembedded when there is no
> equivalent symbol in a library around. It cannot be edited either.  
> This
> is clearly a missing feature, almost a bug. It should be possible to
> unembed and save locally. In the light of this missing feature I  
> revoke
> my statement: Currently information stored in embedded symbols does
> indeed present an obstacle to re-use.
> I'll file a bug report on this.

That's not the issue (although it makes the problem slightly worse).  
Do you embed C headers in your C code, or do you #include them. Why?

>
>
>>> 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?
>
> There seems to be a misunderstanding about the meaning of "attach".  
> Even
> if your symbol files don't contain any footprint attribute, you still
> attach footprints to symbols via gattrib or some other script.

I usually don't. I put the footprint in the symbol. gattrib is handy  
for a few edits, but a dull tool for anything on a major scale.

> The pcb
> backend of gnetlist wouldn't know which footprints to collect for the
> layout.

gnetlist looks in the symbol for my back ends. Does the pcb back end  
have a problem here?

>
>
>>> 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
>>> 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.
>
> scheme syntax in attributes still adds the complexity of a turing
> complete language at a place where next to no syntax is necessary.

Not with (read). I don't propose *evaluating* the expressions. That  
would be dangerous (says he who puts Mathematica expressions, whose  
evaluation is trickier to control, in attributes).

> Note,
> that not implementing scheme syntax for list_of attributes does not
> preclude use of scheme in attributes in any way.

True. But why yet another syntax, when we have a perfectly good one?

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