delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/02/09/16:04:46

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=googlemail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=7WPZqH6K3USM+G4bb1Gj0fGTho5axEZzKXbVi9SigJ8=;
b=f8XDA0BnTLT6qReRvbCz9ASbKiUGNVq0BXI33EFBuwkzA6aqRsLIC99gwMisZpBGph
/X/RsKIdso7X4rz6DswmUZ9Bi8sI0OHvR+jZHIvEXhuw29M6He2fxXdHA/jJynrn2xLd
HCGG4ecwpgXXxp1YsiqRCX/pLL1YL1SnUyMyhKX7fN16SIvlUTSZFrFIS43Ep3vrtJP7
a0ZxfnpSxPP7olPcI78wnXKZN9ZeoXAhm0ppej4qSDlflQ/OJnyRcqvS1n9uIx0bzOLo
MR+//c/VIGA36sFRwQNK4WG3QOqsgww37L6NFWBKXmIYV8aNfU9eHC6XpPGV4BOXhb6g
0xXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=7WPZqH6K3USM+G4bb1Gj0fGTho5axEZzKXbVi9SigJ8=;
b=ImcOU3AjrhgwgnaNLk944XCO/STauk+mHCbY15ZZITExbDaUYiuL62rg77CBGsApev
3HalFDAlTSIeD7ORSSuU5zk48k8VmzpKwauPPJhZvsgjZGEBkrnL6WICAB1KI+ULbETA
JHwh+n/LLWl15gUoa0UgJRm32Y5sHuyHf2YsgrWv/Y0Qi/UGN/pxUHRplbgkq0GHhk5j
UP8G/ki9hWUWEOk1wXwuXrgPeAZmE9ETRafuWqlu1apnI91UuHWaNhhPlMwVAxYl/g0V
GXA7s/b3fgqfd5h5Il5Hd/lkt3afxoGIirZVPuKmTd5d2M1YGfjtavx0U/qUklqkcu59
xlHQ==
X-Gm-Message-State: AG10YORRAct2M7ViC9GH5BUfR3LGYs9t8IeTRqLJZM4Q2j3KIj9rLDNV9rhgFtG9ql/nBvivz8qT73rU/Y2WrA==
MIME-Version: 1.0
X-Received: by 10.60.94.82 with SMTP id da18mr31385129oeb.40.1455051840483;
Tue, 09 Feb 2016 13:04:00 -0800 (PST)
In-Reply-To: <CAC4O8c_d2jqOb=rex4j1aodY_C2Hg=Fbx9mnp_Uacbhmw-mBug@mail.gmail.com>
References: <CAC4O8c-XG7N2Y8YxfrgX-zER5kS9n1Pq+xwi5UMLoS8EpadYRw AT mail DOT gmail DOT com>
<201602090508 DOT u1958Mv1023697 AT envy DOT delorie DOT com>
<CAC4O8c8wYq8uFzsY2gMnj4z=msWJA9KJgeTxSR27-2NxjF0Dgw AT mail DOT gmail DOT com>
<201602090521 DOT u195LYdK025191 AT envy DOT delorie DOT com>
<CAC4O8c85TCxrDe1WBJkxXQFV-Ob8C5Ow1-q2OoSM5f=7f6DnFg AT mail DOT gmail DOT com>
<201602090539 DOT u195d6BR026831 AT envy DOT delorie DOT com>
<CAC4O8c9PMWjswXjcO7E9HK31eBVuOSnoOBbLNtYZ7PYTCn-KaQ AT mail DOT gmail DOT com>
<CAC4O8c_d2jqOb=rex4j1aodY_C2Hg=Fbx9mnp_Uacbhmw-mBug AT mail DOT gmail DOT com>
Date: Tue, 9 Feb 2016 21:04:00 +0000
Message-ID: <CAJXU7q8y51FoFApErOOy_8tDuXnaLeV89=gmG_Q3Fh+PtG54iw@mail.gmail.com>
Subject: Re: [geda-user] what is 'New polygons are full ones' supposed to do?
From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
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

--089e011603f614f967052b5ca8c4
Content-Type: text/plain; charset=UTF-8

Hi...

I'm travelling right now, but you might like to ping a question to Bert. I
reviwed a patch in this area for him, but as I don't have Internet on my pc
on the move, I can't be 100% sure it fixes this particular bug.

As for full polys being the default - I'm uncertain. Harry screwed this up
when he added the polygon algebra... Prior to that polys with no flags were
effectively full, and the introduction of the new code required adding the
full poly flag to recreate the old broken behavior.  (As you note, the
connectivity checking code assumes all pieces are connected).

I have a branch which fully implements polygon pour regions that will
operate correctly with connectivity checking for each piece, and even had
experimental support for automatic Island removal (now that did behave in a
moderately surprising way, since no polygon would be left unless you
connected something to it with a thermal, or joined line etc...)

I think implementing full polys with a resurrection of ideas from my old
"pours" branch may be the way to go. I wish we could turn back time and
make the flag "biggest-poly-fragment" so we didn't break very very old
boards...

Harry was not always as careful as we are currently about not breaking
things.

I'd be happy to change the default to full polys once the connectivity
checking works and we have some means for Island removal or small fragment
culling.

