delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/06/04:59:02

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=66n7Cq9UHUpa3nB6miuiu/s+Yp2CdS54rbPA+JCFk5k=;
b=BmoNaQ3PErZUNW/B2UmNLmTN7lJiUXas5av9uupP1Yk0jl1VIZxBQ/4JPdavPZwQL4
dTHsht2MJWfyz7jnIu61nccOfLwBiDhblRdvcN3Th4Y+Zvwb2linTdtHMNHsP2THQSVz
YUOyVR/8tLOaIYKQ6plklf9HH1pS0EDpBBaO4sDSBCMzaqQ2HoFlU3smiUzF0HNOyfmB
hBygoRAj7QC19vdUm/9tb/UoWnrT2w2oE3D1yukRBE2w+Ea28FTAXTVhCO5JM62WfCE0
qVZdZetV0+hq3vuat/rA89dA0M0s+9Ptg0B/yIrM5FWvFxzABEelyAMKe6emi17ip/1H
Pr+w==
MIME-Version: 1.0
X-Received: by 10.50.134.137 with SMTP id pk9mr8351471igb.93.1452074330142;
Wed, 06 Jan 2016 01:58:50 -0800 (PST)
In-Reply-To: <20160106091006.5F67B809D7A1@turkos.aspodata.se>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
<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>
<0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com>
<CAC4O8c_UAiFE-vGfoE2tXppHLhaa0dSYz9o_rkdCBo7_SRRtxw AT mail DOT gmail DOT com>
<FFBE7623-E240-4798-96B0-2BECF56C8E29 AT noqsi DOT com>
<CAC4O8c980g1gj15=5njstC_BT-WYDgKQx9BRycdFKA8OvgtiOg AT mail DOT gmail DOT com>
<B54C0E1F-1986-4C79-9F70-7F1919B8B26D AT noqsi DOT com>
<CAC4O8c9bxJP1eMG4yz3YwKkQJRmsDGmLQ0aMd5pJRyu0WpdCtQ AT mail DOT gmail DOT com>
<C1CFCCEE-C64A-4E49-AA64-446C061656D6 AT noqsi DOT com>
<CAC4O8c-zt8B=joDd+ws77D2jt6aZf3MWfR_dAvpzGcNuBrTURQ AT mail DOT gmail DOT com>
<alpine DOT DEB DOT 2 DOT 11 DOT 1601030040320 DOT 2176 AT newt>
<D9825C8C-B6FD-4C7F-A8D5-B8AF06253B72 AT noqsi DOT com>
<CAC4O8c_R5xWLmzj_cz0g0mPWNs6mR4efjXKGBoup8YO6nwnPTA AT mail DOT gmail DOT com>
<CAC4O8c8zk8=Py1yX6fVqF+35SYe39Li=y4jZ8bCeZ1Ev8WccAg AT mail DOT gmail DOT com>
<20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se>
<CAC4O8c8cVr1H3skmbGo4Rhf5ZTZj8bDxJw8a9C4qfHeGyXZ4XA AT mail DOT gmail DOT com>
<20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se>
Date: Wed, 6 Jan 2016 10:58:49 +0100
Message-ID: <CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w@mail.gmail.com>
Subject: Re: [geda-user] A fileformat library
From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
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

--047d7b2e3dd8a2c08d0528a7660f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

You can have any difftool for git, so you can do visual diffs or anything
what you want, independent of the file format. (as of today, we HAVE visual
diff for PCB)
You can write your own script in whatever language, as long as it has
bindings for the file format, which is the case.

When selecting a file format I would not have such constraints like "it
should be pretty for a human eye". CAD data is so complex, that one can
(and I believe should not) parse them with naked eye. For a computer,
binary is much more efficient.

So I still prefer the SQLite database, as that library is optimized for our
purpose. Yes, I prefer to have a library, that parses our files, and gives
us the possibility to use, or modify the data. I prefer this way because we
have approx. 50 different implementation of pcb/gschem file parser. There
is one in pcb/gaf, and all the other power users wrote their own. It would
be much better to write the parser once, and other could use that. If file
format changes, you have to just change one code, and not 50+.

If we use a standard file format (SQL, YAML, JSON), the parsing library
could be very thin. The independent parsing code is already written. Only
the application (gEDA) specific code has to be written. Remember, all of us
has very limited time to contribute code to gEDA nowadays.

