X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: multipart/signed; boundary="Apple-Mail=_93E46E0C-8AD0-428F-A880-B926343F2AB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [geda-user] A fileformat library X-Pgp-Agent: GPGMail 2.5.2 From: John Doty In-Reply-To: <20151223194905.7676.qmail@stuge.se> Date: Wed, 23 Dec 2015 14:51:26 -0700 Message-Id: <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0@noqsi.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> To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) 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 --Apple-Mail=_93E46E0C-8AD0-428F-A880-B926343F2AB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 23, 2015, at 12:49 PM, Peter Stuge (peter AT stuge DOT se) [via = geda-user AT delorie DOT com] wrote: > John Doty wrote: >> is it *really* so hard to write a parser for the .sch format? >=20 > It's harder than it needs to be for some tasks. >=20 >=20 >> Seems pretty trivial to me. Easier than figuring out what an >> extra layer is actually doing and wrapping it in yet another >> layer to support what *I* need. >=20 > I call bullshit here. You are making general comments about a > hypothetical piece of software. Let's save this discussion for > whenever there is something concrete. >=20 >=20 > Stephan B=F6ttcher wrote: >> What I value most in both the gschem and pcb file formats is that >> they are easily AWK parsable, so that simple ad-hoc commandline >> scripts can cover deficiencies of the tools. >=20 > Sorry, but I think that's very poor practice, I disagree. I think that having a file format that enables simple means = to achieve simple (but specialized) ends is essential to a good toolkit. = I would, however, disagree that this is =93covering deficiencies=94. I = don=92t expect a tool to do everything I need. It=92s designer generally = doesn=92t know what I need. I expect a tool to cover the basics, and I = love it when the toolkit design allows me to easily cover the special = stuff I need. > and I think we can do a > lot better. >=20 >=20 > 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. Ugh. You lock us into C. >=20 > The library will hopefully have bindings in lots of different = languages, 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? In = general, it looks like two extra layers of obfuscation to me. Of course, = for a specific job, in the box that the developer imagined, it might be = nice. But often, if you=92re a user extending the kit to solve your = special problem, you=92re out of the box. Gnetlist is a fine example. If you=92re writing a flat netlister for = printed circuit layout it=92s easy. But as you move away from that it = gets harder until eventually you need something else. > all your favorite languages, and I see the library being used directly > and indirectly through bindings both by GUI applications and a new > commandline tool which has several different plugins to output > various machine-readable formats on stdout - so that all existing > workflows not only continue to work, but have much easier access to > the data. >=20 >=20 >> For example, rigid-flex boards with more than two outer layers are >> handled with a little awk postprocessing of the pcb file before = Gerber >> export. The awk code is embedded in the Makefile. >=20 > This is something that I think should be maintained within the gEDA > project rather than just within your Makefile. I actually want to > make a rigid-flex board too! :) >=20 >=20 >> 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. :\ No, it=92s a classic UNIX convention with clear thinking behind it. It = works well for us. >=20 > It's 2015 going on 2016 and we can do a whole lot better than that. Not and continue to present the user with UNIX-level flexibility. You=92d = wind up with developers in control rather than users. >=20 > Don't worry, I'm not interesting in breaking any of your workflows, > I'm interesting in enhancing them with benefit for all. But to do that in the style you want, you have to understand my = workflows. Including future ones I haven=92t adopted yet. >=20 >=20 >> I have used gnumeric spreadsheets to generate pcb file fragments >> for complicated circular board outlines, hole and connector = placements. >=20 > 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. You could, but what would be gained? When NeXT replaced the UNIX admin flatfiles with netinfo, it was = supposed to be possible to continue to use old scripts: just nidimp, = process, niload. Except, once they had a new storage scheme, they didn=92t= have the discipline to define the representation of new kinds of = relations in flatfiles, so things broke. If a pretty big company with a = full time professional staff couldn=92t come up with the necessary = discipline (and a similar thing happened at SUN), how can a small = project like ours do so? Just keep the format transparent. >=20 >=20 >> Emacs is regularly used to edit layout and schematics files, = especially >> footprints. >=20 > I make all footprints by hand and think to myself what an utter waste > of time it is with every single one! :) That=92s what transparent formats are for: to enable you to automate or = work by hand, whichever is easier. >=20 > A dxf->fp converter would make sense, so that a decent CAD tool could > be used to draw footprints, as long as one stays with some simple = rules. >=20 >=20 > //Peter >=20 John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail=_93E46E0C-8AD0-428F-A880-B926343F2AB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWexdfAAoJEF1Aj/0UKykRO7AP/3C24LiS/c6c0qMI0pfr6OsU 18npYiUn+Ic6iCCckt0DkI+tNvTHZFDtpD4gVubVZ7NhEEemg0ePlPod60i8Onfn Va91/NYPWPSQfsuDuvC8hMK3mTNw3yn8SvH6WjnO4SsD2IWYJvFdYFlUIA+0EO53 kT6bfkcWWx47NC3wOWcz9GZB9WFf3Tudi4lpxMwi7d1/cBFBrNY1J34VIQ8lDeQK u0PZROtahG/dUlHYlWtkUpnK1Lapfagh5evhlocLFDp9q1ArviT/mcEiWCb2969m dlGNCFEZvMqMR8FVDU2UesZ4qBx27ap57FMDI7tXxD62cnwtqB/eocEqkj6AM1dD jkbeZUxaNxaGZ4XCX57cf0eTPvLYJIC+cS7jcbHNQQyHPPgZwwxUIsUUYzliU23/ HwLnXx57Q4X9JzbXgUetN27Rk00/RKHrRiGRlbkboLewyjpza5aGmQdZot7YnXA7 5D+67SgtwolwHKvk7KJfCxdt/tK+v8DNGldoSj8ewpojrezltzfDJJ1JApKH+FQI 2iaPqrmC5kSiZJAogEBj2KcNu8xtcK2OmHXFxEsiy7S4qNxSaGU7EsDxtizeb+i3 LicKTPu+BY1URh1UYNb4boWZ/TnQBN+WNAIrmevOE7XHYdQk53OEJ0zuRv/Oz2lT 2BAlhdsnRZktUts9WeyK =UEdN -----END PGP SIGNATURE----- --Apple-Mail=_93E46E0C-8AD0-428F-A880-B926343F2AB4--