<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">hi,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 31 Mar 2018, at 17:34, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" class="">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2018-03-31 15:03 GMT+02:00 Esteban Lorenzano<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:estebanlm@gmail.com" target="_blank" class="">estebanlm@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"> <br class=""><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 30 Mar 2018, at 23:56, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" class="">nicolas.cellier.aka.nice@<wbr class="">gmail.com</a>> wrote:</div><br class="gmail-m_4075440791418799699Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2018-03-24 11:11 GMT+01:00 Esteban Lorenzano<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:estebanlm@gmail.com" target="_blank" class="">estebanlm@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">hi,<br class=""><br class="">> On 24 Mar 2018, at 09:50, Cyril Ferlicot D. <<a href="mailto:cyril.ferlicot@gmail.com" target="_blank" class="">cyril.ferlicot@gmail.com</a>> wrote:<br class="">><br class="">> Le 23/03/2018 à 21:52, Eliot Miranda a écrit :<br class="">>> Hi Damien,<br class="">>><br class="">>> Indeed the image is corrupt at start-up. See below.<br class="">>><br class="">>><br class="">>> Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320:<br class="">>><br class="">>> Spur:<br class="">>> Fix a bad bug in SpurPlnningCompactor.<br class="">>> unmarkObjectsFromFirstFreeObje<wbr class="">ct, used when the compactor requires more<br class="">>> than one pass due to insufficient savedFirstFieldsSpace, expects the<br class="">>> corpse of a moved object to be unmarked, but<br class="">>> copyAndUnmarkObject:to:bytes:f<wbr class="">irstField: only unmarked the target.<br class="">>> Unmarking the corpse before the copy unmarks both. This fixes a crash<br class="">>> with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring:<br class="">>> creates lots of files, enough to push the system into the multi-pass regime.<br class="">>><br class="">>><br class="">>> Pharo urgently needs to upgrade the VM to one more up to date than 2017<br class="">>> 08 27 (in fact more up-to-date than opensmalltalk/vm commit<br class="">>> 0fe1e1ea108e53501a0e7287360480<wbr class="">62c83a66ce, Fri Jan 19 13:17:57 2018<br class="">>> -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image<br class="">>> corruption in large images, and can occur (as it has here) at start-up,<br class="">>> causing one's work to be irretrievably lost.<br class="">>><br class="">><br class="">> Hi Eliot,<br class="">><br class="">> I think that there is a lot of people who would like to get a newer<br class="">> stable vm for Pharo 6.1 and 7. The problem is that it is hard to know<br class="">> which VM are stable enough to be promoted as stable.<br class="">><br class="">> Some weeks ago Esteban tried to promote a VM as stable and he had to<br class="">> revert it the same day because a regression occurred in the VM.<br class="">><br class="">> If you're able to tell us which vms are stable in those present at<br class="">><span class="Apple-converted-space"> </span><a href="http://files.pharo.org/vm/pharo-spur32/" rel="noreferrer" target="_blank" class="">http://files.pharo.org/vm/phar<wbr class="">o-spur32/</a><span class="Apple-converted-space"> </span>and<br class="">><span class="Apple-converted-space"> </span><a href="http://files.pharo.org/vm/pharo-spur64/" rel="noreferrer" target="_blank" class="">http://files.pharo.org/vm/phar<wbr class="">o-spur64/</a><span class="Apple-converted-space"> </span>it would be a great help.<br class="">><br class="">> Even better would be for the pharo community to have a way to know which<br class="">> vms are stable or not without having to ask you.<br class=""><br class="">there is no “stable” branch in Cog, and that’s a problem.<br class="">“released” versions (the version you can find as stable) are not working for Pharo :(<br class=""><br class="">I tried to promote versions from end feb and that crashed.<br class=""><br class="">next week I will try again, maybe now they are stable enough… one thing is true: the versions that we consider stable (from oct/17) present problems that are already solved on latest.<br class=""><br class="">Esteban<br class=""><br class=""><br class="">><br class="">> Have a nice day.<br class="">><br class=""><span class="gmail-m_4075440791418799699m_2136362129077557755HOEnZb"><font color="#888888" class="">>><br class="">>> --<br class="">>> _,,,^..^,,,_<br class="">>> best, Eliot<br class="">> --<br class="">> Cyril Ferlicot<br class="">><span class="Apple-converted-space"> </span><a href="https://ferlicot.fr/" rel="noreferrer" target="_blank" class="">https://ferlicot.fr</a><br class="">><br class=""><br class=""></font></span></blockquote></div><br class=""></div><div class="gmail_extra">Hi,<br class=""></div><div class="gmail_extra">Several problems are mixed here, let's try and decouple:<br class=""></div><div class="gmail_extra">- 1) there are ongoing development in the core of VM that may introduce some instability<br class=""></div><div class="gmail_extra">- 2) there are ongoing development in some plugins also<br class=""></div><div class="gmail_extra">- 3) there are infrastructure problems preventing to produce artifacts whatever the intrinsic stability of the VM<br class=""></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">you are right in all points, but for me this is a problem of process. </div><div class=""><br class=""></div><div class="">- we have no defined milestones so nobody knows if they can jump to help.</div><div class="">- plugin development happens “by his own” and nobody knows what happens, why happens and how it happens.</div><div class="">- infrastructure is not bad and a lot of efforts has been made to make it work. But code sources are scattered around the world and the only thing that reunites them is the hand of the one who generates the C sources.</div><div class=""><br class=""></div><div class="">IMHO, is this “disconnection” what causes most of the problems. </div><div class=""><br class=""></div><div class="">cheers,</div><div class="">Esteban</div><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Hi Esteban,<br class=""></div><div class="">I see no fatality, and github also provides tools for that.<br class="">Look, there is the project page on github<br class=""><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/projects/1" class="">https://github.com/OpenSmalltalk/opensmalltalk-vm/projects/1</a><br class=""><br class=""></div><div class="">Maybe the Pharo team is willing to collaborate and take active parts in definition of milestones?<br class=""> <br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">For 1) development happens in VMMaker, and we have to be relying on experts. Today that is Eliot and Clement.<br class=""></div><div class="gmail_extra">We all want 64bits VM, improved GC, improved become:, write barrier, ephemerons, threaded FFI calls and adaptive optimization.<br class=""></div><div class="gmail_extra">Pharo is relying on these progress, they are vital.<br class=""></div><div class="gmail_extra">IMO, we are reaching a good level of confidence, and I hope to see some VMMaker version blessed as stable pretty soon.<br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Instead of whining, the best we can do for reaching this state is help them by providing accurate bug reports and even better reproducible cases.<br class=""></div><div class="gmail_extra">Thanks to all who are working in this direction.<br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">For 2) we had a few problems, but again this is for improving important features (SSL...)<br class=""></div><div class="gmail_extra">Much of the development happens in feature branches already.<br class=""></div><div class="gmail_extra">But since we are targetting so many platforms, and don't have automated tests that scale yet, we still need beta testers.<br class=""></div><div class="gmail_extra">We can discuss about the introduction of such beta features wrt release cycles, that will be a good thing.<br class=""></div><div class="gmail_extra">Ideally we should tend toward continuous integration and have very short cycles, but we're not yet there.<br class=""></div><div class="gmail_extra"><br class="">For 3) we had a lot of problems, like staled links, invalid credentials, evolution of the version of tools at automated build site, etc...<br class=""><br class=""></div><div class="gmail_extra">If we don't build the artifacts, then we can't even have a chance to test the stability of 1) and 2)<br class="">We have to understand that 3) is absolutely vital.<br class=""><br class="">May I remind that for a very long period last year, the build were broken due to lack of work at Pharo side.<br class="">Fortunately, this has changed in 2018.<br class="">Fabio has been working REALLY hard to improve 3), and without the help of Esteban,I don't think he could have reached the holy green build status.<div class="gmail_extra">We will never thank them enough for that. This also shows that cooperation may pay.<br class=""></div><br class="">But this is still very fragile.</div>If we want to make progress, we should ask why it is so.<br class=""></div>We could analyze the regressions, and decide if the complexity is sustainable, or eventually drop some drag.<br class=""></div>We are chasing many hares by building the VM for Newspeak/Pharo/Squeak i386/x86_64/ARM Spur/Stack/V3 Sista/lowcode linux/Macosx/Windows ...<br class=""></div>If it happens that a fix vital for Pharo/Squeak does break Newspeak tests, then it slows down the progress...<br class=""></div>Maybe we would want to decouple a bit more the problems there too (they may come from some image side weakness).<br class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Last two years I've also observed some work exclusively done in the Pharo fork of the opensmalltalk VM.<br class=""></div><div class="gmail_extra">This was counter productive. Work must be produced upstream, or it's wasted.<br class=""></div></div></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This happened just once or twice. And it was because people were ignorant of “joint" so they continued contributing as before (and people were pointed to right place when we had the opportunity).</div><div class="">And I disagree this was counterproductive because I took the effort to merge the changes into osvm. This worked fine until I stopped to do that job, but well… just one PR got stalled there for months and Alistair integrated it recently. </div><div class=""><br class=""></div><div class="">What *did happen* and I’m still not ready to let it go is a lot of the small changes that we presented to be rejected (or ignored) without further consideration. But well, let’s keep it positive and not enter to sterile discussions, I just think you are wrong with this argument.</div><div class=""><br class=""></div></div></div></blockquote><div class="">No, it's important, we (opensmalltalk-vm team) can't let such bad feeling and frustration creep in.<br class=""></div><div class="">Every contribution counts, that does not mean that every PR will be accepted, but we owe an explanation if not.<br class=""></div><div class="">Some are accepted instantly, some are accepted after modification requests, some are rejected (I hope with some rationalization).<br class=""></div><div class="">What is problematic is that some were ignored for too long time, I regret the situation, but there is no deliberate intention to ignore them, just lack of manpower IMO.<br class=""></div><div class="">For example, the recent work of Alistair shows that there is no fatality here, it's just that someone has to do the hard work (kudos!).</div></div></div></blockquote><div><br class=""></div><div>I’m sorry for have a bitter feeling, but I’m going to give you an example so you understand why I’m saying this: I proposed the refactor of Alien package (which is obviously right and simple) at least three times in last three years (by different means). First time I’ve been told “no, we prefer it like that”. Second time I’ve been told “we need to think about that” (and no answer later). Last time I even didn’t receive a response. So well, when Torsten proposed it he first came to me. I told him “talk in vm-dev and good luck”. His proposal was accepted (thanks god). </div><div>Several situations like this one made me think that I’m a second class citizen in this community. And you know what? I’m 46 years and I do not want to be treated as is I’m a child that can play with the toys someone let me or not. So yes, I’m sad and not very “into” this this days. I made a lot of efforts to came back for the de facto fork we had because I always pushed to work together. But I do not see the spirit of collaboration I hoped. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><div class="">Also, the question is coupled with stability: having a red status does not help, for almost every PR that I accepted, I had to dig into travis console reports and compare to status of previous build in order to know if it was a regression, or just a long time failing case... This does not scale!<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>is worst that "does not scale".</div><div>again, let me put you an example: Imagine I want to work on FFI and I need to touch both an external file and VMMaker: I cannot do a PR because VMMaker is not there and VM building will be broken and I cannot push VMMaker because platform sources are not there and VM building will be broken too.</div><div>So, the only solution is what happens today: I need to push VMMaker and changes at the same time. So I’m forced to work on the development branch (we are all forced to work there), instead how I think it should be: each one should be able to work on their branch and contribute changes through PRs (PRs that can be validated with a good CI process).</div><div><br class=""></div><div>As a consequence, since all contributions go to the development branch… we have no stability and we need to wait of the blessing of a VM. That may or may not happen.</div><div><br class=""></div><div>Meh, whatever… is obvious that my way of work is different to most of the people of this community so I will go back to what I do now: just the absolutely necessary.</div><div><br class=""></div><div>cheers, </div><div>Esteban</div><div><br class=""></div><div>ps: I will not continue discussing this… I know how things are and I’m sorry to put such a negative perspective in this list, but I needed to say it.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><div class=""><br class=""></div><div class="">I'm all for more distributed power, and that should come with responsibilities, first a cooperative "you break it, you fix it" attitude.<br class=""><br class=""></div></div><div class="">Or maybe do you want clarified decision process?<br class=""></div><div class="">For now, people that feel interested by a PR raise their voice.<br class=""></div><div class="">I don't know if we need something more formal<br class="">For important design decisions there is vm-dev mailing list to discuss about that.<br class=""></div><br class=""></div><div class="">cheers<br class=""></div><div class="">Nicolas<br class=""></div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><div class=""></div><div class="">cheers,</div><div class="">Esteban</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="gmail_extra">I once thought that the Pharo fork could be the place for the pharo team to manage official stable versions.<br class=""></div><div class="gmail_extra">But I agree that this is too much duplicated work and would be very happy to see the work happen upstream too.<br class=""><br class=""></div><div class="gmail_extra">If you have constructive ideas that will help decoupling all these problems, we are all ear.<br class=""><br class=""></div><div class="gmail_extra">PS: i did not post this answer for avoiding sterile discussion, but since Phil asked...</div></div></div></div></div></div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div><br class=""></body></html>