Mail Archives: geda-user/2015/09/13/16:37:08
--f46d0438932b79f912051fa6e8e2
Content-Type: text/plain; charset=UTF-8
On Sun, Sep 13, 2015 at 10:43 AM, Lev (leventelist AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On Sun, 13 Sep 2015 09:55:25 -0800
> "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
> <geda-user AT delorie DOT com> wrote:
>
>> Obviously i'ts possible, the question is how hard is it for the
>> majority of users. If you look at DBI.pm I think you cannot honestly
>> say that the example I give above will be easier via SQL than it is
>> now.
>
> The majority of users don't really care what is going on behind the
scenes.
> Unfortunately, we are software guys, and we do. :-)
For most software you would be correct, for gEDA I bet most users have at
least looked at file, a health percentage have edited it, and a decent
chunk those scripted it.
>> > I don't think xml/yaml is a better choice. They get very, very
>> > ugly. I
>>
>> True, but so does SQL once things get complicated. As it happens I've
>> done a lot of SQL so you can't fool me here :)
>
> I don't want to fool you. I'm happy that you are a kind of person, who
> actually does something, and not just hang around.
Thanks, but so far I haven't actually done much. It's a little hard to
sort out what contributions would actually end up getting used,
particularly on the parse/file format front where I've ended up making my
first attempt.
My plan was to clean up the existing parser such that it parsed to a
structure that corresponds one-to-one with the pcb format. This would set
the stage for wrappers for script access, export in other formats, and
possibly eventual migration to one of them, which would in turn enable a
richer parser more tolerant of additions. But if DJ an others support the
idea of just starting off with a new format, there's not much point in
touching the existing parser. I've never fully parsed a .pcb and couldn't
off the top of my head say whether a given new format would constitute a
superset of the existing one or not, but probably DJ and others could do so.
>> > don't see any reason why not use SQLite.
>>
>> Because many, possibly most people aren't familiar with it. Give
>> yourself credit for what you've learned about SQL, and acknowledge
>> that it isn't going to be instantaneous for others to get that
>> knowledge.
>
> I don't have much knowledge on SQL. And I don't really feel that I'm
> something special. I just browsed the gEDA/PCB code and I get a feeling
> that life would be much easier if we had that SQL thing as the data
> structure.
>
> In the other hand, I don't think the vast majority of users actually would
> hack an xml. It is pain.
xml is the most painful of the plain-text options.
> I see no difference here.
Users do read and parse the existing format, at least partially.
>> There are actually only two reason *to* use SQL. One is parse speed,
>> which is not significant for most use cases.
>> The other is the additional work for you (or someone) to put it in a
>> readable format. But its easy work and I hereby
>> volunteer to do it.
>
> Okay. Don't get me wrong. I don't care if it is SQL, or not. I just state
> that if we use SQLite, we pull in lots of work. Your work has a value! I
> suggest we concentrate on the PCB part, and not doing something which is
> already done.
>
> That is all I say.
>
> BTW, what is your recommendation? Would you use xml? Would you roll your
own
> file format?
I'd use YAML. It's far more readable that XML, and significantly more
readable and richer than JSON. There's a parser for every common
language. Personally I have no problem with SQLite, I really like it in
fact. But I think already a number of people (Igor, Evan IIRC and at least
one other) have said they would prefer human-readable.
Evan also noted that it's possible to make SQL that can be represented in
text, but in a mostly useless way. It would be nice to avoid this effect.
In my experience SQL formats have a tendency to grow strange tables in all
direction at a great rate. I'm not one to condemn an approach just because
it makes it easier for people to make things confusing. But, the small
discipline of staying in sync with, say, a YAML representation, might not
be a bad thing.
--f46d0438932b79f912051fa6e8e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sun, Sep 13, 2015 at 10:43 AM, Lev (<a href=3D"=
mailto:leventelist AT gmail DOT com">leventelist AT gmail DOT com</a>) [via <a href=3D"ma=
ilto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <<a href=3D"mailt=
o:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> wrote:<br>> On Su=
n, 13 Sep 2015 09:55:25 -0800<br>> "Britton Kerin (<a href=3D"mailt=
o:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"mai=
lto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]"<br>> <<a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> wrote:<=
br>><br>>> Obviously i'ts possible, the question is how hard i=
s it for the<br>>> majority of users.=C2=A0 If you look at DBI.pm I t=
hink you cannot honestly<br>>> say that the example I give above will=
be easier via SQL than it is<br>>> now.<br>><br>> The majority=
of users don't really care what is going on behind the scenes.<br>>=
Unfortunately, we are software guys, and we do. :-)<br><br>For most softwa=
re you would be correct, for gEDA I bet most users have at least looked at =
file, a health percentage have edited it, and a decent chunk those scripted=
it.<br><br>>> > I don't think xml/yaml is a better choice. Th=
ey get very, very<br>>> > ugly. I<br>>><br>>> True, bu=
t so does SQL once things get complicated.=C2=A0 As it happens I've<br>=
>> done a lot of SQL so you can't fool me here :)<br>><br>>=
I don't want to fool you. I'm happy that you are a kind of person,=
who<br>> actually does something, and not just hang around.<br><br>Than=
ks, but so far I haven't actually done much.=C2=A0 It's a little ha=
rd to sort out what contributions would actually end up getting used, parti=
cularly on the parse/file format front where I've ended up making my fi=
rst attempt.<br><br>My plan was to clean up the existing parser such that i=
t parsed to a structure that corresponds one-to-one with the pcb format.=C2=
=A0 This would set the stage for wrappers for script access, export in othe=
r formats, and possibly eventual migration to one of them, which would in t=
urn enable a richer parser more tolerant of additions.=C2=A0 But if DJ an o=
thers support the idea of just starting off with a new format, there's =
not much point in touching the existing parser.=C2=A0 I've never fully =
parsed a .pcb and couldn't off the top of my head say whether a given n=
ew format would constitute a superset of the existing one or not, but proba=
bly DJ and others could do so.<div><div><br></div><div>>> > don=
9;t see any reason why not use SQLite.<br>>><br>>> Because many=
, possibly most people aren't familiar with it.=C2=A0 Give<br>>> =
yourself credit for what you've learned about SQL, and acknowledge<br>&=
gt;> that it isn't going to be instantaneous for others to get that<=
br>>> knowledge.<br>><br>> I don't have much knowledge on S=
QL. And I don't really feel that I'm<br>> something special. I j=
ust browsed the gEDA/PCB code and I get a feeling<br>> that life would b=
e much easier if we had that SQL thing as the data<br>> structure.<br>&g=
t;<br>> In the other hand, I don't think the vast majority of users =
actually would<br>> hack an xml. It is pain.<br><br>xml is the most pain=
ful of the plain-text options.</div><div><br>> I see no difference here.=
<br><br>Users do read and parse the existing format, at least partially.<br=
><br>>> There are actually only two reason *to* use SQL.=C2=A0 One is=
parse speed,<br>>> which is not significant for most use cases.<br>&=
gt;> The other is the additional work for you (or someone) to put it in =
a<br>>> readable format.=C2=A0 But its easy work and I hereby<br>>=
> volunteer to do it.<br>><br>> Okay. Don't get me wrong. I do=
n't care if it is SQL, or not. I just state<br>> that if we use SQLi=
te, we pull in lots of work. Your work has a value! I<br>> suggest we co=
ncentrate on the PCB part, and not doing something which is<br>> already=
done.<br>><br>> That is all I say.<br>><br>> BTW, what is your=
recommendation? Would you use xml? Would you roll your own<br>> file fo=
rmat?<br><br>I'd use YAML.=C2=A0 It's far more readable that XML, a=
nd significantly more readable and richer=C2=A0than JSON.=C2=A0 There's=
a parser for every common language.=C2=A0 Personally I have no problem wit=
h SQLite, I really like it in fact.=C2=A0 But I think already a number of p=
eople (Igor, Evan IIRC and at least one other) have said they would prefer =
human-readable.</div><div><br></div><div style=3D"text-align:left">Evan als=
o noted that it's possible to make SQL that can be represented in text,=
but in a mostly useless way.=C2=A0 It would be nice to avoid this effect.=
=C2=A0 In my experience SQL formats have a tendency to grow strange tables =
in all direction at a great rate.=C2=A0 I'm not one to condemn an appro=
ach just because it makes it easier for people to make things confusing.=C2=
=A0 But, the small discipline of staying in sync with, say, a YAML represen=
tation, might not be a bad thing.</div><div><br></div></div><div><br></div>=
</div>
--f46d0438932b79f912051fa6e8e2--
- Raw text -