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: <CAG4ve9+D53V_nwT4aKs=4qPUFkGnv9AO52bJp6TZ=GwoVNmx-A@mail.gmail.com>
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> <CAG4ve9KgoDkkXivoBGL8C2nwToNWjG_Zo61+XeR=sQNeSAnPow AT mail DOT gmail DOT com> <20140311130801 DOT 94D928020170 AT turkos DOT aspodata DOT se> <CAG4ve9+D53V_nwT4aKs=4qPUFkGnv9AO52bJp6TZ=GwoVNmx-A AT mail DOT gmail DOT com>
Comments: In-reply-to =?KOI8-R?B?4czFy9PFyiDowdLYy8/X08vJyg==?= <svetonomer AT gmail DOT com>
   message dated "Tue, 11 Mar 2014 20:24:03 +0400."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20140311211548.2A88E8020170@turkos.aspodata.se>
Date: Tue, 11 Mar 2014 22:15:45 +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

Алексей Харьковский:
> > > Assume you have a symbol which was included in many your schemas from
> > CVS.
> > > Example capacitor or other usable for you.
> > > Througth time autor change pin length and make this less.
> > > All schemas in you archive is broken.
> >
> > You can solve this example noting the version you used and include it
> > somewhere so people can exstract the same version from cvs. A checksum
> > could be provided as an extra check.
> >
> What solve?
> Symbol already changed.
> Checksum wrong. Yes.
> What gschem must do? Message report? Or CVS roll back? Or contact autor?

Gschem should pick the sym from the right author and extract the right 
version (without manual intervention).

> > > 2. When there exist different sources with the same name. For this case
> > > > you can insert more data into the symbol, i.e. authors name and version
> > > > number.
> > > >
> > > That is, all versions must be kept, even when they are outdated....
> > > That is, project developers must have a centralized repository of
> > > characters.
> >
> > You don't need a "centralized" repository, you need some kind of
> > version control, and it is a good investment to use one.
> 
> All developers in his computers should have identical symbols (copies) and
> version control, even if not editing, simple view.
>
> For this they need to use  many third-party tools for to ensure reliability
> his work, instead simple use of Schematic editor.
> Not all engineers want it.

For viewing wouldn't a pdf (possible with a BOM) suffice ?

> Many want to be sure that they can always open and see his scheme, which
> they did years ago, when they need it, istead to make body movements with
> version control program and others to eliminate unexpected bugs.
> 
> It is certainly possible to embed all symbols in his scheme, but why keep the
> scheme in many of the same characters, if you can keep one as I propose to
> do.
> I do not really understand why we need these EMBEDDED characters in the
> form in which they exist.
> They only complicate the syntax of sch-file and complicate scripts
> writing. EMBEDDED
> [ ] and etc.

Well, your idea with the in-file-lib is better than EMBEDDED, but 
perhaps EMBEDDED should be deprecated.

> Check if you have a disk related problem, are your file currupt,
> > contact the author of the symbol, etc.
> >
>  And the author will respond to you through a month. Surely... :)
> 
> > A checksum is a check that "all are in order". The procedure to handle
> > any mismatch is not solved by using a checksum, but it helps to _detect_
> > possible problems.
> >
> That's understandable.
> Followed by curses and body movements.

Don't blame the checksum for something it's not designed to do.

> So your case for the "in the file library" solution is:
> >
> > 1, solve same name problem
> > 2, get some reliability against sym file changes
> >
> And make this without manual activity.

Agreed.

> 3, and distribution
> >
> Am I right?
> >
> Yes.

Good, can we do that without any copying ?

> > 1 and 2 could be solved by including author/vendor and version
> > information.
> Not solve. Only detect.

I meant that gschem should be able to handle it.

> > 3 can be solved by making the your repo. public or by having some
> > "collect and distribute" script.
> >
> Yes. It may be.
> 
> But all this is more difficult then 30-50 rows of C code for change libgeda.

Yes, but it might be worth it if we could minimize the number of copies 
laying around. Many copies of the same thing leads in the end to a mess.

>  Also minus is that all these solutions are distributed.
> There are thousands of scripts to make any changes to the schema file.
> Only refdesrenum-like scripts are about 10, maybe 100.
> But there is no one place where collected their descriptions.

Well, it means that there is an ecosystem around gschem. It could
mean that there might be something missing in gschem, but could also
be that it easy to make thoose scripts and adapt to a new problem, and
that is a strenght.

> Although this is the main function of the program and shold be performed
> with gschem.

We have all different views what the program should do, but having a
toolbox aproach to the matter suits me fine.

> User, especially the new user, confused and repelled by this approach.

If you want to be really good at something you have to spend at least
10000 hours training for it, there are no shortcuts (perhaps a very good
teacher), ask any musician. If this aproach does not suit a person
then perhaps that person isn't destined to be wery good at the thing.

> > And yes, implementing thoose things, so your solution have a head
> > start, but others can catch up. The most interesting thing right now
> > is to identify problem areas of gschem sym file handling, proposing
> > different solutions, and sharing experiences. Implementation comes
> > later. You have a solution and an implementation, and that is a
> > very good starting point when trying to nail down a problem and
> > for discussions.
> >
> I agree completely.

Good. I see your in-file-lib as one candidate.
I'd like to investigate how gschem can interact with repositories,
if we can solve that, I'd rather use that instead of in-file-lib.

Regards,
/Karl Hammar

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