X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <20151223223853.20197.qmail@stuge.se> Date: Wed, 23 Dec 2015 23:38:53 +0100 From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] A fileformat library Mail-Followup-To: geda-user AT delorie DOT com References: <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com>

<20151223194905 DOT 7676 DOT qmail AT stuge DOT se> <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0 AT noqsi DOT com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0k4Rxg87Lb8yV0u3" Content-Disposition: inline In-Reply-To: <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0@noqsi.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 --0k4Rxg87Lb8yV0u3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John Doty wrote: > I don=E2=80=99t expect a tool to do everything I need. Of course. Enabling integration is very important. But robust, future-proof integration doesn't come from relying on a moving target such as a file format, but from relying on a more stable target intended specifically for integration. > > The way that I see the file format thing playing out is most certainly > > with an internal (*not* turing-complete) data format which is "owned" > > by a C software library. >=20 > Ugh. You lock us into C. No, to what a C program could do, which is pretty much anything. > > The library will hopefully have bindings in lots of different > > languages, >=20 > So the user has to penetrate how an FFI maps a C mapping of a text > file into their language. How does this make life easier, exactly? Text files aren't great for representing structure. The more generic the atoms are, the more structure is neccessary to have a meaningful result. PCB doesn't have very generic atoms and as such can get away with fairly little/simple structure on disk, which can be represented all right in text files. Moving towards more generic atoms (which you and I both welcome) means that more structure will be neccessary, and then a text format just isn't so great anymore. > In general, it looks like two extra layers of obfuscation to me. I guess you might be jaded by a lifetime of poor abstractions. :\ Good abstractions are possible too! They do not obfuscate, but adapt and enable, making it easier for you to do the job you want to do. > if you=E2=80=99re a user extending the kit to solve your special problem, > you=E2=80=99re out of the box. You shouldn't knock it until you've tried it. I think that we as a community can do really well creating at least one and maybe several plugins for a tool that is specifically intended for interchange. > >> This kind of ad-hoc scripting relies on the whitespace/newline > >> placement that the tools write. > >=20 > > Having "relies on the whitespace" in your workflow is IMO a clear > > sign that something is awfully wrong. :\ >=20 > No, it=E2=80=99s a classic UNIX convention with clear thinking behind it. I'm not talking about newlines, but about whitespace in general. > It works well for us. Until it doesn't. I have written plenty of text processing software. > > It's 2015 going on 2016 and we can do a whole lot better than that. >=20 > Not and continue to present the user with UNIX-level flexibility. Sure we can. > > Don't worry, I'm not interesting in breaking any of your workflows, > > I'm interesting in enhancing them with benefit for all. >=20 > But to do that in the style you want, you have to understand my > workflows. I just have to make sure that there are well-defined interfaces for interchange. They can be text based. I expect there to be at least one plugin for the traditional format(s), so that everything possible today remains possible in the future, but also with new possibilities allowing to do the same things as before and more, easier, for those who want - without unneccessarily breaking backwards compatibility. > > Then you could easily add a tool to this pipeline which takes an old > > or new well-defined text format on stdin and outputs the native format. >=20 > You could, but what would be gained? An open EDA standard, which as Peter C pointed out is important to make the most of the scarce developer resources in our domain. > they didn=E2=80=99t have the discipline to define the representation of n= ew > kinds of relations in flatfiles, so things broke. Yes, the text format will also need to evolve. The responsibility for that lies with those with an interest in using it. It's also perfectly fine for you to stay with the older version, or even to create a fork. > If a pretty big company with a full time professional staff Heh, let's just say that I have experience with some Sun employees, and I wouldn't compare such a team with an open source team. > how can a small project like ours do so? Through your contributions. Rest assured, noone will do it for you. > Just keep the format transparent. Interchange interfaces absolutely. Disk formats I don't think that is worth the effort. > > I make all footprints by hand and think to myself what an utter waste > > of time it is with every single one! :) >=20 > That=E2=80=99s what transparent formats are for: to enable you to automat= e or > work by hand, whichever is easier. Work by hand is never easier when the format isn't made for humans. Neither gschem nor PCB file formats are made for humans. A text format is not automatically human writable just because it is human readable. //Peter --0k4Rxg87Lb8yV0u3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFWeyJ9hR3Q0dhIfEgRAkMhAJ0ZGkT43bz6StMgPyU0OOVHKajrYACaA6Mx MP1wgmlp+f5TPNhyEwPrbUg= =mpg+ -----END PGP SIGNATURE----- --0k4Rxg87Lb8yV0u3--