<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 15, 2019 at 3:14 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</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="auto">If the code is hidden in ifdefs it will not be visible to the compiler and thus the CI. Then we will not detect when the old ways break. Maybe implement a feature flag that can be switched from the image. New images can switch the old mess off via some primitive, and tests can switch it on to test the mess.<div dir="auto"><br></div><div dir="auto">After some time the mess and flag can be removed and old images will no longer be supported.</div></div></blockquote><div><br></div><div>+1.  But that's a fair amount of work ;-)  These flags are a precious resource.  What I was suggesting below was that the legacy code, protected by ifdef's, was enabled, and stayed there until some major release, at which time it could be disabled.  I agree with you that disabling it by default is wrong.</div><div><br></div><div>IOn general with the VM one wants to maintain backward compatibility until a major release arrives that makes it impossible to for the current VM to support some set of older versions.  For example, the Spur VMs we use now cannot run V3 images.  So when Spur VMs were introduced any backward compatibility for pre-Spur images could be jettisoned from the Spur VMs.</div><div><br></div><div>So a viable approach is to use ifdefs, to keep the code enabled, and revisit disabling the code pin every major release.</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">Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> schrieb am Di., 10. Dez. 2019, 20:28:<br><div class="gmail_quote"><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 dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" rel="noreferrer" target="_blank">eliot.miranda@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 dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <<a href="mailto:tim@rowledge.org" rel="noreferrer" target="_blank">tim@rowledge.org</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"><br>
<br>
> On 2019-12-10, at 10:05 AM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" rel="noreferrer" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> <br>
> Hi Christoph,<br>
> The image side is totally messy, <br>
> The VM side is also messy, so finding a combination that might work is a sport.<br>
<br>
You're not wrong. I had a bit of fun with this stuff making the Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An interesting problem there was that enabling the linux extension completely broke something else (that I can't remember at all) and made the whole attempt moot.<br>
<br>
<br>
> To summarize: we have reached a point where we cannot change/add one feature without breaking one other (at least).<br>
> The consequence is that we have some sort of "stable" status because we cannot change anything (the statu quo).<br>
<br>
I suspect this is what happens to almost every complex project. I mean, look at how all the OS's get messed up and stall for years. They're all terrible right now.<br>
<br>
Supporting old images means keeping the old messy VM code around. Doing something new and clean means a lot of work and probably using new primitives or some variety of flag to request use of the new code. Then we'd want to decide on a time to drop the old mess.<br></blockquote><div><br></div><div>See can at least comment it and corral the old messy code in ifdef's such as</div><div><br></div><div>#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP</div><div>...</div><div>#endif</div><div><br></div><div>so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.</div></div></div></blockquote><div><br></div><div style="color:rgb(0,0,0)">I mean:</div><div style="color:rgb(0,0,0)">We can at least comment it and corral the old messy code in ifdef's such as</div><br>#if VERSION <= FOO<br># define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1<br>#endif</div><div class="gmail_quote">....<br>#if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP<br>...<br>#endif<div style="color:rgb(0,0,0)"><br></div><div><span style="color:rgb(0,0,0)">so that we don't have to think too hard about what we delete the next time we have a major release that breaks image backward compatibility.  I personally don't mind the old cruft being there.  What I hate is not knowing what the cruft is.  The code, especially the C VM code, must be properly documented so that it doesn't require intimate knowledge with older versions, the history, but twiddling hacks, etc, etc.</span> </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"><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>
Lovely project! ;-)<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" rel="noreferrer" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Strange OpCodes: DPC: Double Precision Crash<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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></div>
<br>
</blockquote></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>