Mail Archives: geda-user/2015/10/27/14:26:08
--001a11c22a521a655305231a34cf
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 27, 2015 at 4:47 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> On Tue, 27 Oct 2015, Levente (leventelist AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
>
>> Okay people... sorry. Calm down.
>>
>
> No worries, I'm totally calm (I use pcb-rnd, and none of these ideas
> affect that fork).
>
>
>> Let us start a technical discussion.
>>
>> Igor2: I didn't want to reflect your other points.
>>
>> There is for exaple distance calculation code, polygon handling, so for
>> example we could detect polygons that are fully covered by another one.
>> That
>> is only one thing.
>> But there are others.
>>
>
> I think we should go the other way around. First enumerate what exactly is
> needed to clean up the current code at the parts where things are happening
> nowdays (Britton is in a good position for that, I think). Then
All I know is what's used in search.c and find.c. That code needs
intersection test and nearest-point between lines, points, rectangles
circles, and arcs of circles. I don't know on the polygon code since I've
never been able to successfully draw one in pcb I don't care.
In theory arcs of ellipse are supported but in practice the implementation
isn't there. I doubt we care. The toporouter which is the most demanding
curved-trace application I know of just uses arcs of circles. So I'd just
disallow creating them for the moment, and die if they show up in a pcb
file.
enumerate what's needed to clean up other parts of the code, like the poly
> dicer or the toporouter. Finally enumerate what kind of plans PCB has for
> the future and what features could potentially help those.
>
What the toporouter does need is 2D triangulated surface. My impression is
that it already uses CGAL via ruby. But I'm not sure that's a good reason
to use it everywhere. It's not at all C-friendly and it's heavy
--001a11c22a521a655305231a34cf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_quote">On Tue, Oct 27, 2015 at 4:4=
7 AM, <span dir=3D"ltr"><<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu" target=
=3D"_blank">gedau AT igor2 DOT repo DOT hu</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<span><br>
<br>
On Tue, 27 Oct 2015, Levente (<a href=3D"mailto:leventelist AT gmail DOT com" targ=
et=3D"_blank">leventelist AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT d=
elorie.com" target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
Okay people... sorry. Calm down.<br>
</blockquote>
<br></span>
No worries, I'm totally calm (I use pcb-rnd, and none of these ideas af=
fect that fork).<span><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
Let us start a technical discussion.<br>
<br>
Igor2: I didn't want to reflect your other points.<br>
<br>
There is for exaple distance calculation code, polygon handling, so for<br>
example we could detect polygons that are fully covered by another one. Tha=
t<br>
is only one thing.<br>
But there are others.<br>
</blockquote>
<br></span>
I think we should go the other way around. First enumerate what exactly is =
needed to clean up the current code at the parts where things are happening=
nowdays (Britton is in a good position for that, I think). Then </blockquo=
te><div><br>All I know is what's used in search.c and find.c.=C2=A0 Tha=
t code needs intersection test and nearest-point between lines, points, rec=
tangles circles, and arcs of circles.=C2=A0 I don't know on the polygon=
code since I've never been able to successfully draw one in pcb I don&=
#39;t care.<br><br>In theory arcs of ellipse are supported but in practice =
the implementation isn't there.=C2=A0 I doubt we care.=C2=A0 The toporo=
uter which is the most demanding curved-trace application I know of just us=
es arcs of circles.=C2=A0 So I'd just disallow creating them for the mo=
ment, and die if they show up in a pcb file. <br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>enumerate what's needed to clean up other parts of the code, like the =
poly dicer or the toporouter. Finally enumerate what kind of plans PCB has =
for the future and what features could potentially help those.<br></blockqu=
ote><div><br></div><div>What the toporouter does need is 2D triangulated su=
rface.=C2=A0 My impression is that it already uses CGAL via ruby.=C2=A0 But=
I'm not sure that's a good reason to use it everywhere.=C2=A0 It&#=
39;s not at all C-friendly and it's heavy<br></div><div><br></div></div=
>
</div>
--001a11c22a521a655305231a34cf--
- Raw text -