On Mon, Jan 4, 2016 at 3:07 AM, Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] <geda-user AT d= elorie.com> wrote:

Ok, sounds like a positive way to proceed, and the DEBUG define lo= oks like a clean way to hide the backtrace code from builds which won't= need it or won't work with it.

I'm alarmed to hear that your seeing the rtree code asse= rt. I guess you are running with DEBUG on, and that perhaps we've misse= d something that crept in at some point. This could be a tricky one, and I&= #39;d be interested to see any data you had on where it is asserting?
Unfortunately I don't recall exactly.=C2=A0 = I believe it's one of the first couple asserts in either r_search or __= r_search.=C2=A0 Apparently I never actually left ASSERT_BT() in any branch = (maybe once backtrace is merged :).=C2=A0 I can't get it to do it now e= ither but unless I'm special if you turn debug on you'll see it soo= ner or later.

I can't entirely recall if it was pcb or gschem where th= e arc code was already re written once during my involvement with the proje= ct (not by me). In the case I'm thinking of, the author told me they ha= d written a monte-carlo test to throw arbitrary data at the code and test f= or bugs. This kind of thing might be cool to try if you were keen to write = test cases=C2=A0

With regards rewriting geometry functions, I'd be intere= sted in a why - if they already worked. The old code looking ugly would be = a fine reason, just be extra sure the replacements will be well behaved ;)<= /p>
I wanted to know the actual intersection po= ints, so I could report them correctly in DRC.=C2=A0 To be honest I found s= ome intersection test functions so convoluted that I couldn't figure ou= t how to get a point out instead of just yes/no.=C2=A0 Then I found that a = number of them didn't work right for a lot of cases and decided to fact= or out common geometric abstractions.

At the end of the day, if these changes don't cause any = problems, we could just push / merge as is. Hopefully we won't need to = be bisecting across them. Keeping a clean patch series is more about review= than anything else for me,=C2=A0 and I do understand there are risks and t= radeoffs involved with rebasing and juggling patch series. (I backup a bran= ch, perhaps by tagging its HEAD before doing a big rebase).

I'll ask my kernel maintainer colleague how they deal wi= th big branches / patch series, for some comparison. I think there - they o= nly merge completed changes, and all the deltas are very clean. The project= s aren't exactly comparable of course - so we might decide to be differ= ent here.

If I catch you on IRC at some point, I'll probably ask y= ou to walk me through a quick high level summary of the big branch. That, a= nd a skim of the diffs is probably the most "help" I can be at th= e moment, and will hopefully give you an extra thumbs up to merge in.

Perhaps I can ask you to do the same with me, on some of my = branches after that? I at least need to rebase against HEAD first :).
I'll be happy to look.=C2=A0 I haven't d= one much with opengl in a while though.
=C2=A0
Britton