Lev

On Wed, Jan 6, 2016 at 10:10 AM, <karl AT aspodata DOT se> wrote:

> Britton Kerin:
> > On Tue, Jan 5, 2016 at 9:21 AM, <karl AT aspodata DOT se> wrote:
> > > Britton Kerin:
> > > > On Sun, Jan 3, 2016 at 6:25 PM, John Doty <jpd AT noqsi DOT com> wrote:
> > > ...
> > > > > Although these are good measures, once you adopt them you may sta=
rt
> > > asking
> > > > > yourself why you aren't just using a binary format.  The argument
> for
> > > text
> > > > > is that you can glance at a chunk of it and easily tell what's
> going
> > > on.
> > > > > A stronger argument for text is that you can process it with
> > > text-oriented
> > > > > tools.
> > > > But ultimately the reason for wanting to use those text-oriented
> tools is
> > > > the same: you can see what you're working on with your own eyes.  I=
n
> > > every
> > > > other respect binary is better.
> > >
> > > I counter that.
> > > . you have to check a binary file for valid values just as you do for=
 a
> > >   text file
>
> You have not commented this point. Any reader, human or program, have
> to verify its input. Just because you have a binary file you can't just
> do
>
>  struct some_struct_type data;
>  read(fd, data, sizeof(struct some_struct_type))
>
> and pretend that data will contain valid values.
>
> > > . if your binary file is in some way invalid, you will have a greater
> > >   problem correcting it than a text file
> > > . discussing why a file is invalid is easier with a text file
> > > . a binary file might be smaller, but that does not matter much
> > > . text files are better provided for by version systems (e.g. git)
> > > . it is easier to write tools that write text than binary, because
> > >   debugging the output is easier
> > Regarding vcs of text data files for GUI program, it's a stretch to cla=
im
> > that the fact that they're text makes them much more compatible.  The
> diffs
> > are only useful for the most trivial of cases.
>
> You used the word "better", now are you judging things around
> "compatible". What do you want ?
> If you want "compatible", then compatible to what ?
>
> I write a sym/fp-generators and I prefer text output; I can check the
> output both "textually" and "visually".
>
> The diffs out the output of thoose generators are valueable when
> debugging.
>
> You might think of gschem and pcb as gui programs, but there is
> ifrastructure around them which is not gui. Don't think about their files
> in the same way as a png or jpg, where the fileformats are well
> entrenched and infrastructure is available.
>
> >  For it to be really useful
> > you need a (non-text) diff viewer of  some sort.
>
> A graphical-diff is provided by
>
>  http://www.imagemagick.org/Usage/compare/
>
> You can generate png's from sch/pcb files and use that program for
> graphical-diffs.
>
> It would be very useful for regression tests, other projects have been
> successful at that.
>
> > All the rest of the above still boil down to examples of things that ar=
e
> > easier because you can see the data, and therefore manipulate and
> validate
> > it more easily.
>
> No, validate input and size, is not about "easier to see".
>
> But...
> Why do you want to remove the text format for me ?
> What are your complaint of having a textual file format ?
>
> By dropping the text you loose something, what is the gain of a binary
> format that outweights that ?
>
> > > Also, there is no reason to change a file format unless you change th=
e
> > > functionality it provides, I have to "side heavily" with John on this=
.
> > > If you want to change the file format, you first have to provide some
> > > goodies that will make people to accept it. And no such "goodie"
> > > thing has appeared.
> > A little while back a PhD Stefan Salewski put together a very good star=
t
> on
> > a very nice router.  IIRC he said 300-400 hours of effort, probably abo=
ut
> > $100k worth with overhead in the american market.  It's not C (for good
> > reasons) and currently can't talk to pcb at all.  I would like to someh=
ow
> > arrange things such than efforts like this could maybe get used.
>
> In what way does his work relate to a decision about text contra binary
> file format.
>
> > > You might write a library that reads and writes the files and if peop=
le
> > > find it useful, they will start using it, else, it will be just your
> own
> > > project.
> > True.  It might be useless but should at least be non-destructive.
>
> I thought you are for a fileformat library. I'm I wrong ?
> But now you say that such a library is useless. Did I get that right ?
>
> I think a fileformat library would be useful, but I still
> would like a textual format for sch/sym/pcb/fp files.
>
> Regards,
> /Karl Hammar
>
> -----------------------------------------------------------------------
> Asp=C3=B6 Data
> Lilla Asp=C3=B6 148
> S-742 94 =C3=96sthammar
> Sweden
> +46 173 140 57
>
>
>

