Pavel
I looked at your PR and I have some questions:
- could the fileReference have a class/instance var pointing to the
store instead of having yet another
global access to a singleton like class :)
- I was wondering why you have macStore and unixStore and …
I imagine to capture the difference but then why there is duplicated
code
e.g. file: path uid: uidInteger gid: gidInteger looks the same
I hope that the class comment explains it :)
- Why do you have a class var for each store? and not one single
metaclass inst var in the superclass?
Stef
> On 9 Jul 2019, at 14:28, Pavel Krivanek <pavel.kriva...@gmail.com> wrote:
>
> Hi,
>
> the current Pharo cannot deal very well in situations when you want to run
> multiple instances from one image file, especially on Windows, which
> complicates the setup of parallel applications. It is not able to work
> reasonably on read-only file-systems too. That's why I did the next attempt
> to improve this functionality of the system.
>
> In summary:
> - the image can be executed with --readOnlyMode image argument
> - the basic system tries to survive such limitation. The changes file is in
> read-only mode and new sources are installed into compiled methods directly,
> Ombu does not save content, Playground does not save cache etc.
> - PharoDebug.log and placeholder files on Windows are not created
> - the limitation is only on image-level so it is easy to bypass it.
> - the presence of the old file streams makes everything uglier and messier
>
> We have an open PR for this issue:
> https://github.com/pharo-project/pharo/pull/3837
> <https://github.com/pharo-project/pharo/pull/3837>
>
> Comments and reviews are welcome.
>
> -- Pavel
>
