Mail Archives: geda-user/2015/12/23/20:28:43
--Apple-Mail=_373160CC-7064-493A-AA27-C1C26B4EC89F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 23, 2015, at 3:38 PM, Peter Stuge (peter AT stuge DOT se) [via =
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> John Doty wrote:
>> I don=92t expect a tool to do everything I need.
>=20
> Of course. Enabling integration is very important. But robust,
> future-proof integration doesn't come from relying on a moving
> target such as a file format,
The .sch format hasn=92t changed in many years. It=92s not a moving =
target.
> but from relying on a more stable
> target intended specifically for integration.
General-purpose APIs are no more stable than file formats, since they =
must track changes in the data representation just as file formats must.
>=20
>=20
>>> The way that I see the file format thing playing out is most =
certainly
>>> with an internal (*not* turing-complete) data format which is =
"owned"
>>> by a C software library.
>>=20
>> Ugh. You lock us into C.
>=20
> No, to what a C program could do, which is pretty much anything.
C is good for writing things like device drivers. It=92s clumsy for high =
level data processing.
>=20
>=20
>>> The library will hopefully have bindings in lots of different
>>> languages,
>>=20
>> So the user has to penetrate how an FFI maps a C mapping of a text
>> file into their language. How does this make life easier, exactly?
>=20
> Text files aren't great for representing structure.
The .sch format is excellent at representing structure.
>=20
> The more generic the atoms are, the more structure is neccessary to
> have a meaningful result.
The atoms in the .sch representation are pretty generic.
> PCB doesn't have very generic atoms and as
> such can get away with fairly little/simple structure on disk, which
> can be represented all right in text files.
>=20
> Moving towards more generic atoms (which you and I both welcome)
> means that more structure will be neccessary, and then a text format
> just isn't so great anymore.
I think the .sch file design falsifies this.
>=20
>=20
>> In general, it looks like two extra layers of obfuscation to me.
>=20
> I guess you might be jaded by a lifetime of poor abstractions. :\
Indeed.
> Good abstractions are possible too! They do not obfuscate, but adapt
> and enable, making it easier for you to do the job you want to do.
The more generic the data, the harder this is.
>=20
>=20
>> if you=92re a user extending the kit to solve your special problem,
>> you=92re out of the box.
>=20
> You shouldn't knock it until you've tried it. I think that we as a
> community can do really well creating at least one and maybe several
> plugins for a tool that is specifically intended for interchange.
OK, show me.
>=20
>=20
>>>> This kind of ad-hoc scripting relies on the whitespace/newline
>>>> placement that the tools write.
>>>=20
>>> Having "relies on the whitespace" in your workflow is IMO a clear
>>> sign that something is awfully wrong. :\
>>=20
>> No, it=92s a classic UNIX convention with clear thinking behind it.
>=20
> I'm not talking about newlines, but about whitespace in general.
There really isn=92t a problem with whitespace in .sch files.
>=20
>=20
>> It works well for us.
>=20
> Until it doesn't. I have written plenty of text processing software.
>=20
>=20
>>> It's 2015 going on 2016 and we can do a whole lot better than that.
>>=20
>> Not and continue to present the user with UNIX-level flexibility.
>=20
> Sure we can.
>=20
>=20
>>> Don't worry, I'm not interesting in breaking any of your workflows,
>>> I'm interesting in enhancing them with benefit for all.
>>=20
>> But to do that in the style you want, you have to understand my
>> workflows.
>=20
> I just have to make sure that there are well-defined interfaces for
> interchange. They can be text based. I expect there to be at least
> one plugin for the traditional format(s), so that everything possible
> today remains possible in the future, but also with new possibilities
> allowing to do the same things as before and more, easier, for those
> who want - without unneccessarily breaking backwards compatibility.
>=20
>=20
>>> Then you could easily add a tool to this pipeline which takes an old
>>> or new well-defined text format on stdin and outputs the native =
format.
>>=20
>> You could, but what would be gained?
>=20
> An open EDA standard, which as Peter C pointed out is important to
> make the most of the scarce developer resources in our domain.
Standards that actually work are based on things that worked well before =
the standardization process started.
>=20
>=20
>> they didn=92t have the discipline to define the representation of new
>> kinds of relations in flatfiles, so things broke.
>=20
> Yes, the text format will also need to evolve.
For pcb, yes. The geda-gaf format is extensible as is.
> The responsibility for
> that lies with those with an interest in using it. It's also
> perfectly fine for you to stay with the older version, or even
> to create a fork.
>=20
>=20
>> If a pretty big company with a full time professional staff
>=20
> Heh, let's just say that I have experience with some Sun employees,
> and I wouldn't compare such a team with an open source team.
>=20
>=20
>> how can a small project like ours do so?
>=20
> Through your contributions. Rest assured, noone will do it for you.
>=20
>=20
>> Just keep the format transparent.
>=20
> Interchange interfaces absolutely.
> Disk formats I don't think that is worth the effort.
If you ever need to do something out of the conventional flow, you=92ll =
want transparent internal formats.
>=20
>=20
>>> I make all footprints by hand and think to myself what an utter =
waste
>>> of time it is with every single one! :)
>>=20
>> That=92s what transparent formats are for: to enable you to automate =
or
>> work by hand, whichever is easier.
>=20
> Work by hand is never easier when the format isn't made for humans.
> Neither gschem nor PCB file formats are made for humans.
Depends. I don=92t often edit .sch, but it=92s not bad considering what =
it does.
>=20
> A text format is not automatically human writable just because it is
> human readable.
No, but some are better than others.
>=20
>=20
> //Peter
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_373160CC-7064-493A-AA27-C1C26B4EC89F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWe0ofAAoJEF1Aj/0UKykR9YAP/1/0GKBvXoYa/elX/kzZkC8x
g7SBQiVx/z9D1ZtiXLn5KYiNxt53fsh8D4Wie6S4BjEFVyYOA05QKAaunGlWKh09
bGuSh1g2Iiit2SGbQiTWCNN0+Vxztz8YK/WrDAd0TZZq7dlE294acUSql5nngeUK
A3oF432Aj6h50nHJXwNHhyCmZC0aTuD4NfyCsf/JiW8n34OOLF5XUNfe+opcnar+
TzEPY2tn1tAmVQ6ofBhokksAcyuDtOdo8h8wiO6/fYpbcFRBH0bIdHDpoizH+ZN1
wYt27Vp1W81QUarV1DxQ5LxxT35yZRaTH+0iQedF+Yg/a1YL7MK03dUzSdstRk+/
pS5TZQ5e5V3vQO1ExyAgcZ9/VREb1vAToYvNscUtR8pRbM2LMB817nYk2ikbbw3I
LBedNtNj+fEr1iQkPB2a7QlFN4KK3kzCn92isC/RhHyuPTpvh92lzMAt6vO1zKw2
MZwSS7/HL+ET4U/mlF6/wd57/FwhuA6+PKLVK9yqNAdgzxcrRtKzSbz2YcCQEaZn
T49UDvt+ETPVnCZw7quIE1lqw4sOs1Qh948/IT1RiaxK3BSRW9kf7jbJXVZgz5Ja
4TKau9VV4q8wL1Oo62Wja1z1MBNzq/RrZIednwB9qWgL0U2xEcaxC1ITHXjBhoue
Q03r3xCHgAC+bKVsva36
=PWDx
-----END PGP SIGNATURE-----
--Apple-Mail=_373160CC-7064-493A-AA27-C1C26B4EC89F--
- Raw text -