X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-TCPREMOTEIP: 207.224.51.38
X-Authenticated-UID: jpd AT noqsi DOT com
Content-Type: multipart/signed; boundary="Apple-Mail=_373160CC-7064-493A-AA27-C1C26B4EC89F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [geda-user] A fileformat library
X-Pgp-Agent: GPGMail 2.5.2
From: John Doty <jpd AT noqsi DOT com>
In-Reply-To: <20151223223853.20197.qmail@stuge.se>
Date: Wed, 23 Dec 2015 18:27:59 -0700
Message-Id: <0D01411A-F6B5-4926-9201-2F11D001F86C@noqsi.com>
References: <B02363CD-469D-493A-AC15-1D5DC7836982 AT noqsi DOT com> <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <CAM2RGhTficnys3a4xs=UBFvk8aPwpzYWUADFLP_pUQ+R1iKs0g AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512230552520 DOT 9035 AT igor2priv> <FC796A30-DF21-42E0-89D4-48F3C202BCAE AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512230648180 DOT 9035 AT igor2priv> <A6BF931F-181E-4B69-8B3E-E1BD202DE7C5 AT noqsi DOT com> <20151223194905 DOT 7676 DOT qmail AT stuge DOT se> <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0 AT noqsi DOT com> <20151223223853 DOT 20197 DOT qmail AT stuge DOT se>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1878.6)
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


--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--