Mail Archives: geda-user/2016/01/02/20:39:08
--Apple-Mail=_4CA6A494-5C62-4C8E-8572-4F00F2FDE6B3
Content-Type: multipart/alternative;
boundary="Apple-Mail=_22F3EF97-076D-4BE9-8D76-017E5C295A5A"
--Apple-Mail=_22F3EF97-076D-4BE9-8D76-017E5C295A5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
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:
>=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.
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.
> 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).
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.
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.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_22F3EF97-076D-4BE9-8D76-017E5C295A5A
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 6:07 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 style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
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>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"><div =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 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-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><br></div><div style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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></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><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=_22F3EF97-076D-4BE9-8D76-017E5C295A5A--
--Apple-Mail=_4CA6A494-5C62-4C8E-8572-4F00F2FDE6B3
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
iQIcBAEBCgAGBQJWiHunAAoJEF1Aj/0UKykROzQP/3HvD+L0H5rXcvVgKURqZf4R
RB6+Mx0feocjFm/DVRSSno2jQu+Rj0jRGCv434zXKmS7K9wXyPIyFtiDBCeAVWrB
isE3wQCda0EcJsMxKD+JWsW3qqpn05Zmzo7wgRLCi8QlcifBErBn3OIaheFq0qNg
igz3FB9/tAQyz4nRpuY+K5dnu0rlK28etCVfBBaHwIGFH4Hbi9oj5xoDXr4bFnhO
F8W5q0pvTkDPBOfDKk9BIkaP03V9TV72fqNz1dUYiOfF00fcuICBHUx3kC2VkkE0
eR/H7aCiOPVklIS+yrowVpoo+veG6RN8gTWx3WQivE0QpVONQdmMHx5tigHaflrq
6LTKg60HQG1Pi+ozuvc04L5cJC7WQurRW2FJM/rXVerXDbrbo87/KZG3BeIrIqba
9vXiOpG2MM3sycGrQteHHn6qLUANJ61T4ZLDz1oizzFdnC2rX46SH7G4XRbh+kaw
uU3j8GftHmjmJORoCoCcEAe+amZXkjamMaCFLxJe4yVn1BLFEVStz2xBA6qgrND3
4XK1RehsGwAqArVBn6gWjdP5gTKplTic62iGq394jiePXg5+0yl1dsEHogQAlL+q
QLBRKDphjzL8J59ulZ+jGOTHAJUdBfs2YKECmFrc3S0h+8YSbfbdpczdXQgYw8yp
Yxedr8HEqA7rxJh0jz6O
=O4B5
-----END PGP SIGNATURE-----
--Apple-Mail=_4CA6A494-5C62-4C8E-8572-4F00F2FDE6B3--
- Raw text -