X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <578E70AF.2010205@xs4all.nl> Date: Tue, 19 Jul 2016 20:25:51 +0200 From: "Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] pcb: polygon "twin hole" bug References: <4f9dfd62-45cd-a307-a6d9-93b7cd4333a2 AT gmail DOT com> In-Reply-To: <4f9dfd62-45cd-a307-a6d9-93b7cd4333a2@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Charles Repetti (charlie94965 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > Confirmed. > > - Charlie > > > On 7/6/16 10:01 PM, gedau AT igor2 DOT repo DOT hu wrote: >> Hi all, >> >> Evan found a bug in pcb-rnd which turned out to be a bug in mainline >> as well. It is really easy to reproduce from scratch: >> >> 1. draw a poly >> 2. draw a hole in it (strange: first click ignored?) >> 3. keep on drawing the second hole (strange: marker is not moved?) >> 4. bug: the poly of step 1 is duplicated (copied in place), and the >> new hole is created on the new poly >> >> Important: do not switch tool between step 2 and 3! This, together >> with the fact that it can be reproduced with both HIDs suggests it's >> a bug in core (the strangenesses are maybe related to handling of the >> mode variable, I have no idea how the poly gets dupped). >> >> Detecting the duplication polys: >> >> - save before and after step 4, compare the two save files; instead >> of one poly object with two holes there are two poly objects with one >> hole each >> >> - move the poly after step 4; expected: moving one poly; what happens >> instead: moving the top poly, leaving the bottom poly in place >> >> - in step 3 draw the second hole so that it has an intersection with >> the first; that intersection is the only copper hole at the end, >> because it is not covered by any of the polygons >> >> In pcb-rnd I am still knee-deep in the conf rewrite, but I plan to >> look at this bug after I finish. In case someone debugs this in >> mainline, I'm interested in the result. Else I can share my >> findings/patches when I get to it, so mainline developers can fix >> this in mainline. >> >> Regards, >> >> Igor2 >> >> > > Hi all, Bug report filed: https://bugs.launchpad.net/pcb/+bug/1604524 Kind regards, Bert Timmerman.