Mail Archives: geda-user/2015/09/13/17:12:25
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
- Raw text -