delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/07/06:55:29

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=FzndwXDQ8TzUIVYzq5PSz9ubgInmzYDQYp6ViP4hmGI=;
b=GNMtf051O0aeewV/mLHinWw9fFAgs++EWFsPtReW/BkYf+6D63RdmgvAFxHF9P9Byp
ul/2rks3mXga6riedbhm1bTjJORP/y/OYHbHs+KmF1As2zLGZvB+D8BI33pb49gbFzFl
PClsHapqXmgk+QRJ6UNx45XZwmpZnzEHYp/il/UUwA7kwIVfxp5fSrBGhLKSF3MBwrHm
F5/jN5y05rleFJz40Z131C1WVXC18vMpCL7TFSLHYQnTbTPbVYnMMJ8YRyvH+n3uNPIJ
G1kIw14cwEIuu/99U657Vvqp+rfGKolgzlGeCgUczzVOOjiBgO/BGSc6+citj4vvLCSJ
2zsQ==
MIME-Version: 1.0
X-Received: by 10.107.44.88 with SMTP id s85mr97387155ios.62.1452167696197;
Thu, 07 Jan 2016 03:54:56 -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 12:54:56 +0100
Message-ID: <CACwWb3AhSh-+NNu--bVMGZBfjaoA+hHg7gbXnoyNv3oMq=e17g@mail.gmail.com>
Subject: Re: [geda-user] (SQL file open/save)
From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <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

--001a113a033cafaedd0528bd2300
Content-Type: text/plain; charset=UTF-8

Okay.


I agree that first the data model shall be defined.

So you say we shall roll our own file format?


On Thu, Jan 7, 2016 at 7:47 AM, 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
> 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).
>
> as far as file formats go, while something standard like json or
> (cringe) yaml or (cringe even harder) xml would have advantages
> (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,
> 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.
> * 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
>
> problem solved, you get canonical parsers for all languages that are
> needed and no extra layers of FFI (which can be needlessly heavy)
>
>

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

<div dir=3D"ltr"><div>Okay.<br><br><br></div>I agree that first the data mo=
del shall be defined.<br><div><br>So you say we shall roll our own file for=
mat?<br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Thu, Jan 7, 2016 at 7:47 AM, Sabin Iacob (<a href=3D"mailto:iacob=
s AT m0n5t3r DOT info">iacobs AT m0n5t3r DOT info</a>) [via <a href=3D"mailto:geda-user AT d=
elorie.com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">On 01/06/2016 09:28 PM, Nic=
klas Karlsson (<a href=3D"mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas.karl=
sson17 AT gmail DOT com</a>)<br>
<span class=3D"">[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT de=
lorie.com</a>] wrote:<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>
</span>all right, can&#39;t stand it any more, I&#39;ve been eating my word=
s 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>
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>
<br>
as far as file formats go, while something standard like json or<br>
(cringe) yaml or (cringe even harder) xml would have advantages<br>
(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>
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>
* 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>
<br>
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>
<br>
</blockquote></div><br></div>

--001a113a033cafaedd0528bd2300--

- Raw text -


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