www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2017/11/23/13:20:52

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]" <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: <alpine.DEB.2.00.1711231909130.27212@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1711210829310 DOT 27212 AT igor2priv> <20171123171301 DOT GH4167 AT stuge DOT se>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
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

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




- Raw text -


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