Mail Archives: geda-user/2016/01/06/18:34:01
--001a114242a406fc130528b2c9d8
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 6, 2016 at 12: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 start
> > > 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. In
> > > 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.
True. The process of writing such validation code is more fun with text
because you can see it. It seems like the same reason again to me.
> > > . 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 claim
> > 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.
>
Not a bad way I'll have to try it.
> 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 are
> > 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 ?
>
I don't, I want to make pcb even more text-ish, so to speak. It might be
worth it if we want to extend the format anyway. Don't worry Jon I don't
want to do .sch files :)
> What are your complaint of having a textual file format ?
>
My problems with our current formats are:
* They're bound to the innards of pcb and lisp. Not a good arrangement
for a suite that claims to favor the toolbox approach.
* They occupy a weird middle ground on readability: not binary, but a
bunch of nameless numeric fields. It's not a huge issue but it's annoying.
Catalogs and the like were being discussed and I was just saying I
don't entirely like that way because then you still can't interpret a
single piece of data in isolation. If you're going text go whole-hog and
get the maximum readability benefits possible is what I say.
By dropping the text you loose something, what is the gain of a binary
> format that outweights that ?
>
Not much, sorry for the confusion. Last time it got discussed the
possibility of an equivalent (optional) sqlite format got discussed and
that seems like a potentially good idea to me since people who like sql
would be starting out substantially ahead of just pile of objects (which is
still substantially ahead of a pile of text which they get now from script
languages).
> > > Also, there is no reason to change a file format unless you change the
> > > 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 start
> on
> > a very nice router. IIRC he said 300-400 hours of effort, probably about
> > $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 somehow
> > 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.
>
It doesn't, it relates to the current text format versus ones that script
languages (Stefan's work is in Ruby for example) could easily read.
> > > You might write a library that reads and writes the files and if people
> > > 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 ?
>
No, it started out as a discussion about exactly why text formats are good
and took a misleading turn.
> I think a fileformat library would be useful, but I still
> would like a textual format for sch/sym/pcb/fp files.
>
Agreed.
Britton
--001a114242a406fc130528b2c9d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 6, 2016 at 12:10 AM, <span dir=3D"ltr"><<a href=3D"mail=
to:karl AT aspodata DOT se" target=3D"_blank">karl AT aspodata DOT se</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Britton Kerin:<br>
> On Tue, Jan 5, 2016 at 9:21 AM, <<a href=3D"mailto:karl AT aspodata DOT se=
">karl AT aspodata DOT se</a>> wrote:<br>
> > Britton Kerin:<br>
> > > On Sun, Jan 3, 2016 at 6:25 PM, John Doty <<a href=3D"mai=
lto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a>> wrote:<br>
> > ...<br>
> > > > Although these are good measures, once you adopt them y=
ou may start<br>
> > asking<br>
> > > > yourself why you aren't just using a binary format.=
=C2=A0 The argument for<br>
> > text<br>
> > > > is that you can glance at a chunk of it and easily tell=
what's going<br>
> > on.<br>
> > > > A stronger argument for text is that you can process it=
with<br>
> > text-oriented<br>
> > > > tools.<br>
> > > But ultimately the reason for wanting to use those text-orie=
nted tools is<br>
> > > the same: you can see what you're working on with your o=
wn eyes.=C2=A0 In<br>
> > every<br>
<span class=3D"">> > > other respect binary is better.<br>
> ><br>
> > I counter that.<br>
> > . you have to check a binary file for valid values just as you do=
for a<br>
> >=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'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.</blockquote><div><br></div=
><div style=3D"">True.=C2=A0 The process of writing such validation code is=
more fun with text because you can see it.=C2=A0 It seems like the same re=
ason again to me.</div><div><br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><span class=3D"">
> > . if your binary file is in some way invalid, you will have a gre=
ater<br>
> >=C2=A0 =C2=A0problem correcting it than a text file<br>
> > . discussing why a file is invalid is easier with a text file<br>
> > . a binary file might be smaller, but that does not matter much<b=
r>
> > . text files are better provided for by version systems (e.g. git=
)<br>
> > . it is easier to write tools that write text than binary, becaus=
e<br>
> >=C2=A0 =C2=A0debugging the output is easier<br>
> Regarding vcs of text data files for GUI program, it's a stretch t=
o claim<br>
> that the fact that they're text makes them much more compatible.=
=C2=A0 The diffs<br>
> are only useful for the most trivial of cases.<br>
<br>
</span>You used the word "better", now are you judging things aro=
und<br>
"compatible". What do you want ?<br>
If you want "compatible", then compatible to what ?<br>
<br>
I write a sym/fp-generators and I prefer text output; I can check the<br>
output both "textually" and "visually".<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'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>
>=C2=A0 For it to be really useful<br>
> 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's from sch/pcb files and use that program for<br>
graphical-diffs.<br></blockquote><div><br></div><div style=3D"">Not a bad w=
ay I'll have to try it.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
It would be very useful for regression tests, other projects have been<br>
successful at that.<br>
<br>
> All the rest of the above still boil down to examples of things that a=
re<br>
> easier because you can see the data, and therefore manipulate and vali=
date<br>
> it more easily.<br>
<br>
No, validate input and size, is not about "easier to see".<br>
<br>
But...<br>
Why do you want to remove the text format for me ?<br></blockquote><div><br=
></div><div style=3D"">I don't, I want to make pcb even more text-ish, =
so to speak.=C2=A0 It might be worth it if we want to extend the format any=
way.=C2=A0 Don't worry Jon I don't want to do .sch files :)</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
What are your complaint of having a textual file format ?<br></blockquote><=
div><br></div><div style=3D"">My problems with our current formats are:</di=
v><div style=3D""><br></div><div style=3D"">=C2=A0 * They're bound to t=
he innards of pcb and lisp.=C2=A0 Not a good arrangement for a suite that c=
laims to favor the toolbox approach.</div><div style=3D""><br></div><div st=
yle=3D"">=C2=A0 * They occupy a weird middle ground on readability: not bin=
ary, but a bunch of nameless numeric fields.=C2=A0 It's not a huge issu=
e but it's annoying.</div><div style=3D"">=C2=A0 =C2=A0 Catalogs and th=
e like were being discussed and I was just saying I don't entirely like=
that way because then you still can't interpret a single piece of data=
in isolation.=C2=A0 If you're going text go whole-hog and get the maxi=
mum readability benefits possible is what I say.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
By dropping the text you loose something, what is the gain of a binary<br>
format that outweights that ?<br></blockquote><div><br></div><div style=3D"=
">Not much, sorry for the confusion.=C2=A0 Last time it got discussed the p=
ossibility of an equivalent (optional) sqlite format got discussed and that=
seems like a potentially good idea to me since people who like sql would b=
e starting out substantially ahead of just pile of objects (which is still =
substantially ahead of a pile of text which they get now from script langua=
ges).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > Also, there is no reason to change a file format unless you chang=
e the<br>
> > functionality it provides, I have to "side heavily" wit=
h John on this.<br>
> > If you want to change the file format, you first have to provide =
some<br>
> > goodies that will make people to accept it. And no such "goo=
die"<br>
> > thing has appeared.<br>
<span class=3D"">> A little while back a PhD Stefan Salewski put togethe=
r a very good start on<br>
> a very nice router.=C2=A0 IIRC he said 300-400 hours of effort, probab=
ly about<br>
> $100k worth with overhead in the american market.=C2=A0 It's not C=
(for good<br>
> reasons) and currently can't talk to pcb at all.=C2=A0 I would lik=
e to somehow<br>
> 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></blockquote><div><br></div><div style=3D"">It doesn't,=
it relates to the current text format versus ones that script languages (S=
tefan's work is in Ruby for example) could easily read.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
> > You might write a library that reads and writes the files and if =
people<br>
> > find it useful, they will start using it, else, it will be just y=
our own<br>
> > project.<br>
> True.=C2=A0 It might be useless but should at least be non-destructive=
.<br>
<br>
I thought you are for a fileformat library. I'm I wrong ?<br>
But now you say that such a library is useless. Did I get that right ?<br><=
/blockquote><div><br></div><div style=3D"">No, it started out as a discussi=
on about exactly why text formats are good and took a misleading turn.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
I think a fileformat library would be useful, but I still<br>
would like a textual format for sch/sym/pcb/fp files.<br></blockquote><div>=
<br></div><div style=3D"">Agreed.</div><div>=C2=A0</div><div style=3D"">Bri=
tton</div><div><br></div></div></div></div>
--001a114242a406fc130528b2c9d8--
- Raw text -