On 06/08/18 18:35, Seth Hillbrand wrote: > > There's another 32-bit RTree issue that is showing its face > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905221). The last > one (https://bugs.launchpad.net/kicad/+bug/1774316), we hacked around > for v5 but as this seems to be a recurring theme, I'd like to address it > with some finality. > > We could maintain the RTree implementation ourselves with updates to > correct these errors. > Or, we could use the Boost-based implementation > (https://www.boost.org/doc/libs/1_67_0/libs/geometry/doc/html/geometry/reference/spatial_indexes/boost__geometry__index__rtree.html). > > I have a basic framework for shifting to the Boost-based > implementation. In tests, I don't see a speed difference in running. > Compiling might be modestly slower.
Hi Seth, I would be careful with anything related to geometry in Boost. Good things from Boost sooner or later end up in the standard C++ library (e.g. unordered). We had a lot of trouble in the past with crashes in boost::polygon that nobody could debug or even understand because of the vast complexity of Boost code. We struggled for few months to replace it with Clipper, since then, we've seen no crashes in polygon boolean ops. If the solution to fix the current R-tree to work on 32-bit platforms is to use doubles instead of floats, why not try it out? By changing to boost::geometry, we'll likely have to report bugs there. I'm also quite surprised this bug surfaced on one particular OS (Debian) 5 years after this R-tree implementation had been introduced to pcbnew. Does anyone here know why it crashes on Debian and not on other 32-bit systems? Tom _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
