delorie.com/archives/browse.cgi   search  
Mail Archives: geda-help/2012/10/12/23:35:23

X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient: geda-help AT delorie DOT com
X-Virus-Scanned: amavisd-new at devio.us
Date: Fri, 12 Oct 2012 23:34:32 -0400 (EDT)
From: Alan Corey <ab1jx AT devio DOT us>
cc: geda-help AT delorie DOT com
Subject: Re: [geda-help] Adding new gschem symbols?
In-Reply-To: <20121012100446.93D648096B1E@turkos.aspodata.se>
Message-ID: <alpine.BSO.2.00.1210122243220.2692@wolfman.devio.us>
References: <alpine DOT BSO DOT 2 DOT 00 DOT 1210110132340 DOT 24638 AT wolfman DOT devio DOT us> <1349966191 DOT 2412 DOT 33 DOT camel AT AMD64X2 DOT fritz DOT box> <alpine DOT BSO DOT 2 DOT 00 DOT 1210112245150 DOT 13854 AT wolfman DOT devio DOT us> <20121012100446 DOT 93D648096B1E AT turkos DOT aspodata DOT se>
User-Agent: Alpine 2.00 (BSO 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-help AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-help AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> Use component-library-search as in:
>
> $ grep component-library-search ~/.gEDA/gafrc
> (component-library-search "/Net/cvs/cvs.gedasymbols.org/www/user" "cvs")
> (component-library-search (build-path (getenv "HOME") "git/openhw/share/gschem") "lcl")
>
> Hope that helps.
>

Thanks, I'll look at that.

> It was added Dec 23 2011 so probably not many know about it (not even
> me till I searched for a previous version). And the documentation don't
> seem to been updated with this new feature. At the bottom of:

Most open-source documentation in general seems to have that problem, 
which doesn't help its credibility either.  I don't have any simple fix, 
but putting dates in things might help.  It's too easy to pick up some 
piece of documentation and take it at face value then find out it's five 
years old or more.  There's no easy fix by newbies or professional writers
possible either or it will be useless fluff.  It either has to be updated 
by people who are at least peers of the original writers, or else mark it 
as flawed and carefully start writing a parallel replacement with 
references to the original.

>
> Anyone (please) is welcome to file a bug or provide a documentation
> patch for this.
>

I'm not qualified.  I haven't seen it work yet.


> Look at http://wiki.geda-project.org/geda:file_format_spec#component
> It says that it is only the basename (i.e. the file name without any
> directory parts in it) of a file. For example:
>
> C 18600 19900 1 0 0 7400-1.sym
>

When I saw that -1 I thought it was a version number, but I really didn't 
think about where it might have come from.  Is it the author's numbering 
or the file system or gschem's? Fairly obvious now it's just the author's 
but it implies that things are more automatic than they are.  At some 
level it would be nice to have a duplicate of 7400-1.sym automatically 
become 7400-2.sym but where would this happen?  Reminds me a little of how 
cdrecord (or whatever layer) assigns names to files so they don't conflict 
when burning CDs/DVDs with reduced path lengths.

> So if you have sym files from multiple sources, this situation is
> unmanaged, and in my opinion this is a deficiency of the file format.
>

Which brings up the question whether the external name or the internal 
name is more significant/reliable.  And of course any external stuff has 
to be compatible (somehow) with everything this is ported to.

> In may 2011 when I did the c version of an enhanced component-library-search
> (the scm version is mainly done by Luigi Salvatore), I found
> (http://archives.seul.org/geda/user/May-2011/msg00646.html):
>
> <<
> There is 71 duplicate and 6 triplicate symbols names in the cvs.
> One of the triplicate is triac-1.sym, and searching for triac in
> the browser gives me five alternatives:
>
> dj_delorie/symbols/nvsemis
>  triac-1.sym
> dj_delorie/symbols
>  triac-1.sym
> levente_kovacs/symbols
>  triac-1.sym
> werner_hoch/symbols/sf
>  triac-2.sym
> Basic devices
>  triac-1.sym
>>>

This looks like what I'd expect to see, you mean gschem doesn't deal with 
it?

>
> Also:
>
> <<
> Using the basename of a file to find it opens up for ambiguity.
>
> Consider a schematic containg components a.sym and b.sym,
> and two libraries with
>
> path1/ a.sym b.sym
> path2/ a.sym b.sym
>
> and suppose we want path1/a.sym and path2/b.sym.
>>>
>
> We really do need something more than the basename to resolve which
> symbol we want.
>
> I propose that we add something after the basename to resolve the
> conflict. E.g. I want diode.sym, which sym file is then choosen?
>
> $ locate /diode.sym
> /Net/cvs/cvs.gedasymbols.org/www/user/kai_martin_knaak/essential/symbols/discrete/diode.sym
> /Net/cvs/cvs.gedasymbols.org/www/user/kai_martin_knaak/symbols/discrete/diodes/diode.sym
> /Net/cvs/cvs.gedasymbols.org/www/user/max_christian_pohle/symbols/diode.sym
> /home/karl/git/openhw/share/gschem/diode.sym
>
> One could possibly solve that by stating that an attribute should match:
>
> C 18600 19900 1 0 0 diode.sym "author=Karl Hammar"
>
> as in:
>
> $ grep author diode.sym
> author=Karl Hammar
>
> or that the path to the file should match:
>
> C 18600 19900 1 0 0 diode.sym "path contain essential"
>
> Any thoughts?
>
> Regards,
> /Karl Hammar
>

This is a mess and there's no simple fix.  If a few dozen people could sit 
around a big conference table for a week or so maybe they could hash 
something out.  Nothing can be done hastily without considering all the 
consequences.

I still think adding an SQL layer might be an option.  All the existing 
symbols could get imported (with checking) or re-exported.  I think maybe 
making changes with sed, etc might have worked well at one point but at 
some point the task outgrows the tools.  With a database you could assign 
every symbol a 16 or 32 bit number that uniquely identifies it, same with 
authors.  You could set up like UPC codes or MAC addresses where part of 
the number is the author's prefix and the rest identifies the symbol.

Gotta go before my dial-up connection upchucks my ssh session and I lose 
this.

   Alan

> -----------------------------------------------------------------------
> Asp? Data
> Lilla Asp? 148
> S-742 94 ?sthammar
> Sweden
> +46 173 140 57
>
>
>

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019