X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Scanned: Debian amavisd-new at papyrus.altaweb.hu
Date: Sun, 13 Sep 2015 23:12:13 +0200
From: "Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Apollon
Message-ID: <20150913231213.0a829971@jive.levalinux.org>
In-Reply-To: <CAC4O8c_rSibSjCuWv6KaCBTFkjAumCtCub+kpwAi2rEGcOjxFw@mail.gmail.com>
References: <20150913140631 DOT 1da1b78d AT jive DOT levalinux DOT org>
	<CAC4O8c_WSck-z2V+iQRZY5HJf2WOu6=ozRpmo6zFGUf5r6DjMA AT mail DOT gmail DOT com>
	<20150913190132 DOT 1926c471 AT jive DOT levalinux DOT org>
	<CAC4O8c-99=qdVrz_-sOLAcr+JGemWf3Gp1NoZzsthG-i8F7vNQ AT mail DOT gmail DOT com>
	<20150913204337 DOT 1e58475a AT jive DOT levalinux DOT org>
	<CAC4O8c_rSibSjCuWv6KaCBTFkjAumCtCub+kpwAi2rEGcOjxFw AT mail DOT gmail DOT com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; amd64-portbld-freebsd10.1)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id t8DLCLJT029568
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

On Sun, 13 Sep 2015 12:36:48 -0800
"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
<geda-user AT delorie DOT com> wrote:


> 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 see it in the opposite direction. People saw/edited the pcb file, because
they had to. I still don't know how to edit the clearance of a pad (of
an existing footprint) in the GUI. I edited the file by hand, and then I
wrote a script.

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

Let's create some roadmap. Where shall we go, what shell we do. You are right.
I don't want to spend time on something which end up unused.

> xml is the most painful of the plain-text options.

Yes.

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

Unfortunately, we can't please everyone. We just can't. There were lots of
attempts to change the data structure. A change always bring in some pain.

However, no pain, no gain! And I hope that at the end of the day, everyone
will be satisfied with the result!
 
> 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.

Okay. Let us make it SQLite and YAML. That will add some overhead, but I think
the heavy lifting is the data structure redesign in pcb.

Lev

-- 
73 de HA5OGL
Op.: Levente