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. > -- > best, > Eliot >
