Hi all,
I am currently developing an application that continuously creates and deletes methods on its own. This, however, leads to the changes file exceeding the limits of what Squeak can handle. The error message tells me to take "some actions", but unfortunately I'm not quite sure, what to do now. I have renamed the changes file as a first fix, but this leads to errors upon startup. So does anybody know what might be the best solution here?
Secondly, I wanted to ask if it is possible to prevent changes of methods that match certain naming patterns from being written to the changes file?
kind regards,
Thomas Kowark
On Mon, 18 Aug 2008 17:21:58 +0200, Thomas Kowark wrote:
Hi all,
I am currently developing an application that continuously creates and deletes methods on its own. This, however, leads to the changes file exceeding the limits of what Squeak can handle. The error message tells me to take "some actions", but unfortunately I'm not quite sure, what to do now. I have renamed the changes file as a first fix, but this leads to errors upon startup. So does anybody know what might be the best solution here?
Some action here usually means that you have to start with a fresh .image and .changes file, then load your app into it. There can be other possibilities like #condenseSources but this doesn't seem to apply to the situation you describe (you continously create and delete methods programmatically).
Secondly, I wanted to ask if it is possible to prevent changes of methods that match certain naming patterns from being written to the changes file?
You might want to look at senders and implementors of #acceptsLoggingOfCompilation, same for #wantsChangeSetLogging if you are concerned about memory and time.
HTH.
/Klaus
kind regards,
Thomas Kowark
Am 18.08.2008 um 17:39 schrieb Klaus D. Witzel:
On Mon, 18 Aug 2008 17:21:58 +0200, Thomas Kowark wrote:
Hi all,
I am currently developing an application that continuously creates and deletes methods on its own. This, however, leads to the changes file exceeding the limits of what Squeak can handle. The error message tells me to take "some actions", but unfortunately I'm not quite sure, what to do now. I have renamed the changes file as a first fix, but this leads to errors upon startup. So does anybody know what might be the best solution here?
Some action here usually means that you have to start with a fresh .image and .changes file, then load your app into it. There can be other possibilities like #condenseSources but this doesn't seem to apply to the situation you describe (you continously create and delete methods programmatically).
#condenseChanges is what you want, not sources.
Secondly, I wanted to ask if it is possible to prevent changes of methods that match certain naming patterns from being written to the changes file?
You might want to look at senders and implementors of #acceptsLoggingOfCompilation, same for #wantsChangeSetLogging if you are concerned about memory and time.
You should use the non-logging methods for adding/removing in this case.
- Bert -
On Mon, Aug 18, 2008 at 05:21:58PM +0200, Thomas Kowark wrote:
Hi all,
I am currently developing an application that continuously creates and deletes methods on its own. This, however, leads to the changes file exceeding the limits of what Squeak can handle. The error message tells me to take "some actions", but unfortunately I'm not quite sure, what to do now. I have renamed the changes file as a first fix, but this leads to errors upon startup. So does anybody know what might be the best solution here?
Secondly, I wanted to ask if it is possible to prevent changes of methods that match certain naming patterns from being written to the changes file?
--------- The best way: -----------------
I assume you are using something like this?
aClass compile: 'aMethod ^ aValue' classified: #autogen
use the longer version:
aClass compile: 'aMethod ^ aValue' classified: #autogen withStamp: 'autogen' notifying: nil logSource: false
The important bit is logSource: false. It is true by default. If you do this, your methods will have no source code, and will have to be decompiled. Check the implementation of compile:classified: to see how it fills in the other parameters.
----------- the next best way: -----------
You can disable the preference general > warnIfNoChangesFile, then delete the .changes file.
This will mean that many methods in your system will not have source code, only those methods unchanged since the creation of the .sources file. This most definitely means methods you created will have no source code.
kind regards,
Thomas Kowark
GMX Kostenlose Spiele: Einfach online spielen und Spa� haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/616919...
squeak-dev@lists.squeakfoundation.org