Remove Changes/Sources files in end-user distribution

Discussion:

Fournier Eric

2006-02-03 22:28:21 UTC

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

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

Bert Freudenberg

2006-02-03 22:34:39 UTC

Permalink

Post by Fournier Eric

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?

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

Looks like we need to fix the Tweak decompiler.

- Bert -

Fournier Eric

2006-02-03 22:40:42 UTC

Permalink

Sorry, bad paste:

With the Changes file in place, I see:

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

I'm wondering what it would take to break this dependency in the
Tweak classes?

(I guess I'm creating 'TweakLand' ;-)

-- Eric

Post by Fournier Eric

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

)

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.
this averted a bad decision.
-- Eric
_______________________________________________
Tweak mailing list
http://impara.de/mailman/listinfo/tweak

Bert Freudenberg

2006-02-03 23:25:49 UTC

Permalink

As I wrote in the previous message - it takes fixing the decompiler
to properly deal with method annotations.

- Bert -

Post by Fournier Eric
onPropertyChanged
<on: propertyChanged in: player>
self player property borderStyle: #none.
self signal: #updateEverything
I'm wondering what it would take to break this dependency in the
Tweak classes?
(I guess I'm creating 'TweakLand' ;-)
-- Eric

Post by Fournier Eric

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

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).
CAssignmentTileCostume>>onPropertyChanged
<on:in:: #(#propertyChanged #player)>
self player property borderStyle: #none.
self signal: #updateEverything
(second line gets: <on:in> expected ->:: #(#propertyChanged
#player)> )
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.
this averted a bad decision.
-- Eric

Bert Freudenberg

2006-02-05 19:36:56 UTC

Permalink

Maybe the attached changeset works for you?

- Bert -

Post by Bert Freudenberg
As I wrote in the previous message - it takes fixing the decompiler
to properly deal with method annotations.
- Bert -

Post by Fournier Eric

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

Fournier Eric

2006-02-06 20:06:45 UTC

Permalink

Gets through the Tweak C-prefixed classes, but syntax error at
DecompilerTests>>addSelectorSilently: t1 withMethod: (t5 generate: t4)
when

literals := encoder allLiterals.

...gets an array of more then 255 values (same problem with
Preference, Preferences, and PreferencePanel). I just proceeded
beyond these to another at MCMergeBrowser>>recompile:
#conflictSelectionDo: from: MCMergeBrowser when

compile: (MCMergeBrowser sourceCodeAt: #conflictSelectionDo:)

produces a block that can't respond to BlockNode>>statements: t1
returns: true

where t1 = #({self selectionIsConflicted
ifTrue: t1
ifFalse: [self inform: 'You must have a conflict selected']} {^ self})

...which I couldn't get past (had to skip the class).

So I very nearly can compile the image without the changes file, but
not quite still.

-- Eric

Post by Bert Freudenberg
Maybe the attached changeset works for you?
- Bert -

Post by Bert Freudenberg
As I wrote in the previous message - it takes fixing the
decompiler to properly deal with method annotations.
- Bert -

Post by Fournier Eric

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

<propDecompile-bf.1.cs.gz>