<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I want to clarify how we do it in Pharo, and why we think is a good approach. <div class=""><br class=""></div><div class="">Please, note that I’m not asking to change anything, I’m just doing story telling :)</div><div class=""><br class=""></div><div class="">1) In Pharo, since a couple of years, VMMaker *and* plugin sources coexist along with platform sources, in same repository. </div><div class=""><br class=""></div><div class="">pharovm/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>image/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>platforms/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>mc/<span class="Apple-tab-span" style="white-space:pre"> </span>—> This is the important!</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>VMMaker.package/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Freetype-Plugin.package/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div class=""><br class=""></div><div class="">(we take the effort of keeping the plugin packages here, as a mirror from his original repositories, but this is more or less automated and also, we think it worths the effort)</div><div class=""><br class=""></div><div class="">2) In Pharo, CI build always rebuild all source code: </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- it builds an image, using a BaselineOf from Metacello</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- then it builds ALL sources</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- then builds the VM</div><div class=""><br class=""></div><div class="">3) CI also executes all Pharo tests (we have an acceptable number of tests)</div><div class=""><br class=""></div><div class="">Of course, doing all this in development time is losing time, but in CI is very important and produces significant advantages: </div><div class=""><br class=""></div><div class="">1) we know exactly which version (including Monticello versions) correspond with each build (and if we want to reproduce it, is a simple checkout)</div><div class="">2) we know immediately if a recent change breaks VMMaker image build (some times has happened)</div><div class="">3) we know immediately if a change broke compilation as a side effect (this happens more of less often, specially when working with the C translator)</div><div class="">4) we know immediately if a change broke something image side <br class=""><div class=""><br class=""></div><div class="">This process will change now, as we adopt OS/vm, but in our plans we will keep parts of this model. We will include OS/vm as submodule along with the packages: </div><div class=""><br class=""></div><div class="">pharovm/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@osvm/ —> this is a submodule<span class="Apple-tab-span" style="white-space: pre;"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>mc/</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class="">- we will first generate image using our method </div><div class="">- then we will follow OS/vm method, using this image (a Pharo image… for us is very important to be able to build the VM from Pharo)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- we will generate sources using it</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- and then we’ll generate the VM using the OS/vm method. </div><div class=""><br class=""></div><div class="">at least, this is what we are aiming for. </div><div class=""><br class=""></div><div class="">Notice that this way everybody has what they want: Eliot and others can continue working how they like, and we have what we want: a complete reconstruction process who verifies everything. </div><div class=""><br class=""></div><div class="">Once put in place, this system will also benefit non-pharo users, because there will be the feedback available too.</div><div class=""><br class=""></div><div class="">cheers, </div><div class="">Esteban </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Jun 2016, at 13:15, Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com" class="">estebanlm@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 22 Jun 2016, at 12:52, <a href="mailto:phil@highoctane.be" class="">phil@highoctane.be</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">One could thing of doing a git submodule with them but it is more trouble than it is worth.<div class=""><br class=""></div><div class="">I want to be able to clone the VM and compile it right away.</div><div class=""><br class=""></div><div class="">Phil</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 22, 2016 at 10:11 AM, Norbert Hartl <span dir="ltr" class=""><<a href="mailto:norbert@hartl.name" target="_blank" class="">norbert@hartl.name</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br class=""><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 22.06.2016 um 09:51 schrieb Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank" class="">lists@fniephaus.com</a>>:</div><br class=""><div class=""><div dir="ltr" class="">AFAIK the pharo-vm projects generates the sources from the VMMaker package during a build.<div class="">Wouldn't it be better if the OpenSmalltalk vm does the same? Then no one needs to generate source manually anymore and we don't have millions of lines [2] of generated code in the repository.</div><div class=""><br class=""></div></div></div></blockquote>How would you release a version of the vm? This is only possible of you archive the static artefacts.</div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div><div class="">I do not understand this question, so maybe I’m answering anything :)</div><div class="">in Pharo, VMMaker package sources coexist along with C sources (thanks to filetree for now, but we are working on enhance that). This way, each release of VM in github contains *exactly* all the sources needed to reconstruct it… </div><div class=""><br class=""></div><div class="">Esteban </div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Norbert</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Fabio<br class=""><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/pharo-project/pharo-vm" target="_blank" class="">https://github.com/pharo-project/pharo-vm</a></div><div class="">[2] see Eliot's stats at <a href="https://github.com/OpenSmalltalk/vm/graphs/contributors" target="_blank" class="">https://github.com/OpenSmalltalk/vm/graphs/contributors</a></div><div class=""><br class=""><div class="">-- <br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 22, 2016 at 4:02 AM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank" class="">lewis@mail.msen.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
On Tue, Jun 21, 2016 at 11:11:28AM -0300, Laura Perez Cerrato wrote:<br class="">
><br class="">
> Hi everyone,<br class="">
><br class="">
> Excuse me if this has been asked already or it's documented somewhere and I<br class="">
> missed it, but what's the criteria to update the code in /src, /stacksrc,<br class="">
> /spursrc and other similar folders in the repository?<br class="">
><br class="">
> -Laura Perez Cerrato<br class="">
<br class="">
Good question. Traditionally, Eliot generates these sources periodically and<br class="">
commits them to the repository (and in recent years I have done that chore for<br class="">
the old trunk interpreter VM). At this point, unless Eliot advises otherwise,<br class="">
I would suggest that no one other than Eliot should commit to the /src trees.<br class="">
<br class="">
Dave<br class="">
<br class="">
</blockquote></div></div></div></div>
</div></blockquote></div><br class=""></div><br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>