--047d7b2e3dd8a2c08d0528a7660f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><br></div><br></div>You=
 can have any difftool for git, so you can do visual diffs or anything what=
 you want, independent of the file format. (as of today, we HAVE visual dif=
f for PCB)<br></div>You can write your own script in whatever language, as =
long as it has bindings for the file format, which is the case.<br><br></di=
v></div>When selecting a file format I would not have such constraints like=
 &quot;it should be pretty for a human eye&quot;. CAD data is so complex, t=
hat one can (and I believe should not) parse them with naked eye. For a com=
puter, binary is much more efficient.<br><br></div>So I still prefer the SQ=
Lite database, as that library is optimized for our purpose. Yes, I prefer =
to have a library, that parses our files, and gives us the possibility to u=
se, or modify the data. I prefer this way because we have approx. 50 differ=
ent implementation of pcb/gschem file parser. There is one in pcb/gaf, and =
all the other power users wrote their own. It would be much better to write=
 the parser once, and other could use that. If file format changes, you hav=
e to just change one code, and not 50+.<br><br></div><div>If we use a stand=
ard file format (SQL, YAML, JSON), the parsing library could be very thin. =
The independent parsing code is already written. Only the application (gEDA=
) specific code has to be written. Remember, all of us has very limited tim=
e to contribute code to gEDA nowadays.<br></div><div><br></div>Lev<br></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jan 6, 2=
016 at 10:10 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:karl AT aspodata DOT se"=
 target=3D"_blank">karl AT aspodata DOT se</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Britton Kerin:<br>
<span class=3D"">&gt; On Tue, Jan 5, 2016 at 9:21 AM, &lt;<a href=3D"mailto=
:karl AT aspodata DOT se">karl AT aspodata DOT se</a>&gt; wrote:<br>
&gt; &gt; Britton Kerin:<br>
&gt; &gt; &gt; On Sun, Jan 3, 2016 at 6:25 PM, John Doty &lt;<a href=3D"mai=
lto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a>&gt; wrote:<br>
&gt; &gt; ...<br>
&gt; &gt; &gt; &gt; Although these are good measures, once you adopt them y=
ou may start<br>
&gt; &gt; asking<br>
&gt; &gt; &gt; &gt; yourself why you aren&#39;t just using a binary format.=
=C2=A0 The argument for<br>
&gt; &gt; text<br>
&gt; &gt; &gt; &gt; is that you can glance at a chunk of it and easily tell=
 what&#39;s going<br>
&gt; &gt; on.<br>
&gt; &gt; &gt; &gt; A stronger argument for text is that you can process it=
 with<br>
&gt; &gt; text-oriented<br>
&gt; &gt; &gt; &gt; tools.<br>
&gt; &gt; &gt; But ultimately the reason for wanting to use those text-orie=
nted tools is<br>
&gt; &gt; &gt; the same: you can see what you&#39;re working on with your o=
wn eyes.=C2=A0 In<br>
&gt; &gt; every<br>
&gt; &gt; &gt; other respect binary is better.<br>
&gt; &gt;<br>
&gt; &gt; I counter that.<br>
&gt; &gt; . you have to check a binary file for valid values just as you do=
 for a<br>
