Mail Archives: geda-user/2015/12/27/16:23:44
--047d7b5d3e645988330527e7cc7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
[snip]
> I thought you were the one who thought accessible file formats were a goo=
d
> idea, and bundling big APIs around them not necessarily? So there's
> nothing to document. Parsers are relatively easy but as you admit not
> exactly instantaneous, so why not use a setup that obviates the need for
> them?
>
> That doesn=E2=80=99t seem to be what everyone is discussing.
>
Sorry for getting worked up before, though you do provoke a bit I think.
Maybe my comment about YAML was off-topic. The point of my comment at
least was accessible formats and access from multiple tools.
> On Dec 27, 2015, at 3:47 AM, Nicklas Karlsson (
> nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] <
> geda-user AT delorie DOT com> wrote:
>
> One function call in each direction: refdes, net, layer, footprint, ...
> There is a need to access objects in different directions or dimensions,
> there may also be a need for a notification to gui or possible dbus then
> data have changed.
>
> C or C++ is probably the first choice since it is very common although I
> like Ada more.
>
> It=E2=80=99s a lot easier to have a single, simple file format than an AP=
I for for
> every language. Maybe multiple API=E2=80=99s, representing different appr=
oaches to
>
Unless the APIs are already written for you, which is the whole point of
YAML/JSON. You get a single, simple, human-readable file format that
already has lots of parsers. As you've pointed out in the past, all the
so-call agile languages have so many features in common that's it's not
much of a question what data structure they will make for lots of data, and
the pcb format is certainly in this set.
> the data (procedural, data-driven, =E2=80=A6). Some processing tools natu=
rally
> work on files and lack a foreign function interface anyway.
>
> The major difference for people wanting to parse things themselves is tha=
t
> the fields have names,
>
> Depends on what language you=E2=80=99re using. It will be different for d=
ifferent
> APIs. Is it more convenient to encode x,y as some sort of pair, or
> separate? Or are you being LISPy and going for positions within lists
> anyway with cadadr et al.?
>
No, I meant that the data file itself will tend to have named fields,
rather than arrays with unnamed heterogeneous elements like the current
format
For the agile languages the names will turn into hashes/dicts/whatever when
vivified.
> so you just read the name rather than digging through the spec
>
> You still have to dig through a document to figure out the name and how
> the API presents it. But first, you have to find the specific document fo=
r
>
No, it will use the name it's got in the file. If there's any doubt you
introspect the vivified object.
> your specific API and try to verify that that API is up to date with both
> the parser the actual file format. Instead of a single document that=E2=
=80=99s
>
Odds are you're looking up exactly one function from the YAML API for the
language you want to work in. It's as low an overhead as you can possibly
get for processing a data file with any complexity whatsoever.
> possibly out of date, you have a stack of them.
>
The API is versioned, 15 years old, and very stable.
> or running a little experiment to figure out which positional field is
> which.
>
> With our existing .sch document I=E2=80=99ve never had to do that.
>
I'm impressed, because the lines look like this:
T 54595 57200 5 10 1 1 0 0 1
I've parsed it a number of times but I sure couldn't tell you now which
fields are which right now. I think I'm probably more representative than
you are in this respect.
> In other words its easier for that purpose too.
>
> Using an accessible format is entirely in keeping with the toolbox
> philosophy which you normally advocate so strongly for in gEDA. Why shou=
ld
> pcb be the only program that can easily fully parse pcb files?
>
>
> Indeed. Why should the user ever need developer support (beyond
> documentation for the file format) to do this?
>
Let me tell you.
.sch are simpler than .pcb for one thing. I agree with you that it's a
much closer call there and probably not worth changing after the fact.
Regarding pcb files, I started to want to parse them fully to fiddle around
with integrating Stephan's toporouter (ruby). I first set out to write a
quick parser of my own but of course it wasn't instantaneous. And it would
have been much slower than the one in pcb. So I though I'd just use that.
Unfortunately it's wound onto pcb innards in such a way that wrapper
generators can't handle it without significant changes. So if significant
changes are going to be required anyway, I though why not solve the problem
for all languages while we're at it?
So you see, my interest in it is not unconsidered, or based on it's acronym=
.
> We have a poorly-documented shared C parser for geda-gaf files along with
> a couple of different poorly-documented Scheme API=E2=80=99s. However, we=
have
> useful utilities in a variety of other languages. How is this possible
> without a common parser? Simple: we have a format that=E2=80=99s easy to =
parse in
> pretty much everything.
>
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?
Britton
--047d7b5d3e645988330527e7cc7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>[snip]<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><=
div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>I thought you were the one who thought acces=
sible file formats were a good idea, and bundling big APIs around them not =
necessarily?=C2=A0 So there's nothing to document.=C2=A0 Parsers are re=
latively easy but as you admit not exactly instantaneous, so why not use a =
setup that obviates the need for them?</div></div></div></div></blockquote>=
That doesn=E2=80=99t seem to be what everyone is discussing.</div></div></b=
lockquote><div><br></div><div style=3D"">Sorry for getting worked up before=
, though you do provoke a bit I think.=C2=A0 Maybe my comment about YAML wa=
s off-topic.=C2=A0 The point of my comment at least was accessible formats =
and access from multiple tools.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
style=3D"word-wrap:break-word"><div>On Dec 27, 2015, at 3:47 AM, Nicklas K=
arlsson (<a href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com" target=3D"_blank">=
nicklas DOT karlsson17 AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie.=
com" target=3D"_blank">geda-user AT delorie DOT com</a>] <<a href=3D"mailto:ged=
a-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>> wrote:<=
br><br><blockquote type=3D"cite">One function call in each direction: refde=
s, net, layer, footprint, ... There is a need to access=C2=A0objects in dif=
ferent directions or dimensions, there may also be a need for a notificatio=
n to gui or=C2=A0possible dbus then data have changed.<br><br>C or C++ is p=
robably the first choice since it is very common although I like Ada more.<=
/blockquote></div><div>It=E2=80=99s a lot easier to have a single, simple f=
ile format than an API for for every language. Maybe multiple API=E2=80=99s=
, representing different approaches to</div></div></blockquote><div><br></d=
iv><div style=3D"">Unless the APIs are already written for you, which is th=
e whole point of YAML/JSON.=C2=A0 You get a single, simple, human-readable =
file format that already has lots of parsers.=C2=A0 As you've pointed o=
ut in the past, all the so-call agile languages have so many features in co=
mmon that's it's not much of a question what data structure they wi=
ll make for lots of data, and the pcb format is certainly in this set.=C2=
=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><div> the data (procedural, data-driven, =E2=80=A6). Some processing to=
ols naturally work on files and lack a foreign function interface anyway.</=
div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div> The major difference for people wantin=
g to parse things themselves is that the fields have names,</div></div></di=
v></div></blockquote>Depends on what language you=E2=80=99re using. It will=
be different for different APIs. Is it more convenient to encode x,y as so=
me sort of pair, or separate? Or are you being LISPy and going for position=
s within lists anyway with cadadr et al.?</div></div></blockquote><div><br>=
</div><div style=3D"">No, I meant that the data file itself will tend to ha=
ve named fields, rather than arrays with unnamed heterogeneous elements lik=
e the current format</div><div style=3D"">For the agile languages the names=
will turn into hashes/dicts/whatever when vivified.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>so you =
just read the name rather than digging through the spec</div></div></div></=
div></blockquote>You still have to dig through a document to figure out the=
name and how the API presents it. But first, you have to find the specific=
document for</div></div></blockquote><div><br></div><div style=3D"">No, it=
will use the name it's got in the file.=C2=A0 If there's any doubt=
you introspect the vivified object.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div style=3D"word-wrap:break-word"><div> your specific API and try to ver=
ify that that API is up to date with both the parser =C2=A0the actual file =
format. Instead of a single document that=E2=80=99s</div></div></blockquote=
><div><br></div><div style=3D"">Odds are you're looking up exactly one =
function from the YAML API for the language you want to work in.=C2=A0 It&#=
39;s as low an overhead as you can possibly get for processing a data file =
with any complexity whatsoever.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
style=3D"word-wrap:break-word"><div> possibly out of date, you have a stac=
k of them.</div></div></blockquote><div><br></div><div style=3D"">The API i=
s versioned, 15 years old, and very stable.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div style=3D"word-wrap:break-word"><div><blockquote type=3D"cite">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
> or running a little experiment to figure out which positional field is wh=
ich.=C2=A0</div></div></div></div></blockquote>With our existing .sch docum=
ent I=E2=80=99ve never had to do that.</div></div></blockquote><div><br></d=
iv><div style=3D"">I'm impressed, because the lines look like this:</di=
v><div><br></div><div><div>=C2=A0 =C2=A0 =C2=A0T 54595 57200 5 10 1 1 0 0 1=
</div></div><div><br></div><div style=3D"">I've parsed it a number of t=
imes but I sure couldn't tell you now which fields are which right now.=
=C2=A0 I think I'm probably more representative than you are in this re=
spect.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div> In other words its easier fo=
r that purpose too.</div><div><br></div><div>Using an accessible format is =
entirely in keeping with the toolbox philosophy which you normally advocate=
so strongly for in gEDA.=C2=A0 Why should pcb be the only program that can=
easily fully parse pcb files?</div></div></div></div></blockquote><div><br=
></div>Indeed. Why should the user ever need developer support (beyond docu=
mentation for the file format) to do this?=C2=A0</div></div></blockquote><d=
iv><br></div><div style=3D"">Let me tell you.</div><div><br></div><div styl=
e=3D"">.sch are simpler than .pcb for one thing.=C2=A0 I agree with you tha=
t it's a much closer call there and probably not worth changing after t=
he fact.=C2=A0 Regarding pcb files, I started to want to parse them fully t=
o fiddle around with integrating Stephan's toporouter (ruby).=C2=A0 I f=
irst set out to write a quick parser of my own but of course it wasn't =
instantaneous.=C2=A0 And it would have been much slower than the one in pcb=
.=C2=A0 So I though I'd just use that.=C2=A0 Unfortunately it's wou=
nd onto pcb innards in such a way that wrapper generators can't handle =
it without significant changes.=C2=A0 So if significant changes are going t=
o be required anyway, I though why not solve the problem for all languages =
while we're at it?</div><div>=C2=A0</div><div style=3D"">So you see, my=
interest in it is not unconsidered, or based on it's acronym.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div></d=
iv><div>We have a poorly-documented shared C parser for geda-gaf files alon=
g with a couple of different poorly-documented Scheme API=E2=80=99s. Howeve=
r, we have useful utilities in a variety of other languages. How is this po=
ssible without a common parser? Simple: we have a format that=E2=80=99s eas=
y to parse in pretty much everything.</div></div></blockquote><div><br></di=
v><div style=3D"">Simple though it is, the effort of parsing it is not zero=
and is mostly 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-readable file format.=C2=A0 What's not to like?</div><div>=C2=A0<=
/div><div style=3D"">Britton</div><div><br></div></div></div></div>
--047d7b5d3e645988330527e7cc7d--
- Raw text -