Mail Archives: geda-user/2015/12/28/23:59:58
--Apple-Mail=_38DE8373-FBD7-4804-9975-EA3B445DA42E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 28, 2015, at 8:29 PM, gedau AT igor2 DOT repo DOT hu wrote:
>=20
>=20
> On Mon, 28 Dec 2015, John Doty wrote:
>=20
>>=20
>> On Dec 28, 2015, at 11:53 AM, Marvin Dickens (mpdickens AT gmail DOT com) =
[via
>> geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>=20
>> Currently, badly needed development rarely occurs because those
>> people who are capable do not contribute because they are put off
>> by a few users who want NOTHING to change because it does not
>> fit their personal work flow.
>>=20
>>=20
>> There are really two projects here: The original gEDA (now =
confusingly
>> called geda-gaf), and pcb. I think everyone agrees that pcb needs a =
lot of
>> work. On the other hand, geda-gaf is matiure, effective, and easy to =
extend
>=20
> I know this will not be productive or encouraging, but...
>=20
> For a long time I was hacking PCB's source and did not check geda-gaf =
sources. You led me believe geda-gaf sources are much better organized, =
and the code much better designed than PCBs.
>=20
> When I worked on back annotation, I finally had to add some code in =
gschem and libgeda.
I think adding code to libgeda is =93fighting the paradigm=94, a last =
resort when a new tool or script can=92t do the job. Annotation is a =
separate operation from schematic drawing and deserves a separate tool.
> It was a big dissapointment. PCB code has its own shortcomings too, =
but gschem is far from being perfect either. If you ask me, _both_ need =
a lot of work.
I very rarely find that I can=92t encode what I need in a .sch file, =
even things way outside the box like makefiles. But pcb can=92t even =
*represent* simple things like blind vias.
>=20
>> with scripting. Pcb development requires a great deal of =
collaboration.
>> Geda-gaf development mostly does not, as anybody can write and =
publish a
>> script.
>=20
> False. I am coding/maintaining pcb-rnd alone and it does work - in the =
sense that I do get the features and bugfixes I wanted to have. When I =
did the back annotation's gschem part, things went much slower. If i had =
to pick, I'd say pcb is easier to hack alone than gschem.
>=20
> As you don't code PCB and you don't even use it, I don't think you are =
in a good position in comparing them like that. You can, of course, just =
noone should take your words seriously.
>=20
>> There would be much less controversy if these projects were =
separated. They
>> represent radically different development patterns: conflating them =
causes
>> much confusion and strife.
>=20
> As an user of _both_ gschem and pcb, as a programmer who has alreay =
hacked both code, I beg to differ. The projects are separate enough.
>=20
> Admitting that a very common (if not the most common) flow is =
gschem->pcb is not a bad thing.
I don=92t disagree. I just want to keep them separate.
> Even if you will write at least 20 mails a month about that your flow =
does not include PCB.
>=20
> Having some scripts and tools for this flow is not any worse than =
having tools an scripts for other flows.
>=20
> Having a common mailing list or homepage or other infrastructure is =
not harmful either. Anyone can use gschem without pcb and can use pcb =
without gschem. It's only you who try to change PCB-related traffic
I often can=92t tell what the author intends.
> into "don't change gschem" threads. Other than this it's usually =
pretty clear when we are talking about gschem or pcb.
>=20
> About how perfect gschem is=85
It=92s not perfect. But it=92s capable and flexible when you use its =
capabilities rather than fighting it.
>=20
> My personal opinion, especially after actually hacking the code for =
back annotation, is that there are design errors in the very core of =
gschem.
While I find that a few lines of Scheme or AWK can work wonders. I think =
you=92re just doing things the hard way.
> A few smallish things that makes life harder in probably most flows, =
makes essential UI features impossible to implement. They are historical =
decisions and are embedded so deep that it's unlikely they'd ever =
change.
> I don't want to go into details, because this mail already can cause =
30 megabytes of flamewar.
Oh, the UI is klunky. And yes, it would have to be a new tool to fix it. =
But I don=92t let the klunky UI bother me. It doesn=92t significantly =
get in the way.
>=20
>=20
> The well-praised sch format: it's uncomfortable to use with a text =
editor. It's 1000x better than a binary format (or a hex dump), and I do =
have my ow set of awk/sed scripts, and it's easy to parse by programs =
(but that's true for tons of other formats too). But if i have to change =
the footprint of R1 from 1206 to 0805 with a text editor, it's just a =
PITA.
But we have other tools for *that*. I don=92t often use an *interactive* =
text editor on .sch files, but their friendliness to sed and AWK can be =
handy.
> I'm not an xml fanboy and I really don't like the overhead of JSON or =
the magic -- =3D=3D ''' marks of wiki/yaml... But really, any of these =
would have been more text-editor-friendly. This is a question of =
personal preference, but just that you repeat twice a weak that the sch =
format is perfect and is better than anything else doesn't change this.
There are 10000 things that are easy with shell one-liners on .sch =
files. Find every page containing a discrete transistor with =93grep =
refdes=3DQ *.sch=94.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_38DE8373-FBD7-4804-9975-EA3B445DA42E
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
iQIcBAEBCgAGBQJWghMiAAoJEF1Aj/0UKykROQ8P/0VBv4vj2wVtmCdntDrwijMr
AHLhjZYzZvpSlQ7vl9HXL9ytCCirJP8q81xEQBSLJoxOdjP7/ZR0rLxgfOhB7ev6
nr9F1skR3eLMSP6ki5WVsX8Y+MZyLJ69rBWJMyJ1GecuwjUj3EjJQtP6yQq39Goi
+Y6nLwZQhWNreUFCYr891t9RyVg+BSpyzwbTlyoaZjL4osHHWJ5BqAfdJ3ZNUAQ1
Jsv/m2yo22xJk+DB813fvNOhhm6Q6vT8o6IhB8HCIxXnX+NmfNaNu1heA+ryDiIk
XZr6qD+9a7UBtNMp0WtxkWdp641DM917A8/FkbG2ArCpJM/T3uvgshyNgJ2mhmKF
LO0irszaBWAOi9NhT1QMkUhwIWAHL+1d1pe8kuukrGj0pI1vZauVai6caMPBrvGr
xTKjMlzcbppGd/ozMnjXrbTQFh2UNPhujiM0y7uMAJiBNC+zoGHI7wD05fWJ8YcM
ISBccVLs35JymL5Bo4N4L7OzmV3/OMNXlTZfDatfNUtn//6iH9fTiJ1R82GEDGkI
/1y6aAUt/aFPP7JKulR8FTurXkeohwpH4u5P7YQDuVhgAe8Rwsh5tMhNhiR1r+un
wBCwCaKt0GaDoAl1CwISeG1kTg/apD6xvBjrXimXklY4labWZuxoYqAjXievP7dR
5KYu7KjIYkCu+mP5A246
=0cI3
-----END PGP SIGNATURE-----
--Apple-Mail=_38DE8373-FBD7-4804-9975-EA3B445DA42E--
- Raw text -