Mail Archives: geda-user/2016/01/06/07:36:29
--Apple-Mail=_9DE033FE-F627-441A-9D43-DA9634BB4DDA
Content-Type: multipart/alternative;
boundary="Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05"
--Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jan 6, 2016, at 4:58 AM, Levente (leventelist AT gmail DOT com) [via =
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>=20
> 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)
And then what do you do with a broken file, with a little bit of garbled =
data in it? Text is more robust.
> You can write your own script in whatever language, as long as it has =
bindings for the file format,
But that=92s more work.
> which is the case.
Not for every language. Certainly not for every text utility.
>=20
> When selecting a file format I would not have such constraints like =
"it should be pretty for a human eye=94.
Not pretty, but comprehensible without processing.
> 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.
It=92s more efficient until something breaks (and something always =
breaks). I note that Mathematica, an enormous, complex program, saves =
its files as text. And every once in a while a rare bug garbles such a =
file. Sometimes they advise =93search for a line like =85 and delete it=94=
as a recovery strategy.
It=92s more efficient if you never want to use text-oriented tools, but =
for files with lots of text data, like attributes and file names, I =
generally want to use text tools to solve some problems. There are =
thousands of tiny problems that you can efficiently address in this way.
>=20
> 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.
No, it gets in the way of using and modifying the data, as then you =
*must* got through the library with all of its limitations.
> I prefer this way because we have approx. 50 different implementation =
of pcb/gschem file parser.
So what? If you have one parser, then you get 50 different =
implementations of the interface to its API. You only move the problem =
to a more difficult layer.
> 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.
Why is it better? I think that is an illusion.
> If file format changes, you have to just change one code, and not 50+.
Not true, because the only sane reason to change the format is to change =
something in the semantics. That means that your common parser=92s API =
will have to change, and everything that uses it will have to =
accommodate that change.
>=20
> If we use a standard file format (SQL, YAML, JSON), the parsing =
library could be very thin.
But it will still get in the way.
> 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.
That=92s why we should not be adding extra, unnecessary layers. That=92s =
why we should not be breaking our existing tools and scripts.
>=20
> Lev
>=20
> 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 =
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
>=20
> 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
>=20
> struct some_struct_type data;
> read(fd, data, sizeof(struct some_struct_type))
>=20
> and pretend that data will contain valid values.
>=20
> > > . 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.
>=20
> You used the word "better", now are you judging things around
> "compatible". What do you want ?
> If you want "compatible", then compatible to what ?
>=20
> I write a sym/fp-generators and I prefer text output; I can check the
> output both "textually" and "visually".
>=20
> The diffs out the output of thoose generators are valueable when
> debugging.
>=20
> 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.
>=20
> > For it to be really useful
> > you need a (non-text) diff viewer of some sort.
>=20
> A graphical-diff is provided by
>=20
> http://www.imagemagick.org/Usage/compare/
>=20
> You can generate png's from sch/pcb files and use that program for
> graphical-diffs.
>=20
> It would be very useful for regression tests, other projects have been
> successful at that.
>=20
> > 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.
>=20
> No, validate input and size, is not about "easier to see".
>=20
> But...
> Why do you want to remove the text format for me ?
> What are your complaint of having a textual file format ?
>=20
> By dropping the text you loose something, what is the gain of a binary
> format that outweights that ?
>=20
> > > 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.
>=20
> In what way does his work relate to a decision about text contra =
binary
> file format.
>=20
> > > 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.
>=20
> 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 ?
>=20
> I think a fileformat library would be useful, but I still
> would like a textual format for sch/sym/pcb/fp files.
>=20
> Regards,
> /Karl Hammar
>=20
> =
-----------------------------------------------------------------------
> Asp=F6 Data
> Lilla Asp=F6 148
> S-742 94 =D6sthammar
> Sweden
> +46 173 140 57
>=20
>=20
>=20
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Jan 6, 2016, at 4:58 AM, Levente =
(<a href=3D"mailto:leventelist AT gmail DOT com">leventelist AT gmail DOT com</a>) =
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
<<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>=
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div =
dir=3D"ltr"><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 =
diff for =
PCB)<br></div></div></div></div></div></blockquote><div><br></div>And =
then what do you do with a broken file, with a little bit of garbled =
data in it? Text is more robust.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div><div>You can write your own =
script in whatever language, as long as it has bindings for the file =
format, </div></div></div></div></blockquote><div><br></div><div>But =
that=92s more work.</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><div><div>which is the =
case.<br></div></div></div></div></blockquote><div><br></div></div><div>No=
t for every language. Certainly not for every text =
utility.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><div><div><br></div>When selecting a file format I =
would not have such constraints like "it should be pretty for a human =
eye=94. </div></div></div></blockquote><div><br></div>Not pretty, but =
comprehensible without processing.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div>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.<br></div></div></div></blockquote><div><br></div>It=92s more =
efficient until something breaks (and something always breaks). I note =
that Mathematica, an enormous, complex program, saves its files as text. =
And every once in a while a rare bug garbles such a file. Sometimes they =
advise =93search for a line like =85 and delete it=94 as a recovery =
strategy.</div><div><br></div><div>It=92s more efficient if you never =
want to use text-oriented tools, but for files with lots of text data, =
like attributes and file names, I generally want to use text tools to =
solve some problems. There are thousands of tiny problems that you can =
efficiently address in this way.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div><br></div>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.</div></div></blockquote><div><br></div>No, it gets in the way of =
using and modifying the data, as then you *must* got through the library =
with all of its limitations.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div> I prefer this way because we have approx. 50 different =
implementation of pcb/gschem file parser. =
</div></div></blockquote><div><br></div>So what? If you have one parser, =
then you get 50 different implementations of the interface to its API. =
You only move the problem to a more difficult =
layer.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>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. =
</div></div></blockquote><br>Why is it better? I think that is an =
illusion.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>If=
file format changes, you have to just change one code, and not =
50+.<br></div></div></blockquote><div><br></div>Not true, because the =
only sane reason to change the format is to change something in the =
semantics. That means that your common parser=92s API will have to =
change, and everything that uses it will have to accommodate that =
change.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><br></div><div>If we use a standard file format (SQL, =
YAML, JSON), the parsing library could be very thin. =
</div></div></blockquote><div><br></div>But it will still get in the =
way.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>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.<br></div></div></blockquote><div><br></div>That=92s why we =
should not be adding extra, unnecessary layers. That=92s why we should =
not be breaking our existing tools and =
scripts.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><br></div>Lev<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jan 6, 2016 =
at 10:10 AM, <span dir=3D"ltr"><<a href=3D"mailto:karl AT aspodata DOT se" =
target=3D"_blank">karl AT aspodata DOT se</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Britton Kerin:<br>
<span class=3D"">> 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"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a>> wrote:<br>
> > ...<br>
> > > > Although these are good measures, once you adopt =
them you may start<br>
> > asking<br>
> > > > yourself why you aren't just using a binary =
format. 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-oriented tools is<br>
> > > the same: you can see what you're working on with your =
own eyes. In<br>
> > every<br>
> > > 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>
> > text file<br>
<br>
</span>You have not commented this point. Any reader, human or program, =
have<br>
to verify its input. Just because you have a binary file you can't =
just<br>
do<br>
<br>
struct some_struct_type data;<br>
read(fd, data, sizeof(struct some_struct_type))<br>
<br>
and pretend that data will contain valid values.<br>
<span class=3D""><br>
> > . if your binary file is in some way invalid, you will have a =
greater<br>
> > problem 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<br>
> > . text files are better provided for by version systems (e.g. =
git)<br>
> > . it is easier to write tools that write text than binary, =
because<br>
> > debugging the output is easier<br>
> Regarding vcs of text data files for GUI program, it's a stretch to =
claim<br>
> that the fact that they're text makes them much more =
compatible. 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 around<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 =
files<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>
> For it to be really useful<br>
> you need a (non-text) diff viewer of some sort.<br>
<br>
</span>A graphical-diff is provided by<br>
<br>
<a href=3D"http://www.imagemagick.org/Usage/compare/" =
rel=3D"noreferrer" =
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>
<br>
It would be very useful for regression tests, other projects have =
been<br>
successful at that.<br>
<span class=3D""><br>
> All the rest of the above still boil down to examples of things =
that are<br>
> easier because you can see the data, and therefore manipulate and =
validate<br>
> it more easily.<br>
<br>
</span>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>
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>
> > Also, there is no reason to change a file format unless you =
change the<br>
> > functionality it provides, I have to "side heavily" with 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 =
"goodie"<br>
> > thing has appeared.<br>
> A little while back a PhD Stefan Salewski put together a very good =
start on<br>
> a very nice router. IIRC he said 300-400 hours of effort, =
probably about<br>
> $100k worth with overhead in the american market. It's not C =
(for good<br>
> reasons) and currently can't talk to pcb at all. I would like =
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 =
binary<br>
file format.<br>
<span class=3D""><br>
> > 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 your own<br>
> > project.<br>
> True. It might be useless but should at least be =
non-destructive.<br>
<br>
</span>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>
<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=F6 Data<br>
Lilla Asp=F6 148<br>
S-742 94 =D6sthammar<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>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">John =
Doty<span class=3D"Apple-converted-space"> =
<span class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=
--Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05--
--Apple-Mail=_9DE033FE-F627-441A-9D43-DA9634BB4DDA
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
iQIcBAEBCgAGBQJWjQpDAAoJEF1Aj/0UKykRJOAP/jBHbsSFSzYD1rhJP5oz7BB9
8RTBhhuknQWJVRkO+ztXFIFTsW12iSUrH6eutPruQsF7WHmtg032AJQnCSJeVSbS
jlnS9vMIL251yhjTogcDlOCc9xxSpJvruuRhYJ4GXOp3R970nG8TFZPoZ4ZUj4n+
mGqTKhZlwS3t4XbbmVyKOA0InmVMvJarQNW3ku0BSNNa8dxLtA43EYCLvzOF8L5/
BHpjXTx2DcOjEsBMVzP6Ri8dCNKoALkKejJwx23e+8sl68z7cvCtUswq4zHdrUOk
rAw7lrW8DVoImY6qc1uCZpitJIyoPonNnb7BKCWuWruPIjz7lNXdrD8XlPa+DQsp
a1FjqYI/94f40zdveProq56v/+GVxonoJ8XWkzRJihw7dj215sszI3EBCtFMwog9
+OTzoMZMYjN+3Hskgu4ahaVpG9DHe5z8ac+Q1eoYoNeo9fNPzt7lj7vcrqlbWb8i
Llkrh2Lj7TdU+rqZqjciHCJx+2Vyf8iUQdgV+aYB7kAGvG0nLfn1POaYo3waINME
+VCMaG47aLrWAArqqnmCqTTNib9SdtnxcfoiG74tcEpZLkIxaZfMBmxYPfejHuyR
9n/06I9q3FF1KOilaImvdc3QmcowCNHXaxcLVu37tmAv3tsAFmj0h7xpT0DWRJzd
hJ7cKX7JWrkLxUfLroH1
=almu
-----END PGP SIGNATURE-----
--Apple-Mail=_9DE033FE-F627-441A-9D43-DA9634BB4DDA--
- Raw text -