[Pharo-project] Problems with MC (was Re: May be some problems with MC history)
Stef, we need the changes to MCPackageLoader>>basicLoad from Squeak trunk. It does a lot more to ensure correct loading of classes and methods. Our version assumes all additions are the same, both new methods and changes to existing methods. it's this assumption that causes the blow up of loading a (pharo compatible) Kernel-eem.242. I have tested that our version definitely can't load the closure fixes. I will start pulling MC changes in and see how it goes. You already started a review of Pharo version of MC? thanks, Mike On Sat, Sep 12, 2009 at 4:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thanks dave. So far I found my way (but I will have a look) and I'm reading carefully the code to see the implication for the loading of the closure fixes.
Stef
On Sep 12, 2009, at 3:45 PM, David T. Lewis wrote:
On Fri, Sep 11, 2009 at 01:48:45PM +0200, Lukas Renggli wrote:
a couple of bugs when understanding the history based merge (ugly)
It is not a merge operation, as I said in my mail. You are merely applying the changes representing a delta between two versions manually. That's all, no magic involved.
? ? ? ?- adding the new method to a cs does not work if you did not install the code before (ok) ? ? ? ?- class definition are not added (yeah) in the changeset. Really cool!
I don't understand what this has to do with change-sets?
Class definitions are part of the patch that is calculated by Monticello. My guess is that the class didn't change for the delta you calculated. To illustrate, in the example above the changes between b.1 and b.2 don't show a class change that happened between a.1 and b.1, even if the delta depends on it.
I use what I described all the time, it is maybe a bit tricky, but works really well.
Stef,
I don't know if this is helpful or not, but FYI Edgar De Cleene has produced the list of change sets corresponding to the MC update stream for Squeak trunk. See this thread on squeak-dev:
 http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/139360...
Dave
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sep 12, 2009, at 8:51 PM, Michael Roberts wrote:
Stef, we need the changes to MCPackageLoader>>basicLoad from Squeak trunk. It does a lot more to ensure correct loading of classes and methods. Our version assumes all additions are the same, both new methods and changes to existing methods. it's this assumption that causes the blow up of loading a (pharo compatible) Kernel-eem.242. I have tested that our version definitely can't load the closure fixes.
I will start pulling MC changes in and see how it goes. You already started a review of Pharo version of MC?
Oh yes! This is why I started. I missed the changes in 3.10 this is why originally I said that there were no change changing the semantics. So what is left on my plate is 309 and 321. I will send them to you in a minute as cs so that you can try. Stef
I just publish a couple of MC packages in the inbox one just to fix a bad reference to ChangeSorter instead of ChangesOrganizer (not needed so far) one for 309 (which was a kind of changes to support atomic loading) but did not really helped one for 321 where andreas patched that so that they could load closure fixes one with installAll menu in MCPatchBrowser :) So let me know if this is working. I could load eliot fixes for kernel (package two = step two of the eight) without problem. Stef (now I'm sick so going to bed).
get better soon! ok i said this in a mail but for this thread I think your second package version is empty. however if I merge 321 from the trunk (carefully!! i.e hand install MCPackageLoader first) then I can load a modified MC version of Eliot's #2 that I made. i will go through all of eliot's fixes tonight. this is progress. check updates to the tracker for each one. cheers, Mike On Sat, Sep 12, 2009 at 8:36 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I just publish a couple of MC packages in the inbox
    one just to fix a bad reference to ChangeSorter instead of ChangesOrganizer (not needed so far)     one for 309 (which was a kind of changes to support atomic loading) but did not really helped     one for 321 where andreas patched that so that they could load closure fixes     one with installAll menu in MCPatchBrowser :)
So let me know if this is working. I could load eliot fixes for kernel (package two = step two of the eight) without problem.
Stef (now I'm sick so going to bed).
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Michael Roberts -
Stéphane Ducasse