<div dir="ltr">Hi,<br><br>Thanks for trusting in my work.<br>This plan is fine to me, I will work on it. I just suggest to rename the configuration setting 'dijkstraHeapBinary' to 'dijkstraBinaryHeap'.<br><br>Diogo.</div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-31 7:43 GMT-03:00 Ferry Huberts <span dir="ltr"><<a href="mailto:mailings@hupie.com" target="_blank">mailings@hupie.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok guys.<br>
<br>
Henning and I talked about this and we're willing to merge the work.<br>
<br>
However, don't cheer to soon because we do have a few demands that must be met before we actually merge it.<br>
<br>
The plan:<br>
1- I'll create a new branch 'dijkstra-binary-heap' next week<br>
2- On that branch I'll put patches that create a new configuration setting 'dijkstraHeapBinary'.<br>
3- You will rebase your branch on the new branch.<br>
4- You will rework your patches such that:<br>
- they are reviewable (see )<br>
- the configuration setting 'dijkstraHeapBinary' determines whether the current heap code is used or your code.<br>
<br>
If your rework is complete, we'll review it again.<br>
<br>
<br>
How is that for a plan?<br>
Please let us know.<br>
<br>
<br>
Ferry & Henning<br>
<br>
PS. Henning would like to pick up your work for olsrd v2 once complete.<span class=""><br>
<br>
On 31/07/15 08:48, Diogo Gonçalves wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
ohh, you are right, thank you!<br>
<br>
If all node's pointers are NULL, the node isn't in the heap, but there<br>
is one special case for root node, this node doesn't point to another one.<br>
<br>
I already fixed it in the function. Thank you again.<br>
<br>
Diogo<br>
<br>
2015-07-31 3:02 GMT-03:00 Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a><br></span>
<mailto:<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>>>:<span class=""><br>
<br>
No,<br>
<br>
I think we are mostly fine...<br>
<br>
Just a last question about the new "heap_is_node_added" inline... are<br>
you sure about the second return command? I think it will only return<br>
"true" if all three fields in the heap are NULL.<br>
<br>
What are you trying to test, are ALL of these fields initialized<br>
normally or just a few of them?<br>
<br>
If all of them are !NULL I would suggest replacing the if() condition<br>
and the both return with:<br>
> return node && node->parent && node->left && node->right;<br>
<br>
if just one of them should be !NULL, maybe this will work:<br>
> return node && (node->parent || node->left || node->right);<br>
<br>
Henning<br>
<br>
On Fri, Jul 31, 2015 at 7:55 AM, Diogo Gonçalves<br>
<<a href="mailto:diogomachadogoncalves@gmail.com" target="_blank">diogomachadogoncalves@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:diogomachadogoncalves@gmail.com" target="_blank">diogomachadogoncalves@gmail.com</a>>> wrote:<br>
> Hi,<br>
><br>
> I updated my binary heap lib in the olsrd [1] with some static<br>
functions. Is<br>
> there something else that I can do?<br>
><br>
> [1]<a href="https://github.com/diogomg/olsrd" rel="noreferrer" target="_blank">https://github.com/diogomg/olsrd</a><br>
><br>
> 2015-07-30 9:22 GMT-03:00 Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a><br></span>
<mailto:<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>>>:<span class=""><br>
>><br>
>> Hi,<br>
>><br>
>> I lost a bit track of this while away at the IETF in Prague...<br>
>><br>
>> Can you send a new patch with the current version of the code to the<br>
>> list? I think we can clean up the rest inside the <a href="http://olsr.org" rel="noreferrer" target="_blank">olsr.org</a><br></span>
<<a href="http://olsr.org" rel="noreferrer" target="_blank">http://olsr.org</a>> repository.<span class=""><br>
>><br>
>> Is the github code still "up to date" in terms of the head.[ch]<br>
code?<br>
>> If yes I will give it a try to use it in the olsrd2 Dijkstra too.<br>
>><br>
>> Henning Rogge<br>
>><br>
>> On Tue, Jul 14, 2015 at 9:27 PM, Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>>> wrote:<br>
>> > Yes,<br>
>> ><br>
>> > that looks better... always a good idea to keep the internal<br>
functions<br>
>> > hidden.<br>
>> ><br>
>> > Henning<br>
>> ><br>
>> > On Tue, Jul 14, 2015 at 5:19 PM, Diogo Gonçalves<br>
>> > <<a href="mailto:diogomachadogoncalves@gmail.com" target="_blank">diogomachadogoncalves@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:diogomachadogoncalves@gmail.com" target="_blank">diogomachadogoncalves@gmail.com</a>>> wrote:<br>
>> >> HI,<br>
>> >><br>
>> >> I cleaned up my heap.h[1], leaving only functions for the<br>
users, as you<br>
>> >> asked me. I hope i'm on right way but I know that there are<br>
>> >> improvements to<br>
>> >> do, so if you have something else to suggest you can ask me.<br>
>> >><br>
>> >><br>
>> >> [1] <a href="https://github.com/diogomg/olsrd" rel="noreferrer" target="_blank">https://github.com/diogomg/olsrd</a><br>
>> >><br>
>> >> 2015-07-13 14:10 GMT-03:00 Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a><br></span>
<mailto:<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>>>:<span class=""><br>
>> >>><br>
>> >>> Hi,<br>
>> >>><br>
>> >>> since we have some people to ask when we have questions<br>
about it, I<br>
>> >>> think it will be good to merge.<br>
>> >>><br>
>> >>> But I would also like someone of you to look after it when I<br>
build it<br>
>> >>> into the olsrd2 dijkstra. If you can clean up the "heap.h"<br>
file so<br>
>> >>> that it only contains the necessary functions for an user<br>
(and not the<br>
>> >>> internal ones), it should be easy to supply a few good<br>
accessor macros<br>
>> >>> (similar to list.h and avl.h in OONF).<br>
>> >>><br>
>> >>> Henning<br>
>> >>><br>
>> >>> On Mon, Jul 13, 2015 at 7:07 PM, Saulo Queiroz<br></span>
<<a href="mailto:ssaulojorge@gmail.com" target="_blank">ssaulojorge@gmail.com</a> <mailto:<a href="mailto:ssaulojorge@gmail.com" target="_blank">ssaulojorge@gmail.com</a>>><span class=""><br>
>> >>> wrote:<br>
>> >>> > Ferry and Henning, ok.<br>
>> >>> > We have just to care about real routing metrics, like ETX<br>
>> >>> > since the priority queue will be arranged based on such<br>
>> >>> > real value. What you think?<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On 13 July 2015 at 13:47, Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>>> wrote:<br>
>> >>> >><br>
>> >>> >> On Mon, Jul 13, 2015 at 6:01 PM, Saulo Queiroz<br></span>
>> >>> >> <<a href="mailto:ssaulojorge@gmail.com" target="_blank">ssaulojorge@gmail.com</a> <mailto:<a href="mailto:ssaulojorge@gmail.com" target="_blank">ssaulojorge@gmail.com</a>>><span class=""><br>
>> >>> >> wrote:<br>
>> >>> >> > Yes,<br>
>> >>> >> > something like 1/priority_value (for instance) might work.<br>
>> >>> >><br>
>> >>> >> I thought more about (UINT32_MAX-value)<br>
>> >>> >><br>
>> >>> >> Henning<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > --<br>
>> >>> > Saulo Jorge bq<br>
>> >>> > -<br>
>> >>> > "In theory, there is no difference between practice and<br>
theory, in<br>
>> >>> > practice<br>
>> >>> > there is"<br>
>> >>> > -- Someone<br>
>> >><br>
>> >><br>
><br>
><br>
<br>
<br>
<br>
<br>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
Ferry Huberts<br>
</font></span></blockquote></div><br></div>