Mail Archives: geda-user/2016/01/08/08:37:58
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 -