Re: Remove Changes/Sources files in end-user distribution

[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).

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-3]

Am 03.02.2006 um 23:28 schrieb 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
>>
>
> 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

Looks like we need to fix the Tweak decompiler.

- Bert -

[Fournier Eric]

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



On Feb 3, 2006, at 4:28 PM, Fournier Eric wrote:

>
>>>> 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
>
>
>
> _______________________________________________
> Tweak mailing list
> Tweak@...
> http://impara.de/mailman/listinfo/tweak

_______________________________________________
Tweak mailing list
Tweak@...
http://impara.de/mailman/listinfo/tweak

[Bert Freudenberg-3]

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

- Bert -

Am 03.02.2006 um 23:40 schrieb Fournier Eric:

> 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
>
>
>
> On Feb 3, 2006, at 4:28 PM, Fournier Eric wrote:
>
>>
>>>>> 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

_______________________________________________
Tweak mailing list
Tweak@...
http://impara.de/mailman/listinfo/tweak

[Bert Freudenberg-3]

Maybe the attached changeset works for you?

- Bert -

Am 04.02.2006 um 00:25 schrieb Bert Freudenberg:

> As I wrote in the previous message - it takes fixing the decompiler  
> to properly deal with method annotations.
>
> - Bert -
>
> Am 03.02.2006 um 23:40 schrieb Fournier Eric:
>
>> 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
>>
>>
>>
>> On Feb 3, 2006, at 4:28 PM, Fournier Eric wrote:
>>
>>>
>>>>>> 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

_______________________________________________
Tweak mailing list
Tweak@...
http://impara.de/mailman/listinfo/tweak

[Fournier Eric]

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



On Feb 5, 2006, at 1:36 PM, Bert Freudenberg wrote:

> Maybe the attached changeset works for you?
>
> - Bert -
>
> Am 04.02.2006 um 00:25 schrieb Bert Freudenberg:
>
>> As I wrote in the previous message - it takes fixing the  
>> decompiler to properly deal with method annotations.
>>
>> - Bert -
>>
>> Am 03.02.2006 um 23:40 schrieb Fournier Eric:
>>
>>> 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
>>>
>>>
>>>
>>> On Feb 3, 2006, at 4:28 PM, Fournier Eric wrote:
>>>
>>>>
>>>>>>> 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
>
> <propDecompile-bf.1.cs.gz>

_______________________________________________
Tweak mailing list
Tweak@...
http://impara.de/mailman/listinfo/tweak