X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=SCoKqdMAtIUtg/nsTkkbc7CF18WdzDQ+jbySihG9wRg=;
	b=DDQj2MppXjEBYrhdKXLXCXDHRxAf4v8kOHkX7gwtyscbSr+zWP/ID1GY9EgzP7q67H
	+teHgAxj/FxLG6FvkHKWBfwzHRwQzSo5pv+X/nYHX61eKgj14pNq0gESmcFAi8R/oSjc
	OjyaNyDpg+u9kv+sgZ2W5Lv6C7zojD6kApg9Qa8abzZNpDkDKHlsAQPLOaJrcB9hwuBh
	efpxM2UT5GkByKV8vFxsBXqlzdOLgrEGQuPc/CnUvYkJ+D40o3e8AtaDqJcbQyfguSpu
	Lnx6FRNJae7D2Tc41KzHT6YqHg0XTuq8XbN2avC5tVwMZfiBPNQea/Am+HVfhPPE9vUy
	gAlw==
MIME-Version:	1.0
X-Received:	by 10.180.87.6 with SMTP id t6mr1533877wiz.20.1442092277973; Sat,
	12 Sep 2015 14:11:17 -0700 (PDT)
In-Reply-To:	<55F3FD8F.4090709@jump-ing.de>
References:	<CAC4O8c_XFEAgyrokrwwavB0C+OjWXCB5xptkVwMx2i_t960qFg AT mail DOT gmail DOT com>
	<55F3FD8F DOT 4090709 AT jump-ing DOT de>
Date:	Sat, 12 Sep 2015 13:11:17 -0800
Message-ID:	<CAC4O8c8-Tzm1C=av11BswKC=hAtqvT=OnkZ6hEAmwL9VDjgjdA@mail.gmail.com>
Subject:	Re: [geda-user] shortest way towards parsing .pcb files outside pcb
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT 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

On Sat, Sep 12, 2015 at 2:25 AM, Markus Hitter (mah AT jump-ing DOT de) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> Am 12.09.2015 um 04:29 schrieb Britton Kerin (britton DOT kerin AT gmail DOT com)
> [via geda-user AT delorie DOT com]:
>> Speaking of the parser, I think the easiest way to get an accessible
>> version of it would be
>> to add a structure that corresponds one-to-one with what goes in a .pcb file.
>> The parser could load stuff into that.  The current  "PCBType"
>> structure (really a sort of global application context) could be
>> filled in from that structure, rather than incrementally during the
>> parse.
>> Would this offend anyone?
>
> No offense, of course.  But then it's hard to see the advantage, because
> what you write here pretty much duplicates what's already there. Having

We would indeed have a similar data struction to what's already there
(specifically it would be similar to PCBType).

> two storages which have to be kept in sync are certainly not a good idea.

I would not keep the new type alive for any amount of time in pcb itself.

> A more worthwhile goal might be to /replace/ pcbs current storage and
> storage handling. Code which fits into a library and is used by pcb as

This is what I (and I think Lev) have in mind.  Or at least I have part of this
in mind.

> well as by other layout handling applications. Certainly not a trivial
> task, but it could help greatly to de-obfuscate pcbs code. In case you'd

There are potentially several steps to this.

  1.  Make a new structure PCBFile or so with 1-1 correspondence to
       the contents of a .pcb file.

  2.  Have a method PCBType * pcb_file_convert (PCBFile **) or so
       which would transfer everything to be owned by a PCBType,
       getting things to the state they are now after a parse in pcb.
       Presumably similar approach for save.

  3.  Refactor all the rest of pcb to somehow use structures that don't
      mix together board data, settings, rtrees, etc.

1 and 2 are relatively easy.  Number 3 huge difficult task that I
don't propose to
undertake now at least.

The advantage of this breakdown is we would get a type that corresponds
to the PCBFile (i.e. to what actually gets stored for a given board, without
settings mixed in).  This would be convenient for any approach that wants
to re-use the existing parser.  It would be a step towards 3 in that it would
disentangle one part of the many things currently munged together in PCBType.

The disadvantage is one additional type.

- Raw text -