<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-08-23 17:14 GMT+02:00 Holger Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 18. Aug 2017, at 23:56, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@<wbr>gmail.com</a>> wrote:<br>
<br>
Hi!<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>Hi Holger,<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Are the packaging stuff in opensmalltalk too, or just in pharo-vm?<br>
> It would be great to move all to opensmalltalk.<br>
> What is specificity of pharo-vm repository now?<br>
<br>
</span>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].<br>
<br></blockquote><div><br></div><div>Ah yes,<br>there have been some propositions to perform this task in a specific development branch in opensmalltalk, but so far nothing has happened...<br><br></div><div>As Eliot explained once, we currently have no guaranty to regenerate identical sources (mostly we observe signed/unsigned type swapping).<br></div><div>Probably type inference depends on the order of MethodDictionary scanning which is random.<br></div><div>Of course it should be fixed, but someone has to do it....<br></div><div>Untill then, generated sources have to be versionned, there is no alternative way,<br></div><div>otherwise we don't have reproducible artefacts...<br>A specific build could suddenly start crashing without any easy way to reproduce and debug, think of it twice before regenerating sources...<br></div><div><br></div><div><div>Porting VM to another OS without having to regenerate still is another valuable feature.</div>I also find the ability to track generated-source diffs valuable:<br>it's a complementary check, especially when changing code-generation part.<br></div>That's why we continue to version generated source, whatever the ready-made thinking.<br><div><br></div><div>Once the code generation is stable, it can be done by a bot.<br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<br>
<br></blockquote><br><div>Backporting upstream changes between squeak/newspeak vm and pharo vm was not sustainable, and mostly one way (unfair).<br>That's also what motivated the switch to opensmalltalk: it's dialect neutral.<br><br></div><div>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.<br>Remember that VM stability is valued not only because there are grumpy old and conservative fellows here ;)<br>Without VM stability, how could we have a smooth and sustainable overall development process?<br></div><div><br>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).<br></div><div>If that's the case, that's regrettable. So don't hesitate to complain here.<br></div><div><br></div><div>It doesn't mean that every PR has to be accepted.<br>Ideally, they should be closed in a reasonnable time,<br></div><div>with comments telling why or what needs to be improved for inclusion...<br></div><div>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.<br></div><div><br></div><div>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.<br>We are supposed to have non regression tests to lower the level of heroism of the poor human integrators that we all are.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am happy to answer questions about the packaging process or the OBS/travis-ci integration!<br>
<br>
holger<br>
<br></blockquote><div><br></div><div>Thanks!<br></div><div>I hope someone will jump at the opportunity :)<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian" rel="noreferrer" target="_blank">https://github.com/pharo-<wbr>project/pharo-vm/blob/master/<wbr>Makefile.debian</a><br>
[2] <a href="https://github.com/pharo-project/pharo-vm/blob/master/packaging/pharo6-vm-core/debian/rules" rel="noreferrer" target="_blank">https://github.com/pharo-<wbr>project/pharo-vm/blob/master/<wbr>packaging/pharo6-vm-core/<wbr>debian/rules</a></blockquote></div><br></div></div>