Mail Archives: geda-user/2014/03/11/18:45:41
On Tue, Mar 11, 2014 at 2:15 PM, <karl AT aspodata DOT se> wrote:
> Алексей Харьковский:
>> > > 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).
The fact that gedasymbols is still on CVS shows pretty clearly how far there
would be to go to get a symbol library with the features you're thinking of.
Clearly its not enough of a priority for anyone to get a lot of attention.
>> > > 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 ?
Perhaps, but then if you want to use the design you get to put it all back
in yourself?!? I don't know why OP mentions read-only here but its not
enough and distracts on this issue.
>> 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 ?
Maybe but copying is the easiest way. Its not even that inappropriate for
hardware, since you want a pretty hard freeze once you have things working.
I'm not convinced the concern over clone-and-modify destructiveness applies
well here. For one thing there isn't that much out there to destroy.
For another I don't think modifications in subdesigns would cause that
much harm: the only cost would be lost effort that could have improved the
root symbol. Symbols are relatively simple compared to other software, and
at some fairly early point in development can be considered "good enough".
And it would still be a huge efficiency improvement over the amount of
reinvention that goes on in the current situation.
>> 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.
My Makefile+scripts is 1600 lines and its all doing the obvious stuff that
everyone else must be doing also in some slightly different incompatible way,
its just a waste
>> 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.
I dunno, I don't think you're gonna convince the kids on upverter about this.
They're cranking things out already despite the awful UI.
Britton
- Raw text -