X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20151223194905.7676.qmail@stuge.se>
Date: Wed, 23 Dec 2015 20:49:05 +0100
From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] A fileformat library
Mail-Followup-To: geda-user AT delorie DOT com
References: <s6n37uumanm DOT fsf AT blaulicht DOT dmz DOT brux> <CAJXU7q_qxdvJaejF-VcY=u7VHZ-zrfrc+Z7-qSwfFyPdy-umxw AT mail DOT gmail DOT com> <B02363CD-469D-493A-AC15-1D5DC7836982 AT noqsi DOT com> <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <CAM2RGhTficnys3a4xs=UBFvk8aPwpzYWUADFLP_pUQ+R1iKs0g AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512230552520 DOT 9035 AT igor2priv> <FC796A30-DF21-42E0-89D4-48F3C202BCAE AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512230648180 DOT 9035 AT igor2priv> <A6BF931F-181E-4B69-8B3E-E1BD202DE7C5 AT noqsi DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <s6n7fk51453.fsf@blaulicht.dmz.brux> <A6BF931F-181E-4B69-8B3E-E1BD202DE7C5@noqsi.com>
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

John Doty wrote:
> is it *really* so hard to write a parser for the .sch format?

It's harder than it needs to be for some tasks.


> Seems pretty trivial to me. Easier than figuring out what an
> extra layer is actually doing and wrapping it in yet another
> layer to support what *I* need.

I call bullshit here. You are making general comments about a
hypothetical piece of software. Let's save this discussion for
whenever there is something concrete.


Stephan Böttcher wrote:
> What I value most in both the gschem and pcb file formats is that
> they are easily AWK parsable, so that simple ad-hoc commandline
> scripts can cover deficiencies of the tools.

Sorry, but I think that's very poor practice, and I think we can do a
lot better.


The way that I see the file format thing playing out is most certainly
with an internal (*not* turing-complete) data format which is "owned"
by a C software library.

The library will hopefully have bindings in lots of different languages,
all your favorite languages, and I see the library being used directly
and indirectly through bindings both by GUI applications and a new
commandline tool which has several different plugins to output
various machine-readable formats on stdout - so that all existing
workflows not only continue to work, but have much easier access to
the data.


> For example, rigid-flex boards with more than two outer layers are
> handled with a little awk postprocessing of the pcb file before Gerber
> export.  The awk code is embedded in the Makefile.

This is something that I think should be maintained within the gEDA
project rather than just within your Makefile. I actually want to
make a rigid-flex board too! :)


> This kind of ad-hoc scripting relies on the whitespace/newline
> placement that the tools write.

Having "relies on the whitespace" in your workflow is IMO a clear
sign that something is awfully wrong. :\

It's 2015 going on 2016 and we can do a whole lot better than that.

Don't worry, I'm not interesting in breaking any of your workflows,
I'm interesting in enhancing them with benefit for all.


> I have used gnumeric spreadsheets to generate pcb file fragments
> for complicated circular board outlines, hole and connector placements.

Then you could easily add a tool to this pipeline which takes an old
or new well-defined text format on stdin and outputs the native format.


> Emacs is regularly used to edit layout and schematics files, especially
> footprints.

I make all footprints by hand and think to myself what an utter waste
of time it is with every single one! :)

A dxf->fp converter would make sense, so that a decent CAD tool could
be used to draw footprints, as long as one stays with some simple rules.


//Peter