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: <55F3FD8F DOT 4090709 AT jump-ing DOT de> Date: Sat, 12 Sep 2015 13:11:17 -0800 Message-ID: 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]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 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 On Sat, Sep 12, 2015 at 2:25 AM, Markus Hitter (mah AT jump-ing DOT de) [via 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.