Le 30/04/2015 19:43, Wayne Stambaugh a écrit : > On 4/30/2015 1:38 PM, jp charras wrote: >> Le 30/04/2015 18:53, Wayne Stambaugh a écrit : >>> >>> >>> On 4/30/2015 7:28 AM, jp charras wrote: >>>> Le 29/04/2015 15:11, Wayne Stambaugh a écrit : >>>>> Blair, >>>>> >>>>> Thanks for testing this. I am curious if the boost::geometry issue has >>>>> been fixed. I looked at the change log and there were a bunch of bug >>>>> fixes in the geometry library. Although the bug report JP filed was not >>>>> among them. Hopefully they solved this problem. If someone could >>>>> verify that, I would appreciate it. >>>>> >>>>> Thanks, >>>>> >>>>> Wayne >>>>> >>>> >>>> The crash happens in 1.58, with my test program (the one I sent to the >>>> boost::polygon maintainer). >>>> >>>> >>> Sigh!!! I guess it was wishful thinking. It's been over two years >>> since this bug was filed and all we have is an acknowledgement that it >>> is indeed a problem. After the stable release, maybe we need to look at >>> alternate polygon libraries. >> >> There are not a lot of these libs (at least for FOSS). >> The last, not yet used or tested, (with an acceptable license) I know is >> CGAL. > > Is there some test condition for the polygon that causes the crash that > we can use to at least prevent the crash? I know it's less than ideal > but at least we can warn the user to change their clearances slightly > and refill the zone rather than allow Pcbnew to crash and potentially > cause data loss.
I don't know. The only one thing I noticed is the fact the risk is lowered when circles are approximated by 15, 17 or 18 segments instead of 16. But it is not null. > >> >> I am using Clipper for some operations not handled by Boost, but when >> combining polygons, the result is strange. >> >> This bug is really annoying, but to tell the True, the issue with >> boost::context (on Windows, not supporting gcc) is for me a lot more >> annoying. >> > > For all the hype about Boost, they are not very cooperative when it > comes to fixing things. I'm starting to regret that made kicad so > dependent on Boost. Removing it now would probably be more work than > providing our own Boost patches. > As long we are using only headers, Boost is acceptable and we can patch it. This is the fact we have to build some libraries, and mainly a library written in assembler which creates 90% of issues, because the building process is not compatible with gcc (for asm files) and is not compatible with mingw/msys2 for building tools, which is very dangerous for the near future. Therefore, this is mainly these libraries which have to be removed, not the full .hpp headers. But I agree, the less Boost is used, the better. -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
