Mail Archives: geda-user/2015/12/16/15:01:39
--001a1148e62ab160a50527095eb1
Content-Type: text/plain; charset=UTF-8
On Tue, Dec 15, 2015 at 2:09 PM, DJ Delorie <dj AT delorie DOT com> wrote:
> PCB does support width!=height arcs, for example, the gerber HID has
> special code for drawing them. Why are we removing support for them?
There was no real implementation in find.c or search.c. There are comments
to
that effect in the original code. I checked if the renderer handled them,
and it didn't, it just draws an arc of circle (using I don't know which
dimension). It may have gerber export done as you say, but if so that's
about the only thing that's in place. They are a lot more work and slower
to test intersections (iterative solution required), and mostly pointless
compared to an arc of circle and a line or three. Apparently no one is
using them now. We don't anticipate needing them for anything that I know
of.
> I note you use // for comments. If we're going this route, we should
> update configure to test for a C99-compliant compiler.
This is probably a pretty safe assumption now.
> arcs with square ends - yeah, we can probably ignore those. Although
> it's better to keep the arcs (and drop the square end flag) than drop
> the arc completely.
Ok.
> In many cases in the geometry module, you use Vec where you mean
> Point. Granted, the data is the same, but the meanings should be
> clear to the user, since it's part of the "documentation".
It bugs me too. The C alternatives I'm aware of are:
* use casts wherever a conversion happens. Not sure how ugly it would
get in this particular case but it usually gets ugly pretty fast this
way
I've done similar stuff the more pedantic way with Vec as another
dynamically allocated type and it's so ugly, you end up with more math
bugs
from trying to keep track of it all
* Change Vec to Tuple so people can't complain :)
> I think the debug markers should either be removed for now, or
> "completed" - added to all HIDs and documented with some
> programmer-specific documentation.
Would you settle for stubs in the non-gtk HIDs, and programmer
documentation?
It's not obvious to me how to do it in lesstif and I have no real motivation
to figure it out. What do you mean by programmer documentation besides
comments in hid.h?
> has_flag() shouldn't be needed as the parser converts strings on read.
Yeah it's left-over junk, I'll remove
> The right way to ignore square flags on arcs is to update the flag
> parsing table so that it's not in the supported flags... oh wait, it's
> already ignored there.
I didn't find this table... so I can just take out all the square arc stuff
and it should do the right thing (though a message would be nice really)?
> Rather than check for zero-sized arcs, check for non-positive-sized arcs.
Ok.
> Foo foo foooo, twice. With an abort, no less.
Well I was making sure I'd found the arc parser. Seems you have some
old-style arcs around
> "double" type isn't precise enough to hold a pcb coord - "double" is
> 53 bits, but Coord is 64 bits. Does this matter?
Well, the existing geometry code does this quite a lot.
My system is so old Coord is 32 on it (I guess that's why) and it works
fine,
so I think it's ok. It bugs me too though. In pcb_geometry.h I have this:
// I'd like ensure that the floating point type used always be wider than
// the coordinate type, to guarantee that we can go from the latter to the
// former without loss, but pcb doesn't do this and it would be a
significant
// change to the build requirements. This would do it:
//_Static_assert (
// (sizeof (GEOM_DEFAULT_FLOAT_TYPE) > sizeof (Coord)),
// "floating point type for geometry.h not wider than Coord type" );
I'll uncomment that and use long double if you want, though as a subsequent
poster pointed out it's probably ok precision-wise as it is.
> You left debugging enabled in search.c
I'll remove it.
Britton
--001a1148e62ab160a50527095eb1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div class=3D"gmail_quote">On Tue, Dec 15, 2015 at 2:09 PM, DJ Delorie =
<<a href=3D"mailto:dj AT delorie DOT com">dj AT delorie DOT com</a>> wrote:</div><d=
iv class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> PCB does=
support width!=3Dheight arcs, for example, the gerber HID has</div><div cl=
ass=3D"gmail_quote">> special code for drawing them.=C2=A0 Why are we re=
moving support for them?</div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">There was no real implementation in find.c or search.c.=
=C2=A0 There are comments to</div><div class=3D"gmail_quote">that effect in=
the original code.=C2=A0 I checked if the renderer handled them,</div><div=
class=3D"gmail_quote">and it didn't, it just draws an arc of circle (u=
sing I don't know which</div><div class=3D"gmail_quote">dimension).=C2=
=A0 It may have gerber export done as you say, but if so that's</div><d=
iv class=3D"gmail_quote">about the only thing that's in place.=C2=A0 Th=
ey are a lot more work and slower</div><div class=3D"gmail_quote">to test i=
ntersections (iterative solution required), and mostly pointless</div><div =
class=3D"gmail_quote">compared to an arc of circle and a line or three.=C2=
=A0 Apparently no one is</div><div class=3D"gmail_quote">using them now.=C2=
=A0 We don't anticipate needing them for anything that I know of.</div>=
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> I note=
you use // for comments.=C2=A0 If we're going this route, we should</d=
iv><div class=3D"gmail_quote">> update configure to test for a C99-compl=
iant compiler.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">This is probably a pretty safe assumption now.</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">> arcs with square end=
s - yeah, we can probably ignore those.=C2=A0 Although</div><div class=3D"g=
mail_quote">> it's better to keep the arcs (and drop the square end =
flag) than drop</div><div class=3D"gmail_quote">> the arc completely.</d=
iv><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Ok.</div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> In ma=
ny cases in the geometry module, you use Vec where you mean</div><div class=
=3D"gmail_quote">> Point.=C2=A0 Granted, the data is the same, but the m=
eanings should be</div><div class=3D"gmail_quote">> clear to the user, s=
ince it's part of the "documentation".</div><div class=3D"gma=
il_quote"><br></div><div class=3D"gmail_quote">It bugs me too.=C2=A0 The C =
alternatives I'm aware of are:</div><div class=3D"gmail_quote"><br></di=
v><div class=3D"gmail_quote">=C2=A0 * use casts wherever a conversion happe=
ns.=C2=A0 Not sure how ugly it would</div><div class=3D"gmail_quote">=C2=A0=
=C2=A0 get in this particular case but it usually gets ugly pretty fast th=
is way</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 I've done similar =
stuff the more pedantic way with Vec as another</div><div class=3D"gmail_qu=
ote">=C2=A0 =C2=A0 dynamically allocated type and it's so ugly, you end=
up with more math bugs</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 from =
trying to keep track of it all</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">=C2=A0 * Change Vec to Tuple so people can't c=
omplain :)</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote"><br></div><div class=3D"gmail_quote">> I think the debug markers sh=
ould either be removed for now, or</div><div class=3D"gmail_quote">> &qu=
ot;completed" - added to all HIDs and documented with some</div><div c=
lass=3D"gmail_quote">> programmer-specific documentation.</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Would you settle for=
stubs in the non-gtk HIDs, and programmer documentation?</div><div class=
=3D"gmail_quote">It's not obvious to me how to do it in lesstif and I h=
ave no real motivation</div><div class=3D"gmail_quote">to figure it out.=C2=
=A0 What do you mean by programmer documentation besides</div><div class=3D=
"gmail_quote">comments in hid.h?</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">> has_flag() shouldn't be needed as the p=
arser converts strings on read.</div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">Yeah it's left-over junk, I'll remove</di=
v><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> The =
right way to ignore square flags on arcs is to update the flag</div><div cl=
ass=3D"gmail_quote">> parsing table so that it's not in the supporte=
d flags... oh wait, it's</div><div class=3D"gmail_quote">> already i=
gnored there.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">I didn't find this table... so I can just take out all the squa=
re arc stuff</div><div class=3D"gmail_quote">and it should do the right thi=
ng (though a message would be nice really)?</div><div class=3D"gmail_quote"=
><br></div><div class=3D"gmail_quote">> Rather than check for zero-sized=
arcs, check for non-positive-sized arcs.</div><div class=3D"gmail_quote"><=
br></div><div class=3D"gmail_quote">Ok.</div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote">> Foo foo foooo, twice.=C2=A0 With an =
abort, no less.</div><div class=3D"gmail_quote"><br></div><div class=3D"gma=
il_quote">Well I was making sure I'd found the arc parser.=C2=A0 Seems =
you have some</div><div class=3D"gmail_quote">old-style arcs around</div><d=
iv class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> "do=
uble" type isn't precise enough to hold a pcb coord - "double=
" is</div><div class=3D"gmail_quote">> 53 bits, but Coord is 64 bit=
s.=C2=A0 Does this matter?</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote" style=3D"">Well, the existing geometry code does this =
quite a lot.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">My system is so old Coord is 32 on it (I guess that's why) and i=
t works fine,</div><div class=3D"gmail_quote">so I think it's ok.=C2=A0=
It bugs me too though.=C2=A0 In pcb_geometry.h I have this:</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">// I'd like ensu=
re that the floating point type used always be wider than</div><div class=
=3D"gmail_quote">// the coordinate type, to guarantee that we can go from t=
he latter to the</div><div class=3D"gmail_quote">// former without loss, bu=
t pcb doesn't do this and it would be a significant</div><div class=3D"=
gmail_quote">// change to the build requirements.=C2=A0 This would do it:</=
div><div class=3D"gmail_quote">//_Static_assert (</div><div class=3D"gmail_=
quote">// =C2=A0 =C2=A0(sizeof (GEOM_DEFAULT_FLOAT_TYPE) > sizeof (Coord=
)),</div><div class=3D"gmail_quote">// =C2=A0 =C2=A0"floating point ty=
pe for geometry.h not wider than Coord type" );</div><div class=3D"gma=
il_quote"><br></div><div class=3D"gmail_quote">I'll uncomment that and =
use long double if you want, though as a subsequent</div><div class=3D"gmai=
l_quote">poster pointed out it's probably ok precision-wise as it is.</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> Yo=
u left debugging enabled in search.c</div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote" style=3D"">I'll remove it.</div><div cla=
ss=3D"gmail_quote" style=3D""><br></div><div class=3D"gmail_quote" style=3D=
"">Britton</div></div></div></div>
--001a1148e62ab160a50527095eb1--
- Raw text -