Recover question at startup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Recover question at startup

HilaireFernandes
Hi,

When I build DrGeo app against P7, then test it on a *different*
computer used to build it, I have this dialog message at start up: "Its
seems your last Pharo session existed without saving some code. Do you
want to recover it?"

As far as I understand it is related to Epicea, as I don't I need it in
appication built, what is the way to properly unactivate it? Can it be
uninstalled may be?

Hilaire

--
Dr. Geo
http://drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

HilaireFernandes
Replying to myself for the record, these two lines seem to inactivate Epicea

     "Inactivate Epicea"
     EpSettings monitorEnabled: false.
     EpSettings lostEventsDetectorEnabled: false.


Now, there is still likely an issue I don't understand


--
Dr. Geo
http://drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

tesonep@gmail.com
Hi,  
   I have been checking this problem and the message is shown because is trying to find the ombu file for the current session. 
Usually what it does is comparing the file with the recorded size and timestamp in the image to check that the file has no new changes.
If the file is newer or larger than the previous info of the image, the recover message appears.

I think there is a bug here, although I am not sure, I think that Martín has to help to understand it.
Because in the current implementation if the file does not exists it produces the recovery message. 
Even though it can show that there are changes, if there is no file with them I think is quite difficult to recover them.

This behaviour is not happening in the machine where the image is built, because the file exists in the disk. They are stored in the pharo-local directory.

Cheers,
Pablo

On Sat, Apr 14, 2018 at 5:56 PM, Hilaire <[hidden email]> wrote:
Replying to myself for the record, these two lines seem to inactivate Epicea

    "Inactivate Epicea"
    EpSettings monitorEnabled: false.
    EpSettings lostEventsDetectorEnabled: false.


Now, there is still likely an issue I don't understand



--
Dr. Geo
http://drgeo.eu






--
Pablo Tesone.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

HilaireFernandes
Le 14/04/2018 à 18:32, [hidden email] a
écrit :
>
> This behaviour is not happening in the machine where the image is
> built, because the file exists in the disk. They are stored in the
> pharo-local directory.

And it tries to access it  and at some point the path to the file get
absolute, right? Then saved in the built image? May be this should not
happen.

Thanks for the clarifications.

Hilaire

--
Dr. Geo
http://drgeo.eu



Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

Ben Coman
In reply to this post by tesonep@gmail.com
On Sat, Apr 14, 2018 at 5:56 PM, Hilaire <[hidden email]> wrote:
Replying to myself for the record, these two lines seem to inactivate Epicea

    "Inactivate Epicea"
    EpSettings monitorEnabled: false.
    EpSettings lostEventsDetectorEnabled: false.


Now, there is still likely an issue I don't understand


On 15 April 2018 at 00:32, [hidden email] <[hidden email]> wrote:
Hi,  
   I have been checking this problem and the message is shown because is trying to find the ombu file for the current session. 
Usually what it does is comparing the file with the recorded size and timestamp in the image to check that the file has no new changes.
If the file is newer or larger than the previous info of the image, the recover message appears.

I think there is a bug here, although I am not sure, I think that Martín has to help to understand it.
Because in the current implementation if the file does not exists it produces the recovery message. 
Even though it can show that there are changes, if there is no file with them I think is quite difficult to recover them.

This behaviour is not happening in the machine where the image is built, because the file exists in the disk. They are stored in the pharo-local directory.

Cheers,
Pablo


I didn't have a chance to check for repeat-ability, but yesterday I saved-quit and Image-A, 
then in PharoLauncher did a Copy of Image-A to image-B, 
then opening Image-B got a question about Recovery that I didn't expect or want.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

tesonep@gmail.com
I have created an Issue (https://pharo.fogbugz.com/f/cases/21708/Epicea-should-not-offer-to-recover-changes-if-the-ombu-file-does-not-exists)
to follow the conversation and to notify Martín and listen to his opinion.

Cheers,
Pablo

On Sun, Apr 15, 2018 at 7:02 AM, Ben Coman <[hidden email]> wrote:
On Sat, Apr 14, 2018 at 5:56 PM, Hilaire <[hidden email]> wrote:
Replying to myself for the record, these two lines seem to inactivate Epicea

    "Inactivate Epicea"
    EpSettings monitorEnabled: false.
    EpSettings lostEventsDetectorEnabled: false.


Now, there is still likely an issue I don't understand


On 15 April 2018 at 00:32, [hidden email] <[hidden email]> wrote:
Hi,  
   I have been checking this problem and the message is shown because is trying to find the ombu file for the current session. 
Usually what it does is comparing the file with the recorded size and timestamp in the image to check that the file has no new changes.
If the file is newer or larger than the previous info of the image, the recover message appears.

I think there is a bug here, although I am not sure, I think that Martín has to help to understand it.
Because in the current implementation if the file does not exists it produces the recovery message. 
Even though it can show that there are changes, if there is no file with them I think is quite difficult to recover them.

This behaviour is not happening in the machine where the image is built, because the file exists in the disk. They are stored in the pharo-local directory.

Cheers,
Pablo


I didn't have a chance to check for repeat-ability, but yesterday I saved-quit and Image-A, 
then in PharoLauncher did a Copy of Image-A to image-B, 
then opening Image-B got a question about Recovery that I didn't expect or want.

cheers -ben



--
Pablo Tesone.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

CyrilFerlicot
On 16/04/2018 11:30, [hidden email] wrote:
> I have created an Issue
> (https://pharo.fogbugz.com/f/cases/21708/Epicea-should-not-offer-to-recover-changes-if-the-ombu-file-does-not-exists)
> to follow the conversation and to notify Martín and listen to his opinion.
>

Hi,

Indeed it would be cool to not show the recover window when there is no
ombu file. It was something I already raised in this message:

http://forum.world.st/Problems-with-Epicea-on-Pharo-7-td5069768.html

> Cheers,
> Pablo
>
> --
> Pablo Tesone.
> [hidden email] <mailto:[hidden email]>


--
Cyril Ferlicot
https://ferlicot.fr

Reply | Threaded
Open this post in threaded view
|

Re: Recover question at startup

tesonep@gmail.com
Hi Cyril, I have taken your mail and added to the issue.

Thanks

On Mon, Apr 16, 2018 at 11:35 AM, Cyril Ferlicot D. <[hidden email]> wrote:
On 16/04/2018 11:30, [hidden email] wrote:
> I have created an Issue
> (https://pharo.fogbugz.com/f/cases/21708/Epicea-should-not-offer-to-recover-changes-if-the-ombu-file-does-not-exists)
> to follow the conversation and to notify Martín and listen to his opinion.
>

Hi,

Indeed it would be cool to not show the recover window when there is no
ombu file. It was something I already raised in this message:

http://forum.world.st/Problems-with-Epicea-on-Pharo-7-td5069768.html

> Cheers,
> Pablo
>
> --
> Pablo Tesone.
> [hidden email] <mailto:[hidden email]>


--
Cyril Ferlicot
https://ferlicot.fr




--
Pablo Tesone.
[hidden email]