X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: karl AT aspodata DOT se
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] identical symbol names
In-reply-to: <1394402434.2151.28.camel@AMD64X2.fritz.box>
References: <CAG4ve9LgHNoVZoGaGgF67tadJ_n=L6Uy1g=UPPrkM0fL6Rgufw AT mail DOT gmail DOT com> <20140127234944 DOT 924148045B78 AT turkos DOT aspodata DOT se> <CAG4ve9+3jhFJ1Cr6CLUyLX_y02uigJECiUCwxjUWdP=heVocqg AT mail DOT gmail DOT com> <20140128201110 DOT DF7D78045B78 AT turkos DOT aspodata DOT se> <20140129072550 DOT GA24560 AT localhost DOT localdomain> <CAG4ve9+v9QxNRaPSFkmGfr6bKsv7km-Gt_gwXF7Eh4TX+AmNug AT mail DOT gmail DOT com> <CAOP4iL2JBUdF93kZF-iQ9Rv+VTN3iXoT+6C4LoBi5qaMxof=sA AT mail DOT gmail DOT com> <CAG4ve9+QsUf=nVXPe-f3VddGiqHn8sjZUJNkdu3QV1cOQDWiAg AT mail DOT gmail DOT com> <86CABBE6-EE80-4347-B7AA-3F5A8DA4C658 AT noqsi DOT com> <CAG4ve9LX0mYk2a1zpfWJJC=OP5Weq9pt3PF7_Nqx5vX4wpR=Bg AT mail DOT gmail DOT com> <1394402434 DOT 2151 DOT 28 DOT camel AT AMD64X2 DOT fritz DOT box>
Comments: In-reply-to Stefan Salewski <mail AT ssalewski DOT de>
   message dated "Sun, 09 Mar 2014 23:00:34 +0100."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20140309235005.783608020170@turkos.aspodata.se>
Date: Mon, 10 Mar 2014 00:50:05 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
Note-from-DJ: This may be spam
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Stefan Salewski:
> On Mon, 2014-03-10 at 00:40 +0400, Алексей Харьковский wrote:
> > > The problem with all these ideas is that they make schematics less
> > > reusable.
> > >
> > Disagree.
> > Problems depends not on ideas but on their implementation.

Ohoh, wrong ideas causes more problems than errors in implementations.

To somewhat sum up, to solve the "indentical symbol names" problem, you 
can simply embed the symbol, for simple schematics the problem is
solved. I see no reason to change any program for that case, since 
there is a "workaround".

For bigger schematics with lots of symbols in it, it would mean 
possible execessive copies within the file. But bigger schematics also 
means a lot of other things that I don't have experience about. My guess 
that putting the symbol in a library section of the file simply doesn't 
cut it. As a midway solution, why not add a "save this symbol as" in 
the library browser, then the manual copying and renaming argument 
would be moot (that could also be done by an external program) and
the file format doesn't have to change ?
 Also, I don't see the "one file solution" to be viable for the big
complex case, since you probably already have a lot of files in your
project. And if you still want just one file, you can simply zip or tar 
up the files, gschem doesn't have to provide that functionality.

John Eaton's comment 8 mars seems more reasonable, you want to be able 
to put in libs of symbols from different vendors/devs/people and to be
able to have them versioned. In that scenario gschem have to know the
vendor/author name, git/cvs/etc. id, and possible other things.

Soo, I don't see the use case for a library section in gschem files.

...
> Long time ago I suggested that gschem should store a checksum for each
> referenced symbol, so changes of that symbol can be detected.
...

I wouldn't mind a checksum, but in what way doesn't a git/cvs/... id
handle that case ?

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57