2014-04-24 22:43 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: > > 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. > > It's easy for me to say, because I did the job of tracing the differences when tracking bug https://pharo.fogbugz.com/f/cases/11130 And since git is a super tool, all is publicly traced.
So here is the major source of cosmetic changes: the scripts for applying the transformation (self var: #foo ...) -> <var: #foo type: ... > have been applied separately in pharo branch, but with a different layout (space after :) like Dave did in interpreter VM, but unlike Eliot did in .oscog branch if I remember correctly. Then a few other formatting have been done manually. Normally after a merge they are not shown... But since the last merge wirth 333 was partial, we can't use merge from MC, we are forced to use changes that show all the diffs, otherwise we'll miss some of the changes not merged in further merges. Thoses changes can be cancelled by re-applying Eliot's version. You can check on my branch UndoBlankChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/7ee237a851f2470ca433dcd53388570248778c19 As for the random changes, they are all marked LucFabresse (I think an effect of older gitfiletree). I don't think they are really random: it's more like an aborted merge that was partially reverted. So logically, the things that were not reverted were harmless (the Spur related things). There was certainly a good reason for wanting to merge (like work on simulator maybe) And reverting was probably a good decision at that time because Spur introduction was wausing some Cog regressions. My point is not to denigrate Luc's or Esteban's work, maintaining a parallel branch is complex enough! But when you are searching for a specific bug like those differences appear as random and are parasiting... And when it's time to cancel the debt toward Eliot's branch, that can be disturbing : those methods conflict because of author and time stamp, as I said probably a former gitfiletree bug... You can check the changes in my branch revertLucFabresseAheadChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/847c254168d0b246c49dfcfe3f3b294c92ca60a8 Looking at history, the merge was with Eliot's 406: https://github.com/nicolas-cellier-aka-nice/pharo-vm/commits/a05cda7fb80d891a3ded12f049d4efa5cc41b477/mc/VMMaker-oscog.package/ObjectMemory.class/instance/shouldRemapObj..st The last thing I did was to apply Eliot's changes that were not applied in last merge with 333. This is in fixMergeWithEliotVersion333. In fact, it's better to merge with 334, because 333 had some snafu... https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/8d97c34571adc305461bbb1e1ed9165ed655b7a9and ancestors... ------ But as I said, I would rather throw all that work away and proceed differently, starting from Spur and merging pharo-vm. So what are these changes? There are all the changes related to making VMMaker work in pharo. Pharo API is diverging a bit from squeak over time, especially for the simulator (graphics/forms) and the generator part (file system). IMO, the best would be for squeak to catch up file system changes, but it's only an opinion... For most of the rest, we could arrange to cooperate and integrate some changes for Pharo support / or just add a compatibility package in Pharo branch. Then there are the really essential changes: ephemerons (might be superseded by Spur?) and NB. These are relatively well delimited and should not be a major problem to integrate back. Then the changes of platform files... Most of them should be integrated back in Eliot's svn branch, but they are behind for now. Last, all the CMakeVMMaker work is huge but well separated for now - until tty integrate them back :) and PharoVMMaker, well, is for the pharo configuration obviously. I probably forgotten a few, but IMO, it's not a huge work this way around. > 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 > > Yes, since it's in the replacement for ClassBuilder, a danger zone... Maybe something like executing a method not correctly recompiled, while the receiver layout has changed? or vice versa... > > > >> -- >> best, >> Eliot >> > > >
