Mail Archives: geda-user/2016/01/04/15:59:44
--001a114242a496e52f0528886467
Content-Type: text/plain; charset=UTF-8
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 delorie DOT com> wrote:
> Ok, sounds like a positive way to proceed, and the DEBUG define looks 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 assert. I guess you
> are running with DEBUG on, and that perhaps we've missed something that
> crept in at some point. This could be a tricky one, and I'd be interested
> to see any data you had on where it is asserting?
>
Unfortunately I don't recall exactly. I believe it's one of the first
couple asserts in either r_search or __r_search. Apparently I never
actually left ASSERT_BT() in any branch (maybe once backtrace is merged
:). I can't get it to do it now either but unless I'm special if you turn
debug on you'll see it sooner or later.
> I can't entirely recall if it was pcb or gschem where the arc code was
> already re written once during my involvement with the project (not by me).
> In the case I'm thinking of, the author told me they had written a
> monte-carlo test to throw arbitrary data at the code and test for bugs.
> This kind of thing might be cool to try if you were keen to write test
> cases
>
With regards rewriting geometry functions, I'd be interested 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 ;)
>
I wanted to know the actual intersection points, so I could report them
correctly in DRC. To be honest I found some intersection test functions so
convoluted that I couldn't figure out how to get a point out instead of
just yes/no. Then I found that a number of them didn't work right for a
lot of cases and decided to factor 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, and I do understand there are risks and tradeoffs involved with
> rebasing and juggling patch series. (I backup a branch, perhaps by tagging
> its HEAD before doing a big rebase).
>
> I'll ask my kernel maintainer colleague how they deal with big branches /
> patch series, for some comparison. I think there - they only merge
> completed changes, and all the deltas are very clean. The projects aren't
> exactly comparable of course - so we might decide to be different here.
>
If I catch you on IRC at some point, I'll probably ask you to walk me
> through a quick high level summary of the big branch. That, and a skim of
> the diffs is probably the most "help" I can be at the 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. I haven't done much with opengl in a while though.
Britton
--001a114242a496e52f0528886467
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 Mon, Jan 4, 2016 at 3:07 AM, Peter Clifton (<a href=3D"mailto:peterc=
jclifton AT googlemail DOT com">petercjclifton AT googlemail DOT com</a>) [via <a href=3D=
"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"=
><<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT d=
elorie.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">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.</p>
<p dir=3D"ltr">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?</p></=
blockquote><div style=3D"">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.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">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</p></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">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></blockquote><div style=3D"">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.</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">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).</p>
<p dir=3D"ltr">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.</p></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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 :).</p></=
blockquote><div style=3D"">I'll be happy to look.=C2=A0 I haven't d=
one much with opengl in a while though.</div><div>=C2=A0</div><div style=3D=
"">Britton</div></div></div></div>
--001a114242a496e52f0528886467--
- Raw text -