Mail Archives: geda-user/2016/01/02/23:27:45
--001a114527821dbd4a0528666bbf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 2, 2016 at 6:07 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
> 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:
>
>
>
> On Sat, Jan 2, 2016 at 4:38 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
>>
>> 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:
>>
>> Personally I find formats like this:
>>
>> device=3DRESISTOR
>> T 44400 49300 5 10 1 1 90 0 1
>>
>> substantially less readable than ones with field names, but they are
>> indeed easy to parse.
>>
>>
>> Personally, I rarely edit these things manually except for the text
>> fields, which are not difficult to find. The fact that they=E2=80=99re e=
asy to
>> parse is handy for automation.
>>
>> The pcb format is quite a bit more elaborate and the savings from not
>> rolling your own parser are more significant.
>>
>> 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 libged=
a
>> gets by far the best return on investment, since it's so widely known an=
d
>> with a little care wrappers can then be provided almost automatically fo=
r a
>> wide variety of languages (via SWIG or some other similar mechanism -- o=
r
>> maybe Xorn facilitates this, I'm a little unclear).
>>
>>
>> I don=E2=80=99t find deconstructing C data structures particularly easie=
r 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=E2=80=99t handle binary data.
>>
>> Wrappers CAN be provided, but will they? FFI programming is not the
>> easiest thing. I hear complaints about the need for developers to maint=
ain
>> code. It seems to me that one way to address these concerns is to avoid =
and
>> eliminate unnecessary code.
>>
>
> Good question. It's a great result if you get it but a lot more work tha=
n
> 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?
>
Two things:
1. A human- and partial-parser-script-readable format
2. Full parsers for as many languages as possible without writing them
by hand
Now take a look at the design goals for YAML:
http://www.yaml.org/spec/1.2/spec.html#id2708649
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.
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).
Britton
--001a114527821dbd4a0528666bbf
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 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> wr=
ote:<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.kerin@=
gmail.com" target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"m=
ailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>] &=
lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT del=
orie.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 n=
oqsi.com" target=3D"_blank">jpd AT noqsi DOT com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft: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-variant:normal;font-weight:=
normal;letter-spacing:normal;line-height:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px">Personally I=
find formats like this:<br><br>=C2=A0 device=3DRESISTOR<br>=C2=A0 T 44400 =
49300 5 10 1 1 90 0 1<br><br>substantially less readable than ones with fie=
ld names, but they are indeed easy to parse.</div></blockquote><div><br></d=
iv></span>Personally, I rarely edit these things manually except for the te=
xt fields, which are not difficult to find. The fact that they=E2=80=99re e=
asy to parse is handy for automation.</div><div><br><blockquote type=3D"cit=
e"><span><div style=3D"font-family:Helvetica;font-size:12px;font-style:norm=
al;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height=
:normal;text-align:start;text-indent:0px;text-transform:none;white-space:no=
rmal;word-spacing:0px">=C2=A0 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;f=
ont-variant:normal;font-weight:normal;letter-spacing:normal;line-height:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px"><br></div></span><span><div style=3D"font-family:Helveti=
ca;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;=
letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px">I think you're =
criteria for what should go in libgeda are spot-on btw.=C2=A0 Nor do I have=
any problem with a C interface calling python or gschem or for that matter=
C++.=C2=A0 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 l=
ittle care wrappers can then be provided almost automatically for a wide va=
riety of languages (via SWIG or some other similar mechanism -- or maybe Xo=
rn facilitates this, I'm a little unclear).</div></span></blockquote><b=
r></div><div>I don=E2=80=99t find deconstructing C data structures particul=
arly easier than parsing the format above. Just another layer I have to pen=
etrate to get to the data. I do significant processing with simple things l=
ike sed, which don=E2=80=99t handle binary data.</div><div><br></div><div>W=
rappers CAN be provided, but will they? FFI programming is not the easiest =
thing. I hear =C2=A0complaints about the need for developers to maintain co=
de. It seems to me that one way to address these concerns is to avoid and e=
liminate unnecessary code.</div></div></blockquote><div><br></div><div>Good=
question.=C2=A0 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></b=
lockquote>Serialization library? Why do you want a extra, unnecessary, opaq=
ue interface? What, exactly, are you trying to accomplish?</div></div></blo=
ckquote><div><br></div><div style=3D"">Two things:=C2=A0</div><div style=3D=
""><div><br></div><div>=C2=A0 =C2=A0 1.=C2=A0 A human- and partial-parser-s=
cript-readable format</div><div><br></div></div><div style=3D"">=C2=A0 =C2=
=A0 2.=C2=A0 Full parsers for as many languages as possible without writing=
them by hand</div><div style=3D""><br></div><div style=3D"">Now take a loo=
k at the design goals for YAML:</div><div style=3D""><br></div><div>=C2=A0 =
=C2=A0 <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 styl=
e=3D"">It's a good fit.=C2=A0 If it was only a matter of the technical =
merits I would say as close to perfect as it gets with software.</div><div =
style=3D"">Unfortunately there's the usual good-versus-most-popular tra=
de-off in deciding between YAML and JSON.=C2=A0 I still favor YAML in this =
case, largely because I can't look at people like you and honestly clai=
m 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 ubi=
quitous they have some annoying characteristics =C2=A0(at least the Perl on=
e does).</div><div style=3D""><br></div><div style=3D"">Britton</div><div s=
tyle=3D""><br></div></div></div></div>
--001a114527821dbd4a0528666bbf--
- Raw text -