On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano <esteba...@gmail.com>wrote:
> > On 24 Apr 2014, at 22:13, Nicolas Cellier < > nicolas.cellier.aka.n...@gmail.com> wrote: > > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>: > >> Again, cc'ing vm-dev is courteous. >> >> >> On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.ter...@gmail.com >> > wrote: >> >>> Segfault!!!!! >>> >>> Could it be due to #become: or #valueUnpreemptively ? (see >>> PharoClassInstaller>>migrateClasses:to:using:) >>> >> >> I suspect the become. Thats the last primitive. I suspect it's >> something to do with become on machine code. I suspect some of my recent >> changes have not been integrated. e.g. VMMaker.oscog-eem.669. >> > > > Hi Eliot, > no, it is way behind ! > The https://github.com/pharo-project/pharo-vm/ master head is marked as > merged with VMMaker.oscog-eem.333 though the merge is very partial. > There are also some changes that have been picked from further MC > versions, quite randomly IMO (most are related to the Spur VM and are of no > value for COG!), but the MC versions are not marked as merged this time. > As for the platform sources, I have no idea what/when was the last merge > with your svn branch... > > As I already ranted about, there have been a lot of cosmetic changes (like > reformatting some methods) which now are a drag causing many conflicts at > each MC merge operation... > I've cancelled most of these in my > https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch > just to see a bit clearer. > It could be a better start for integrating your changes. > But synchronizing the svn changes with the MC changes is not that easy; > doing it manually is error prone, it should be automated. > For this reason, the all-in-one git repo is superior IMO, despite the > small MC-git complications. > > I think the fastest strategy for catching up with Spur would be to > re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather > than the opposite, but I'm not the maintainer. > Igor, Esteban and co may have a different idea about it. > > > no, I was thinking more or less the same… but still did not looked at it > deeply :) > > btw… I do not know which randomly picked changes you are talking about. I > certainly stopped doing integrations when Eliot started to commit spur > stuff, to wait until is more or less ready (bah, with Clement we tried once > and it was not worthy, so we rolled back). > then… other stuff: I also don’t know about random methods reformatted. I > know I reformatted some, but those I worked on (usually not in VMMaker, > with minor exceptions). Of course, I’m not the only one working on those > sources, but I certainly did many changes with the years. > > Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad > integration (in the new class builder) we rollbacked. That’s why it was not > copied to vm-dev :) > At last for the core VM classes (ignore plugins) I wish you would integrate by integrating your ephemeron and NativeBoost changes into my tip. I think you're losing a lot of goodness coming form the continuous integration and testing my colleague Bob Westergaard does at Cadence. It worries me that the Pharo VM is buggy. I don't think it needs to be. And please don't take this as a criticism. It's more my anxiety. > cheers, > Esteban > cheers! > > > > >> -- >> best, >> Eliot >> > > > -- best, Eliot
