Re: [Pharo-project] After loading a package...all changes with "revision changed"
it would be nice to have a simple case that we can reproduce. Stef On Sep 27, 2010, at 10:42 PM, Mariano Martinez Peck wrote:
2010/9/26 Javier Pimás <elpochodelagente@gmail.com> We had a similar problem in squeaknos package, but just for some kind of classes. It was caused by having an initialize class method in classes derived from ExternalStructure, maybe it's because of the same reason? look there, you may get some answers.
Thanks. It is good to know I am not the only one. This bug is REAAAAALY annoying since you cannot see your changes.
I've checked and I have no #initialize at class level :(
The only thing I found is class side #new implementd something like:
new
^super new initialize.
can this be the problem?
where could I put a halt to see the problem ?
thanks in advance
mariano
regards, javier.
2010/9/26 Norbert Hartl <norbert@hartl.name>
FYI I encountered the same problem in gemstone. The only thing I know is that all loaded packages were created in pharo that showed this behaviour. It didn't show up in a reproducable manner and some packages were clean again after a few package updates. And for some month now I didn't see it.
Norbert
Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck <marianopeck@gmail.com>:
On Sat, Sep 25, 2010 at 9:02 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote:
Hi. I am having a probem with Glorp and I really have no idea what can be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed.
To reproduce:
- Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX - Open a MC Browser, select Glorp package and press the "Changes" button agains the ss repo. And you will see :)
May be the image used to save the package got a problem and changed the timestamp of the methods. So when you merge you get changed methods.
I've just tried commiting and load them in a clean image...same problem.
And if it were what you say...is there a solution?
thanks
mariano
Any help is really appreaciated.
Thanks
Mariano _______________________________________________ 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
_______________________________________________ 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
-- Javier Pimás Ciudad de Buenos Aires
_______________________________________________ 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
If you get that case, an idea that should work is to modify Behavior>>#compile:classified:notifying:trailer:ifFail: method (or someone like it) to insert a breakpoint that only halts when the new code is the same than the existing one. Then you could trace back who is recompiling existing code without your knowledge Regards, Javier. On Tue, Sep 28, 2010 at 4:11 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
it would be nice to have a simple case that we can reproduce.
Stef
On Sep 27, 2010, at 10:42 PM, Mariano Martinez Peck wrote:
2010/9/26 Javier Pimás <elpochodelagente@gmail.com> We had a similar problem in squeaknos package, but just for some kind of
classes. It was caused by having an initialize class method in classes derived from ExternalStructure, maybe it's because of the same reason? look there, you may get some answers.
Thanks. It is good to know I am not the only one. This bug is REAAAAALY
annoying since you cannot see your changes.
I've checked and I have no #initialize at class level :(
The only thing I found is class side #new implementd something like:
new
^super new initialize.
can this be the problem?
where could I put a halt to see the problem ?
thanks in advance
mariano
regards, javier.
2010/9/26 Norbert Hartl <norbert@hartl.name>
FYI I encountered the same problem in gemstone. The only thing I know is
that all loaded packages were created in pharo that showed this behaviour. It didn't show up in a reproducable manner and some packages were clean again after a few package updates. And for some month now I didn't see it.
Norbert
Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck <
marianopeck@gmail.com>:
On Sat, Sep 25, 2010 at 9:02 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote:
Hi. I am having a probem with Glorp and I really have no idea what can
be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed.
To reproduce:
- Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX - Open a MC Browser, select Glorp package and press the "Changes"
button agains the ss repo. And you will see :)
May be the image used to save the package got a problem and changed the timestamp of the methods. So when you merge you get changed methods.
I've just tried commiting and load them in a clean image...same problem.
And if it were what you say...is there a solution?
thanks
mariano
Any help is really appreaciated.
Thanks
Mariano _______________________________________________ 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
_______________________________________________ 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
-- Javier Pimás Ciudad de Buenos Aires
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Javier Pimás Ciudad de Buenos Aires
participants (2)
-
Javier Pimás -
Stéphane Ducasse