Mail Archives: geda-user/2015/12/29/00:14:12
On Tue, Dec 29, 2015 at 4:59 AM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Dec 28, 2015, at 8:29 PM, gedau AT igor2 DOT repo DOT hu wrote:
>
>>
>>
>> On Mon, 28 Dec 2015, John Doty wrote:
>>
>>>
>>> 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:
>>>
>>> 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.
>>>
>>>
>>> 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
>>
>> I know this will not be productive or encouraging, but...
>>
>> 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.
>>
>> When I worked on back annotation, I finally had to add some code in gschem and libgeda.
>
> I think adding code to libgeda is “fighting the paradigm”, a last resort when a new tool or script can’t 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’t encode what I need in a .sch file, even things way outside the box like makefiles. But pcb can’t even *represent* simple things like blind vias.
>
>>
>>> with scripting. Pcb development requires a great deal of collaboration.
>>> Geda-gaf development mostly does not, as anybody can write and publish a
>>> script.
>>
>> 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.
>>
>> 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.
>>
>>> There would be much less controversy if these projects were separated. They
>>> represent radically different development patterns: conflating them causes
>>> much confusion and strife.
>>
>> 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.
>>
>> Admitting that a very common (if not the most common) flow is gschem->pcb is not a bad thing.
>
> I don’t disagree. I just want to keep them separate.
I think most of us don't disagree but we are tired of being hammered
on this point.
>> Even if you will write at least 20 mails a month about that your flow does not include PCB.
>>
>> Having some scripts and tools for this flow is not any worse than having tools an scripts for other flows.
>>
>> 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’t tell what the author intends.
Please asking more and iterate less.
>> into "don't change gschem" threads. Other than this it's usually pretty clear when we are talking about gschem or pcb.
>>
>> About how perfect gschem is…
>
> It’s not perfect. But it’s capable and flexible when you use its capabilities rather than fighting it.
A lot of your flows to me look more like you are fighting the tool.
>>
>> 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’re just doing things the hard way.
Back annotation should just work out of the box. I accept that it
needs another tool in between but if we are asking users to code their
own awk scripts and accept that it is not interactive in some level
with a visual of the schematic it is just hot air.
>> 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’t let the klunky UI bother me. It doesn’t significantly get in the way.
Yes but you yell down anyone who wants to improve it simply because
they are bringing the much despised change.
>>
>>
>> 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’t 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 -- == ''' 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 “grep refdes=Q *.sch”.
>
>
> John Doty Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd AT noqsi DOT com
>
>
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2
mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----
- Raw text -