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/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
