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 :) cheers, Esteban > > > > > -- > best, > Eliot >
