X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: karl AT aspodata DOT se To: geda-user AT delorie DOT com Subject: Re: [geda-user] A fileformat library In-reply-to: <6C2FA19B-9B5C-4F6E-841C-4C3031BF9D2D@noqsi.com> 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> <20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se> <6C2FA19B-9B5C-4F6E-841C-4C3031BF9D2D AT noqsi DOT com> Comments: In-reply-to John Doty message dated "Wed, 06 Jan 2016 07:36:18 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <20160106133050.C4148809D79C@turkos.aspodata.se> Date: Wed, 6 Jan 2016 14:30:50 +0100 (CET) X-Virus-Scanned: ClamAV using ClamSMTP 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 John Doty: > On Jan 6, 2016, at 4:58 AM, Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > > You can have any difftool for git, so you can do visual diffs or > > anything what you want, independent of the file format. (as of > > today, we HAVE visual diff for PCB) > And then what do you do with a broken file, with a little bit of garbled > data in it? Text is more robust. Ack. > > You can write your own script in whatever language, as long as it > > has bindings for the file format, > But that's more work. > > which is the case. > Not for every language. Certainly not for every text utility. Until someone writes that library and provides all bindings, isn't this discussion moot ? > > When selecting a file format I would not have such constraints like > > "it should be pretty for a human eye". > Not pretty, but comprehensible without processing. But then, it is ofther easier to understand things that is nicely formatted. > > CAD data is so complex, that one can (and I believe should not) parse > > them with naked eye. For a computer, binary is much more efficient. > It's more efficient until something breaks (and something always breaks). ... Step is for complex cad data, and it is a text format, so your claim is not fully valid. > It's more efficient if you never want to use text-oriented tools, > but for files with lots of text data, like attributes and file > names, I generally want to use text tools to solve some problems. > There are thousands of tiny problems that you can efficiently address > in this way. It is not efficient when debugging, and even if you have binary data, you have to validate it, don't accept data at face value. ... > > If file format changes, you have to just change one code, and not 50+. > Not true, because the only sane reason to change the format is to > change something in the semantics. That means that your common > parser's API will have to change, and everything that uses it will > have to accommodate that change. ... Ack. Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57