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=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=S2Uz6k3O9XnYYDHTPuSn55h1fIZR7yxYXyheyTnJLdo=;
        b=npw3yqR2mt8sUQuyVX9B7W17+B5H9PCbl+WrLnnKRUwrR1YIZP7GFvURyA/apGE0nN
         Qso/u2eBvx6Av2Lf6QwLGr8WrCOsFiGMX5z68hoHjlSTZjRRIqJIaanJWGdJP2uISiL+
         Z89eaDp5NwsFmn34L3yzDYMO2Ep3Gtui9XhtzU/KKCQtjCjtnojeSD8i3uFl/4TO+eHS
         KdGfAO+JMZgZELp+jZzu52h3bsT4BdUZHRvb1SpkTZbOo+Migjlfivn4lwvSSCFKGk6U
         FtRyrctQ1eePVjgi7KSoCuM37OsA8a7QFf/4Nsje+A4vZV5RWNlO5+VQcV0lT5y3cpch
         EkAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=S2Uz6k3O9XnYYDHTPuSn55h1fIZR7yxYXyheyTnJLdo=;
        b=hDEAh5jzYhjEBMa4h81r3tfufRQqkf2HVd4ZjLu03EV0beUOi+TWEU1V7+wfNK1CKp
         9ElNlAe+H/rmpJ8PP9fLhvFiDgix4Uj8q7owtbRfDGyrBO+fouQxb+8vAb689QB4l2j7
         VnfUobSqbgwuXY83LNeYEwZNmOIsTOt2wOXrpZht2QnVEmzzkwMSxWslZycn36lk/2L1
         NSIN2rIXxDCqjUZoBpanb7MTujwH73TwqnGG5oF8y3WyZ+XMeT10Qh+MeFW+AJe8ePTU
         /oXoCEdSOWRiiPilKPWuollIT5XygQAnyIm4CUcA9t/HSBnjyXrK/bVaHPk1eYUmVuhL
         1zsA==
X-Gm-Message-State: AGi0PubUVO3e9dur+I4GBBnyzIk5Ieo10MQX6230AvhLUxL3xrwNXVs+
	Nj0dOut2bVXcpDMJey8/TOOX9vhgAzinSwTTXskhtA==
X-Google-Smtp-Source: APiQypL2rqIwwENP/w3KsIY+WHx5SzBwPQQbrcoxeO51aMZSAEnq1xtA9lJpDDnqQGxq/0N7ddDQrVV0e2n2X6GN3Us=
X-Received: by 2002:a1f:5f53:: with SMTP id t80mr8064452vkb.39.1585947777664;
 Fri, 03 Apr 2020 14:02:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAC4O8c9baAQTW4bqaHLWJ=395oQfqwc6ySO2kAGD3YM5Au-nhg AT mail DOT gmail DOT com>
 <xno8s8qvp4 DOT fsf AT envy DOT delorie DOT com> <CAC4O8c9YUVj6+5FUFHx5dDLkLBUjXaz5qs+n3RtTBgngPJ2EdQ AT mail DOT gmail DOT com>
In-Reply-To: <CAC4O8c9YUVj6+5FUFHx5dDLkLBUjXaz5qs+n3RtTBgngPJ2EdQ@mail.gmail.com>
From: "Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date: Fri, 3 Apr 2020 17:02:46 -0400
Message-ID: <CAJZxidDpjN_4ZftC=ug=UB+8Obpw9uf8hdiFyC9J9U4k50Ldwg@mail.gmail.com>
Subject: Re: [geda-user] Fwd: [pcb-rnd] connectivity bug -> fullpoly again
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary="000000000000eb89e605a2693dd1"
Reply-To: geda-user AT delorie DOT com

--000000000000eb89e605a2693dd1
Content-Type: text/plain; charset="UTF-8"

Yes please. Until one of us gets around to addressing the underlying
problem (and realistically that could be a while), we should have warnings
in place so the user knows to pay special attention.

Thanks,
--Chad

On Fri, Apr 3, 2020 at 4:46 PM Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

