X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nr8lymO3z3r+Z+00micJfsazh5ulcd8INyA70gotU3Q=; b=xkyUnVzHY5nDXpyIb4nkrypIaBTAoXYllzras5JIGKxQaTqXPxHKQBgPMeBPZOzUmC QU8X/U8mGnDzcG8yhCpfvn3UnBGD4PpcKgiEbHgK7qSLRIX4SLW5rmdhL6CiDCXzGIln HPabQz1J7AlMiLuXlPfyUPJ7tzrjMr6LOyn1TlT1DWl4k4pHT2ON8eqwzEYMURZZ07U3 TVDxcmbVQ+D8Z1yDrcdtPioNbdDAxq6ScgtAAgzOEWlKNMj7SNCsXulfSjs08Fj9jIBb OLrF9XmlhYUY+FKC0ox1f+0sN3HCU44kkFBQxDU6j7138WBCK/lKm5+QJ/xQmpiYATsj y9HA== MIME-Version: 1.0 X-Received: by 10.28.3.133 with SMTP id 127mr97260192wmd.101.1451795232438; Sat, 02 Jan 2016 20:27:12 -0800 (PST) In-Reply-To: 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> Date: Sat, 2 Jan 2016 19:27:11 -0900 Message-ID: Subject: Re: [geda-user] A fileformat library From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=001a114527821dbd4a0528666bbf 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 --001a114527821dbd4a0528666bbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jan 2, 2016 at 6:07 PM, John Doty 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] wrote: > > > > On Sat, Jan 2, 2016 at 4:38 PM, John Doty 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] 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


On Sat, Jan 2, 2016 at 6:07 PM, John Doty <jpd AT noqsi DOT com> wr= ote:

= On Jan 2, 2016, at 7:47 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] &= lt;geda-user AT del= orie.com> wrote:



On Sat, Jan = 2, 2016 at 4:38 PM, John Doty <jpd AT noqsi DOT com> wrote:


Personally I= find formats like this:

=C2=A0 device=3DRESISTOR
=C2=A0 T 44400 = 49300 5 10 1 1 90 0 1

substantially less readable than ones with fie= ld names, but they are indeed easy to parse.

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.

=C2=A0 The pcb format is quite a bit more elaborate = and the savings from not rolling your own parser are more significant.
<= /div>

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

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.

Serialization library? Why do you want a extra, unnecessary, opaq= ue interface? What, exactly, are you trying to accomplish?




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

Britton

--001a114527821dbd4a0528666bbf--