delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/08/08:37:58

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=m0n5t3r.info; s=m0n5t3r;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-type;
bh=0/eZxeJ4HO9Cnwez77cR8jnRWb1p/oZA+pUWMKHn2pY=;
b=CY9G1SzpnVfBY6BMgHWO3s47lBYZt5z3hahMBAtiR2FS/blAuq/i8N7AZ+6oImpRKC
zgPI+rgOTMg5An9y5KKO+/f7VVFK5XBxBxFlwpPmQB64TxjfJ1fBwWAC+Wlf4eiL4goK
uhClh1aI+sCqgiFnLeBOv7EK0kI7J1YnASJnk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-type;
bh=0/eZxeJ4HO9Cnwez77cR8jnRWb1p/oZA+pUWMKHn2pY=;
b=VVWqAYksJ7GLAMQTgHTvPoMR7ibHSvyxGSjqaKahISDlVDbqxK1+8JfK+8HSABiHEt
cyhZ38/hRkSoBjlUwnHw0llJuXRQ7CX+5i1ATE+/buGz560H88CrjCAYThd8/JxsQqKJ
UZ0Ad0B5gIF9klACGyYlf2eb+b6owRrFZqMwkWVY6ZixrjnWeZMLLdgeKznn3Bxox0si
VWWN21dw52lr+jjCVf4ZLBmWb4H8wxGSKpHZuiR8FUnb2FanS9f0q3LT5qCPQuOrgaun
07tYs3J00Uj3Vu50ZKZm5+WBbGIHXERAgAiEgCU5R2fxxFocQ2azxf//QQ2K/zFxsR25
6hyg==
X-Gm-Message-State: ALoCoQkYAOk922zCtbmAalLA3CZFqt8CDoFF3qgp5xfxw2luDb444h75mN5eWijVIHt/MVuPUQwC4fDsNcMHdCCayCeiOlXQ3A==
X-Received: by 10.28.140.201 with SMTP id o192mr24226696wmd.88.1452260264663;
Fri, 08 Jan 2016 05:37:44 -0800 (PST)
Subject: Re: [geda-user] (SQL file open/save)
To: geda-user AT delorie DOT com
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
<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>
<CAC4O8c9cun6X69Lt_nY0HDNF59b9GADdwEQiFp7p9bU7uz=SoA AT mail DOT gmail DOT com>
<568F9A18 DOT 2080007 AT iee DOT org>
From: "Sabin Iacob (iacobs AT m0n5t3r DOT info) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Enigmail-Draft-Status: N1110
Message-ID: <568FBBA6.8050808@m0n5t3r.info>
Date: Fri, 8 Jan 2016 15:37:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <568F9A18.2080007@iee.org>
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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--KSBTB5WhmRB8BtootBMKng67DUkdaDBCw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 01/08/2016 01:14 PM, M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via
geda-user AT delorie DOT com] wrote:
> 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!

there are features some people miss and it seems the file format will at
least need extending

> 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.
>

(sorry, I got too delete-happy and deleted Britton's mail before
managing to respond)

> 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


well, they are sets of points (pins/pads) connected by edges (traces),
so they are graphs if you squint really hard :)


>> =20
>>
>>     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.=20


my biggest concern here is having to maintain an ORM and dealing with
migrations / schema changes, which is complicated even for a centralised
thing like a web application; I imagine telling random people to open a
terminal and run some alter table because they can't open their designs
any more won't go down too well (it's either this, or coming up with a
set tools to do this for them and account for all possible ways things
could fail)


>> =20
>>
>>     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.


multi-line text fields and the way I never know how much to indent
something kill yaml for me; references could have some value if you
intend to embed footprints in the file and have a way to explicitly
point to them, but we refer to footprints by name anyway, so they can be
inferred while constructing the thing in memory

yes, json is noisier, but it has explicit delimiters and can be mapped
easily to simple in-memory structures (hashes and lists, or even
s-expressions... speaking of which, does anyone know how well
s-espressions work for kicad? I find the idea intriguing)


>> =20
>>
>>     (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


not really, the main argument was that it's tiny and very embeddable
and, if asked nicely, promised to only parse literals and not execute cod=
e


>> =20
>>
>>     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.
>> =20
>>
>>     * decide on syntax, write formal grammar; this is where you take i=
nto
>>     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.


after looking at the state of the art some more I'm not so sure any more
about how easy the last one would be, because the tool with the largest
language support is ANTLR 3; maybe if language-specific libraries are a
built separately it would be viable, though

however, a formal grammar might be useful anyway if we don't choose a
separate, for documentation purposes if nothing else.


>> =20
>>
>>     problem solved, you get canonical parsers for all languages that a=
re
>>     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


some people are expert in one or two or more scripting languages, but
not so much in C; I think the main argument would be that they can
inspect the guts of their tools easily (for instance, Python C
extensions feel very much like black boxes to me, I have to either dig
up the C source, or rely on whatever documentation I can find for them;
with native libs I can always do thing?? in ipython, see the source code
and understand what happened without any apt-get source blah blah or web
searches)


--KSBTB5WhmRB8BtootBMKng67DUkdaDBCw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWj7umAAoJEIIekQf3ltoLDHEQAIUWA1L0ydibC8LQkljifpC0
zWoCmvYchCcuQIc3TifCQ5BalxIdDyDtpqxAggDTjyl00pXTEWCzg0fS6wn3E0D4
MXICnHf8QJ9w4EkUG0Xx+xFQSkKh8WqtQg7dPFDEgPqxKpvDovkhAY9UjdlDwJZf
P6WUoHi1LZVuKPYpfUDHGSdcLMe6HV6NIdO/Ad9H13zAMoJM4O3AKepCGrqUWxYo
ssvgwTiCFF5mc6EAqVsdvLL4JXKi5uc4imbQNMIdakhk4MvJDALq1A6wj3zR9k5C
QmQWb3S2MpNmn+ruFP1XahgnCMs1EX0SYi19t9v1/cDY2FXtu4fvIBjHOkXLpl2e
iLXbvq/pIgED7acYJsA6xnl4XLRdHHubMwrxVY7JHfcZS+E/Dprcz7kYd8cv8vus
uOEsCSNl3mStMIyRQgNln3jTAG273tBcwsXMPrCl1rPI0oM4hsShfEmKsZXSQ302
CfT5/v7IzO1mUKc4f9TdC2QEdRiWobpRXnUppAvkP743Itn7GwmPzX9JRWFXz/5B
kpCa1qiwn4a3gpnpx0b6uf5m8Kt3n9Rwjr5SX2JgmUvjiPzE77Wn3NCT/pY+K2el
HATrUmzPGpDft3ToYF1A7n4Fn41I1T6nfUoSeEA+G6zvSHDcS3bUtOvx8TJ7koN1
PxdESB2Apql1f9gJ4X3e
=NhBr
-----END PGP SIGNATURE-----

--KSBTB5WhmRB8BtootBMKng67DUkdaDBCw--

- Raw text -


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