Mail Archives: geda-user/2016/01/08/02:30:34
--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"><<a href=3D"mailto=
:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>></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>
>> On Wed, 6 Jan 2016 18:09:12 +0100<br>
>> "Nicklas Karlsson (<a href=3D"mailto:nicklas DOT karlsson17 AT gmail=
.com">nicklas DOT karlsson17 AT gmail DOT com</a>) [via<br>
>> <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>
>>> Then it come to SQL can you solve file open and save as usual?=
Or do<br>
>>> you have to make connection to some kind of database?<br>
>> Yes. SQLite.<br>
>><br>
>> <a href=3D"https://www.sqlite.org/" rel=3D"noreferrer" target=3D"_=
blank">https://www.sqlite.org/</a><br>
>><br>
>> Using server/client architectured database engin like postgresql i=
s IMHO<br>
>> overkill.<br>
>><br>
>> Lev<br>
> 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>
><br>
><br>
<br>
all right, can't stand it any more, I'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'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'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'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 &<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'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 "design for humans first, computers later")<=
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'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 -