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=cSeD3lhzYlU7n8qw/3BdR30XGw2i+zOU1ou8qSPDuE8=;
        b=nAThxsWz9+QOahfZcBLX5xiOjsKTlNQUCAIRwM0nDkZujfCXY1Vcreye1bDzpcHC3y
         itvvIlqLJ1VCU7t8cj2ZHooPf6ZJSUiTgLbolbDaQ/6eDRS6xtvinAIgYKn5BluIhF8c
         4DepAShhdjZDxD5HN2x3XmgPo9j1b7VhDm7HmpZmerIePjOOl2q79Wz2Si15FeJnQKmr
         +tOG4uaPmQ1refLmhwpjsz9TiyFvaAaU0g2KQf5bFoGwlQeu2p2vM1hEWUwO8H+qTZJW
         GIRRwZU+R49IQRZ7ekxdU/pEuTFiBI6K5wqPnzzW+RYoO7mwyoPSQ58PsqzQZENTQoAn
         1V4A==
MIME-Version: 1.0
X-Received: by 10.28.23.73 with SMTP id 70mr24451500wmx.37.1451609956722; Thu,
 31 Dec 2015 16:59:16 -0800 (PST)
In-Reply-To: <1628443.xzcfV1e99J@office.tfsoft.local>
References: <1628443 DOT xzcfV1e99J AT office DOT tfsoft DOT local>
Date: Thu, 31 Dec 2015 15:59:16 -0900
Message-ID: <CAC4O8c_TiZcHSXRf277-5X=xUzX5o_taRLSRMM6g7rE7bH4ghQ@mail.gmail.com>
Subject: Re: [geda-user] [pcb] An advice on (possible) AutoEnforceDRC-related
 bugfix needed
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary=001a1145a83ad2af5d05283b47d7
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

--001a1145a83ad2af5d05283b47d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 29, 2015 at 3:57 PM, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=94=D1=
=83=D0=B1=D0=BD=D1=8F=D0=BA <twister AT tfsoft DOT org DOT ua> wrote:

> Spent several days trying to fix this bug:
> https://bugs.launchpad.net/pcb/+bug/1013358
>
> I was convinced that it is due to rounding errors somewhere in
> find.c/search.c,
> when DRC clearance and grid spacing are the same. But turns out, it is no=
t.
> Please, see the trivial patch in attachment. Looks like it solves the
> described problem.
>
> I'm suspicious if the bug is fixed _that_ simple (taking into account my
> shallow knowledge of codebase).
>
> It would be great if someone explain what was the intention of "PCB->Bloa=
t
> +
> 1" in that place? Maybe it is vital for some other actions, not related t=
o
> this bug?
>

It looks like it's meant to be conservative.  Bloat ends up set such that
lines have to be thickened by twice that amount to cause a new intersection
when a DRC violation exists.  But bloat may itself already have been
subject to rounding, so throwing the extra 1 in makes it "safer" in the
sense that it will fire a violation in the marginal conditions that I think
that bug report is describing.

By removing the -1 you may "fix" this particular case, but unfortunately
the underlying problem still exists and will likely manifest elsewhere as
well (for non-axis-aligned lines for example).  The only real solution is
to use a DRC clearance requirement smaller than your actual spacing by some
reasonable epsilon.  That done, you're version may still be better, as
there would then be no need for half-assed efforts to dodge the issue with
things like that extra +1.  Using a DRC value equal to your grid and line
sizes is asking for trouble.  IMO we should change pcb to somehow make this
clear to users, rather than trying to paper over the problem in the
calculations themselves.

Britton

--001a1145a83ad2af5d05283b47d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Dec 29, 2015 at 3:57 PM, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=94=
=D1=83=D0=B1=D0=BD=D1=8F=D0=BA <span dir=3D"ltr">&lt;<a href=3D"mailto:twis=
ter AT tfsoft DOT org DOT ua" target=3D"_blank">twister AT tfsoft DOT org DOT ua</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">Spent several days trying to fix th=
is bug:<br>
<a href=3D"https://bugs.launchpad.net/pcb/+bug/1013358" rel=3D"noreferrer" =
target=3D"_blank">https://bugs.launchpad.net/pcb/+bug/1013358</a><br>
<br>
I was convinced that it is due to rounding errors somewhere in find.c/searc=
h.c,<br>
when DRC clearance and grid spacing are the same. But turns out, it is not.=
<br>
Please, see the trivial patch in attachment. Looks like it solves the<br>
described problem.<br>
<br>
I&#39;m suspicious if the bug is fixed _that_ simple (taking into account m=
y<br>
shallow knowledge of codebase).<br>
<br>
It would be great if someone explain what was the intention of &quot;PCB-&g=
t;Bloat +<br>
1&quot; in that place? Maybe it is vital for some other actions, not relate=
d to<br>
this bug?<br></blockquote><div><br></div><div style=3D"">It looks like it&#=
39;s meant to be conservative.=C2=A0 Bloat ends up set such that lines have=
 to be thickened by twice that amount to cause a new intersection when a DR=
C violation exists.=C2=A0 But bloat may itself already have been subject to=
 rounding, so throwing the extra 1 in makes it &quot;safer&quot; in the sen=
se that it will fire a violation in the marginal conditions that I think th=
at bug report is describing.</div><div style=3D""><br></div><div style=3D""=
>By removing the -1 you may &quot;fix&quot; this particular case, but unfor=
tunately the underlying problem still exists and will likely manifest elsew=
here as well (for non-axis-aligned lines for example).=C2=A0 The only real =
solution is to use a DRC clearance requirement smaller than your actual spa=
cing by some reasonable epsilon.=C2=A0 That done, you&#39;re version may st=
ill be better, as there would then be no need for half-assed efforts to dod=
ge the issue with things like that extra +1.=C2=A0 Using a DRC value equal =
to your grid and line sizes is asking for trouble.=C2=A0 IMO we should chan=
ge pcb to somehow make this clear to users, rather than trying to paper ove=
r the problem in the calculations themselves.</div><div style=3D""><br></di=
v><div style=3D"">Britton</div><div style=3D""><br></div></div></div></div>

--001a1145a83ad2af5d05283b47d7--