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=zUp8JnI3jdSr1c5XKXBq9wMXoPd9WvY2w80k51cfsTY=; b=BGETFMeEuF44KXa7570XsYEbELPvRKWOB83p+8l92g8ntBjJ4Fdm7pgaPk7yCKroUD xhjA98Ay7Gs9+EqCAbTsSt9X4JIuIAk3f/YNeKOZkISkJ76cOkfyK7u6ikGqPorVoTWh 3H7GBqaydIAqqx+Hj5nSRbNqgo50XBo/6jOYNAL596N4rg8DyptIM92cqHg02KBpKWTY LoQUUEYQUQPEfEqbZ3u5z3MAfgfE+XGVydJ+Fi6TkQ222UGi29hzaODbLSAx7RiC28aG XQcrdNgfUpkfyaCx/fEEaMu+WSjo+Hqpp1+yPb7hmGql9Mj0LmLJQLBFJDoANNAwCgXa vE0w== MIME-Version: 1.0 X-Received: by 10.28.1.23 with SMTP id 23mr31756043wmb.37.1451789256409; Sat, 02 Jan 2016 18:47:36 -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 17:47:36 -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=001a113d7c3eeaca3f0528650672 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 --001a113d7c3eeaca3f0528650672 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 ea= sy 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=E2=80=99t find deconstructing C data structures particularly easier= than > parsing the format above. Just another layer I have to penetrate to get t= o > 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 mainta= in > code. It seems to me that one way to address these concerns is to avoid a= nd > eliminate unnecessary code. > 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. Britton --001a113d7c3eeaca3f0528650672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

=
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 g= mail.com) [via geda-user AT delorie DOT com] <geda-user AT delorie 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

sub= stantially less readable than ones with field names, but they are indeed ea= sy to parse.

Personally, I rarely e= dit these things manually except for the text fields, which are not difficu= lt to find. The fact that they=E2=80=99re easy to parse is handy for automa= tion.

=C2=A0 The pcb format is quite a bit more elaborate and the savings fro= m not rolling your own parser are more significant.
=
I think you're criteria= for what should go in libgeda are spot-on btw.=C2=A0 Nor do I have any pro= blem 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 bes= t return on investment, since it's so widely known and with a little ca= re wrappers can then be provided almost automatically for a wide variety of= languages (via SWIG or some other similar mechanism -- or maybe Xorn facil= itates this, I'm a little unclear).

=

I don=E2=80=99t find deconstructing C data structures particularly eas= ier than parsing the format above. Just another layer I have to penetrate t= o 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 =C2=A0complaints about the need for developers to maintain code. It s= eems to me that one way to address these concerns is to avoid and eliminate= unnecessary code.

G= ood question.=C2=A0 It's a great result if you get it but a lot more wo= rk than using a serialization library, which is why the latter approach see= ms to me like a useful step in the right direction.

Britton

--001a113d7c3eeaca3f0528650672--