Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore
On 9 May 2010 21:39, Alain Plantec <alain.plantec@free.fr> wrote:
Le 09/05/2010 18:48, Igor Stasenko a écrit :
On 9 May 2010 13:29, Alain Plantec<alain.plantec@free.fr> Â wrote:
This was a result of lack of attention, not my real intent. :)
ok, so we have the same version
But unfortunately, this solution seems to be broken to. It works one time,
but while trying to condenseChanges again several time, my squeak process is killed without flushing any log.
You mean running #condenseChanges multiple times in a row, or interrupting it and then start over again? You should know, that it is important to not interrupt it in the middle, because when you doing that, part of your methods having old source pointers, while rest part having new ones, and there is no way to tell, which one is correct.
I take a fresh image. SmalltalkImage current condenseChanges. then I update some methods individually and save my image, then SmalltalkImage current condenseChanges. and it crash
Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again no crash reported.
Alain
-- Best regards, Igor Stasenko AKA sig.
Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :( Alain
Alain
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran  Smalltalk condenseChanges - changed the single method - saved image - ran  Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?). Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods. Nicolas 2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran  Smalltalk condenseChanges - changed the single method - saved image - ran  Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
nicolas do you have an idea where we can look? Stef On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
2010/5/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
do you have an idea where we can look?
Stef
Sorry, I don't have time to dig into it... But I think invent is a more appropriate verb than look in this case. The ideas of Igor sound good to me, delegate some to CompiledMethods and maybe use a mass becomeForward Nicolas
On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran  Smalltalk condenseChanges - changed the single method - saved image - ran  Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
Ok...now it seems to be working again. However, It takes MUCH more time than in Pharo 1.0. I really don't care too much, I just want to know if this is expected or not. Cheers Mariano On Tue, May 11, 2010 at 8:41 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2010/5/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
do you have an idea where we can look?
Stef
Sorry, I don't have time to dig into it... But I think invent is a more appropriate verb than look in this case. The ideas of Igor sound good to me, delegate some to CompiledMethods and maybe use a mass becomeForward
Nicolas
On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges
:(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
On May 13, 2010, at 11:33 PM, Mariano Martinez Peck wrote:
Ok...now it seems to be working again. However, It takes MUCH more time than in Pharo 1.0.
can you be more precise? Apparently they are a lot of methods hanging around and they should be cleaned. Now we do not care that condense Changes is fast or not. It works so perfect.
I really don't care too much, I just want to know if this is expected or not.
Cheers
Mariano
On Tue, May 11, 2010 at 8:41 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote: 2010/5/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
do you have an idea where we can look?
Stef
Sorry, I don't have time to dig into it... But I think invent is a more appropriate verb than look in this case. The ideas of Igor sound good to me, delegate some to CompiledMethods and maybe use a mass becomeForward
Nicolas
On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, May 14, 2010 at 12:15 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On May 13, 2010, at 11:33 PM, Mariano Martinez Peck wrote:
Ok...now it seems to be working again. However, It takes MUCH more time than in Pharo 1.0.
can you be more precise?
Yes, I can: "In PharoCore 10517" MessageTally time: [Smalltalk condenseChanges]. -> 8127 "In PharoCore 11357" MessageTally time: [Smalltalk condenseChanges]. 490523
Apparently they are a lot of methods hanging around and they should be cleaned. Now we do not care that condense Changes is fast or not. It works so perfect.
Yes. But I am intrigued why.
I really don't care too much, I just want to know if this is expected or not.
Cheers
Mariano
On Tue, May 11, 2010 at 8:41 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote: 2010/5/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
do you have an idea where we can look?
Stef
Sorry, I don't have time to dig into it... But I think invent is a more appropriate verb than look in this case. The ideas of Igor sound good to me, delegate some to CompiledMethods and maybe use a mass becomeForward
Nicolas
On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second
condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
_______________________________________________ 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
2010/5/14 Mariano Martinez Peck <marianopeck@gmail.com>:
On Fri, May 14, 2010 at 12:15 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 13, 2010, at 11:33 PM, Mariano Martinez Peck wrote:
Ok...now it seems to be working again. However, It takes MUCH more time than in Pharo 1.0.
can you be more precise?
Yes, I can:
"In PharoCore 10517" MessageTally time: [Smalltalk condenseChanges]. -> 8127
"In PharoCore 11357" MessageTally time: [Smalltalk condenseChanges]. 490523
Apparently they are a lot of methods hanging around and they should be cleaned. Now we do not care that condense Changes is fast or not. It works so perfect.
Yes. But I am intrigued why.
array := ByteArray new: 100. Try compare speed between array at: 1 put: 10. and: arrayCopy := array copy. arrayCopy at: 1 put: 10. arrayCopy becomeForward: array.
I really don't care too much, I just want to know if this is expected or not.
Cheers
Mariano
On Tue, May 11, 2010 at 8:41 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote: 2010/5/10 Stéphane Ducasse <stephane.ducasse@inria.fr>:
nicolas
do you have an idea where we can look?
Stef
Sorry, I don't have time to dig into it... But I think invent is a more appropriate verb than look in this case. The ideas of Igor sound good to me, delegate some to CompiledMethods and maybe use a mass becomeForward
Nicolas
On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran  Smalltalk condenseChanges - changed the single method - saved image - ran  Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
On 10 May 2010 19:26, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Sorry for the infinite loop, it was my fault. I thought it had been detected and solved already (in squeak ?).
Destroying source pointer of un-installed methods was just a workaround to be used in case of already broken sources. There is another strategy : detect the source pointer of un-installed methods and store them in the new change log. This has to be done before logging source code of installed methods.
I'd like to point, that some trailer kinds don't need to be altered even if you condensing changes. They are completely self sufficient and not related to 'standard' source management system. In fact, a condense changes _should_ take care only about methods which having a trailers carrying the source pointers ("001000" #VarLengthSourcePointer, "111111" #SourcePointer ) while others don't need any changes. There is a test method in CompiledMethodTrailer, #hasSourcePointer which can be used to check if you need to deal with this method when condensing .changes or not. But since currently the variety of trailers its not widely adopted (most of methods just storing a source pointers there), its fine to destroy trailers of non-installed methods. In future, it could be made more clever.
Nicolas
2010/5/9 Igor Stasenko <siguctua@gmail.com>:
On 9 May 2010 23:17, Alain Plantec <alain.plantec@free.fr> wrote:
Ok, i took the 11343 - fixed the #condenseChanges - ran  Smalltalk condenseChanges - changed the single method - saved image - ran  Smalltalk condenseChanges again
no crash reported.
Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :(
Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it.
Alain
Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Alain Plantec -
Igor Stasenko -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse