Mail Archives: geda-user/2016/01/08/06:14:49
This is a multi-part message in MIME format.
--------------080004020306050207000305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Apologies folks, as I'm "coming late to the party" on this one.
Sabin and Britton (if I read the thread correctly!!) make some
interesting points, and I'm not privy to the argument why the existing
geda/pcb file is considered 'deficient' (apart from the "its text, its
not sexy-this or sexy-that or latest-exciting-development-tool-here"
one, which is rarely valid). I'm personally a firm fan of the "if it
ain't broke, don't fix it" ethos!
Perhaps somebody can compile a list of potential options with their
relative pro's and con's on the wiki page, (preferably without personal
bias) and then we can take a(n) (anonymous) vote on which direction to
take? The other option is to introduce a 'compatibility' import/export
option ie. users don't -have- to use the default text format, and you
create a series of 'file filters' that geda -can- use .. and any
individual can use whatever happens to suit them. Think office programs,
and RTF vs. ODF vs. M$ etc.
Michael.
On 08/01/16 07:30, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
>
>
> On Wed, Jan 6, 2016 at 9:47 PM, Sabin Iacob (iacobs AT m0n5t3r DOT info
> <mailto:iacobs AT m0n5t3r DOT info>) [via geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>> wrote:
>
> On 01/06/2016 09:28 PM, Nicklas Karlsson
> (nicklas DOT karlsson17 AT gmail DOT com <mailto:nicklas DOT karlsson17 AT gmail DOT com>)
> [via geda-user AT delorie DOT com <mailto: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
> <mailto:nicklas DOT karlsson17 AT gmail DOT com>) [via
> >> geda-user AT delorie DOT com <mailto:geda-user AT delorie DOT com>]"
> <geda-user AT delorie DOT com <mailto: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
>
--------------080004020306050207000305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Apologies folks, as I'm "coming late to the party" on this one.<br>
<br>
Sabin and Britton (if I read the thread correctly!!) make some
interesting points, and I'm not privy to the argument why the
existing geda/pcb file is considered 'deficient' (apart from the
"its text, its not sexy-this or sexy-that or
latest-exciting-development-tool-here" one, which is rarely valid).
I'm personally a firm fan of the "if it ain't broke, don't fix it"
ethos!<br>
<br>
Perhaps somebody can compile a list of potential options with their
relative pro's and con's on the wiki page, (preferably without
personal bias) and then we can take a(n) (anonymous) vote on which
direction to take? The other option is to introduce a
'compatibility' import/export option ie. users don't -have- to use
the default text format, and you create a series of 'file filters'
that geda -can- use .. and any individual can use whatever happens
to suit them. Think office programs, and RTF vs. ODF vs. M$ etc.<br>
<br>
Michael.<br>
<br>
<div class="moz-cite-prefix">On 08/01/16 07:30, Britton Kerin
(<a class="moz-txt-link-abbreviated" href="mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:<br>
</div>
<blockquote
cite="mid:CAC4O8c9cun6X69Lt_nY0HDNF59b9GADdwEQiFp7p9bU7uz=SoA AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 6, 2016 at 9:47 PM, Sabin
Iacob (<a moz-do-not-send="true"
href="mailto:iacobs AT m0n5t3r DOT info">iacobs AT m0n5t3r DOT info</a>)
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
01/06/2016 09:28 PM, Nicklas Karlsson (<a
moz-do-not-send="true"
href="mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas DOT karlsson17 AT gmail DOT com</a>)<br>
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
wrote:<br>
>> On Wed, 6 Jan 2016 18:09:12 +0100<br>
>> "Nicklas Karlsson (<a moz-do-not-send="true"
href="mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas DOT karlsson17 AT gmail DOT com</a>)
[via<br>
>> <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]"
<<a moz-do-not-send="true"
href="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 moz-do-not-send="true"
href="https://www.sqlite.org/" rel="noreferrer"
target="_blank">https://www.sqlite.org/</a><br>
>><br>
>> Using server/client architectured database engin
like postgresql is IMHO<br>
>> overkill.<br>
>><br>
>> Lev<br>
> 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.<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>
</blockquote>
<div><br>
</div>
<div style="">PCBs are not graphs</div>
<div>Â </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-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>
<div><br>
</div>
<div style="">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.
 </div>
<div>Â </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left: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>
</blockquote>
<div><br>
</div>
<div style="">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.</div>
<div>Â </div>
<blockquote class="gmail_quote" style="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="">lua as the file format is a very different
proposition, since it doesn't get you portability to
anything besides lua</div>
<div>Â </div>
<blockquote class="gmail_quote" style="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>
</div>
<div style="">Yes, this is the hardest part.</div>
<div>Â </div>
<blockquote class="gmail_quote" style="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>
<div style="">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.</div>
<div>Â </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left: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>
</blockquote>
<div><br>
</div>
<div style="">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Â </div>
<div><br>
</div>
<div style="">Britton</div>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------080004020306050207000305--
- Raw text -