Category to be ignored by Monticello?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Category to be ignored by Monticello?

Dave Mason-3
I have some code that generates code on the fly in user classes.  I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved.  I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories.

Any help appreciated - either "Yes, it ignores *foo*bar* category", or "Here's where to look in Monticello"

Thanks  ../Dave


Reply | Threaded
Open this post in threaded view
|

Re: Category to be ignored by Monticello?

Eliot Miranda-2


On Tue, Jan 3, 2012 at 10:39 AM, Dave Mason <[hidden email]> wrote:
I have some code that generates code on the fly in user classes.  I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved.  I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories.

Any help appreciated - either "Yes, it ignores *foo*bar* category", or "Here's where to look in Monticello"

The convention understood by Monticello is that categories that begin with *package- are part of package.  e.g. in my image there's a protocol in class Object called "*VMMaker-translation support" that contains extensions on Object that are part of the VMMaker package.  The methods there-in are saved only when the VMMaker package is saved, not when the Kernel package (which contains the class Object) is saved.  

So to arrange that user classes are unaffected it is sufficient to add your code in some invented package, using the above convention, e.g. "*ThisIsNotARealMonticelloPackage-so dont worry about the methods here in" :)  When Monticello is used to save the user's code these extensions will be ignored.  The would only get saved if one tried to save the ThisIsNotARealMonticelloPackage package.

HTH
 

Thanks  ../Dave





--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Category to be ignored by Monticello?

Colin Putney-3
In reply to this post by Dave Mason-3
On Tue, Jan 3, 2012 at 10:39 AM, Dave Mason <[hidden email]> wrote:
> I have some code that generates code on the fly in user classes.  I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved.  I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories.

The easiest thing to do is create package for all your generated code,
and categorize the methods as extensions. So something like
'*dave-generated' would prevent the methods from being part of the
package to which the class belongs.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Category to be ignored by Monticello?

Bert Freudenberg
In reply to this post by Dave Mason-3

On 03.01.2012, at 19:39, Dave Mason wrote:

> I have some code that generates code on the fly in user classes.  I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved.  I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories.
>
> Any help appreciated - either "Yes, it ignores *foo*bar* category", or "Here's where to look in Monticello"
>
> Thanks  ../Dave



There is an example for this in

        Preferences class>>compileAccessMethodForPreference:

It puts generated methods into "*autogenerated" and uses silent compilation which avoids notifying Monticello. That way the "autogenerated" package doesn't even show up in MC.

- Bert -