Mail Archives: geda-user/2015/12/31/00:23:56
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
- Raw text -