delorie.com/archives/browse.cgi   search  
Mail Archives: geda-help/2012/10/13/13:50:26

X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient: geda-help AT delorie DOT com
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
To: geda-help AT delorie DOT com
Subject: Re: [geda-help] Adding new gschem symbols?
In-reply-to: <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> <alpine DOT BSO DOT 2 DOT 00 DOT 1210122243220 DOT 2692 AT wolfman DOT devio DOT us>
Comments: In-reply-to Alan Corey <ab1jx AT devio DOT us>
message dated "Fri, 12 Oct 2012 23:34:32 -0400."
Mime-Version: 1.0
Message-Id: <20121013174902.160C98117B42@turkos.aspodata.se>
Date: Sat, 13 Oct 2012 19:48:59 +0200 (CEST)
From: karl AT aspodata DOT se (Karl Hammar)
X-Virus-Scanned: ClamAV using ClamSMTP
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

Alan Corey:
...
> > 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.

Since sym files are just plain text files that could be created in now 
unimaginable ways and be scattered all over the file system, it is hard 
to set up any rules except on its internal content.

> > 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.

(What do you mean with external/internal name?)
I don't think a path name, for example, would solve the issue since people
may place the files wherever they want.

...
> > 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?

No, it just picks the first one it finds.

...
> 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.

This sound like you propose adding an attribute "author-id=12345" and/or
"symbol_uid=0x1234567890abcdef" to the sym file, and using a constructs
like:

C 18600 19900 1 0 0 7400-1.sym author-id=12345
C 18600 19900 1 0 0 7400-1.sym symbol_uid=0x1234567890abcdef

You don't need a sql layer for that, you need someone who is willing 
(for free) to administrate and give out such numbers to users.
For MAC addresses you pay IEEE (I think) 15000USD for a number series.
A single user or corporation might have the urge to implement this, 
but I don't think uid's and such a scheme will ever work for gschem.

A very simplistic way to use "uid's" is to keep all sym files in the same 
directory and use the file name as your uid.

I think the only reasonable and sufficiently simple way of handling 
this to use the basename + some author id or name as in

C 18600 19900 1 0 0 7400-1.sym "author=Karl Hammar"

Let it be the author's pain to keep his/hers "basenames" unique, and 
then use something to keep each authors basename spaces separate.
If you wish, we could use the mac address of "my first computer with a 
network card". That would be unique enought (though a little
cumbersome).

Well you could possible use the md5sum of the sym file, what about:

$ md5sum git/openhw/share/gschem/diode.sym 
cc2da042b5ea5afd65f4153bfff79b92  git/openhw/share/gschem/diode.sym

And in the .sch file, this file is referenced by:

C 18600 19900 1 0 0 diode.sym md5=cc2da042b5ea5afd65f4153bfff79b92

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

Yea, know the feeling.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
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