<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Laura,<br></div><div><br>On Jun 21, 2016, at 7:11 AM, Laura Perez Cerrato <<a href="mailto:lauraperezcerrato@gmail.com">lauraperezcerrato@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div>Hi everyone,</div><div><br></div>Excuse me if this has been asked already or it's documented somewhere and I missed it, but what's the criteria to update the code in /src, /stacksrc, /spursrc and other similar folders in the repository?</div></div></blockquote><div><br></div>I should document this. There are three main criteria:<div><br></div><div>- does the source need to be updated to fix a bug or make available new functionality urgently needed? Since up until now my VM builds have been manually kicked off on the three platforms it took a while and I'd only do new builds when necessary</div><div><br></div><div>- does the source look sane? One should always look at the differences to the generated source if any part of Slang's translator has been modified to check for bugs.</div><div><br></div><div>- is the source generated from versioned input? The generated C source is marked with the Monticello package version, including UUID, of the packages from which it was created (eg a package providing a plugin) and that created it (i.e. the VMMaker package). These marks will contain asterisks for modified Monticello packages. Clearly one should never check in source containing asterisks. The one exception I've allowed myself is MiscPrimitivesPlugin which gets generated from base image code, and I have a few choice base image modifications (such as a much higher character limit on the Transcript, or different code highlighting) that make it really painful to keep <span style="background-color: rgba(255, 255, 255, 0);">MiscPrimitivesPlugin clean.</span></div><div><br></div><div>I'm happy for others to generate and check in VM source provided:</div><div>- you carefully check the generated source before checking it in to verify that the delta is as expected and no new bugs have been introduced</div><div>- you generate as little change as possible.</div><div>-- There is a script that reverts generated plugins that have changed only in their Monticello markings that allows us to not checkin inessential revisions to plugins and see when I fact they did change</div><div>-- wrapping the generation code with [...] valueAnswering: false (or whatever the selector is) avoids regenerating VM headers (cointerp.h cogit.h cogmethod.h interp.h) when these haven't been modified</div><div><br></div><div>In short, only do this if you know what you're doing. But got people to know what they're doing the process has to be documented along with the rationale. I guess this email and my reply to Fabio's question can serve as input to that documentation.<br><div><br><blockquote type="cite"><div dir="ltr"><span style="font-family: arial, helvetica, sans-serif; font-size: small;">-Laura Perez Cerrato</span>
</div>
</blockquote></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br>_,,,^..^,,,_ (phone)</span></div></div></body></html>