eliot.miranda at gmail.com
Thu Aug 11 17:07:38 UTC 2016
On Mon, Aug 8, 2016 at 2:51 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:
> Hi Eliot,
> the VMMaker changes relative to LLP64 are so far really tiny: just the
> change of CCodeGenerator for >> and the memcpy.
> I think it's easy enough to revert and test if it changes anything to
> One bad side of this kind of CCodeGenerator change is that it generates
> thousands of diff preventing any manual review of generated source code
> IMO, this should be separated in own commit so that we can bissect.
> More generally, we should generate source in a more atomic fashion (for
> each feature/fix).
> The infrastructure progress (automated tests), and the way to declare a VM
> stable (whatever it is) are there to enable this process.
> One possibility would be to use VMMaker branches coupled to git branches
> like I did for LLP64.
> Once we have VM smoke tests + VM simulator tests to improve confidence
> level, you could merge the VMMaker branch with MC, merge the necessary
> platforms changes with git (resolve all *src conflicts as using COG
> branch), regenerate the sources, and commit. I'm pretty sure that a pair of
> MC+git gurus could script that procedure.
> If we use such process for each feature, we could integrate several
> features at once, with so called "octopus" merge.
> This would be the process nearest to current one: the integrator (you)
> assemble several features for the next "release" (understand HEAD commit).
> This may raise several questions about rebasing or merging changes, but
> it's worth thinking about it.
I'm having difficulty focussing on fixing this problem right now because
the bug means I don't have a stable VM. I'm trying to a) release machine
code shallowCopy and b) fix a Slang bug (a TSendNode whose receiver is a
Set instead of a member of the TParseNode hierarchy). So right now I want
to locate a VM that was built before any of the changes that was stable. I
suppose I could revert my git repository and go from that. But I'd prefer
to download one. Things seemed stable in June. i wonder what revision to
revert to. I'll take a look. Bisecting is hard without a reliable test to
crash the program :-(
BTW, somehow I forgot to mark SpurMemoryManager>>markAndTrace: as <inline:
#never> and consequently it is being inlined into markAndTraceStackPage;
not a good idea ;-) I'll be able to respond more cogently when I feel I
have a stable VM :-/
> 2016-08-06 11:00 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:
>> On 06.08.2016, at 08:46, Tim Felgentreff <timfelgentreff at gmail.com>
>> > Hi,
>> > I agree that only reasonably stable code should go into the Cog branch.
>> But how do we ensure that? I'm against going with someone's "gut feeling"
>> for this, instead I think we really do need some tests. Right now the only
>> "test" we run is that the VM compiles in different configurations on
>> different platforms. We really need proper stress tests, in-Image as well
>> as out-of-Image. There are many tests in Squeak, for example, that have
>> nothing to do with the system and only test VM specifics (that are subject
>> to change anyway, like testing that Floats are boxed). Personally I would
>> think we should move these into the VM project and run them on Travis.
>> Additionally we need an easy way to add a test when a new crash is
>> discovered to guard ourselves against regressions.
>> > I believe that with more people making contributions (which was one of
>> the reasons for the github move) it just becomes infeasible to always test
>> branches manually.
>> Nothing to add, just what he says.
>> Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev