X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5MgK/z2lK45ZNyhC+uISOsG0oMew1plD9+ML8Et5tos=; b=oK+3jvFirbbgi5KmICNLqUj0Nl1iWV5UXq4O4wDwW2uGRY3iX5I9wtSTHpmYUi84Vi REQG6JXbDMGnK3DDM/diCl7ti8ffe7Ugs6ONZ0eTBsh6n3giguF149EKessOWXMpegU/ O4vAappOWhFDBAsbYrBdl5BYrLsQnM9GAKRzjW1xfgD9OUGWHHORvgKvbmvcRssX8w7o v7fh6QunFHtT5opV2IVbtCrEGPtUBt/RbprA9tyOLIfjZea1pmQR9OdsUb57vGD65wtK L6eJJgTyDtOUONhVb0u0NXGFxhRlcejmSs0hsFgSzfLAfHUnxkAOJwwjs8/FM2KBoqPP vyPg== MIME-Version: 1.0 X-Received: by 10.180.85.164 with SMTP id i4mr8365209wiz.54.1443992055780; Sun, 04 Oct 2015 13:54:15 -0700 (PDT) In-Reply-To: <5610FEF9.5050307@jump-ing.de> References: <560F9AC7 DOT 3040607 AT jump-ing DOT de> <5610FEF9 DOT 5050307 AT jump-ing DOT de> Date: Sun, 4 Oct 2015 12:54:15 -0800 Message-ID: Subject: Re: [geda-user] making DRC less misleading in the presence of shorts, non-routed rats, etc. From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=f46d0445182f8b1da205214d99a2 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 --f46d0445182f8b1da205214d99a2 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 2:27 AM, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote: > Am 04.10.2015 um 00:46 schrieb Britton Kerin: > > On Sat, Oct 3, 2015 at 1:07 AM, Markus Hitter wrote: > > > >> Am 03.10.2015 um 01:21 schrieb Britton Kerin: > >> > >>> At the moment DRC catches near-shorts (trace too close to another), but > >> is > >>> completely silent when there's an actual short. > >> > >> That's expected, that's what DRC does. Checking for shorts means to > > > > When I started, it was not at all expected. Its weird that you can go > from > > almost-short, to short, and thereby make a violation vanish. > > What I mean is that it's pointless to try to fix DRC code for detecting > shorts. DRC techniques can't do this. Comparing connections with the > netlist can, and that's what "optimize rats" already does. No need to > duplicate existing code. > > All you have to do is to make sure and intuitive that users check not > only for DRC violations, but also for shorts. Following the code in > ActionAddRats() in action.c shows how to do this. > > I'd try to catch the output of AddAllRats() into a buffer for displaying > it in the DRC window. Perhaps only the first 1024 bytes or something. > Some new GUI code, reuse of short-checking code, mission accomplished. > > BTW., this will also check for missing connections, which are certainly > also a reason to not send a board to the manufacturer. Yes, I said so already. The branch I made mentions it also. I'm moving on from this issue. If anyone wants to do any of the much harder things proposed instead of what I put in home/bkerin/drc_warning_for_noobs that would be great, but I submit that until that time the simple change in that branch is better than nothing. --f46d0445182f8b1da205214d99a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 4, 2015 at 2:27 AM, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wr= ote:
Am 04.10.2015 um 00:46 schrieb Britt= on Kerin:
> On Sat, Oct 3, 2015 at 1:07 AM, Markus Hitter wrote:<= br> >
>> Am 03.10.2015 um 01:21 schrieb Britton Kerin:
>>
>>> At the moment DRC catches near-shorts (trace too close to anot= her), but
>> is
>>> completely silent when there's an actual short.
>>
>> That's expected, that's what DRC does. Checking for shorts= means to
>
> When I started, it was not at all expected.=C2=A0 Its weird that you c= an go from
> almost-short, to short, and thereby make a violation vanish.

What I mean is that it's pointless to try to fix DRC code for de= tecting
shorts. DRC techniques can't do this. Comparing connections with the netlist can, and that's what "optimize rats" already does. No= need to
duplicate existing code.

All you have to do is to make sure and intuitive that users check not
only for DRC violations, but also for shorts. Following the code in
ActionAddRats() in action.c shows how to do this.

I'd try to catch the output of AddAllRats() into a buffer for displayin= g
it in the DRC window. Perhaps only the first 1024 bytes or something.
Some new GUI code, reuse of short-checking code, mission accomplished.

BTW., this will also check for missing connections, which are certainly
also a reason to not send a board to the manufacturer.
Yes, I said so already.=C2=A0 The branch I made ment= ions it also.

I'm moving= on from this issue.=C2=A0 If anyone wants to do any of the much harder thi= ngs proposed instead of what I put in home/bkerin/drc_warning_for_noobs tha= t would be great, but I submit that until that time the simple change in th= at branch is better than nothing.

--f46d0445182f8b1da205214d99a2--