<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Mar 2016, at 16:57, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" class="">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Hi,<br class=""></div>I feel like I did not explain my short term goals.<br class="">This lack of explanation may let my recent commit be viewed as gratuitous breakage.<br class=""><br class=""></div>They are not. What I'm after is:<br class=""><br class=""></div>- reduce the number of C Undefined Behaviours that we depend upon<br class=""></div><div class=""> my own vm brand can be compiled without the -fwrapv workaround, it's doable.<br class=""></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div><div>Excellent I love that</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">- eliminate ever more C compiler warnings<br class=""></div><div class=""> Eliot did really a great job these last two years<br class=""></div><div class=""> maybe we're not yet ready to compile with -Wall -Werror, but we are approaching<br class=""></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div>Excellent that too. </div><div>I think that it will improve quality. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">- simplify the slang source when possible<br class=""></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div>Would be nice. <br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">- connect the 32 bits limbs trick for accelerating large integer arithmetic<br class=""><br class=""></div>About this last point, I'm now thinking about a different strategy for the hypothetical BIG-ENDIAN machines: swap bytes while fetching/storing limbs instead of using native order tricks.<br class=""></div>It's more robust and not really expensive nowadays.<br class=""></div><div class="">This way, the code that would fetch largeInteger bytes would still work unchanged.<br class=""></div><div class="">Also no need to hack ImageSegment and image version number.<br class=""></div><div class=""><br class=""></div>I'm thinking of using the approach of this kind of references:<br class=""><a href="http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp" target="_blank" class="">http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp</a><br class=""><a href="https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun" target="_blank" class="">https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun</a><br class=""><a href="http://hardwarebug.org/2010/01/14/beware-the-builtins/" target="_blank" class="">http://hardwarebug.org/2010/01/14/beware-the-builtins</a><br class=""><a href="http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c" target="_blank" class="">http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c</a><br class=""><br class=""></div>So, once again, apologies for the hiccups, </div></div></div></div></div></div></blockquote><div><br class=""></div><div>there is no problems about hiccups this is life.</div><div>there are problems not taming then with computer power and not engineer time. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">there might be a few more, even if I'll try my best to take it seriously and carefully, it's currently too expensive to guaranty non regression. With a single dev branch, it's more than expensive, it's impossible.<br class=""><br class=""></div>Until we come with a more modern architecture, please don't consider that each and every monticello commit is OK to take as is.<br class="">Eliot has short release cycles, and he does generally commit on .SVN repository when there is a MC version ready with enough added value and enough stability. That's not at each and every MC version.<br class=""><br class=""></div>It's far from perfect, and maybe won't scale once a few more people add noise.<br class=""></div>But in the interim, my advice is to synch the production on .SVN release and associated MC version, not on MC. <br class="">Running tests for the two are different jobs, that's a way to mitigate the fact that we have a single branch.<br class=""><br class=""></div><div class="">cheers<br class=""></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>