Mail Archives: geda-user/2015/12/31/01:13:16
gedau AT igor2 DOT repo DOT hu wrote:
>
>
> On Wed, 30 Dec 2015, John Doty wrote:
>
>>
>> On Dec 30, 2015, at 9:01 PM, gedau AT igor2 DOT repo DOT hu wrote:
>>
>>>
>>>
>>> On Wed, 30 Dec 2015, John Doty wrote:
>>>
>>>>
>>>> On Dec 30, 2015, at 1:03 AM, gedau AT igor2 DOT repo DOT hu wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 30 Dec 2015, John Doty wrote:
>>>
>>> <snip>
>>>
>>>>>> Grep is your friend. The textutils can do 10,000 things with .sch
>>>>>> files. No GUI tool will ever be able to do all, or even most of
>>>>>> them.
>>>>>
>>>>> So please show me the grep command line that does this RELIABLY.
>>>>> Net segment connections included. net attributes included. Even in
>>>>> non-embedded symbols. Multi sheet designs, hierarchic or not,
>>>>> included.
>>>>
>>>> It?s a quick heuristic. Speed is important for tracking down such
>>>> things, perfection is not. Reliability is more the domain of DRC,
>>>> which definitely needs work, and I?ve been working on it.
>>>
>>> Friedly reminder: I'm still waiting for the answer here: either a
>>> grep commandline that really does the job or a conclusion that it is
>>> not possible.
>>>
>>
>> It does the job by my pragmatic standards. I?m interested in getting
>> designs done, not in splitting hairs. I don?t suppose anything would
>> satisfy you. But I?m *extremely* happy with the actual productivity
>> of the toolkit.
>
>
> Ok, so there's an actual problem I face from time to time: after
> prototyping I figure a specific connection should not be made. This
> means I need to go back and change the design. First step, find out
> where the connection is made.
>
> The toolkit doesn't have a feature for this. Grep doesn't help. I have
> a partial solution in C and Vladimir showed another partial solution
> in scheme. It seems there's no easy way to make a solution that really
> covers all practical cases (cases that I actually do have as an user).
>
> Your solution is: first state that grep solves it, but when it turns
> out it doesn't, classify the problem as splitting hair.
>
> No personal offense meant, but if such a simple thing is this hard to
> do with geda, there must be some desing problem in the foundation. I
> also think this kind of unfruitful flame does keep us back from
> discussing such design questions in gschem. This is exactly what I
> meant when I said earlier that some people just swamp any attempt to
> even discuss bugfixes and improvements in geda.
>
> Again no offense, but I honestly do believe to progress positively, we
> first need to reolve some issues, for which the first step is naming
> the issues. One of these issues: if someone brings up an uncomfortable
> quesiton (e.g. where geda seems to fail), some people convert it
> immediately into an abstrack "toolkit vs. integrated" flame, while
> others convert it into a "C vs scheme" flame (even if I explicitly
> said there, more than once that the question is NOT about programming
> languages). After the 3rd mail, the original question is totally lost
> and topic converted to one or more of the usual flame wars. This how
> we can not talk about anything else but toolkits and scheme.
>
> This is why I originally tried to resist entering these threads. And
> this is why I give up on this and will ignore geda/gschem related
> posts on the list.
>
> On the side note, I think it'd be also really really useful to make a
> representative poll among the actual userbase about these things:
> whether they'd find a
>
> "search for connection", "search for network by name"
>
> less important than
>
> "more c<->scheme conversion" (whichever direction you happen to
> prefer) and "toolkitness" questions.
>
> Kind regards,
>
> Igor2
>
Hi Igor2,
Over the years I have found that people react differently to issues
outside their comfort zone.
Some embrace the issue as a chance for improvement (learning), dig and
prod into it, find and grasp the root cause and solve the issue for
themselves, and sometimes for others too.
Others push the issue as far away as possible and ignore it. Let
somebody else solve it.
Some others duck the issue by bending any conversation about the issue
into a direction they feel comfortable with, and hope it goes away by
itself or is solved for them.
Just plain human nature ;-)
I try to do the first.
I think you do too.
Kind regards,
Bert Timmerman
- Raw text -