There is some code which armed l aimed to remove small fragments, but as
implemented it was broken - hence is disabled. For the incremental polygon
operations to work correctly, we need all the fragments - no matter the
size, so they need excluding with a flag or similar, not just deleting out
of existence.

Peter
On 9 Feb 2016 20:05, "Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:

> On Tue, Feb 9, 2016 at 10:45 AM, Britton Kerin <britton DOT kerin AT gmail DOT com>
> wrote:
> > On Mon, Feb 8, 2016 at 8:39 PM, DJ Delorie <dj AT delorie DOT com> wrote:
> >>
> >> IIRC the option is newer than polygons; the default behavior used to
> >> be the only behavior.  If you think it should be changed, come up with
> >> a good case for it and present it in a launchpad bug report.
> >
> > So we have Gabriel also saying they have caused him trouble.  The
> > polygon interface is overall weird enough to use that I gave up and
> > didn't bother for years, and that's what I'd like to fix.
> >
> > In thinking it over it is a harder call than I though at first, as
> > tiny invisible conductive slivers could indeed be quite nasty.  The
> > proper place to handle this is the connectivity check or DRC though.
> > I'll take a look at how these behave with respect to polygon slivers.
>
> Looks like connectivity tests behave as if full poly is always off:
> they don't notice any poly fragment that would be eliminated if the
> poly wasn't 'full'.
> Given this bug I guess the full poly default can't be changed, but
> sheesh that should really be fixed if we're going to advertise full
> poly as being available at all.
>
> Britton
>

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

<p dir=3D"ltr">Hi...</p>
<p dir=3D"ltr">I&#39;m travelling right now, but you might like to ping a q=
uestion to Bert. I reviwed a patch in this area for him, but as I don&#39;t=
 have Internet on my pc on the move, I can&#39;t be 100% sure it fixes this=
 particular bug.</p>
<p dir=3D"ltr">As for full polys being the default - I&#39;m uncertain. Har=
ry screwed this up when he added the polygon algebra... Prior to that polys=
 with no flags were effectively full, and the introduction of the new code =
required adding the full poly flag to recreate the old broken behavior.=C2=
=A0 (As you note, the connectivity checking code assumes all pieces are con=
nected).</p>
<p dir=3D"ltr">I have a branch which fully implements polygon pour regions =
that will operate correctly with connectivity checking for each piece, and =
even had experimental support for automatic Island removal (now that did be=
have in a moderately surprising way, since no polygon would be left unless =
you connected something to it with a thermal, or joined line etc...)</p>
<p dir=3D"ltr">I think implementing full polys with a resurrection of ideas=
 from my old &quot;pours&quot; branch may be the way to go. I wish we could=
 turn back time and make the flag &quot;biggest-poly-fragment&quot; so we d=
idn&#39;t break very very old boards...</p>
<p dir=3D"ltr">Harry was not always as careful as we are currently about no=
t breaking things.</p>
<p dir=3D"ltr">I&#39;d be happy to change the default to full polys once th=
e connectivity checking works and we have some means for Island removal or =
small fragment culling.</p>
<p dir=3D"ltr">There is some code which armed l aimed to remove small fragm=
ents, but as implemented it was broken - hence is disabled. For the increme=
ntal polygon operations to work correctly, we need all the fragments - no m=
atter the size, so they need excluding with a flag or similar, not just del=
eting out of existence.</p>
<p dir=3D"ltr">Peter</p>
<div class=3D"gmail_quote">On 9 Feb 2016 20:05, &quot;Britton Kerin (<a hre=
f=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a h=
ref=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]&quot; &lt;<=
a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>&gt; wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Feb 9, 201=
6 at 10:45 AM, Britton Kerin &lt;<a href=3D"mailto:britton DOT kerin AT gmail DOT com"=
>britton DOT kerin AT gmail DOT com</a>&gt; wrote:<br>
&gt; On Mon, Feb 8, 2016 at 8:39 PM, DJ Delorie &lt;<a href=3D"mailto:dj AT de=
lorie.com">dj AT delorie DOT com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; IIRC the option is newer than polygons; the default behavior used =
to<br>
&gt;&gt; be the only behavior.=C2=A0 If you think it should be changed, com=
e up with<br>
&gt;&gt; a good case for it and present it in a launchpad bug report.<br>
&gt;<br>
&gt; So we have Gabriel also saying they have caused him trouble.=C2=A0 The=
<br>
&gt; polygon interface is overall weird enough to use that I gave up and<br=
>
&gt; didn&#39;t bother for years, and that&#39;s what I&#39;d like to fix.<=
br>
&gt;<br>
&gt; In thinking it over it is a harder call than I though at first, as<br>
&gt; tiny invisible conductive slivers could indeed be quite nasty.=C2=A0 T=
he<br>
&gt; proper place to handle this is the connectivity check or DRC though.<b=
r>
&gt; I&#39;ll take a look at how these behave with respect to polygon slive=
rs.<br>
<br>
Looks like connectivity tests behave as if full poly is always off:<br>
they don&#39;t notice any poly fragment that would be eliminated if the<br>
poly wasn&#39;t &#39;full&#39;.<br>
Given this bug I guess the full poly default can&#39;t be changed, but<br>
sheesh that should really be fixed if we&#39;re going to advertise full<br>
poly as being available at all.<br>
<br>
Britton<br>
</blockquote></div>

--089e011603f614f967052b5ca8c4--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019