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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Apr 7 16:28:31 EDT 2014

Esteban, you probably have a recent computer, not an old Core2duo like me...
What diffing Monticello from latest Pharo3.0 with latest Squeak trunk costs
For VMMaker it's worse.
It's matter of seconds for displaying the old diff tool...

2014-04-07 17:19 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> 2014-04-07 13:28 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:
> 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?
>> Esteban
>> ps: afaik, vmmaker was loading in 3.0 with some fixes, but there is still
>> not configuration released for it.
> Hi Esteban,
> The most probable explanation is that you are so used to these failures
> that you adopted a circumvention strategy, consciously or not.
> You must consider me as a newbie, and as a newbie I step where the
> experimented user has learned not to...
> Try
> https://pharo.fogbugz.com/f/cases/13181/MCVersion-should-NEVER-cache-a-snapshot-of-the-working-copyand tell me if this is reproducible for you or not.
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140407/dc765494/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PolymorphDiff_TimeProfiler.png
Type: image/png
Size: 157867 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140407/dc765494/attachment.png>

More information about the Pharo-dev mailing list