MC diffs are seriously broken in Pharo2.0
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.
On 06 Apr 2014, at 17:36, Nicolas Cellier <nicolas.cellier.aka.nice@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. Do you have the same with 30? Because I know that there were some problems when we merged OC and EC but this is nearly more than a year ago.
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.
Nicolas this is probably not gratuitoulsy and you know it. Doing imply doing mistakes. Give me a fully tested system and you will see that we will not break it. So can you open a bug entry so that we do not forget to fix it.
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.
Thanks this is the best things to do. You see probably one guy tried to speed up the system and this happens.
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?
We are constantly using Pharo alpha the complete moose and pharo
Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;)
I guess so. Esteban does not look like using Pharo2.0 but I will let him reply.
Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version.
Us too. :) Thanks for reporting problems. Can you open bug entries so that we can handle these problems? Stef
On 06 Apr 2014, at 5:36 , Nicolas Cellier <nicolas.cellier.aka.nice@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.
Not only that, the simplest possible merge operation is broken: https://pharo.fogbugz.com/f/cases/12776/Cancelling-Previous-Contents-in-a-Wo... As it stands, MC in Pharo is nothing but a fancy change set applier, not a version control system. Cheers, Henry
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. On 06 Apr 2014, at 12:36, Nicolas Cellier <nicolas.cellier.aka.nice@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.
On 07 Apr 2014, at 08:28, Esteban Lorenzano <estebanlm@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@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.
Hi: On 07 Apr 2014, at 13:28, Esteban Lorenzano <estebanlm@gmail.com> wrote:
ps: afaik, vmmaker was loading in 3.0 with some fixes, but there is still not configuration released for it.
This requires the use of the old compiler I think. The whole source code generation does not yet work is Opal. The simulators however work in Pharo 3.0. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
2014-04-07 13:28 GMT+02:00 Esteban Lorenzano <estebanlm@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-snaps... tell me if this is reproducible for you or not.
On 06 Apr 2014, at 12:36, Nicolas Cellier < nicolas.cellier.aka.nice@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.
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 attached. 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@gmail.com>:
2014-04-07 13:28 GMT+02:00 Esteban Lorenzano <estebanlm@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-snaps... tell me if this is reproducible for you or not.
On 06 Apr 2014, at 12:36, Nicolas Cellier < nicolas.cellier.aka.nice@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.
participants (5)
-
Esteban Lorenzano -
Henrik Johansen -
Nicolas Cellier -
Pharo4Stef -
Stefan Marr