Mail Archives: geda-user/2016/01/07/06:55:29
--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"><<a href=3D"mai=
lto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>><=
/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>
>> 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>
</span>all right, can't stand it any more, I'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 &<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 "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>
<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 -