Mail Archives: geda-user/2016/01/02/20:08:06
--001a114242a47df1db052863a13d
Content-Type: text/plain; charset=UTF-8
On Sat, Jan 2, 2016 at 3:26 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Jan 2, 2016, at 5:04 PM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
>
> > On Thu, 24 Dec 2015, Peter Clifton (petercjclifton AT googlemail DOT com) [via
> > geda-user AT delorie DOT com] wrote:
> >> Getting the data model right is almost completely independent of the
> rest - even if some may work more elegantly than others.
> >>
> >> Getting the data model right is also the hard bit - unfortunately.
> >
> > I absolutely agree. I've been working hard to get the in-memory data
> representation for Xorn right, and the main thing which keeps me from
> defining PCB object types right now is that I haven't found a convincing
> data model for these yet.
> >
> > On Sun, 27 Dec 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
> >> Simple though it is, the effort of parsing it is not zero and is mostly
> a waste. Modern language have built-in serialization, and with YAML you
> get a cross-language version of that plus a well-defined human-readable
> file format. What's not to like?
> >
> > The part of parsing a .sym/.sch file which can potentially become easier
> with YAML is as simple as a sscanf(3).
>
> Except that what we have is already easy to parse with sscanf() and other
> things. We have a lot of infrastructure based on what we have: symbol
> generators, refdes renumberers, ...
>
As I've mentioned previously I'm talking pcb, which is a more painful
format to parse (such that so far as I'm aware the parser in pcb is the
only one). Personally I find formats like this:
device=RESISTOR
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. The pcb format is quite a bit more elaborate and the
savings from not rolling your own parser are more significant.
> > After extracting the value strings from the file, you still have parse
> and validate them no matter whether they have been stored in a .sym/.sch or
> YAML file.
>
True. One of the nutty things about XML as people tried to use it was the
notion that it can somehow validate the data. Trying to do that just
causes schizophrenia about where validation should happen and I wouldn't
attempt it. That needs an API like libgeda. However, a lot of potential
application may just want to get the file parsed, and trust themselves to
make some valid modifications. This can fairly easily be provided. If
Xorn later supersedes direct use of YAML with a full validating load/save
for the language in question, wonderful.
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).
Britton
--001a114242a47df1db052863a13d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">On Sat, Jan 2, 2016 at 3:26 PM, John Doty <s=
pan dir=3D"ltr"><<a href=3D"mailto:jpd AT noqsi DOT com" target=3D"_blank">jpd@=
noqsi.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D""><br>
On Jan 2, 2016, at 5:04 PM, Roland Lutz <<a href=3D"mailto:rlutz AT hedmen.=
org">rlutz AT hedmen DOT org</a>> wrote:<br>
<br>
> On Thu, 24 Dec 2015, Peter Clifton (<a href=3D"mailto:petercjclifton AT g=
ooglemail.com">petercjclifton AT googlemail DOT com</a>) [via<br>
> <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wr=
ote:<br>
>> Getting the data model right is almost completely independent of t=
he rest - even if some may work more elegantly than others.<br>
>><br>
>> Getting the data model right is also the hard bit - unfortunately.=
<br>
><br>
> I absolutely agree.=C2=A0 I've been working hard to get the in-mem=
ory data representation for Xorn right, and the main thing which keeps me f=
rom defining PCB object types right now is that I haven't found a convi=
ncing data model for these yet.<br>
><br>
> On Sun, 27 Dec 2015, Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gm=
ail.com">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delo=
rie.com">geda-user AT delorie DOT com</a>] wrote:<br>
>> Simple though it is, the effort of parsing it is not zero and is m=
ostly a waste.=C2=A0 Modern language have built-in serialization, and with =
YAML you get a cross-language version of that plus a well-defined human-rea=
dable file format.=C2=A0 What's not to like?<br>
><br>
> The part of parsing a .sym/.sch file which can potentially become easi=
er with YAML is as simple as a sscanf(3).<br>
<br>
</span>Except that what we have is already easy to parse with sscanf() and =
other things. We have a lot of infrastructure based on what we have: symbol=
generators, refdes renumberers, ...<br></blockquote><div><br>As I've m=
entioned previously I'm talking pcb, which is a more painful format to =
parse (such that so far as I'm aware the parser in pcb is the only one)=
.=C2=A0 Personally I find formats like this:<br><br>=C2=A0 device=3DRESISTO=
R<br>=C2=A0 T 44400 49300 5 10 1 1 90 0 1<br><br>substantially less readabl=
e than ones with field names, but they are indeed easy to parse.=C2=A0 The =
pcb format is quite a bit more elaborate and the savings from not rolling y=
our own parser are more significant.<br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><span class=3D"">
>=C2=A0 After extracting the value strings from the file, you still have=
parse and validate them no matter whether they have been stored in a .sym/=
.sch or YAML file.<br></span></blockquote><div><br>True.=C2=A0 One of the n=
utty things about XML as people tried to use it was the notion that it can =
somehow validate the data.=C2=A0 Trying to do that just causes schizophreni=
a about where validation should happen and I wouldn't attempt it.=C2=A0=
That needs an API like libgeda.=C2=A0 However, a lot of potential applicat=
ion may just want to get the file parsed, and trust themselves to make some=
valid modifications.=C2=A0 This can fairly easily be provided.=C2=A0 If Xo=
rn later supersedes direct use of YAML with a full validating load/save for=
the language in question, wonderful.<br><br>I think you're criteria fo=
r what should go in libgeda are spot-on btw.=C2=A0 Nor do I have any proble=
m 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 r=
eturn 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 la=
nguages (via SWIG or some other similar mechanism -- or maybe Xorn facilita=
tes this, I'm a little unclear).<br>=C2=A0<br>Britton<br></div></div>
--001a114242a47df1db052863a13d--
- Raw text -