[Vm-dev] The code in the src folders in the repository
Laura Perez Cerrato
lauraperezcerrato at gmail.com
Wed Jun 22 13:52:29 UTC 2016
Hi Eliot, Hi everyone,
Thanks for the comprehensive answer. May I suggest this, along with your
response to Fabio's question, be added to CONTRIBUTING.md? I wouldn't mind
doing so myself if you all agree (since I'm not a contributor to the GitHub
repository I'd submit it through a pull request though).
-Laura Perez Cerrato
On 22 June 2016 at 10:27, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Laura,
> On Jun 21, 2016, at 7:11 AM, Laura Perez Cerrato <
> lauraperezcerrato at gmail.com> wrote:
> Hi everyone,
> 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?
> I should document this. There are three main criteria:
> - 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
> - 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.
> - 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 MiscPrimitivesPlugin clean.
> I'm happy for others to generate and check in VM source provided:
> - 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
> - you generate as little change as possible.
> -- 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
> -- 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
> 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.
> -Laura Perez Cerrato
> _,,,^..^,,,_ (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev