Mail Archives: geda-user/2014/03/11/17:16:38
Алексей Харьковский:
> > > 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
- Raw text -