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=simple; d=mail.ud03.udmedia.de; h=
	subject:to:references:from:message-id:date:mime-version
	:in-reply-to:content-type:content-transfer-encoding; s=beta; bh=
	Xd6uJjOaMcMYDWxBbvlKVEey0hcacy+eESqKS6kHn9M=; b=fjRsq1wiV7e5Ncs/
	mBauFAReBd9HJgVndIep0nv23IqxftmM/UzzgeVXodRW1V32yKWief0urCRY45mI
	MDnL6BUdddsCirOAe8q76iLFeNK/dU9kFVJe7rNS6q0XiF705NPU0FhEXQBH0ZdY
	WdS+G2R5Q/FGb3mP61fOvlhIY+g=
Subject: Re: [geda-user] shortest way towards parsing .pcb files outside pcb
To: geda-user AT delorie DOT com
References: <CAC4O8c_XFEAgyrokrwwavB0C+OjWXCB5xptkVwMx2i_t960qFg AT mail DOT gmail DOT com>
From: "Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID: <55F3FD8F.4090709@jump-ing.de>
Date: Sat, 12 Sep 2015 12:25:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAC4O8c_XFEAgyrokrwwavB0C+OjWXCB5xptkVwMx2i_t960qFg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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

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
two storages which have to be kept in sync are certainly not a good idea.

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
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
ask: partitioning of xorn code looks good, usage of plain C would be an
advantage.


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/