delorie.com/archives/browse.cgi | search |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |