Remove Changes/Sources files in end-user distribution

I have located in class FileDirectory (and, IMO, the wrongest place  
for this to be) the spot where Squeak complains if the Changes and  
Sources files are missing/unreadable/unwritable. To trim down my end-
user distribution, I'd like to silence the complaints and not include  
these files (my user base will not be accessing Squeak in such a way  
that these files will be beneficial to them).

I did a couple of class-recompilation tests, which seem to work fine.

The question is: can I get away with not including either of these  
files in an installation where some classes/methods will be re-
compiled via update streams? Is there some hidden necessity to having  
these two files present in the installation?

Eric Fournier
University Technology Development Center
University of Minnesota Office of Information Technology
[hidden email]

Am 02.02.2006 um 21:29 schrieb Fournier Eric:

> I have located in class FileDirectory (and, IMO, the wrongest place  
> for this to be) the spot where Squeak complains if the Changes and  
> Sources files are missing/unreadable/unwritable. To trim down my  
> end-user distribution, I'd like to silence the complaints and not  
> include these files (my user base will not be accessing Squeak in  
> such a way that these files will be beneficial to them).

There are two preferences for this

        warnIfNoChangesFile
        warnIfNoSourcesFile

Just disable them.

> The question is: can I get away with not including either of these  
> files in an installation where some classes/methods will be re-
> compiled via update streams?

Yes.

> Is there some hidden necessity to having these two files present in  
> the installation?

No.

You might want to look at the Squeakland distribution, it does not  
include source files either.

- Bert -

>>The question is: can I get away with not including either of these files in an installation where some classes/methods will be re-compiled via update streams?
>
>Yes.
>
>>Is there some hidden necessity to having these two files present in the installation?
>
>No.
>
>You might want to look at the Squeakland distribution, it does not include source files either.

Before relying on this, it would be advisable to remove your source files and *then* recompile the entire system (...recompileAll...).  This should work fine, but I don't know that current maintainers do this kind of stress test (it is demanding of the decompiler) at every release.

        - Dan

Hi dan

do you have a check list of all the actions to be done in that way?
So that we learned. Mike produced some scripts in ReleaseBuilder and  
I plan to study them soon now.

Stef

Hm. I start seeing syntax errors as soon as I get into Tweak classes.  
Worked when sources/changes were in place (it's the missing changes  
file).

The errors are on Tweak annotations like:

CAssignmentTileCostume>>onPropertyChanged
        <on:in:: #(#propertyChanged #player)>
        self player property borderStyle: #none.
        self signal: #updateEverything

(second line gets: <on:in> expected ->:: #(#propertyChanged #player)>  )


With the Changes file in place, I see:

onPropertyChanged
        <on:in:: #(#propertyChanged #player)>
        self player property borderStyle: #none.
        self signal: #updateEverything


So, it seems the changes file is providing some annotation syntaxia  
that goes missing without it, making annotated Tweak classes un-
compilable.

Seems to be happy without Sources, however. Thanks for the tip: this  
averted a bad decision.

-- Eric

Am 03.02.2006 um 23:28 schrieb Fournier Eric:

Looks like we need to fix the Tweak decompiler.

- Bert -