X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Tue, 5 Jan 2016 15:34:28 -0500 Message-Id: <201601052034.u05KYSuc032326@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: <0254E441-E74C-490E-BFF0-DD0BED19F2B2@noqsi.com> (message from John Doty on Tue, 5 Jan 2016 15:10:34 -0500) Subject: Re: [geda-user] A fileformat library References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com> <20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se> <201601051829 DOT u05IT7TI021027 AT envy DOT delorie DOT com> <0254E441-E74C-490E-BFF0-DD0BED19F2B2 AT noqsi 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 Precedence: bulk > But for gEDA, it's a small overhead relative to everything else, > especially if it allows you to use old-fashioned kilobyte tools > rather than trendy megabyte tools for processing. Schematics have less info in them than layouts, so sure. Layout files tend to grow significantly bigger so the overhead becomes more significant. Until now, we've been letting processing and I/O performance keep up with our bandwidth needs, but the balance might tip at any time. Plus, a more complex data structure makes text-based tools harder to use, as they don't follow the structure with enough context to be reliable. PCB intentionally makes the output file format text-friendly but most scripts which read PCB files *cannot* read "just any" PCB files. As for kilobyte vs megabyte tools, I think you're just making that up - and once again choosing emotionally charged terms where they're totally superfluous. A perl script that imports a yaml library is going to be significantly shorter than a perl script that has to parse a schematic file manually. The benefits depend heavily on the implementation and the functional requirements. > But, at least for me, "diff" is pretty common on schematics. It's > easy to spot attribute and symbol changes in a diff. Diff is also > part of my layout vs schematic checks using Osmond PCB. A simple binary-to-ascii converter is all that's required to support such tasks, much like SQL databases can export to a text file. But, using diff that way could be a crutch to let us defer creating better tools for comparing iterations of designs. If diffing schematic files didn't work, we'd probably have a better schematic-comparison tool by now.