Mail Archives: geda-user/2015/12/23/17:39:10
--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--
- Raw text -