Mail Archives: geda-user/2014/03/11/09:08:33
Алексей Харьковский:
> Stefan Salewski:
> > Assume you have a symbol which includes a link to a PDF Datasheet.
> > The link may change.
> Yes. Offensively.
You could solve that with a local cache or finding some archive on the
net.
For a local cache of e.g. pdf's you could use
wget --no-check-certificate -x -N -c --protocol-directories <URL>
in "your local cache" directory. Though that doesn't help when people are
hiding the files behind javascript.
> 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.
> Yes, they can generate trouble:
> > 1. When you have an untrusted source
>
> Yes. Example gedasymbols.
(I wouldn't call gedasymbols an "untrusted" source, it's more of a
"remote" source that you yourself don't have control over.)
> > (for this problem you should make a
> > local backup copy.)
> >
> If insert symbol from local copy to schemas always, how to detect source
> change. Before placing perform diff command?
If you always are using your own copy, you are not bothered by source
changes. If you have a specific sym you are interested in you can check
the changes manually.
> If insert from changeable, and make backup after, this similar my propose.
I don't understand your english here.
> > 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.
...
> > Long time ago I suggested that gschem should store a checksum for each
> > referenced symbol, so changes of that symbol can be detected. I still
> > think that that is a good idea. Further gschem could save some fields,
> > i.e. author and version. So if it becomes unclear which symbol the
> > schematic is referencing, there is some information available to decide.
> I open file from gschem. Gschem sees that the checksum is incorrect.
> What gschem should make?
Check if you have a disk related problem, are your file currupt,
contact the author of the symbol, etc.
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.
> > I agree that for some cases copies of symbols are preferable. Some
> > people like self-contained documents
>
> Self-contained documents more relaible versus referable.
> Reliability that you should strive.
> Reliability are not redundant.
So your case for the "in the file library" solution is:
1, solve same name problem
2, get some reliability against sym file changes
> In some cases, it more conveniently.
> Imagine I want to send the scheme to another developer to edit or cut of
> part of this or simple view.
> I send him a circuit file and say: this symbol take from Stefan, this from
> Karl, at this from DJ Delorie, and the rest from I send in archive.
> :)))
3, and distribution
Am I right?
1 and 2 could be solved by including author/vendor and version
information.
3 can be solved by making the your repo. public or by having some
"collect and distribute" script.
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.
///
Problem areas are (as I understand):
. same sym file name problem
. cvs.gedasymbols.org, your own git/hg/... repo. sym file changes
. distribution of scheme files (so all symbols show up correct)
. remote sources of sym files (netw., connectivity, local caches)
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
- Raw text -