> On Fri, Apr 3, 2020 at 10:57 AM DJ Delorie <dj AT delorie DOT com> wrote:
> >
> >
> > IIRC Peter and I talked about this long ago, and one solution we came up
> > with was to have a "polygon stack" so you could do things like "invert
> > this section" or "cut this polygon with this line" (different than
> > clearing a polygon with a trace).  The user would edit the things at the
> > bottom of the stack (the original polygons, cut lines, etc), but the
> > system would see the "virtual polygons" at the top (result) of the
> > stack.  It added a bunch of functionality and fixed the full poly
> > problem, but neither of us ended up implementing it.
>
> This sounds very much like what Igor has just implemented as a fix in
> pcb-rnd.
> It would be good, but as far as I'm concerned it isn't absolutely required.
> fullpoly is one of those things in pcb that I only ever used because I
> didn't
> actually know what it did or what the risks were, simply not using it was a
> very easy solution.
>
> > So yeah, old problem.  Bug?  Feature?  You decide :-)
>
> I don't understand how this can be construed as a feature.  For all it's
> alleged problems over the years, pcb has only actually lied to me twice
> that I
> know of.  First time was by failing to mention actual shorts during DRC,
> that
> has been resolved by a simple warning about the issue in DRC.  This is the
> second time.  I would very much like to see it addressed somehow.  If
> there is
> interest (i.e. if it's guaranteed to get merged) I'll try to prepare a
> small
> patch that mentions the issue in the documentation and in DRC (warn if it
> sees fullpoly).
>
> Britton
>

--000000000000eb89e605a2693dd1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Yes please. Until one of us gets around to addressing=
 the underlying problem (and realistically that could be a while), we shoul=
d have warnings in place so the user knows to pay special attention.</div><=
div><br></div><div>Thanks,<br></div><div>--Chad<br></div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 3, 202=
0 at 4:46 PM Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com">brit=
ton DOT kerin AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda=
-user AT delorie DOT com</a>] &lt;<a href=3D"mailto:geda-user AT delorie DOT com">geda-us=
er AT delorie DOT com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">On Fri, Apr 3, 2020 at 10:57 AM DJ Delorie &lt;<a href=3D"mai=
lto:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; IIRC Peter and I talked about this long ago, and one solution we came =
up<br>
&gt; with was to have a &quot;polygon stack&quot; so you could do things li=
ke &quot;invert<br>
&gt; this section&quot; or &quot;cut this polygon with this line&quot; (dif=
ferent than<br>
&gt; clearing a polygon with a trace).=C2=A0 The user would edit the things=
 at the<br>
&gt; bottom of the stack (the original polygons, cut lines, etc), but the<b=
r>
&gt; system would see the &quot;virtual polygons&quot; at the top (result) =
of the<br>
&gt; stack.=C2=A0 It added a bunch of functionality and fixed the full poly=
<br>
&gt; problem, but neither of us ended up implementing it.<br>
<br>
This sounds very much like what Igor has just implemented as a fix in pcb-r=
nd.<br>
It would be good, but as far as I&#39;m concerned it isn&#39;t absolutely r=
equired.<br>
fullpoly is one of those things in pcb that I only ever used because I didn=
&#39;t<br>
actually know what it did or what the risks were, simply not using it was a=
<br>
very easy solution.<br>
<br>
&gt; So yeah, old problem.=C2=A0 Bug?=C2=A0 Feature?=C2=A0 You decide :-)<b=
r>
<br>
I don&#39;t understand how this can be construed as a feature.=C2=A0 For al=
l it&#39;s<br>
alleged problems over the years, pcb has only actually lied to me twice tha=
t I<br>
know of.=C2=A0 First time was by failing to mention actual shorts during DR=
C, that<br>
has been resolved by a simple warning about the issue in DRC.=C2=A0 This is=
 the<br>
second time.=C2=A0 I would very much like to see it addressed somehow.=C2=
=A0 If there is<br>
interest (i.e. if it&#39;s guaranteed to get merged) I&#39;ll try to prepar=
e a small<br>
patch that mentions the issue in the documentation and in DRC (warn if it<b=
r>
sees fullpoly).<br>
<br>
Britton<br>
</blockquote></div>

--000000000000eb89e605a2693dd1--