Mail Archives: geda-user/2015/12/27/10:03:28
--Apple-Mail=_C35E6EC2-FEB5-4CE1-A306-777202CE407A
Content-Type: multipart/alternative;
boundary="Apple-Mail=_DFDAFCB8-84AF-4B2B-A08B-DCF94A0A0617"
--Apple-Mail=_DFDAFCB8-84AF-4B2B-A08B-DCF94A0A0617
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 26, 2015, at 9:04 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>=20
> On Fri, Dec 25, 2015 at 12:13 PM, John Doty <jpd AT noqsi DOT com> wrote:
>=20
> On Dec 25, 2015, at 1:38 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
>>=20
>>=20
>> On Thu, Dec 24, 2015 at 1:39 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>=20
>> On Dec 24, 2015, at 12:53 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>=20
>>> Agreed. I like YAML for this reason. You get a parser in every =
language for free, without any other library material required.
>>=20
>> AWK? sed? grep? cut? sort?
>>=20
>> Why not? Unless a newline in your regex really frightens you that =
much...
>>=20
>> Records separated by newline with fields separated by whitespace is =
*better* supported than YAML or any of the other candidates mentioned. =
The only things it lacks for our purposes is a spiffy name and the need =
for extra layers of lasagna code.
>>=20
>> Fine. Put your money where your mouth is. Send me a full parser for =
pcb files with binding for perl, python, ruby, C, and virtually every =
other extant language.
>=20
> I=92m not talking about pcb. I=92m talking about geda-gaf
>=20
>=20
> Geda-gaf is a much cleaner design. The pcb format doesn=92t even =
represent a proper model of what a printed circuit board is.
>=20
> Writing a parser for geda-gaf files is simpler than penetrating an API =
wrapping such a parser. That doesn=92t mean you can do either in an =
instant.
>=20
> Highly unlikely for .sch, no chance whatsoever for pcb. We're talking =
about one function call in each direction form YAML/JSON. Not that I =
would advocate doing anything to sch format.
>> It's easy so you should be able to get it to me BEFORE your next bs =
email.
> If having common parser makes things so easy, you should be able to =
document API=92s
>=20
> I thought you were the one who thought accessible file formats were a =
good 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=92t seem to be what everyone is discussing.
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.
>=20
> C or C++ is probably the first choice since it is very common although =
I like Ada more.
It=92s a lot easier to have a single, simple file format than an API for =
for every language. Maybe multiple API=92s, representing different =
approaches to the data (procedural, data-driven, =85). Some processing =
tools naturally work on files and lack a foreign function interface =
anyway.
> The major difference for people wanting to parse things themselves is =
that the fields have names,
Depends on what language you=92re using. It will be different for =
different 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.?
> 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 =
for 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=92s possibly out of date, you have a stack of them.
> or running a little experiment to figure out which positional field is =
which.
With our existing .sch document I=92ve never had to do that.
> In other words its easier for that purpose too.
>=20
> Using an accessible format is entirely in keeping with the toolbox =
philosophy which you normally advocate so strongly for in gEDA. Why =
should 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?
We have a poorly-documented shared C parser for geda-gaf files along =
with a couple of different poorly-documented Scheme API=92s. 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=92s easy =
to parse in pretty much everything.
>=20
> Britton
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_DFDAFCB8-84AF-4B2B-A08B-DCF94A0A0617
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Dec 26, 2015, at 9:04 PM, Britton =
Kerin (<a =
href=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) =
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
<<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>=
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Fri, Dec 25, 2015 at 12:13 PM, John Doty <span =
dir=3D"ltr"><<a href=3D"mailto:jpd AT noqsi DOT com" =
target=3D"_blank">jpd AT noqsi DOT 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"><div =
style=3D"word-wrap:break-word"><br><div><div>On Dec 25, 2015, at 1:38 =
PM, Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com" =
target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>> =
wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><br><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 24, =
2015 at 1:39 PM, John Doty <span dir=3D"ltr"><<a =
href=3D"mailto:jpd AT noqsi DOT com" =
target=3D"_blank">jpd AT noqsi DOT 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"><div =
style=3D"word-wrap:break-word"><span><br><div><div>On Dec 24, 2015, at =
12:53 PM, Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com" =
target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com" =
target=3D"_blank">geda-user AT delorie DOT com</a>> =
wrote:</div><br><blockquote type=3D"cite"><span =
style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;float:none;display:inline!important">Agreed. I like =
YAML for this reason. You get a parser in every language for free, =
without any other library material =
required.</span></blockquote></div></span><div>AWK? sed? grep? cut? =
sort?</div></div></blockquote><div><br></div><div>Why not? Unless =
a newline in your regex really frightens you that =
much...</div><div> </div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word">Records =
separated by newline with fields separated by whitespace is *better* =
supported than YAML or any of the other candidates mentioned. The only =
things it lacks for our purposes is a spiffy name and the need for extra =
layers of lasagna =
code.</div></blockquote><div><br></div><div>Fine. Put your money =
where your mouth is. Send me a full parser for pcb files with =
binding for perl, python, ruby, C, and virtually every other extant =
language.</div></div></div></div></blockquote><div><br></div>I=92m not =
talking about pcb. I=92m talking about =
geda-gaf</div></div></blockquote><div><br></div><div> </div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Geda-gaf =
is a much cleaner design. The pcb format doesn=92t even represent a =
proper model of what a printed circuit board =
is.</div><div><br></div><div>Writing a parser for geda-gaf files is =
simpler than penetrating an API wrapping such a parser. That doesn=92t =
mean you can do either in an =
instant.</div></div></blockquote><div><br></div><div style=3D"">Highly =
unlikely for .sch, no chance whatsoever for pcb. We're talking =
about one function call in each direction form YAML/JSON. Not that =
I would advocate doing anything to sch format.</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">It's easy so you should be able to get it to me =
BEFORE your next bs email.</div></div></div></blockquote>If having =
common parser makes things so easy, you should be able to document API=92s=
</div></blockquote><div><br></div><div style=3D"">I thought you were =
the one who thought accessible file formats were a good 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?</div></div></div></div></blockquote><div><br></div>That doesn=92t =
seem to be what everyone is discussing.</div><div><br></div><div>On Dec =
27, 2015, at 3:47 AM, Nicklas Karlsson (<a =
href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas DOT karlsson17 AT gmail DOT com<=
/a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> =
wrote:<br><br><blockquote type=3D"cite">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.<br><br>C or C++ is probably the first choice since it is =
very common although I like Ada =
more.</blockquote></div><div><br></div><div>It=92s a lot easier to have =
a single, simple file format than an API for for every language. Maybe =
multiple API=92s, representing different approaches to the data =
(procedural, data-driven, =85). Some processing tools naturally work on =
files and lack a foreign function interface =
anyway.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D""> The =
major difference for people wanting to parse things themselves is that =
the fields have names, =
</div></div></div></div></blockquote><div><br></div>Depends on what =
language you=92re using. It will be different for different 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.?</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D"">so you =
just read the name rather than digging through the =
spec</div></div></div></div></blockquote><div><br></div>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 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=92s=
possibly out of date, you have a stack of =
them.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D""> or =
running a little experiment to figure out which positional field is =
which. </div></div></div></div></blockquote><div><br></div>With our =
existing .sch document I=92ve never had to do =
that.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D""> In =
other words its easier for that purpose too.</div><div =
style=3D""><br></div><div style=3D"">Using an accessible format is =
entirely in keeping with the toolbox philosophy which you normally =
advocate so strongly for in gEDA. 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 documentation for =
the file format) to do this? </div><div><br></div><div>We have a =
poorly-documented shared C parser for geda-gaf files along with a couple =
of different poorly-documented Scheme API=92s. 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=92s easy to parse in =
pretty much everything.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br></div><div =
style=3D"">Britton</div></div></div></div>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">John =
Doty<span class=3D"Apple-converted-space"> =
<span class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=
--Apple-Mail=_DFDAFCB8-84AF-4B2B-A08B-DCF94A0A0617--
--Apple-Mail=_C35E6EC2-FEB5-4CE1-A306-777202CE407A
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
iQIcBAEBCgAGBQJWf/2LAAoJEF1Aj/0UKykRqyMQAKx8fgaN/j4nIq2vLyW7CaKW
XBYGir6ZP/6OGy4yQi+TLx2qWpVz7l22x7RL8cTX+SIF4quJb6G0S6MbHNMWC0er
AutGtswMUr0OAG/JygIYcClSdcZ4sC7atGN4vIMejsmr3Hz5q+Zpk+eaF1UnA48U
GnNWau+V9IvPhS2Qvp8rHo3VPRsly/YwL2v3OhUJIJx8E2MUTZQMrVbCz1rYDH/u
+6PLnVg7hX9DkKxXrquJSeiWA/kGbQhQc2d831AiPWE0oMct6YjVp4j84rL1Dfg6
hBpthdi7lKGLldWduIxNYMJOgdgzTrXGKoQnCitB4oxko/rTX2xXBvDthJMzX0Wd
Tgutu5roqc7gDs6gdjP9jAp0g5RwpkBJq+o4RqSMc/Ciyc2iuXhzSFFLqlCaNJj5
Nej/nogKAFC5xHVpZgmcIZZ4D0z5funBB4gIOJLLPrEdkYJAMYZs2g58cBMiRVQf
OAOzVeRWUU0DeyzZyi3HFvkD2GRlezo+zN5NcclzktoMYl0NHWZXsGiDfkm0a128
NLElfsHXR03GtWTuJ1OwLH35O6tRJJDvMoGMs6z1zML26guJ9bQWk3JzeOlekNI1
eliKFxga29WRSU6NjGFVlWSzFCWVs7P9+35LxF3WdQefkYB8w/iqwruekZdHzC51
aVb5IGXf/WLuHQbxX9l0
=enwL
-----END PGP SIGNATURE-----
--Apple-Mail=_C35E6EC2-FEB5-4CE1-A306-777202CE407A--
- Raw text -