[Vm-dev] snafu for e013b6766a05037812d48960702c0910

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Nov 24 14:50:07 UTC 2017

+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
- 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:
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
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>

More information about the Vm-dev mailing list