delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/08/02:30:34

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=c8AM1nXX8Ztea8OEqUPRa8Y//OO7UoF5qkfo3j/3g0E=;
b=OvuJRrDyiOpWr8H7SyVoCJER1JkptCYNv3r/Arl5Rw+P6QLLgfiKbWAf+RBSMx6A68
hKi3UYIYTenT+r26b7aScb+Uckk9FBC/nVRpDm/KUsBrigvBgNvMBMuoKwDPACH6CK8e
PH2gN3BR1sz5VQYZDYUMtlxxpKNCfEx9yLaRN83DnK5pGff14dSvj7vnatcOLp2vLPda
MLcCDAiD7j/pY7Urnlr6bOkZbnx65QZhCKfuCUZdmN8SMZj/P/Vm/Npt0y6Z9nqFgroV
5fdNXepV+1KkCHHwpnJ/8ZDVmuVJ9Et3EwtMXnnnNoRW/GqqHZT7UzCPONrDOowyxM5S
SksA==
MIME-Version: 1.0
X-Received: by 10.194.82.36 with SMTP id f4mr15242039wjy.87.1452238210152;
Thu, 07 Jan 2016 23:30:10 -0800 (PST)
In-Reply-To: <568E09ED.1080508@m0n5t3r.info>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
<C1CFCCEE-C64A-4E49-AA64-446C061656D6 AT noqsi DOT com>
<CAC4O8c-zt8B=joDd+ws77D2jt6aZf3MWfR_dAvpzGcNuBrTURQ AT mail DOT gmail DOT com>
<alpine DOT DEB DOT 2 DOT 11 DOT 1601030040320 DOT 2176 AT newt>
<D9825C8C-B6FD-4C7F-A8D5-B8AF06253B72 AT noqsi DOT com>
<CAC4O8c_R5xWLmzj_cz0g0mPWNs6mR4efjXKGBoup8YO6nwnPTA AT mail DOT gmail DOT com>
<20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se>
<CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w AT mail DOT gmail DOT com>
<20160106133049 DOT 5A0E9809D79B AT turkos DOT aspodata DOT se>
<CACwWb3Cyk4yLwt3=V1Mu5C4RieOQEjYH3ej5MXZSNnLPbshqDg AT mail DOT gmail DOT com>
<20160106143629 DOT 4D39D809D79B AT turkos DOT aspodata DOT se>
<CACwWb3BXbnQXs+DwVVzmC8DrhwOYxPgVyUhZTPL9bM9cJbHimw AT mail DOT gmail DOT com>
<20160106164022 DOT D0D4E809D79B AT turkos DOT aspodata DOT se>
<20160106180912 DOT 42ddf4079d91384f206b7c35 AT gmail DOT com>
<20160106191433 DOT 5dc5cb59 AT jive DOT levalinux DOT org>
<20160106202817 DOT 56197b2c539d426a1b724c9e AT gmail DOT com>
<568E09ED DOT 1080508 AT m0n5t3r DOT info>
Date: Thu, 7 Jan 2016 22:30:10 -0900
Message-ID: <CAC4O8c9cun6X69Lt_nY0HDNF59b9GADdwEQiFp7p9bU7uz=SoA@mail.gmail.com>
Subject: Re: [geda-user] (SQL file open/save)
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
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

--047d7beba114a5446e0528cd8ed7
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 6, 2016 at 9:47 PM, Sabin Iacob (iacobs AT m0n5t3r DOT info) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

> On 01/06/2016 09:28 PM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com)
> [via geda-user AT delorie DOT com] wrote:
> >> On Wed, 6 Jan 2016 18:09:12 +0100
> >> "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via
> >> geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:
> >>
> >>> Then it come to SQL can you solve file open and save as usual? Or do
> >>> you have to make connection to some kind of database?
> >> Yes. SQLite.
> >>
> >> https://www.sqlite.org/
> >>
> >> Using server/client architectured database engin like postgresql is IMHO
> >> overkill.
> >>
> >> Lev
> > I used SQL once to write a small database application but I used an SQL
> server and even though it works and could be done it will be rather
> complicated for ordinary use. With a simple library binding it could be
> worth a try.
> >
> >
>
> all right, can't stand it any more, I've been eating my words for a
> while now: please, please, please, stop with this SQL nonsense... I know
> that once you find a new shiny hammer everything looks like a nail, but
> schematics and PCBs are graphs at the core, and SQL databases are a
>

PCBs are not graphs


> pretty bad fit for storing graphs (yes, you can shoehorn them in - see
> mptt - but the results are more often than not awful); I too would like
> to see a more comprehensible file format for PCB, but SQL will be
> anything but comprehensible (source: used SQL extensively for the last
> 15 or so years as a developer and a server babysitter).
>

I've worked with it quite a bit too, I understand your concern.  IMO the
big trouble is SQL makes it so easy to extend formats that formats quickly
become extremely complicated often with redundant and poorly thought out
tables.  However, for someone who knows SQL it's tough to look at them and
say that vivified objects from a format like JSON (array+dict) or YAML
(array+dict+ref) will be anywhere near as potent for them.


> as far as file formats go, while something standard like json or
> (cringe) yaml or (cringe even harder) xml would have advantages
>

Out of curiosity you like JSON better than YAML?  It's certainly more
widespread but noisy and lacking refs, so YAML seems easier overall to me.


> (ubiquitous library support, easy-ish to parse and modify with awk &
> friends for people who are so inclined), it will degenerate into
> unproductive holy wars (see previous pushes for lua as the file format,
>

lua as the file format is a very different proposition, since it doesn't
get you portability to anything besides lua


> or various bickering about which text format is best); the way I see it,
> the process looks like this:
>
> * decide on data model; this is where you think hard about what you need
> to do, how it maps to the physical world, etc.
>

