X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Thu, 23 Nov 2017 19:30:33 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: push & shove (was: Re: [geda-user] [dev] rtree rewrite -> minilib) In-Reply-To: <20171123171301.GH4167@stuge.se> Message-ID: References: <20171123171301 DOT GH4167 AT stuge DOT se> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Precedence: bulk Hello Peter, On Thu, 23 Nov 2017, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] wrote: > Have you looked at the data structures used by the KiCAD PCB tool? > It also uses R-trees, but maybe not quite the same way? > > I didn't think of it at first, but the push-and-shove effort that > CERN contributed to KiCAD seems to tie into this part of the code, > and I think it would be great to be able to reuse that at some point! > > In this video from a few years ago: > https://video.fosdem.org/2015/devroom-electronic_design_automation/pcb_routing.mp4 > > the (one?) developer of that feature goes into some detail about > KiCAD data structures for geometry. > > > Do you see some overlap, enough to reuse their work? R-tree-wise: I don't think rtrees have anything to do with push&shove. Well, not more than arrays, lists or loops in general. About push&shove.... The video, their implementation: looks good. They have largely different data structures from ours so they pick different approach to solve problems. What works there won't work here and vice versa. Our implementation: we are working on small features that will some day lead to push&shove in pcb-rnd. It will take a lot of time, and the implementation will be different from theirs in many aspects. It's because the differences in what tools and algorithms already available in the code base and what small, useful features we can add before it all gets together to form a push&shove. Overlap: I see some theoretical overlap; mostly overlap in some basic ideas. I don't see any actual algorithmic or code overlap. Reusing their code: Absolutely not. Kicad is C++ and depends on boost; pcb-rnd is C89 and avoids large dependencies. The two worlds are very far apart. Reusing any code from kicad would cost magnitudes more time and effort than writing the same thing from scratch. It's just not worth it. Push&shove roadmap: nothing specific at the moment; we are working on those features that are already useful in themselves and will also be needed for P&S. The data model rewrite/cleanup that is near to compete with padstacks will help a lot too. On the other hand, according to my experience, P&S is a hot topic among virtual users but seems to be much less of a "we must have it by tomorrow" thing for our actual users. I mean they would love it too, but there seem to be higher priority tasks. So it's not likely that we would go and concentrate on P&S starving all the other ongoing efforts. Regards, Igor2