X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 6 Jan 2016 12:46:28 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] A fileformat library
In-Reply-To: <s6nziwjt23p.fsf@falbala.ieap.uni-kiel.de>
Message-ID: <alpine.DEB.2.00.1601061228131.9035@igor2priv>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <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> <s6nziwjt23p DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-736034488-1452080788=:9035"
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-736034488-1452080788=:9035
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Wed, 6 Jan 2016, Stephan B=C3=B6ttcher wrote:

>
> "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.  Th=
is
>> 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

Nice!

Btw, in pcb-rnd my policy is to keep formats awk parsable. If mainline=20
switches to sql or other binaries, pcb-rnd will become incompatible=20
(or compatible with external converters only) instead of implementing it.

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

+1

<snip>

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

I am not sure about pcb's action script. pcb-rnd's gpmi plugin has a=20
package that lets scripts (awk, perl, scheme, etc.) access design data in=
=20
memory. Scripts can search/list objects, delete/move/change existing=20
objects or create new objects (arc, via and line for now). This can also=20
work in the way you described: draw something from scratch on an empty=20
design.

The other direction, converting an existing design into a set of draw=20
commands in one-of-the-10-scripting-languages doesn't exist. It wouldn't=20
be veryhard to make it, but I am reluctant about moving design data from a=
=20
pure data format to a script format.

>
> 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.500=
0mm "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:out=
line"
>
> 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 ca=
ses.

I think this is a common misunderstanding. The reason PCB doesn't support=
=20
burried/blind via is like 5% file format and 95% all-internal-code-in-pcb.=
=20
(The 5-95 split is an educated guess, not a fact, but I believe it's not=20
far from reality). The 95% includes everything from find.c and DRC to=20
export HIDs and GUI HIDs.

If we want blind/burried vias, we'll need to find how it is to be=20
represented in a save file eventually, but the bulk of the work won't be=20
around that part.

Regards,

Igor2
--0-736034488-1452080788=:9035--