X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-TCPREMOTEIP: 207.224.51.38
X-Authenticated-UID: jpd AT noqsi DOT com
Content-Type: multipart/signed; boundary="Apple-Mail=_16537CCD-5AF7-4349-897B-D33CE0F7D7E9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: gEDA and it's future with Scheme & Guile was Re: [geda-user] Project leadership
X-Pgp-Agent: GPGMail 2.5.2
From: John Doty <jpd AT noqsi DOT com>
In-Reply-To: <alpine.DEB.2.00.1512310559330.9035@igor2priv>
Date: Thu, 31 Dec 2015 12:34:53 -0700
Message-Id: <AEAC78ED-98C4-45EA-8374-5FDAB4B1E831@noqsi.com>
References: <CAM2RGhS4L-ch6FEcLtdSt0vA0BdQZvq+AuFDP+9ea7Ftd=AALg AT mail DOT gmail DOT com> <8444F816-17CE-4A56-A982-4A60DEDA72B8 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300544550 DOT 9035 AT igor2priv> <A06FE370-5416-41F5-BBAA-BCF0D975DDD3 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300635240 DOT 9035 AT igor2priv> <2297464D-0109-4CA8-98D5-AC33BD0B02C5 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300723150 DOT 9035 AT igor2priv> <73273554-3E38-4F1F-9423-F731753B41D8 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300817590 DOT 9035 AT igor2priv> <41F5814C-CBF1-4F51-8CFA-F9A2F56EC2EF AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300858260 DOT 9035 AT igor2priv> <306C32FA-255A-4B1E-8B00-BD21D7C37F67 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512310459310 DOT 9035 AT igor2priv> <978615B0-F33E-4B70-88C2-DC2D05E9C62A AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512310559330 DOT 9035 AT igor2priv>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1878.6)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


--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--