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

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 23 00:19:09 UTC 2016


On Wed, Jun 22, 2016 at 6:52 AM, Laura Perez Cerrato <
lauraperezcerrato at gmail.com> wrote:

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

Yes, please!


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


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160622/8befdda8/attachment.htm


More information about the Vm-dev mailing list