<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 8, 2016 at 2:51 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi Eliot,<br></div>the VMMaker changes relative to LLP64 are so far really tiny: just the change of CCodeGenerator for >> and the memcpy.<br></div>I think it's easy enough to revert and test if it changes anything to stability.<br><br></div>One bad side of this kind of CCodeGenerator change is that it generates thousands of diff preventing any manual review of generated source code changes.<br></div>IMO, this should be separated in own commit so that we can bissect.<br></div>More generally, we should generate source in a more atomic fashion (for each feature/fix).<br>The infrastructure progress (automated tests), and the way to declare a VM stable (whatever it is) are there to enable this process.<br></div><br></div>One possibility would be to use VMMaker branches coupled to git branches like I did for LLP64.<br></div>Once we have VM smoke tests + VM simulator tests to improve confidence level, you could merge the VMMaker branch with MC, merge the necessary platforms changes with git (resolve all *src conflicts as using COG branch), regenerate the sources, and commit. I'm pretty sure that a pair of MC+git gurus could script that procedure.<br><br>If we use such process for each feature, we could integrate several features at once, with so called "octopus" merge.<br>This would be the process nearest to current one: the integrator (you) assemble several features for the next "release" (understand HEAD commit).<br></div><div>This may raise several questions about rebasing or merging changes, but it's worth thinking about it.<br></div></div></blockquote><div><br></div><div>I'm having difficulty focussing on fixing this problem right now because the bug means I don't have a stable VM. I'm trying to a) release machine code shallowCopy and b) fix a Slang bug (a TSendNode whose receiver is a Set instead of a member of the TParseNode hierarchy). So right now I want to locate a VM that was built before any of the changes that was stable. I suppose I could revert my git repository and go from that. But I'd prefer to download one. Things seemed stable in June. i wonder what revision to revert to. I'll take a look. Bisecting is hard without a reliable test to crash the program :-(</div><div><br></div><div><br></div><div>BTW, somehow I forgot to mark SpurMemoryManager>>markAndTrace: as <inline: #never> and consequently it is being inlined into markAndTraceStackPage; not a good idea ;-) I'll be able to respond more cogently when I feel I have a stable VM :-/</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-06 11:00 GMT+02:00 Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 06.08.2016, at 08:46, Tim Felgentreff <<a href="mailto:timfelgentreff@gmail.com" target="_blank">timfelgentreff@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I agree that only reasonably stable code should go into the Cog branch. But how do we ensure that? I'm against going with someone's "gut feeling" for this, instead I think we really do need some tests. Right now the only "test" we run is that the VM compiles in different configurations on different platforms. We really need proper stress tests, in-Image as well as out-of-Image. There are many tests in Squeak, for example, that have nothing to do with the system and only test VM specifics (that are subject to change anyway, like testing that Floats are boxed). Personally I would think we should move these into the VM project and run them on Travis. Additionally we need an easy way to add a test when a new crash is discovered to guard ourselves against regressions.<br>
><br>
> I believe that with more people making contributions (which was one of the reasons for the github move) it just becomes infeasible to always test branches manually.<br>
<br>
Nothing to add, just what he says.<br>
<br>
Best regards<br>
<span><font color="#888888"> -Tobias<br>
<br>
</font></span></blockquote></div><br></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>