Mail Archives: geda-user/2015/12/29/00:27:48
On Mon, 28 Dec 2015, John Doty 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.
I love how you state that without even asking what kind of code I am
talking about and whether it has anything to do directly with annotation
of any direction.
>
>> 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.
That's not a file format question.
<snip>
>> 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.
They are separate. You pretend they are not.
>
>> 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.
I recall a few mails a year when a new user posts a question without
stating whether it's about pcb or gschem. It's usually trivail to clear
this in one go. This issue is not worse than the usual
English-is-not-my-primary-language problems.
>
>> 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.
Same sentence is true for PCB, if you read it carefully and put aside any
prejudicates. This doesn't mean PCB's model of the world is good. Just
like I've figured there are similar holes in gschem's model.
The nature of the holes obviously differ.
>
>>
>> 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.
Scheme or awk won't provide me an UI feature. We disagree what the UI
should be capable of. For you, the UI is complete, for me it is not.
>> 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.
I disagree. Sometimes it's just a small feature that's missing or not
implemented to be general enough.
> But I don?t let the klunky UI bother me. It doesn?t significantly get in
> the way.
Which doesn't mean it won't get in the way of others.
>>
>>
>> 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'd often like to use a text editor on .sch, just like i do on .pcb.
>
>> 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?.
I was not talking about shell one-liners. I said the sch format is PITA
for text editors. PCB got this aspect much better.
My point is that you are stick to the .sch format and wouldn't even
consider that there could be another format that can represent all that an
sch can, can be used with shell as easily as sch _and_ can be good for
text editors. You've already decided sch was the best format. Might be for
you, but clearly not for me. Note: I am not campaining for any specific
format. I am campaining against blindly refusing to even consider.
- Raw text -