Yes, this is the hardest part.


> * decide on syntax, write formal grammar; this is where you take into
> account parse-ability with standard text tools and human brains (I, for
> one, am a big fan of "design for humans first, computers later")
> * have a parser generator generate parsers for every language you use,
> generate some more as they are requested
>

What do you get by doing these two?  It's a pain and its already been done,
in JSON, in YAML, in XML, in SQL.


> problem solved, you get canonical parsers for all languages that are
> needed and no extra layers of FFI (which can be needlessly heavy)
>

gEDA already uses a big stack of libraries, one small additional one is all
that any of the existing solutions mentioned above would require, not FFI

Britton

--047d7beba114a5446e0528cd8ed7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jan 6, 2016 at 9:47 PM, Sabin Iacob (<a href=3D"mailto:iacobs AT m=
0n5t3r.info">iacobs AT m0n5t3r DOT info</a>) [via <a href=3D"mailto:geda-user AT delo=
rie.com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr">&lt;<a href=3D"mailto=
:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 01/06/2016 09:28 PM, Nickla=
s Karlsson (<a href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas.karlsso=
n17 AT gmail DOT com</a>)<br>
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wr=
ote:<br>
&gt;&gt; On Wed, 6 Jan 2016 18:09:12 +0100<br>
&gt;&gt; &quot;Nicklas Karlsson (<a href=3D"mailto:nicklas DOT karlsson17 AT gmail=
.com">nicklas DOT karlsson17 AT gmail DOT com</a>) [via<br>
&gt;&gt; <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>=
]&quot; &lt;<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com<=
/a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Then it come to SQL can you solve file open and save as usual?=
 Or do<br>
&gt;&gt;&gt; you have to make connection to some kind of database?<br>
&gt;&gt; Yes. SQLite.<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://www.sqlite.org/" rel=3D"noreferrer" target=3D"_=
blank">https://www.sqlite.org/</a><br>
&gt;&gt;<br>
&gt;&gt; Using server/client architectured database engin like postgresql i=
s IMHO<br>
&gt;&gt; overkill.<br>
&gt;&gt;<br>
&gt;&gt; Lev<br>
&gt; I used SQL once to write a small database application but I used an SQ=
L server and even though it works and could be done it will be rather compl=
icated for ordinary use. With a simple library binding it could be worth a =
try.<br>
&gt;<br>
&gt;<br>
<br>
all right, can&#39;t stand it any more, I&#39;ve been eating my words for a=
<br>
while now: please, please, please, stop with this SQL nonsense... I know<br=
>
that once you find a new shiny hammer everything looks like a nail, but<br>
schematics and PCBs are graphs at the core, and SQL databases are a<br></bl=
ockquote><div><br></div><div style=3D"">PCBs are not graphs</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
pretty bad fit for storing graphs (yes, you can shoehorn them in - see<br>
mptt - but the results are more often than not awful); I too would like<br>
to see a more comprehensible file format for PCB, but SQL will be<br>
anything but comprehensible (source: used SQL extensively for the last<br>
15 or so years as a developer and a server babysitter).<br></blockquote><di=
v><br></div><div style=3D"">I&#39;ve worked with it quite a bit too, I unde=
rstand your concern.=C2=A0 IMO the big trouble is SQL makes it so easy to e=
xtend formats that formats quickly become extremely complicated often with =
redundant and poorly thought out tables.=C2=A0 However, for someone who kno=
ws SQL it&#39;s tough to look at them and say that vivified objects from a =
format like JSON (array+dict) or YAML (array+dict+ref) will be anywhere nea=
r as potent for them. =C2=A0</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
as far as file formats go, while something standard like json or<br>
(cringe) yaml or (cringe even harder) xml would have advantages<br></blockq=
uote><div><br></div><div style=3D"">Out of curiosity you like JSON better t=
han YAML?=C2=A0 It&#39;s certainly more widespread but noisy and lacking re=
fs, so YAML seems easier overall to me.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
(ubiquitous library support, easy-ish to parse and modify with awk &amp;<br=
>
friends for people who are so inclined), it will degenerate into<br>
unproductive holy wars (see previous pushes for lua as the file format,<br>=
</blockquote><div><br></div><div style=3D"">lua as the file format is a ver=
y different proposition, since it doesn&#39;t get you portability to anythi=
ng besides lua</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
or various bickering about which text format is best); the way I see it,<br=
>
the process looks like this:<br>
<br>
* decide on data model; this is where you think hard about what you need<br=
>
to do, how it maps to the physical world, etc.<br></blockquote><div><br></d=
iv><div style=3D"">Yes, this is the hardest part.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
* decide on syntax, write formal grammar; this is where you take into<br>
account parse-ability with standard text tools and human brains (I, for<br>
one, am a big fan of &quot;design for humans first, computers later&quot;)<=
br>
* have a parser generator generate parsers for every language you use,<br>
generate some more as they are requested<br></blockquote><div><br></div><di=
v style=3D"">What do you get by doing these two?=C2=A0 It&#39;s a pain and =
its already been done, in JSON, in YAML, in XML, in SQL.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
problem solved, you get canonical parsers for all languages that are<br>
needed and no extra layers of FFI (which can be needlessly heavy)<br></bloc=
kquote><div><br></div><div style=3D"">gEDA already uses a big stack of libr=
aries, one small additional one is all that any of the existing solutions m=
entioned above would require, not FFI=C2=A0</div><div><br></div><div style=
=3D"">Britton</div></div><br></div></div>

--047d7beba114a5446e0528cd8ed7--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019