delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/04/15:59:44

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=gRcR5xylORnek5zTSTiDhtubLJr0E0EWl31JtfF2k0k=;
b=uCCxmJGC1pV+ay8fJougnMJGiMgOoDc8XmcGL307EYu5ih86larAyrJeV/YY5zlnWA
YdA93ogxfrhkGfOyMYcUIu/Z3IVSnlH56HlNv+N3gd0vwNzs+Od4qnAL0F4IvV5yDz1d
BNUQGWBxEGnfgdd3twxBzw4IghdTJIaPYNj5QB/3TfYiktTa/H+ilpZ4g25dQ2XFeiho
Ptosjl/t+AwUu8HT4/UuDWxv6tm348mbpAoCwl9W0w1IZhTVa7M/w92QWw9GdA93MJEw
hgNkSM1rgF1ALml0sgBWJxCGsPTZDTHCTs2U8cU9d8/eRMARtzc1ojn1sGWrVE+KdozS
x1Qw==
MIME-Version: 1.0
X-Received: by 10.28.48.131 with SMTP id w125mr402212wmw.18.1451941151824;
Mon, 04 Jan 2016 12:59:11 -0800 (PST)
In-Reply-To: <CAJXU7q8eto_ByskRgpQJB47YjEqOc5vaXwQ-7tGsQfefC403eQ@mail.gmail.com>
References: <CAC4O8c_p5bMB1cKzDEsQFSnbZvY3TgnczH94pO_qCoJmiv2iWQ AT mail DOT gmail DOT com>
<CAJXU7q9rMcQpLU5020RoZTqskT4moOS6f3Ugw+g3_mhO565MLg AT mail DOT gmail DOT com>
<CAC4O8c-nPx1isS2DA4=X1vQFVY51vQ6pAY6sSfHBMog_m0_2dg AT mail DOT gmail DOT com>
<CAJXU7q8jLiY2oAGmkgfXfzdNoAg2xVRx8bxgAXyF_qqYs=9Dgw AT mail DOT gmail DOT com>
<CAC4O8c8=Vh7DcVrdrG4GE7ssBNG_VuxDLw2JSyg=Bv7Lnvfysg AT mail DOT gmail DOT com>
<CAJXU7q-iNx7PVbZHe_SC+VGs1SN-zOSPEyQjBc6CS2qD8wnpvw AT mail DOT gmail DOT com>
<CAC4O8c8sm-jp7+jvV_QJ9Zskwb31JsmPUA+BY2UkUMg31_Htsg AT mail DOT gmail DOT com>
<CAJXU7q_K3xSdNWaZy3AZ_zCCAGWjvasc8TrJYrD5xz-CZujYDA AT mail DOT gmail DOT com>
<CAC4O8c_=Hch0ttt56fyfTFaw+tcpsNG9ZA9wyfeLCynK=Bqp0A AT mail DOT gmail DOT com>
<CAJXU7q8eto_ByskRgpQJB47YjEqOc5vaXwQ-7tGsQfefC403eQ AT mail DOT gmail DOT com>
Date: Mon, 4 Jan 2016 11:59:11 -0900
Message-ID: <CAC4O8c9At_WbRJcZ8DAUeBy4xm9hCdOcVBWc3PJGMLD7NxAKPw@mail.gmail.com>
Subject: Re: [geda-user] Merging stuff. How to make it happen
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

--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"=
>&lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT d=
elorie.com</a>&gt;</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&#39;t=
 need it or won&#39;t work with it.</p>
<p dir=3D"ltr">I&#39;m alarmed to hear that your seeing the rtree code asse=
rt. I guess you are running with DEBUG on, and that perhaps we&#39;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&#39;t recall exactly.=C2=A0 =
I believe it&#39;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&#39;t get it to do it now e=
ither but unless I&#39;m special if you turn debug on you&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;t cause any =
problems, we could just push / merge as is. Hopefully we won&#39;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&#39;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&#39;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&#39;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 &quot;help&quot; 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&#39;ll be happy to look.=C2=A0 I haven&#39;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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019