Mail Archives: geda-user/2015/12/23/16:52:13
--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] <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--
- Raw text -