X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=CnJ6hK8RrDHIa9ntKVP0uCrED851N2ERGQ1Ztl/iEMA=;
        b=lNAOgtCJQZF0ZFWK7zQWI2rhklxd1ykNVz+hVSAK8Q1Hafvd5WUV3UUz3y6F6eHx+A
         XOS4TjMNQuoIvgRhEFumtkj27Gz7G/N3nLEyQXGYAlWGlpG9KdfrCyk7Zp81FULb+5x0
         U1jmVNiwh8jOlO0sOJMh+UD+UOv1CCPi0YnvKHzKh9XelnugtEvz9ZRYYVka91AjjAcP
         Z266rLPSBiMiOrkONn5wEvhJGLMgLBUgw8J3Z/7ZwjSH7/0aTMoIvcinxptbw+O1LJ22
         biVv3m5h2CP2vpDQXWFu/+wmmamY8KNKpp/gAl3Y5lCcEEK5c1tXOCvPKiLJ6X+DTjdp
         zZ2A==
MIME-Version: 1.0
X-Received: by 10.25.163.85 with SMTP id m82mr11120069lfe.76.1450890896391;
 Wed, 23 Dec 2015 09:14:56 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1512230552520.9035@igor2priv>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
	<CAJXU7q_mXmipJ1fLvLpuLvnYjktV2SHoA+bG=L5+E-EfdygeOA AT mail DOT gmail DOT com>
	<s6n37uumanm DOT fsf AT blaulicht DOT dmz DOT brux>
	<CAJXU7q_qxdvJaejF-VcY=u7VHZ-zrfrc+Z7-qSwfFyPdy-umxw AT mail DOT gmail DOT com>
	<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>
Date: Wed, 23 Dec 2015 12:14:56 -0500
Message-ID: <CAM2RGhTWPjzb5fKh5e+ud-xsL1THt9Py2gTW4S_UUsHm1tY+5Q@mail.gmail.com>
Subject: Re: [geda-user] A fileformat library
From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA users mailing list <geda-user AT delorie DOT com>
Content-Type: text/plain; charset=UTF-8
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

On Wed, Dec 23, 2015 at 12:16 AM,  <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> On Wed, 23 Dec 2015, Evan Foss (evanfoss AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
>> On Tue, Dec 22, 2015 at 11:47 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>>
>>>
>>> On Dec 22, 2015, at 4:22 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:
>>>>>>
>>>>>> Bonus points for PCB using the core-library too, so it can "give up"
>>>>>> its one preferred on-disk netlist format, and read any useful ones we
>>>>>> care to implement a reader for in the core EDA library.
>>>>>
>>>>>
>>>>> I?m quite skeptical of a core library. An agreed-upon external data
>>>>> representation is handy, but tool writers will want their own
>>>>> internal representations in their own languages for their own problems.
>>>>
>>>>
>>>> The purpose of a core library is to take care of the lower-level
>>>> things required to deal with the external data representation.
>>>
>>>
>>> I?d prefer to make the external representation transparent.
>>>
>>>>
>>>> It is key for a core library to make all available data easily usable
>>>> for tool writers, not to enforce a particular internal representation.
>>>
>>>
>>> But of course, it will use a particular representation. A core library
>>> for C++ isn?t going to be useful to an AWK programmer.
>>>
>>> One thing that?s nice about our .sch format is that it is easy to read
>>> and write from pretty much any language. There?s no need for any extra
>>> layer.
>>
>>
>> Yes but with an extra layer more people can play with files made in
>> PCB. Why force them to write and maintain a whole second library to
>> handle our file format? Look at the number of utilities that people
>> have written to create footprints and things via their own file
>> parsing code. That is a lot of duplicated effort that will be broken
>> when we revise the format. I know you don't use it but I do and I can
>> tell you there are things we need the format to represent that it just
>> can not right now.
>
>
> I think this is a bit more complicated in real life and the truth is
> somewhere in between.
>
> It's great to have an official library that supports the file format and
> tracks (or even defines) the changes of the file format. It's good if it's
> widely available with very low burden.
>
> Now consider not everyone will use the same domain that you do, or the
> library does. Like someone may want to use awk to generate footprints (like
> I do). If you really picked the lowest possible burden, there is a good
> chance I can use your library (e.g. it is possible to bind C functions to
> gawk or libmawk, so if you have written your library in plain C, I could use
> it. If the library is in python, the burden is somewhat higher, and if it's
> written in clipper, well...).
>
> But sometimes it is just not worth it. Like if you need to write software
> that spits out an xml with 2 nodes, and you are sure it won't get more
> complicated over time, you probably won't use an XML library and won't build
> a full DOM and call the readily available function to export the DOM to XML.
> It's just cheaper to do a single line printf(), and works equally good. This
> does not mean having a library for xml is always bad or manually doing
> something with an xml is always good.

I support the idea of a library. I don't like XML or any of the
database ideas people have proposed in the past.

> The question is where does the line between "use the library" vs. "it's much
> simpler with a printf()" sits. And this depends on a lot of factors: the
> person who is doing the project, the actual burden of your library,
> accessibility of your libary, documentation, etc.
>
> A lot of this is totally subjective. Even the burden part. For example I
> have scripts parsing .sch files. It's painful, and I am fully aware of
> risking a rewrite if the file format changes. I am also fully aware of the
> fact that libgeda exists and it is invented exactly for this kind of stuff.
> However, the way libgeda is structured, the API and dependencies, its
> coupling with scheme... For me, all these makes it a worse altenrative than
> just rewriting the part I need. But how one weigths these properties of the
> library vs. the pain of the hand crafted parser is totally subjective.
>
> So I have to agree with John about one thing: a transparent file format is
> good. (Even if I personally find the .sch format very unfriendly.) I don't
> think the file format can not or should not change, even if it breaks a lot
> of hand written parsers. But I also don't think there is an ultimate
> solution to this. And especially don't think it's possible to write a
> fit-for-all library that is then used happily by everyone ever after, thus
> solving the problem.

I agree with that. I did not see it as an "ultimate solution" just a
good thing to go with our already good format documentation. For
reasons unclear to me people seem to see it as a one or the other
thing.

> I think we should just accept that different things work for different
> people, and try to make things versatile so all approaches could work.
> Transparent file format _and_ good libraries handling them. Relatively
> stable file formats _and_ making changes to them when it becomes necessary.
>
>
>



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----