<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 12:53 PM Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Hi Dave,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">With respect to VM changes, there is very little chance that the<br>
VM (FilePlugin actually) has changed recently. But is it certainly<br>
possible that the compilers and runtime libraries have changed over<br>
the last year or so, and it is possible that the actual runtime<br>
behavior of fflush() will be different as a result. If so, I would<br>
not regard that as a VM problem per se, it is really going be a<br>
difference in the runtime environment.<br></blockquote><div><br></div><div>I do hope you're right, but when you say, the "runtime environment", do you mean statically-linked stuff?   Because, in terms of the dynamic linkages, the test is running both times in the same environment.  If I use the old VM, it works.  If I use the new VM, I have to change #flush or it won't work.</div></div></div></blockquote><div><br></div><div>Can you provide the version info for both please?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div> - Chris</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
As a point of comparison, I find that my CommandShell has accumulated<br>
a few bugs over the years as a result of differences in the runtime<br>
environments on Linux and other Unix systems. Some of these I have<br>
addressed, and some I haven't. But it is not a defect in the VM, more<br>
likely it is some poor assumptions in my original implementation that<br>
became visible as the runtime C library changed.<br>
<br>
HTH,<br>
Dave<br>
<br>
<br>
On Mon, Jan 13, 2020 at 01:15:15AM +0100, Levente Uzonyi wrote:<br>
> Hi Chris,<br>
> <br>
> Do you expect #flush to write the changes to disk?<br>
> <br>
> Levente<br>
> <br>
> On Sun, 12 Jan 2020, Chris Muller wrote:<br>
> <br>
> >Magma has been stable in 5.2 for a long time under an older VM, all tests <br>
> >pass.?? But by changing ONLY the VM (not the image) to the new <br>
> >release-candidate, it fails the forward-recovery test.?? This test tests <br>
> >the scenario of a<br>
> >server failure during mid-write.?? Unless I change <br>
> >StandardFileStream>>#flush as in Files-cmm.182,??the recovery data which <br>
> >Magma relies on #flush to ensure is preserved is, in fact, not <br>
> >preserved.?? It appears to be a breakage<br>
> >of the contract which causes the test to fail.?? This functionality is <br>
> >important to avoid corrupting databases.<br>
> >I saw a discussion on the Cuis list in which someone was asserting that <br>
> >flush is no longer necessary(!!), and made a vague reference to a "thread <br>
> >on squeak-dev" which I never found.<br>
> ><br>
> >I hope this is just an oversight, otherwise I'll have to rely something <br>
> >like Files-cmm.182, which is half the speed of the old #flush.<br>
> ><br>
> >Best,<br>
> >?? Chris<br>
> ><br>
> ><br>
<br>
> <br>
<br>
<br>
</blockquote></div></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="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>