[Pharo-dev] MC diffs are seriously broken in Pharo2.0

Esteban Lorenzano estebanlm at gmail.com
Mon Apr 7 07:41:05 EDT 2014


On 07 Apr 2014, at 08:28, Esteban Lorenzano <estebanlm at gmail.com> wrote:

> Hi,
> 
> Sorry but I do not have *any* of this problems (and I use same things as you all the time for the vm stuff). 
> I wonder what happened to you to get this kind of behaviour. 
> Can I have your image to test it?

forget to say that I will check it later on the week… now I have an plane to take :)

> 
> Esteban
> 
> ps: afaik, vmmaker was loading in 3.0 with some fixes, but there is still not configuration released for it. 
> 
> On 06 Apr 2014, at 12:36, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
>> I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools.
>> 
>> The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable.
>> 
>> The pharo's PolyMorphDiffTool is good looking but awfully sloooow
>> It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool.
>> But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again.
>> 
>> But worse than all, there are insane caches operating in MCVersion that drove me crazy.
>> Here is the scenario:
>> 1) I diff working copy against package.branchA-version.mcz
>> 2) I cherry pick and install a few methods
>> 3) I diff against package.branchA-version.mcz again to check if I missed smthing
>> 4) Huh? it looks like my cherry pick have not been installed???
>> Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!!
>> What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff.
>> So I had to change MCVersion>>changes
>>    ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot
>> 
>> This is so broken that I have to report here.
>> Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure!
>> 
>> Guys, it makes me wonder, who is eating the dog food?
>> Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;)
>> Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version.
> 





More information about the Pharo-dev mailing list