[Vm-dev] The code in the src folders in the repository

[Laura Perez Cerrato]

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).

Cheers!

-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...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/2661213a/attachment-0001.htm