Thanks guille for this analysis. I would move it to Pharo 8.0 Now I think that we should revive your analysis on state because I would love to have first class objects with a good and nice logic for such cases and others. The lifetime of a variable looks more complex than it looks.
On 8 Jan 2019, at 12:19, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi all,
I was checking issue https://pharo.fogbugz.com/f/cases/19852 <https://pharo.fogbugz.com/f/cases/19852> which is about the problems that arise when we move an image of location, and moreover when we move it between different platforms (windows to linux or mac for example).
The problem are dangling file references pointing to invalid locations.
We have found 4 of them:
SystemResolver localdirectory is cached in a class variable GTPlaybook caches the cache and stash directories in class variables OMSessionStore retrieves at some point during startup an invalid file reference from the (wrongly cached) local directory IceLibgitRepository Sharedrepositorieslocation is also cached
All these are actually caused by settings, whose behavior is not defined when an image is moved. There are several strange issues like, if we store settings, the local directory is stored, and then all images will (wrongly) use the same pharo-local directory of the first image. This is particularly annoying when using the launcher for example :).
Now, we can leave this as it is right now and just move it to pharo8. A quick fix for Pharo7 would be removing those settings and avoiding caching, but that is probably very disruptive too...
Opinions?
Guille