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: by amavisd-new (Uni-Kiel/l2ms-sc)
From: geda AT psjt DOT org (Stephan =?utf-8?Q?B=C3=B6ttcher?=)
To: <geda-user AT delorie DOT com>
Subject: Re: [geda-user] A fileformat library
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG>
	<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>
	<0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com>
	<CAC4O8c_UAiFE-vGfoE2tXppHLhaa0dSYz9o_rkdCBo7_SRRtxw AT mail DOT gmail DOT com>
	<FFBE7623-E240-4798-96B0-2BECF56C8E29 AT noqsi DOT com>
	<CAC4O8c980g1gj15=5njstC_BT-WYDgKQx9BRycdFKA8OvgtiOg AT mail DOT gmail DOT com>
	<B54C0E1F-1986-4C79-9F70-7F1919B8B26D AT noqsi DOT com>
	<CAC4O8c9bxJP1eMG4yz3YwKkQJRmsDGmLQ0aMd5pJRyu0WpdCtQ AT mail DOT gmail DOT com>
	<C1CFCCEE-C64A-4E49-AA64-446C061656D6 AT noqsi DOT com>
	<CAC4O8c-zt8B=joDd+ws77D2jt6aZf3MWfR_dAvpzGcNuBrTURQ AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 11 DOT 1601030040320 DOT 2176 AT newt>
	<D9825C8C-B6FD-4C7F-A8D5-B8AF06253B72 AT noqsi DOT com>
	<CAC4O8c_R5xWLmzj_cz0g0mPWNs6mR4efjXKGBoup8YO6nwnPTA AT mail DOT gmail DOT com>
	<A942261D-7C25-4F2D-9CB1-FFC60FA1C160 AT noqsi DOT com>
	<CAC4O8c8zk8=Py1yX6fVqF+35SYe39Li=y4jZ8bCeZ1Ev8WccAg AT mail DOT gmail DOT com>
	<20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se>
	<8E0210CD-0694-4717-A7B1-3224E39691DA AT sbcglobal DOT net>
	<CAC4O8c8CxyULauKj+1RT73qdLDnPa1_TOAXY_pXnJNPtnNJYqQ AT mail DOT gmail DOT com>
Date: Wed, 06 Jan 2016 11:48:58 +0100
In-Reply-To: <CAC4O8c8CxyULauKj+1RT73qdLDnPa1_TOAXY_pXnJNPtnNJYqQ@mail.gmail.com>
	(Britton Kerin's message of "Tue, 5 Jan 2016 14:52:37 -0900")
Message-ID: <s6nziwjt23p.fsf@falbala.ieap.uni-kiel.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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


"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
<geda-user AT delorie DOT com> writes:

> The big potential down-side to *extending* via (not just supporting)
>  YAML/JSON/SQL, relative to extending the existing format is that tools
> that do partial parse have no chance to continue working unmodified.  This
> sounds worse than it is though.

Those "tools that do partial parse" are awk and sed, and small scripts,
typed day to day fresh on the commandline, or embedded in Makefiles.
Those will adapt to whatever extensions are added to the file
format.  But they must not become non-awk-parsable.

Those "tools that do partial parse" are required to solve problems, or
provide features, that the primary tools do not provide, yet, but which
need solutions now.

E.g., rigid-flex boards.  One of those is right now driving around on
Mars, designed with gaf and pcb.  Other boards in the same box have
complex shapes, with lots of Arcs.  Those where designed with gnumeric,
which yielded a pcb file fragments that were cut&paste into the layout
file.  Like this one:
http://www.ieap.uni-kiel.de/et/people/stephan/msl/eda/RADE/RADE-silk.png

This kind of accessibility to the file format is what keeps me using gaf
and pcb.  The tools will never do all what I need natively, when I need
it.


An nice addition/alternative to accessible file formats is discoverable
scripting in the layout tool.

I once used that with Silicon Explorer for an ASIC.  The layout tool had
a window that logs every modification of the layout in form of script
commands.

I cut&paste those logs into a big script that did the complete ASIC
from scratch.  When I changed the Verilog source and typed 'make all',
the whole design flow would run automatically.  Simulation, sythesis,
simulation, layout, place and route, drc, lvs, simulation.  This worked
because there was not much that needed to be drawn by hand, and because
the scriping/syntax was very discoverable.

Does pcb scripting support drawing a line between to points?  There may
be a lot that can be done with scripts in PCB.  But it is certainly not
discoverable, and from what I read from the manual, once I found it,
it is not complete.  You cannot :ExecuteFile() a script into an empty
layout and get a finshed board, can you?   If you could, that script
would be a file format for layouts.  Next, I'd ask for an export hid to
write such scripts.

If the current file format is extended by adding layer fields to all
objects, those object stanzas become script commands:

 Line["signal2" 119.6929mm 101.0041mm 4757.60mil 102.9959mm 0.2500mm 0.5000mm "clearline"]

Add layer fields to Via to support blind/burried vias.

The layer fields in the objects inside an Element support: text on silk,
boards with more than two outer layers, ...

This might need to be complemeted with another syntax/indirection level
for specifying layers.

  "flextop", "flextop:silk", "flextop:mask", "flextop:paste", "flextop:outline"

The data model becomes more othogonal, no restrictions what can be drawn where.

Step 1. teach PCB to read this format within scripts.  Throw Errors when
something is drawn where the current data model does not allow.

Step 1b: allow this format in layout files.

Step 2. teach PCB to write this format.

Steps 3...: change the internal data model to support more and more of cases. 

-- 
Stephan