[Vm-dev] snafu for e013b6766a05037812d48960702c0910

[Nicolas Cellier]

+1 for using generous features of github.
creating branches is a cheap action for developpers

I also see another problem: we use two different paths for developping the
VM
- via VMMaker (slang) changes and VM simulator tests
- via code generation from VMMaker, compilation of VM, and non regression
testing by passing some image SUnit test cases

Only the latest form is on Opensmalltalk-vm (github) right now.
This can lead to long periods without github/travis tests.
In our case see:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/spur64src/vm/cogitX64WIN64.c
https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/spur64src/vm/gcc3x-cointerp.c
there's been no travis regression tests from VMMaker.oscog-eem.2262 to
VMMaker.oscog-eem.2277 for the JIT
and from VMMaker.oscog-eem.2266 to VMMaker.oscog-eem.2277 for the
interpreter...
That's a lot of changes at once.

In particular, each and every change to CCodeGeneration SHALL be tested
individually on github/travis, because it is precisely what can make a
difference between the VM simulator and the C code.

So having the code generated from VMMaker committed into a specific branch
as already proposed might help bissecting the problems...



2017-11-24 7:47 GMT+01:00 Holger Freyther <holger at freyther.de>:

>
>
> > On 24. Nov 2017, at 13:27, Ben Coman <btc at openinworld.com> wrote:
> >
>
> Hey!
>
>
> >
> > I haven't used them, but there seem a few options for issuing PRs from
> the command-line, which may make this more palatable.
> > Thus the CI should run without needing to visit github's web-UI.
>
>
> and one can probably use the github API to auto-merge PRs that have a
> successful build and come from a trusted developer. It is nice to live in a
> time computing time is so cheap. ;)
>
> holger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171124/0f98777e/attachment.html>