X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Wed, 16 Dec 2015 15:12:03 -0500
Message-Id: <201512162012.tBGKC3w8013222@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to:
	<CAC4O8c8jaeiyrD4eEcWAR69GC=nd__gBLfPtstNUfQDAstvBcA AT mail DOT gmail DOT com>
	(geda-user AT delorie DOT com)
Subject: Re: [geda-user] merge please (or rebase if you must)
References: <CAC4O8c_Jc98kmjDp_O2hKbY9BWWAjGk+nb0L5L=jqXfeTAYGGA AT mail DOT gmail DOT com>
	<201512152309 DOT tBFN90dS016514 AT envy DOT delorie DOT com> <CAC4O8c8jaeiyrD4eEcWAR69GC=nd__gBLfPtstNUfQDAstvBcA AT mail DOT gmail DOT com>
Reply-To: geda-user AT delorie DOT com


> > 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

> > 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...

> > 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 :-)

> > 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

It's for backwards compatibility - older file formats have a different
syntax.

And no, I have no such files, I read the diff.

> > "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.

As noted elsewhere, it's probably not a problem anyway.  I was
thinking of the limits of 32 bit coords, we're nowhere near the limits
on 64 bit coords.