I found this StackOverflow question: and this older forum thread: I'm using Pharo5.0 and neither of these options is available anymore. What is the new way to do this? -- Andreas Sunardi |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> 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@.../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 >> >> > |
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. On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <[hidden email]> wrote: We started to work on making the system ready to stop using these files. |
On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <[hidden email]> wrote:
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)... 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) cheers -ben
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > > On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> > >> 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@.../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 > >> > >> > > > > > > |
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> >> >> On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >>>> 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@.../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 >>>> >>>> >>> >> >> >> >> > |
In reply to this post by Sven Van Caekenberghe-2
> On 7 Jun 2017, at 09:38, Sven Van Caekenberghe <[hidden email]> wrote: > > I think that could/would work (the code in System-Sources was refactored quite well). I added an issue and a slice (in the Pharo 6 inbox): https://pharo.fogbugz.com/f/cases/20126/Running-Without-Changes-and-Sources Make it possible to Run without changes and sources Add two new classes: - NoChangesLog as subclass of ChangesLog - NoPharoFilesOpener as subclass of PharoFilesOpener Both are do nothing variants of their superclass. To run without changes or sources, execute NoChangesLog install. NoPharoFilesOpener install. And save your image. You now no longer need the changes file nor the sources file and you can safely move or remove them. To restore the initial situation, execute ChangesLog reset. PharoFilesOpener reset. Note: it might be possible that some code fails due to missing method sources, YMMV. Warning: of course you should no longer develop in such an image. Sven |
I applied the solution of Sven over a minimal image of Pharo and it works!
I created a script to disable the calls to sources and changes and then I deleted those. The complete tutorial for use the minimal image is here <https://despotadesdibujau.github.io/southsmalltalks/how-to-deploy-in-pharo> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
In reply to this post by Sven Van Caekenberghe-2
> On 7. Jun 2017, at 17:11, Sven Van Caekenberghe <[hidden email]> wrote: Hi, > > Note: it might be possible that some code fails due to missing method sources, YMMV. does the exception handling code need the sources files? Anecdotical I had some issues (exception handling causing exception handling taking 99% CPU and filling up the debug log) which went away after installing the source files. cheers holger |
In reply to this post by despotadesdibujau
> On 19 Nov 2017, at 01:54, despotadesdibujau <[hidden email]> wrote: > > I applied the solution of Sven over a minimal image of Pharo and it works! > I created a script to disable the calls to sources and changes and then I > deleted those. > The complete tutorial for use the minimal image is here > <https://despotadesdibujau.github.io/southsmalltalks/how-to-deploy-in-pharo> I just wanted to add that NoChangesLog and NoPharoFilesOpener are standard parts of Pharo 7 (I forgot when we actually added them). |
Free forum by Nabble | Edit this page |