Smalltalk › Pharo › Pharo Smalltalk Developers

why is gt playground not saving the code

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Peter Uhnak

why is gt playground not saving the code

At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.

In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…

Peter

Nicolai Hess-3-2

Re: why is gt playground not saving the code

2016-08-31 12:00 GMT+02:00 Peter Uhnák <[hidden email]>:

At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.

In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…

This was discussed a couple of time and we even had some bug-entries.

But it is working that way "by-design".

I don't understand why, but the current content is not shown in the history, only if you close the current playground window *withouth* deleteing the content.

If the content is not shown in the history, it may be still in the play-cache folder.

Peter

Andrei Chis

Re: why is gt playground not saving the code

On Wed, Aug 31, 2016 at 12:32 PM, Nicolai Hess <[hidden email]> wrote:

2016-08-31 12:00 GMT+02:00 Peter Uhnák <[hidden email]>:
At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.

In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…

This was discussed a couple of time and we even had some bug-entries.
But it is working that way "by-design".
I don't understand why, but the current content is not shown in the history, only if you close the current playground window *withouth* deleteing the content.

I do not remember the previous discussion in details but I think we should consider this a bug.

I'll open a bug report and try to dig the previous discussion about this topic.

Cheers,

Andrei

If the content is not shown in the history, it may be still in the play-cache folder.

Peter

Tudor Girba-2

Re: why is gt playground not saving the code

In reply to this post by Peter Uhnak

Hi,

The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm?

One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed.

As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well.

In any case, the dealing with the history of the playground is underdeveloped. So, let’s see if we can identify ways to improve the situation.

What do you think?

Cheers,
Doru

> On Aug 31, 2016, at 12:00 PM, Peter Uhnák <[hidden email]> wrote:
>
> At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.
>
> In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…
>
> <F091EED2725D4C679C390F5BC76E1CE3.png>
>
> Peter
> <F091EED2725D4C679C390F5BC76E1CE3.png>

--
www.tudorgirba.com
www.feenk.com

"Speaking louder won't make the point worthier."

Peter Uhnak

Re: why is gt playground not saving the code

On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote:

Thank you both for the answers, I didn't know there was a disk storage that was independent of what was shown to me, so next time I crash I will check.
But there were other strange issues going around, or at least confusing. So I'll try to play with it a bit tomorrow.

Thanks,
Peter

Sven Van Caekenberghe-2

Re: why is gt playground not saving the code

You can also explicitly name your pages (tabs) by double-clicking the title and changing it. Then your pages get copied to play-stash using that name. This gives you more control over what happens.

On 31 Aug 2016, at 22:30, Peter Uhnak <[hidden email]> wrote:

On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote:
Hi,

The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm?

One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed.

As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well.

In any case, the dealing with the history of the playground is underdeveloped. So, let’s see if we can identify ways to improve the situation.

What do you think?

Thank you both for the answers, I didn't know there was a disk storage that was independent of what was shown to me, so next time I crash I will check.
But there were other strange issues going around, or at least confusing. So I'll try to play with it a bit tomorrow.

Thanks,
Peter

Esteban A. Maringolo

Re: why is gt playground not saving the code

In reply to this post by Tudor Girba-2

One use case that sometimes bites me is when I'm working in the "code"
of the Playground (first screen), and then I start going deep with
"Evaluate and Go", basically inspecting my objects, and then I close
the window thinking I'm dealing with an inspector hence losing the
code of the "workspace" in the Playground that started the inspection
"workflow", without receiving any warning about "losing" my changes.

I'd like an explicit "Save" in the Playground, but since I'm not
adding it, I can't complain much. :)

Regards.

Esteban A. Maringolo
Esteban A. Maringolo

2016-08-31 17:10 GMT-03:00 Tudor Girba <[hidden email]>:

> Hi,
>
> The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm?
>
> One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed.
>
> As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well.
>
> In any case, the dealing with the history of the playground is underdeveloped. So, let’s see if we can identify ways to improve the situation.
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Aug 31, 2016, at 12:00 PM, Peter Uhnák <[hidden email]> wrote:
>>
>> At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.
>>
>> In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…
>>
>> <F091EED2725D4C679C390F5BC76E1CE3.png>
>>
>> Peter
>> <F091EED2725D4C679C390F5BC76E1CE3.png>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Speaking louder won't make the point worthier."
>
>

