Recovering lost changes

Hello all,

I had some type of melt-down today and ended up with an image that won't load.  I have a backup from a few days ago, but a lot has happened since then.  Recent change logs seem to be readable, but the "Recover lost changes" GUI has not been terribly helpful.  Is there a way to filter to things like most recent versions of a any given methods, and/or sort on the types of chunks?

One surprising weakness I noted was that many do-it chunks involve things that were in context in the debugger, are "now" nil and ended up breaking the file-in command.  I put an error handler around the evaluatations which helped, but things are still somewhat slow thanks to other do-its that do a LOT of work.  I might start chipping away from the most recent chunks until it recovers enough that I can cut my loses.

Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to emulate.  With what we have now, any workarounds for the things above would be greatly appreciated.

Is there a way to do extended selection (e.g. shift-select to select a range of chunks)?

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mar 27, 2010, at 4:09 AM, Schwab,Wilhelm K wrote:

> Hello all,
>
> I had some type of melt-down today and ended up with an image that won't load.  I have a backup from a few days ago, but a lot has happened since then.  Recent change logs seem to be readable, but the "Recover lost changes" GUI has not been terribly helpful.  Is there a way to filter to things like most recent versions of a any given methods, and/or sort on the types of chunks?
>
> One surprising weakness I noted was that many do-it chunks involve things that were in context in the debugger, are "now" nil and ended up breaking the file-in command.  I put an error handler around the evaluatations which helped, but things are still somewhat slow thanks to other do-its that do a LOT of work.  I might start chipping away from the most recent chunks until it recovers enough that I can cut my loses.
>
> Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to emulate.  With what we have now, any workarounds for the things above would be greatly appreciated.


we should already log class definition as class definition and not doits.
There are so many things to fix.
Cleaning the chunk format, fileouter, changes recorder...

> Is there a way to do extended selection (e.g. shift-select to select a range of chunks)?
>
> Bill
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef,

I just spent an hour or so using the lost changes browser to recover much of the past couple of day's work.   The good news is that it was very stable in doing what it does.  I have been doing a lot of code generation from meta data, which allowed me to make a *very* large number of entries in the change log.  Sorting through that was problematic.  Features of Ian Bartholomew's Chunk Browser would have been very helpful.  In particular, Ian offers ways to filter on chunk type and to identify the most recent chunks for any given class/method.

My big mistake was failing to make a backup following the last generation step and before importing more of my code from Dolphin.  I have been using SIF to export code followed by "search and replace" via the regex package to create relatively cleanly loading code.  Being forced to do that again, I improved the search and replace step and found many relevant chunks that have most of the imported code in reasonable shape; a lot of it will be buggy for some time due to callbacks and other details.

One thing that has been (temporarily) lost is some category changes, but that will be easy to replicate.  I am more concerned about subtle changes to the generation that might not have survived the recovery.  So far, it looks ok, but my first priority was to get a post-recovery backup to avoid repeating the whole mess.

Now I notice that my change log is 29MB and climbing.  Does #condenseChanges work?  The limit is 32 MB, right?  It might also simply be time to build a new image on RC3.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Saturday, March 27, 2010 7:12 AM
To: [hidden email]
Subject: Re: [Pharo-project] Recovering lost changes


On Mar 27, 2010, at 4:09 AM, Schwab,Wilhelm K wrote:

> Hello all,
>
> I had some type of melt-down today and ended up with an image that won't load.  I have a backup from a few days ago, but a lot has happened since then.  Recent change logs seem to be readable, but the "Recover lost changes" GUI has not been terribly helpful.  Is there a way to filter to things like most recent versions of a any given methods, and/or sort on the types of chunks?
>
> One surprising weakness I noted was that many do-it chunks involve things that were in context in the debugger, are "now" nil and ended up breaking the file-in command.  I put an error handler around the evaluatations which helped, but things are still somewhat slow thanks to other do-its that do a LOT of work.  I might start chipping away from the most recent chunks until it recovers enough that I can cut my loses.
>
> Ian Bartholomew's Chunk Browser for Dolphin would be an ideal tool to emulate.  With what we have now, any workarounds for the things above would be greatly appreciated.


we should already log class definition as class definition and not doits.
There are so many things to fix.
Cleaning the chunk format, fileouter, changes recorder...

> Is there a way to do extended selection (e.g. shift-select to select a range of chunks)?
>
> Bill
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mar 27, 2010, at 3:34 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> I just spent an hour or so using the lost changes browser to recover much of the past couple of day's work.   The good news is that it was very stable in doing what it does.  I have been doing a lot of code generation from meta data, which allowed me to make a *very* large number of entries in the change log.  Sorting through that was problematic.  Features of Ian Bartholomew's Chunk Browser would have been very helpful.  In particular, Ian offers ways to filter on chunk type and to identify the most recent chunks for any given class/method.
>
> My big mistake was failing to make a backup following the last generation step and before importing more of my code from Dolphin.  I have been using SIF to export code followed by "search and replace" via the regex package to create relatively cleanly loading code.  Being forced to do that again, I improved the search and replace step and found many relevant chunks that have most of the imported code in reasonable shape; a lot of it will be buggy for some time due to callbacks and other details.
>
> One thing that has been (temporarily) lost is some category changes, but that will be easy to replicate.  I am more concerned about subtle changes to the generation that might not have survived the recovery.  So far, it looks ok, but my first priority was to get a post-recovery backup to avoid repeating the whole mess.
>
> Now I notice that my change log is 29MB and climbing.  Does #condenseChanges work?

It should. We use it for building the release candidates
Now I thought that we do not have this limit but 2Gb

>  The limit is 32 MB, right?  It might also simply be time to build a new image on RC3.

rebuilding fresh is always good.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef, all,

I doubt I will actually do this since I seem to have recovered things fairly well, but what do you think about the following proceedure:

(1) use most recent loadable image from a backup and the most recent available changes (which I already did)

(2) condense changes

(3) recover lost changes in the resulting image.

If it does what I think/want it to do, I assume the redudant changes would be eliminated, making it easier to recover the most recent state of any given method.  Does that sound right?

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Saturday, March 27, 2010 10:00 AM
To: [hidden email]
Subject: Re: [Pharo-project] Recovering lost changes


On Mar 27, 2010, at 3:34 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> I just spent an hour or so using the lost changes browser to recover much of the past couple of day's work.   The good news is that it was very stable in doing what it does.  I have been doing a lot of code generation from meta data, which allowed me to make a *very* large number of entries in the change log.  Sorting through that was problematic.  Features of Ian Bartholomew's Chunk Browser would have been very helpful.  In particular, Ian offers ways to filter on chunk type and to identify the most recent chunks for any given class/method.
>
> My big mistake was failing to make a backup following the last generation step and before importing more of my code from Dolphin.  I have been using SIF to export code followed by "search and replace" via the regex package to create relatively cleanly loading code.  Being forced to do that again, I improved the search and replace step and found many relevant chunks that have most of the imported code in reasonable shape; a lot of it will be buggy for some time due to callbacks and other details.
>
> One thing that has been (temporarily) lost is some category changes, but that will be easy to replicate.  I am more concerned about subtle changes to the generation that might not have survived the recovery.  So far, it looks ok, but my first priority was to get a post-recovery backup to avoid repeating the whole mess.
>
> Now I notice that my change log is 29MB and climbing.  Does #condenseChanges work?

It should. We use it for building the release candidates Now I thought that we do not have this limit but 2Gb

>  The limit is 32 MB, right?  It might also simply be time to build a new image on RC3.

rebuilding fresh is always good.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project