2017-08-23 17:14 GMT+02:00 Holger Freyther <holger@freyther.de>:
On 18. Aug 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
Hi!
Hi Holger,
Are the packaging stuff in opensmalltalk too, or just in pharo-vm? It would be great to move all to opensmalltalk. What is specificity of pharo-vm repository now?
the packaging bits are in the pharo-vm repository only. What is pharo specific from a technical point of view is that I re-generate the sources before building the source package. There is a Makefile[1] that drives building the source package and the actual compilation is here[2].
Ah yes, there have been some propositions to perform this task in a specific development branch in opensmalltalk, but so far nothing has happened... As Eliot explained once, we currently have no guaranty to regenerate identical sources (mostly we observe signed/unsigned type swapping). Probably type inference depends on the order of MethodDictionary scanning which is random. Of course it should be fixed, but someone has to do it.... Untill then, generated sources have to be versionned, there is no alternative way, otherwise we don't have reproducible artefacts... A specific build could suddenly start crashing without any easy way to reproduce and debug, think of it twice before regenerating sources... Porting VM to another OS without having to regenerate still is another valuable feature. I also find the ability to track generated-source diffs valuable: it's a complementary check, especially when changing code-generation part. That's why we continue to version generated source, whatever the ready-made thinking. Once the code generation is stable, it can be done by a bot. But don't forget that not all VMMaker commit will produce interesting C sources, because a great deal of development happens in VM-Simulator, not in C - at least the major features that Eliot and Clement are after.
I don't want this to sound offensive but the non-technical part is that it seems easier to get changes into the PharoVM than into opensmalltalk-vm. One example could be the FilePlugin and my attempt to use inotify without periodic polling (wastes power, adds latency and increases your bill in cloud computing, etc).
Backporting upstream changes between squeak/newspeak vm and pharo vm was not sustainable, and mostly one way (unfair). That's also what motivated the switch to opensmalltalk: it's dialect neutral. Of course, changes in opensmalltalk must be done with retro and cross compatibility constraints which may require a little more effort, but at worse we have dialect-specific #ifdef directives. Remember that VM stability is valued not only because there are grumpy old and conservative fellows here ;) Without VM stability, how could we have a smooth and sustainable overall development process? That said, I hate nothing much than stale pull request and it's clearly the next obstacle to contributions (in case vm contributions was easy enough). If that's the case, that's regrettable. So don't hesitate to complain here. It doesn't mean that every PR has to be accepted. Ideally, they should be closed in a reasonnable time, with comments telling why or what needs to be improved for inclusion... IMO in absence of dedicated paid staff, we should start closing old PR (exactly as Pharo is closing stale fogbugz entries). it's not satisfying, but letting a long list of open PR is worse. Non-technically speaking, Esteban is among the core developpers of opensmalltalk, so it should be as easy to integrate changes as in a pharo-vm copy, modulo cross and retro compatibility concerns. We are supposed to have non regression tests to lower the level of heroism of the poor human integrators that we all are.
I am happy to answer questions about the packaging process or the OBS/travis-ci integration!
holger
Thanks! I hope someone will jump at the opportunity :)
[1] https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian [2] https://github.com/pharo-project/pharo-vm/blob/master/ packaging/pharo6-vm-core/debian/rules