Tudor Girba-2

Re: why is gt playground not saving the code

Hi,

> On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo <[hidden email]> wrote:
>
> One use case that sometimes bites me is when I'm working in the "code"
> of the Playground (first screen), and then I start going deep with
> "Evaluate and Go", basically inspecting my objects, and then I close
> the window thinking I'm dealing with an inspector hence losing the
> code of the "workspace" in the Playground that started the inspection
> "workflow", without receiving any warning about "losing" my changes.
> I'd like an explicit "Save" in the Playground, but since I'm not
> adding it, I can't complain much. :)

Thanks for the input. What would the Save do in this case?

Should the “save" save the code from the playground? The code from the playground is actually not lost when you close the Playground, and neither is the code you write in the Raw panes. Or is there a different thing you have in mind?

Doru

>
> Regards.
>
>
> Esteban A. Maringolo
> Esteban A. Maringolo
>
>
> 2016-08-31 17:10 GMT-03:00 Tudor Girba <[hidden email]>:
>> Hi,
>>
>> The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm?
>>
>> One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed.
>>
>> As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well.
>>
>> In any case, the dealing with the history of the playground is underdeveloped. So, let’s see if we can identify ways to improve the situation.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>>
>>> On Aug 31, 2016, at 12:00 PM, Peter Uhnák <[hidden email]> wrote:
>>>
>>> At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.
>>>
>>> In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…
>>>
>>> <F091EED2725D4C679C390F5BC76E1CE3.png>
>>>
>>> Peter
>>> <F091EED2725D4C679C390F5BC76E1CE3.png>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Speaking louder won't make the point worthier."
>>
>>
>

--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

Esteban A. Maringolo

Re: why is gt playground not saving the code

2016-08-31 18:43 GMT-03:00 Tudor Girba <[hidden email]>:

> Hi,
>
>> On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo <[hidden email]> wrote:
>>
>> One use case that sometimes bites me is when I'm working in the "code"
>> of the Playground (first screen), and then I start going deep with
>> "Evaluate and Go", basically inspecting my objects, and then I close
>> the window thinking I'm dealing with an inspector hence losing the
>> code of the "workspace" in the Playground that started the inspection
>> "workflow", without receiving any warning about "losing" my changes.
>> I'd like an explicit "Save" in the Playground, but since I'm not
>> adding it, I can't complain much. :)
>
> Thanks for the input. What would the Save do in this case?

It should let me decide IF and WHEN to store the code contents.

Also, if you tests scripts in a workspace and evaluate them
"outside" of it (e.g. from the command line) I have to copy/paste the
contents back and forth from the Playground to a text editor to
save/modify something that in the past I did with the Workspace.

> Should the “save" save the code from the playground?

Yes.

> The code from the playground is actually not lost when you close the Playground, and neither is the code you write in the Raw panes. Or is there a different thing you have in mind?

Is not lost, but sometimes I want to reset it (reload) from a previous
saved state. Maybe the latest evaluation isn't what I want to recover.
Also the menu isn't the best option if you have several expressions
that start with the same characters and are indistinguishable from
each other.

I appreciate the "autosave" like feature (although I'd like to be able
to disable it for security paranoid concerns), but I also like to
decide when to save.

But the use case I pointed wasn't about storing the contents outside
of the playground but instead of getting a warning or something when
closing the Playground doing inspection. Sometimes I don't want to
close the playground, just want to reset everything to the original
code pane as if no "Evaluate and Go" was ever ran.

Regards!

Esteban A. Maringolo

stepharo

Re: why is gt playground not saving the code

In reply to this post by Tudor Girba-2

Le 31/8/16 à 22:10, Tudor Girba a écrit :
> Hi,
>
> The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm?
>
> One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed.

should protect it with a session check

>
> As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well.
>
> In any case, the dealing with the history of the playground is underdeveloped. So, let’s see if we can identify ways to improve the situation.
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Aug 31, 2016, at 12:00 PM, Peter Uhnák <[hidden email]> wrote:
>>
>> At this point I’ve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose.
>>
>> In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…
>>
>> <F091EED2725D4C679C390F5BC76E1CE3.png>
>>
>> Peter
>> <F091EED2725D4C679C390F5BC76E1CE3.png>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Speaking louder won't make the point worthier."
>
>
>