« Return to Thread: Re: Remove Changes/Sources files in end-user distribution
Re: Remove Changes/Sources files in end-user distribution
by Fournier Eric
::
Rate this Message:
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
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
« Return to Thread: Re: Remove Changes/Sources files in end-user distribution
| Free Forum Powered by Nabble | Forum Help |