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>

<20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se> <20160106133049 DOT 5A0E9809D79B AT turkos DOT aspodata DOT se> <20160106143629 DOT 4D39D809D79B AT turkos DOT aspodata DOT se> <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> <568F9A18 DOT 2080007 AT iee DOT org> From: "Sabin Iacob (iacobs AT m0n5t3r DOT info) [via 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> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KSBTB5WhmRB8BtootBMKng67DUkdaDBCw" 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 Precedence: bulk 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 >> ) [via 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 ]" >> > 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--