&gt; &gt;=C2=A0 =C2=A0text file<br>
<br>
</span>You have not commented this point. Any reader, human or program, hav=
e<br>
to verify its input. Just because you have a binary file you can&#39;t just=
<br>
do<br>
<br>
=C2=A0struct some_struct_type data;<br>
=C2=A0read(fd, data, sizeof(struct some_struct_type))<br>
<br>
and pretend that data will contain valid values.<br>
<span class=3D""><br>
&gt; &gt; . if your binary file is in some way invalid, you will have a gre=
ater<br>
&gt; &gt;=C2=A0 =C2=A0problem correcting it than a text file<br>
&gt; &gt; . discussing why a file is invalid is easier with a text file<br>
&gt; &gt; . a binary file might be smaller, but that does not matter much<b=
r>
&gt; &gt; . text files are better provided for by version systems (e.g. git=
)<br>
&gt; &gt; . it is easier to write tools that write text than binary, becaus=
e<br>
&gt; &gt;=C2=A0 =C2=A0debugging the output is easier<br>
&gt; Regarding vcs of text data files for GUI program, it&#39;s a stretch t=
o claim<br>
&gt; that the fact that they&#39;re text makes them much more compatible.=
=C2=A0 The diffs<br>
&gt; are only useful for the most trivial of cases.<br>
<br>
</span>You used the word &quot;better&quot;, now are you judging things aro=
und<br>
&quot;compatible&quot;. What do you want ?<br>
If you want &quot;compatible&quot;, then compatible to what ?<br>
<br>
I write a sym/fp-generators and I prefer text output; I can check the<br>
output both &quot;textually&quot; and &quot;visually&quot;.<br>
<br>
The diffs out the output of thoose generators are valueable when<br>
debugging.<br>
<br>
You might think of gschem and pcb as gui programs, but there is<br>
ifrastructure around them which is not gui. Don&#39;t think about their fil=
es<br>
in the same way as a png or jpg, where the fileformats are well<br>
entrenched and infrastructure is available.<br>
<span class=3D""><br>
&gt;=C2=A0 For it to be really useful<br>
&gt; you need a (non-text) diff viewer of=C2=A0 some sort.<br>
<br>
</span>A graphical-diff is provided by<br>
<br>
=C2=A0<a href=3D"http://www.imagemagick.org/Usage/compare/" rel=3D"noreferr=
er" target=3D"_blank">http://www.imagemagick.org/Usage/compare/</a><br>
<br>
You can generate png&#39;s from sch/pcb files and use that program for<br>
graphical-diffs.<br>
<br>
It would be very useful for regression tests, other projects have been<br>
successful at that.<br>
<span class=3D""><br>
&gt; All the rest of the above still boil down to examples of things that a=
re<br>
&gt; easier because you can see the data, and therefore manipulate and vali=
date<br>
&gt; it more easily.<br>
<br>
</span>No, validate input and size, is not about &quot;easier to see&quot;.=
<br>
<br>
But...<br>
Why do you want to remove the text format for me ?<br>
What are your complaint of having a textual file format ?<br>
<br>
By dropping the text you loose something, what is the gain of a binary<br>
format that outweights that ?<br>
<span class=3D""><br>
&gt; &gt; Also, there is no reason to change a file format unless you chang=
e the<br>
&gt; &gt; functionality it provides, I have to &quot;side heavily&quot; wit=
h John on this.<br>
&gt; &gt; If you want to change the file format, you first have to provide =
some<br>
&gt; &gt; goodies that will make people to accept it. And no such &quot;goo=
die&quot;<br>
&gt; &gt; thing has appeared.<br>
&gt; A little while back a PhD Stefan Salewski put together a very good sta=
rt on<br>
&gt; a very nice router.=C2=A0 IIRC he said 300-400 hours of effort, probab=
ly about<br>
&gt; $100k worth with overhead in the american market.=C2=A0 It&#39;s not C=
 (for good<br>
&gt; reasons) and currently can&#39;t talk to pcb at all.=C2=A0 I would lik=
e to somehow<br>
&gt; arrange things such than efforts like this could maybe get used.<br>
<br>
</span>In what way does his work relate to a decision about text contra bin=
ary<br>
file format.<br>
<span class=3D""><br>
&gt; &gt; You might write a library that reads and writes the files and if =
people<br>
&gt; &gt; find it useful, they will start using it, else, it will be just y=
our own<br>
&gt; &gt; project.<br>
&gt; True.=C2=A0 It might be useless but should at least be non-destructive=
.<br>
<br>
</span>I thought you are for a fileformat library. I&#39;m I wrong ?<br>
But now you say that such a library is useless. Did I get that right ?<br>
<br>
I think a fileformat library would be useful, but I still<br>
would like a textual format for sch/sym/pcb/fp files.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Regards,<br>
/Karl Hammar<br>
<br>
-----------------------------------------------------------------------<br>
Asp=C3=B6 Data<br>
Lilla Asp=C3=B6 148<br>
S-742 94 =C3=96sthammar<br>
Sweden<br>
<a href=3D"tel:%2B46%20173%20140%2057" value=3D"+4617314057">+46 173 140 57=
</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>

--047d7b2e3dd8a2c08d0528a7660f--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019