X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: multipart/signed; boundary="Apple-Mail=_4CA6A494-5C62-4C8E-8572-4F00F2FDE6B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [geda-user] A fileformat library X-Pgp-Agent: GPGMail 2.5.2 From: John Doty In-Reply-To: Date: Sat, 2 Jan 2016 18:38:46 -0700 Message-Id: References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>

<20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com>

To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --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] 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

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=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.

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-- --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--