Mail Archives: geda-user/2015/12/18/20:58:19
--047d7b5d49769ea77705273695d3
Content-Type: text/plain; charset=UTF-8
On Wed, Dec 16, 2015 at 11:12 AM, DJ Delorie <dj AT delorie DOT com> wrote:
>
> > > 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.
>
> Still, a check would be nice.
>
> > It bugs me too. The C alternatives I'm aware of are:
>
> #define Point Vec
>
Funny what you don't think of. Seems a good way, no need for the compiler
to know what's going on in this case. At first I though this would break
down for the signatures of functions that take arguments which could be
either Point or Vec, but I think I got over it. This seems to be saying
that Point is-a Vec (implicitly from 0, so restricted in a sense), which
means routines that would take a supertype if one existed (e.c. vec_from())
can still use Vec in argument signatures without the choice being
arbitrary. So it's like it is now with Vec the supertype, only you can
specify the more specific Point sub-type many places for readability.
> > > 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?
>
> Sure. At the moment, it's just a couple extra functions that nobody
> calls and aren't documented. I still don't really know what they're
> used for...
>
Any time you make a geometrical calculation that spits out something that
can be represented with a point or two, its an easy way to check if it's
doing what is expected regardless of scale or background color. So you can
easily check intermediate results and such. I tried to document them by
commenting them in hid.h. If the comments don't make it clear what they
are for please advise how to change them. Where would you like them
documented besides hid.h?
> > > 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)?
>
> strflags.c
>
> There are a lot of unsupported flags that we don't error (or warn)
> for, if you want to add warnings for them, go for it :-)
>
Ok, I've done this. I just added some code to complain and clear the flag
if it's type doesn't support it according to the tables.
For now its only called for arcs but can be added for other types later.
Britton
--047d7b5d49769ea77705273695d3
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">On Wed, Dec 16, 2015 at 11:12 AM, DJ Delorie <span dir=3D"ltr"><<a h=
ref=3D"mailto:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
> > I note you use // for comments.=C2=A0 If we're going this rou=
te, we should<br>
> > update configure to test for a C99-compliant compiler.<br>
><br>
> This is probably a pretty safe assumption now.<br>
<br>
</span>Still, a check would be nice.<br>
<span class=3D""><br>
> It bugs me too.=C2=A0 The C alternatives I'm aware of are:<br>
<br>
</span>#define Point Vec<br></blockquote><div><br></div><div style=3D"">Fun=
ny what you don't think of.=C2=A0 Seems a good way, no need for the com=
piler to know what's going on in this case.=C2=A0 At first I though thi=
s would break down for the signatures of functions that take arguments whic=
h could be either Point or Vec, but I think I got over it.=C2=A0 This seems=
to be saying that Point is-a Vec (implicitly from 0, so restricted in a se=
nse), which means routines that would take a supertype if one existed (e.c.=
vec_from()) can still use Vec in argument signatures without the choice be=
ing arbitrary.=C2=A0 So it's like it is now with Vec the supertype, onl=
y you can specify the more specific Point sub-type many places for readabil=
ity.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
> > I think the debug markers should either be removed for now, or<br=
>
> > "completed" - added to all HIDs and documented with som=
e<br>
> > programmer-specific documentation.<br>
><br>
> Would you settle for stubs in the non-gtk HIDs, and programmer<br>
> documentation?<br>
> It's not obvious to me how to do it in lesstif and I have no real =
motivation<br>
> to figure it out.=C2=A0 What do you mean by programmer documentation b=
esides<br>
> comments in hid.h?<br>
<br>
</span>Sure.=C2=A0 At the moment, it's just a couple extra functions th=
at nobody<br>
calls and aren't documented.=C2=A0 I still don't really know what t=
hey're<br>
used for...<br></blockquote><div><br></div><div style=3D"">Any time you mak=
e a geometrical calculation that spits out something that can be represente=
d with a point or two, its an easy way to check if it's doing what is e=
xpected regardless of scale or background color.=C2=A0 So you can easily ch=
eck intermediate results and such.=C2=A0 I tried to document them by commen=
ting them in hid.h.=C2=A0 If the comments don't make it clear what they=
are for please advise how to change them.=C2=A0 Where would you like them =
documented besides hid.h?</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D"">
> > The right way to ignore square flags on arcs is to update the fla=
g<br>
> > parsing table so that it's not in the supported flags... oh w=
ait, it's<br>
> > already ignored there.<br>
><br>
> I didn't find this table... so I can just take out all the square =
arc stuff<br>
> and it should do the right thing (though a message would be nice reall=
y)?<br>
<br>
</span>strflags.c<br>
<br>
There are a lot of unsupported flags that we don't error (or warn)<br>
for, if you want to add warnings for them, go for it :-)<br></blockquote><d=
iv><br></div><div style=3D"">Ok, I've done this.=C2=A0 I just added som=
e code to complain and clear the flag if it's type doesn't support =
it according to the tables.</div><div style=3D"">For now its only called fo=
r arcs but can be added for other types later.</div><div><br></div><div sty=
le=3D"">Britton</div></div></div></div>
--047d7b5d49769ea77705273695d3--
- Raw text -