You could also subclass PharoFilesOpener with NoPharoFilesOpener, override #sourcesFileOrNil and #changesFileOrNil to just return nil, and #install it as Default. And hope that the callers can deal with the nils.
On 7 Jun 2017, at 09:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Andreas,
What if you subclassed ChangesLog, say with something called NoChangesLog and installed that as its DefaultInstance (as accessed by #default), with an #install class side message.
Then override #logChange: and #logSnapshot:andQuit: to do nothing.
No need to subscribe to system announcements.
To install, you do
NoChangesLog install.
To get back, you do
ChangesLog reset.
I think that could/would work (the code in System-Sources was refactored quite well).
HTH,
Sven
On 7 Jun 2017, at 04:19, Andreas Sunardi <a.sunardi@gmail.com> wrote:
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 <btc@openinworld.com> wrote:
On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi@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-... 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-writabl... https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-sou...
cheers -ben
On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self@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.sunardi@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.sunardi@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.sunardi@gmail.com> wrote:
I found this StackOverflow question:
https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-phar...
and this older forum thread:
https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.ht...
I'm using Pharo5.0 and neither of these options is available anymore. What is the new way to do this?
-- Andreas Sunardi