Re: gEDA-user: gschem, More than one component found with name ...

[John Doty <jpd@xxxxxxxxxxxxx>]

On Oct 19, 2007, at 2:32 PM, Peter Clifton wrote:

>
> On Fri, 2007-10-19 at 14:12 -0600, John Doty wrote:
>> On Oct 19, 2007, at 11:00 AM, Peter TB Brett wrote:
>
>>> The intention is to provide a straightforward but powerful GUI for
>>> keeping
>>> schematic & library up to date.  There would be a list of all  
>>> symbols
>>> currently embedded in the schematic, showing how many times each
>>> has been
>>> instantiated.
>>
>> What schematic? File != schematic.
>
> Which is exactly the problem in many cases, your foo.sch file is not
> enough to share, or move into a different project, you have a whole
> array of other symbol files which are explicitly required along  
> with it.
>
> I'm not necessarily suggesting that we must make entire designs fit in
> one file, but saving a cached copy of symbols used along with a .sch
> file (in the file) will help schematic reuse.

But the symbols in a project are typically shared across  
multiple .sch files. I very commonly want an update of a project  
symbol to propagate across all of them. I don't want to open every  
file to see if I need to fix something to get this change to "take".  
That's also why it's a bad idea to automatically promote attributes  
like footprint.

>
>>> Symbols which differ from that found in the library would be
>>> flagged with an
>>> icon, indicating whether the library symbol is newer or older  
>>> than the
>>> embedded version.
>>
>> What library? We don't even yet have the most crucial thing: the
>> project library concept. So we all implement it in ad hoc ways,
>> because the symbols in the distributed library are usually wrong for
>> any specific purpose. So, you copy, customize, and then updates of
>> the distributed library are irrelevant: your project library has what
>> you need.
>
> We have a project library if you set one up in your gafrc, but that
> means you have another file required to open the schematic page and  
> find
> the symbols, and that must be merged if you want to re-use a page in a
> different project.

I don't see that as a problem at all. A project library from an old,  
similar project is a good start for a new project.

>
> More explicitly... we don't have a concept of _project_ in gschem.
> (Hence the problem requiring these extra files).

Well, maybe that's what we need. But we don't need to make it harder  
to do projects in a portable, modular way.

A script that, given a set of top level .sch files, would assemble  
the other .sch files and the needed symbols into a tarball would be  
very useful. But embedded symbols are trouble.

>
>>> It would be possible to select all instances of a symbol, so that
>>> users can
>>> see which symbols would be affected by an update.  Clicking an
>>> "Update"
>>> button would show the user a dialog with a preview the old and new
>>> symbols,
>>> and a radio box to select which symbol to use.
>>
>> Completely unnecessary with a project library.
>
> Ok, so you're going to maintain a set of your own symbols per project,
> rather than "globally" on the computer.

Absolutely! There's no other sane way to do it. Project symbols go  
under revision control, just like the rest of the project's files.

>
> I'll assume there is some reuse, and perhaps you find a bug in a  
> symbol.

Very rarely.

> Isn't updating your project library for each project is no easier than
> updating embedded symbols in the schematic?

It's much easier. Because once the symbol is right for *my* project,  
it stays right. While the common symbols are subject to changes  
because somebody found them wrong FOR SOME OTHER PROJECT. There are  
no universal right answers. Is "OUT D" pin 14 or 16 on an OP490?

> You'll still have to go into
> each project, update the symbol in that project library, and verify it
> hasn't broken any of the schematics.

Why should it break anything as long as you don't move pins? I can't  
think of a case where I took a symbol from one project and found a  
bug later.

>
>>> It would also be possible to "export" embedded symbols into a local
>>> library,
>>
>> As far as I'm concerned, this should happen automatically. Both
>> embedded symbols and instantiations of distributed library symbols
>> are trouble waiting to happen. But a library of customized project
>> symbols is a valuable asset, analogous to a parts stock in drawers.
>
> I wonder if we aren't all thinking along similar lines, but  
> disagreeing
> on whether the cache of the symbol in use should be in the schematic
> file or a separate "database" along with the project?

The big difference seems to me that you're still seriously thinking  
of the distributed libraries as something more than just starting  
points. Once you've made the copy, checked for problems and fixed  
them (remember, there is *no* universally correct OP490 symbol: you  
always need to check), then there is no need ever to look back at the  
distributed libraries.

>
>>> and to rename embedded symbols without making any library changes.
>>>
>>> My viewpoint on all of this is that it currently seems that
>>> detailed knowledge
>>> of the gschem library system is required in order to gschem &
>>> friends at all
>>> effectively.  We are severely hampered in our ability to
>>> interoperate with
>>> other libgeda tools due to this.  Some sort of sane self-contained
>>> file
>>> format is not only desirable but *required*, and the current  
>>> embedding
>>> mechanism fails at this in an embarrassing fashion.
>>
>> No! A self-contained file isn't reusable, while the present approach
>> allows .sch files to be used as components of multiple schematics.
>> Please, please, do not compromise gEDA's most valuable asset: its
>> flexibility.
>
> Why would a file with caches of its used symbols be any less re-usable
> than one which simply has symbol names in it?

Because the symbol names refer to the project's symbols. They're  
reusable files. But an embedded symbol is more difficult to tear out  
and put into a file.

> It should be _more_
> re-usable. At least then, if you open it with a different library  
> search
> path, you won't get a load of missing symbol errors, you'll get some
> more informative warning that the library part can't be found, and  
> we're
> using a cached version.

If you have project symbols, the search path and library contents  
don't matter. When importing a schematic from another project, the  
missing symbol errors are a handy list of the symbols you need to  
import along with it. Easy. Could automate that, too...

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