Mail Archives: geda-user/2016/01/03/00:20:10
--Apple-Mail=_8FF2230B-0A65-4F36-A62C-DC1682FCF008
Content-Type: multipart/alternative;
boundary="Apple-Mail=_32E0A445-4093-4F42-A102-540C2F3DFCE4"
--Apple-Mail=_32E0A445-4093-4F42-A102-540C2F3DFCE4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jan 2, 2016, at 9:27 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via =
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>=20
> On Sat, Jan 2, 2016 at 6:07 PM, John Doty <jpd AT noqsi DOT com> wrote:
>=20
> On Jan 2, 2016, at 7:47 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>>=20
>>=20
>> On Sat, Jan 2, 2016 at 4:38 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>=20
>> On Jan 2, 2016, at 6:07 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>=20
>>> Personally I find formats like this:
>>>=20
>>> device=3DRESISTOR
>>> T 44400 49300 5 10 1 1 90 0 1
>>>=20
>>> substantially less readable than ones with field names, but they are =
indeed easy to parse.
>>=20
>> Personally, I rarely edit these things manually except for the text =
fields, which are not difficult to find. The fact that they=92re easy to =
parse is handy for automation.
>>=20
>>> The pcb format is quite a bit more elaborate and the savings from =
not rolling your own parser are more significant.
>>>=20
>>> I think you're criteria for what should go in libgeda are spot-on =
btw. Nor do I have any problem with a C interface calling python or =
gschem or for that matter C++. I do think providing a clean C interface =
to libgeda gets by far the best return on investment, since it's so =
widely known and with a little care wrappers can then be provided almost =
automatically for a wide variety of languages (via SWIG or some other =
similar mechanism -- or maybe Xorn facilitates this, I'm a little =
unclear).
>>=20
>> I don=92t find deconstructing C data structures particularly easier =
than parsing the format above. Just another layer I have to penetrate to =
get to the data. I do significant processing with simple things like =
sed, which don=92t handle binary data.
>>=20
>> Wrappers CAN be provided, but will they? FFI programming is not the =
easiest thing. I hear complaints about the need for developers to =
maintain code. It seems to me that one way to address these concerns is =
to avoid and eliminate unnecessary code.
>>=20
>> Good question. It's a great result if you get it but a lot more work =
than using a serialization library, which is why the latter approach =
seems to me like a useful step in the right direction.
> Serialization library? Why do you want a extra, unnecessary, opaque =
interface? What, exactly, are you trying to accomplish?
>=20
> Two things:
>=20
> 1. A human- and partial-parser-script-readable format
We have that, I think. But you left out the most important virtue: =
*simple*.
>=20
> 2. Full parsers for as many languages as possible without writing =
them by hand
So instead, you need to write an interface between a complicated parser =
and every application by hand. Where=92s the gain?
>=20
> Now take a look at the design goals for YAML:
>=20
> http://www.yaml.org/spec/1.2/spec.html#id2708649
>=20
> It's a good fit. If it was only a matter of the technical merits I =
would say as close to perfect as it gets with software.
Compare it to http://wiki.geda-project.org/geda:file_format_spec
YAML is enormously more complex to no advantage for us.
> Unfortunately there's the usual good-versus-most-popular trade-off in =
deciding between YAML and JSON. I still favor YAML in this case, =
largely because I can't look at people like you and honestly claim that =
JSON is in all respects fun to read/edit/sed over etc., and because my =
personal experience with JSON is that although the parsers are truly =
ubiquitous they have some annoying characteristics (at least the Perl =
one does).
But since it doesn=92t relieve the need of the application programmer to =
understand the interface, it is merely adding more code for no gain (or =
even negative gain, given the added complexity). And neither YAML nor =
JSON is as universally readable and processable as the format we have.
>=20
> Britton
>=20
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_32E0A445-4093-4F42-A102-540C2F3DFCE4
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 2, 2016, at 9:27 PM, Britton =
Kerin (<a =
href=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin 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"><br><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Sat, Jan 2, 2016 at 6:07 PM, John Doty <span =
dir=3D"ltr"><<a href=3D"mailto:jpd AT noqsi DOT com" =
target=3D"_blank">jpd AT noqsi DOT com</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><br><div><div>On Jan 2, 2016, at 7:47 PM, =
Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com" =
target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>> =
wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><br><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jan 2, 2016 =
at 4:38 PM, John Doty <span dir=3D"ltr"><<a =
href=3D"mailto:jpd AT noqsi DOT com" =
target=3D"_blank">jpd AT noqsi DOT com</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><br><div><span><div>On Jan 2, 2016, at =
6:07 PM, Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com" =
target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>> =
wrote:</div><br><blockquote type=3D"cite"><div =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px">Personally I find formats like this:<br><br> =
device=3DRESISTOR<br> T 44400 49300 5 10 1 1 90 0 =
1<br><br>substantially less readable than ones with field names, but =
they are indeed easy to =
parse.</div></blockquote><div><br></div></span>Personally, I rarely edit =
these things manually except for the text fields, which are not =
difficult to find. The fact that they=92re easy to parse is handy for =
automation.</div><div><br><blockquote type=3D"cite"><span><div =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"> The pcb format is quite a bit more elaborate and the =
savings from not rolling your own parser are more =
significant.<br></div><div =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"><br></div></span><span><div =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px">I think you're criteria for what should go in libgeda are =
spot-on btw. Nor do I have any problem with a C interface calling =
python or gschem or for that matter C++. I do think providing a =
clean C interface to libgeda gets by far the best return on investment, =
since it's so widely known and with a little care wrappers can then be =
provided almost automatically for a wide variety of languages (via SWIG =
or some other similar mechanism -- or maybe Xorn facilitates this, I'm a =
little unclear).</div></span></blockquote><br></div><div>I don=92t find =
deconstructing C data structures particularly easier than parsing the =
format above. Just another layer I have to penetrate to get to the data. =
I do significant processing with simple things like sed, which don=92t =
handle binary data.</div><div><br></div><div>Wrappers CAN be provided, =
but will they? FFI programming is not the easiest thing. I hear =
complaints about the need for developers to maintain code. It =
seems to me that one way to address these concerns is to avoid and =
eliminate unnecessary =
code.</div></div></blockquote><div><br></div><div>Good question. =
It's a great result if you get it but a lot more work than using a =
serialization library, which is why the latter approach seems to me like =
a useful step in the right =
direction.</div></div></div></div></blockquote>Serialization library? =
Why do you want a extra, unnecessary, opaque interface? What, exactly, =
are you trying to =
accomplish?</div></div></blockquote><div><br></div><div style=3D"">Two =
things: </div><div style=3D""><div><br></div><div> =
1. A human- and partial-parser-script-readable =
format</div></div></div></div></div></blockquote><div><br></div>We have =
that, I think. But you left out the most important virtue: =
*simple*.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div =
style=3D""><div><br></div></div><div style=3D""> 2. =
Full parsers for as many languages as possible without writing them by =
hand</div></div></div></div></blockquote><div><br></div>So instead, you =
need to write an interface between a complicated parser and every =
application by hand. Where=92s the gain?</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div style=3D""><br></div><div style=3D"">Now take =
a look at the design goals for YAML:</div><div =
style=3D""><br></div><div> <a =
href=3D"http://www.yaml.org/spec/1.2/spec.html#id2708649">http://www.yaml.=
org/spec/1.2/spec.html#id2708649</a></div><div><br></div><div =
style=3D"">It's a good fit. If it was only a matter of the =
technical merits I would say as close to perfect as it gets with =
software.</div></div></div></div></blockquote><div><br></div>Compare it =
to <a =
href=3D"http://wiki.geda-project.org/geda:file_format_spec">http://wiki.ge=
da-project.org/geda:file_format_spec</a></div><div>YAML is enormously =
more complex to no advantage for us.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div style=3D"">Unfortunately there's the usual =
good-versus-most-popular trade-off in deciding between YAML and =
JSON. I still favor YAML in this case, largely because I can't =
look at people like you and honestly claim that JSON is in all respects =
fun to read/edit/sed over etc., and because my personal experience with =
JSON is that although the parsers are truly ubiquitous they have some =
annoying characteristics (at least the Perl one =
does).</div></div></div></div></blockquote><div><br></div>But since it =
doesn=92t relieve the need of the application programmer to understand =
the interface, it is merely adding more code for no gain (or even =
negative gain, given the added complexity). And neither YAML nor JSON is =
as universally readable and processable as the format we =
have.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div =
style=3D""><br></div><div style=3D"">Britton</div><div =
style=3D""><br></div></div></div></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=_32E0A445-4093-4F42-A102-540C2F3DFCE4--
--Apple-Mail=_8FF2230B-0A65-4F36-A62C-DC1682FCF008
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
iQIcBAEBCgAGBQJWiK9qAAoJEF1Aj/0UKykR/mUQAK38Q0qvQzd/vcVZJQjMD3T2
osTxJ5XUTQ0qDrD2tsYQvTXyEXZ4G3U2JMvVbyWchkLBxLVW7sFqBGHUur9nZYhl
m6ZM6NW6Sh8Yyud0ljrIyvfM1RVlov5ZEYdnoDyii9nF1nig8+Lb+bMQ+7a+8G8c
6fqGLgS4gBeV0he9fiCc69B8AzW80wKP9F79QUBpAZRtT7Na4w9TcfhD6jMQTcJb
TX0bPN4GlLUhb9YdXKNuDUSyNDZS+tR5MnLJLWZlSPTa0OzGhSaYHvh7PJryzYTa
NUgQTnIO0JOa0ONG5BvFtt3Xfph7p8h7OsGLQ4/8xQfSs6mk+TcEU+UozNKac0RQ
aBew4tOuDR9hMiyfZPNgLpy/mmgPVboCXyl3Jj1xac/sMpZQrr+O886SgRSGz+HO
pS2sblwuBv9JqgX1Rq1pQ0e6R8rEW1j3WJ5zT+g18899qVYXS5Uc1AoyHwNzG9aO
5YGp/x4SSJ418yUPX47dlw3mx2t0DG2/REC2jggJANwSGxsWo+N+I60tikphPu1C
qRwJPVS7EhPm7hv6LOSi87tT1lkBEtCuzpLreB4Yu6ZIR40BAb7XWH/EwlCUE265
fuXaJgl9n+cXjzd/JVll1H7aU4cr6syWF+Mdlhxn0RPqI+kYR1LJA5t5oTWYInut
iQDLr1NtDgajMRO1LMS3
=/yty
-----END PGP SIGNATURE-----
--Apple-Mail=_8FF2230B-0A65-4F36-A62C-DC1682FCF008--
- Raw text -