For now, in my 'deployed' image, I have: 1. Disabled SourceFilesArray >> forceChangesToDisk I did not find any code branch that would avoid this, so for now I just made it do nothing. Maybe I should disable ChangesLog >> logChange: instead.
2. Disabled PharoFilesOpener >> changesFileOrNil Same story. But this only causes warning get printed out, not error. Disabling it removes the warning message. 3. Set changesFileStream to nil (SourceFiles changesFileStream: nil). Some code does have guard against nil value for this changes stream. This works for me if I do not have the changes file with the image. If I have the changes file and it's read-only, that's a different problem. It seems that this was possible before, judging from the older links I found in my original email and the existence of some guards against non-existence changes file. I'll check those links and perhaps see if I can be helpful there, but I right now have delivery to make. And I can't wait to try Pharo 6 too. -- Andreas On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <b...@openinworld.com> wrote: > > > On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.suna...@gmail.com> > wrote: > >> Hi Stef, >> >> I can't have changes file bundled with the tool because the tool is >> installed in a centralized location in my network and multiple users will >> run it. So the image is in a central location and read-only and so is the >> changes file (if I must have a changes file). The tool is only a processor. >> It does not need to keep/save its state. >> >> Hence, I cannot have multiple users writing to that one and the same >> changes file. >> >> I'm trying to dissect the call chain to ChangesLog and try to cut it so >> Pharo won't write to the changes file. I'm sure I should not do this. There >> must be a better way. >> > > I guess this use case just hasn't been critical for other people (there > are lots of competing priorities) and they've found ways of working around > it, like making your network located tool a script that copies itself > itself to a use folder and run from there. But of course it would be > better for Pharo to work cleanly without a changes file. To make it better, > someone has to do it, so feel free to propose some code changes (with > discussion of such on pharo-dev list). > > Here is one hint (something related I worked on recently)... > https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death- > when-sources-file-missing > To view the changes, open image 60494 (easiest using PharoLauncher) > and load the slice. > > Filtering the issue tracker on "changes file" pops up a few other > possibilities (I haven't reviewed them, and you might find others) > https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes- > file-is-not-writable > https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic- > that-opens-the-sources-and-changes-files > > cheers -ben > > >> >> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse < >> stepharo.s...@gmail.com> wrote: >> >>> We started to work on making the system ready to stop using these files. >>> There are two things. >>> - the changes are a tape that logs what you are doing and right now >>> the system is not done to accept not to log >>> So I imagine that you can remove the changes file but then do not >>> compile code. >>> - I do not get the "so I can't have changes file bundled with the tool." >>> you do not have a bat or script that launches the application that is >>> somewhere in a folder where you have the vm and the image? you could >>> have the changes file there. >>> >>> We are interested in your scenario because last year I got a guy >>> working on making pharo silent. I do not know if its changes got >>> integrated into pharo. >>> This is really something that we want to have. >>> - having sources and changes in a specific location >>> - having no source and no changes (even if it means lose your code). >>> - ... >>> >>> Stef >>> >>> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.suna...@gmail.com> >>> wrote: >>> > Sorry to bring this up again. But it turns out that I had the image >>> > directory writable by myself, so it created a new changes file. That's >>> why >>> > Pharo didn't complain about missing changes file. When I removed write >>> > permission in the tool installation, Pharo gives error for not having >>> or not >>> > able to write to changes file. >>> > >>> > I guess I'm back to the problem how to deploy a tool without changes >>> file. I >>> > have multiple users that will be running this tool, which is installed >>> in a >>> > centralized site, so I can't have changes file bundled with the tool. >>> > >>> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.suna...@gmail.com> >>> wrote: >>> >> >>> >> I had my changes and sources files in the bundle but has their write >>> >> permission removed, and that causes the error. Simply deploying the >>> tool >>> >> without the changes file seems to fix it. Pharo5 doesn't complain if >>> the >>> >> changes file isn't there. >>> >> >>> >> However, without the sources file, I get this warning that pharo >>> cannot >>> >> locate the sources file. Including the sources file in the deployed >>> tool is >>> >> fine with me. >>> >> >>> >> So, I think that's my solution. Thanks! >>> >> >>> >> >>> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.suna...@gmail.com> >>> >> wrote: >>> >>> >>> >>> I found this StackOverflow question: >>> >>> >>> >>> https://stackoverflow.com/questions/14737695/is-it-possible- >>> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328 >>> >>> >>> >>> and this older forum thread: >>> >>> >>> >>> https://www.mail-archive.com/pharo-project@lists.gforge.inri >>> a.fr/msg21170.html >>> >>> >>> >>> I'm using Pharo5.0 and neither of these options is available anymore. >>> >>> What is the new way to do this? >>> >>> >>> >>> -- >>> >>> Andreas Sunardi >>> >> >>> >> >>> > >>> >>> >> >
