Mail Archives: geda-user/2015/12/31/14:35:24
--Apple-Mail=_16537CCD-5AF7-4349-897B-D33CE0F7D7E9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 30, 2015, at 10:25 PM, gedau AT igor2 DOT repo DOT hu wrote:
>=20
>=20
> On Wed, 30 Dec 2015, John Doty wrote:
>=20
>>=20
>> On Dec 30, 2015, at 9:01 PM, gedau AT igor2 DOT repo DOT hu wrote:
>>=20
>>>=20
>>>=20
>>> On Wed, 30 Dec 2015, John Doty wrote:
>>>=20
>>>>=20
>>>> On Dec 30, 2015, at 1:03 AM, gedau AT igor2 DOT repo DOT hu wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Wed, 30 Dec 2015, John Doty wrote:
>>>=20
>>> <snip>
>>>=20
>>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>=20
>> 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.
>=20
>=20
> Ok, so there's an actual problem I face from time to time: after =
prototyping I figure a specific connection should not be made.
For me, that=92s the hard part. Connections that should be made but =
aren=92t are even harder to detect.
> This means I need to go back and change the design. First step, find =
out where the connection is made.
I=92ve never spent significant time on that.
>=20
> The toolkit doesn't have a feature for this.
Good. Every feature that is missing saves the user time when they don=92t =
use it. Suppose you had this feature in a menu. Assume that skipping =
over a menu item you don=92t need costs 0.1 second. Suppose you look at =
that menu 100 times a day, 100 days a year. Suppose there are 1000 users =
in a similar situation. Suppose we value engineering time at $100/hour =
(this is getting to be like the Drake Equation ;-). GEDA has been around =
for about 15 years, so by this estimate each unnecessary feature not =
implemented has saved more than $400,000.
> Grep doesn't help.
Works for me. Recent example: layout contractor called me up, toldd me =
that the +3.3B supply wasn=92t connected to anything. Now, I knew that I =
intended that for the MAX9180 LVDS buffers. But I didn=92t remember =
which page they=92re on. I don=92t remember exactly what I did, but it =
was something like:
Kakuzen:Schematic jpd$ make Interface.bom.txt
(if I didn=92t already have it around)
Kakuzen:Schematic jpd$ grep MAX9180 Interface.bom.txt
U12 MAX9180 unknown unknown SC70-6 unknown
U11 MAX9180 unknown unknown SC70-6 unknown
(Ok, it=92s U11 and U12 that need the connection)
Kakuzen:Schematic jpd$ grep refdes=3DU12 Interface.*.sch
Interface.1.sch:refdes=3DU12
(Ok, one of them is on page 1, and actually they both are, trivial to =
spot)
Now, I don=92t know exactly what your problem is. I=92ve been using gEDA =
since 2002, for some very complicated projects (2000 component boards, =
6000 component ASICs). I=92ve never found it difficult to locate an =
erroneous connection once I knew it existed.
> 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).
Since it is unclear to me why this is difficult for you, I cannot make a =
suggestion.
>=20
> Your solution is: first state that grep solves it, but when it turns =
out it doesn't, classify the problem as splitting hair.
Since it is unclear to me why this is difficult for you, I cannot tell =
you how to solve it.
>=20
> 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.
It=92s a feature whose lack does not prevent the user from representing =
the necessary circuit, so it=92s not a fundamental problem. Its lack is =
apparently inconvenient for you, but convenient for me. So, it is =
emphatically not a design problem, but a matter of matching personal =
preference.
The purpose of the scripting interface is to allow you to customize the =
tool to suit your preferences and to share those customizations with =
those who share your approach. If there=92s a limitation in the =
scripting interface that makes a clearly defined, reasonable feature =
impossible, we should fix that limitation if the fix doesn=92t =
complicate life for others (e.g. by forcing the tool to adopt special =
features of your flow).
> 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.
I don=92t necessarily call something that will cost users $400,000 an =
improvement. Now, it *is* reasonable to argue that the value of the =
feature might offset the cost. But that=92s exactly the kind of argument =
that the scripting feature is supposed to prevent, by enabling =
customization.
>=20
> 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.
>=20
> 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.
>=20
> 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
>=20
> "search for connection", "search for network by name=94
You=92re glossing over the tricky issues. Part of the problem is that =
geda-gaf implements no concept of a project (which seems to be what you =
want to search). I suppose that you=92d call this another defect. I =
would argue it=92s not. There=92s no single project concept that even =
covers all of my flows, let alone other people=92s, so the freedom to =
structure the project to fit the job is a critically important =
capability of geda-gaf. If knowledge of project structure is desired in =
gschem, it needs to be in optional scripts, not built in.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_16537CCD-5AF7-4349-897B-D33CE0F7D7E9
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
iQIcBAEBCgAGBQJWhYNeAAoJEF1Aj/0UKykRCWUP/2lqdyICkitgF5RKDJ58qsPm
4U2I/9djhL7mavLOEWj+ervfY4CvCC/TVPB12PAaWq2xrSuWhfNu8NPPG1gS1WVG
TdPCm0glwyYKSBRFXsXYlVn27biJK+DRM3Iabmv6hDjvzZeqtVMP9BFGIzIcY6n8
/i0yb2neNubEIQtass2+3/wkGZg1y+pv7z50PPOsQfaQGBTGMPcuoXOpittulEfV
RW9e2YNaq83kCm4CeDWONg1uMYNlq4R5c55dTxcFimewewg5qmXKvyTIwFCm7xSP
KEPJ5dwGkUHx4cuF1OpYIVD1dYw9Aw52vV2SuGLNZt3hsgoPlu2AN5KrBqNyb2q7
iKwkpkG9/FfG3a8MM4+meRSHxLu91EcNbrkJck/842nObY0/C0HQA1ZmqFkcF4uE
uYyNDQu+U3PriFyKUo3NOcB2H3XEO6VqMgW0NgG0r+G1eCk0ACNc1SOcaveAn6er
c8FSyuHhIg90FtACTWGHuZz/C9TZYLYT/a+Dr1cim0vkZHqTTWxDCsw2uGsSerHs
lwVmn1rbnQlDCTcgVs6jHiOATIpMgRejraG+TgwT0AMHhN8AmoxgoQfQuN9SXvf2
PFWk/QSrKy4l/cIwKDJK85jnhLCLBj5L07K2Ig+0EQjLyZK44ovvREmZwVJuVD/e
48WnzLKvM6PxI3015qHL
=4Pg1
-----END PGP SIGNATURE-----
--Apple-Mail=_16537CCD-5AF7-4349-897B-D33CE0F7D7E9--
- Raw text -