Recovery log thoughts

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

Recovery log thoughts

xx397
One area I see some beginners struggle with image development is with
regards to losing work, and I feel that Pharo's recovery log could be
improved to help with this.

Two scenarios that come to mind are firstly where methods are filed in
that created an instance variable at method save the first time round.
These log to the transcript that the variable is now undeclared, but
that can go unseen, and the result is things appearing to work while you
only have one instance of that object. Could this bring up a similar
prompt maybe? Another difficulty is that you can not simply file in all
selections as any do-it's which were done in a different context will
fail. Is there any way we can differentiate the important do-it's such
as class definitions, selector removes and so on from the rest?

Regards,
Chris

Reply | Threaded
Open this post in threaded view
|

Re: Recovery log thoughts

Stéphane Ducasse

On Jul 22, 2012, at 9:23 PM, Chris wrote:

> One area I see some beginners struggle with image development is with regards to losing work, and I feel that Pharo's recovery log could be improved to help with this.

yes :)
Now that we have ring we should start rethinking source management but this will not be for 2.0
except if somebody come up with a good and working solution.

> Two scenarios that come to mind are firstly where methods are filed in that created an instance variable at method save the first time round. These log to the transcript that the variable is now undeclared, but that can go unseen, and the result is things appearing to work while you only have one instance of that object. Could this bring up a similar prompt maybe? Another difficulty is that you can not simply file in all selections as any do-it's which were done in a different context will fail. Is there any way we can differentiate the important do-it's such as class definitions, selector removes and so on from the rest?

I would really like to have a structured logger and not just a flow of text.

>
> Regards,
> Chris
>


Reply | Threaded
Open this post in threaded view
|

Re: Recovery log thoughts

xx397
On 23/07/2012 07:58, Stéphane Ducasse wrote:

> On Jul 22, 2012, at 9:23 PM, Chris wrote:
>
>> One area I see some beginners struggle with image development is with regards to losing work, and I feel that Pharo's recovery log could be improved to help with this.
> yes :)
> Now that we have ring we should start rethinking source management but this will not be for 2.0
> except if somebody come up with a good and working solution.
>
>> Two scenarios that come to mind are firstly where methods are filed in that created an instance variable at method save the first time round. These log to the transcript that the variable is now undeclared, but that can go unseen, and the result is things appearing to work while you only have one instance of that object. Could this bring up a similar prompt maybe? Another difficulty is that you can not simply file in all selections as any do-it's which were done in a different context will fail. Is there any way we can differentiate the important do-it's such as class definitions, selector removes and so on from the rest?
> I would really like to have a structured logger and not just a flow of text.
>

That sounds great for the long term, but was wondering if there were any
good ideas in the meantime! I could only think of applying do-it's if it
starts with a class name for example.


Reply | Threaded
Open this post in threaded view
|

Re: Recovery log thoughts

Stéphane Ducasse

On Jul 23, 2012, at 10:34 PM, Chris wrote:

> On 23/07/2012 07:58, Stéphane Ducasse wrote:
>> On Jul 22, 2012, at 9:23 PM, Chris wrote:
>>
>>> One area I see some beginners struggle with image development is with regards to losing work, and I feel that Pharo's recovery log could be improved to help with this.
>> yes :)
>> Now that we have ring we should start rethinking source management but this will not be for 2.0
>> except if somebody come up with a good and working solution.
>>
>>> Two scenarios that come to mind are firstly where methods are filed in that created an instance variable at method save the first time round. These log to the transcript that the variable is now undeclared, but that can go unseen, and the result is things appearing to work while you only have one instance of that object. Could this bring up a similar prompt maybe? Another difficulty is that you can not simply file in all selections as any do-it's which were done in a different context will fail. Is there any way we can differentiate the important do-it's such as class definitions, selector removes and so on from the rest?
>> I would really like to have a structured logger and not just a flow of text.
>>
>
> That sounds great for the long term, but was wondering if there were any good ideas in the meantime! I could only think of applying do-it's if it starts with a class name for example.

yes if you have some hacks like that send them and we will probably introduce them.

>
>