[squeak-dev] The Inbox: Kernel-fbs.735.mcz

Frank Shearar frank.shearar at gmail.com
Thu Jan 31 09:51:23 UTC 2013


On 31 January 2013 09:49, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 31 January 2013 09:36, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 31 January 2013 06:31, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> Am 30.01.2013 um 19:50 schrieb Frank Shearar <frank.shearar at gmail.com>:
>>>
>>>> On 30 January 2013 18:33,  <commits at source.squeak.org> wrote:
>>>>> Frank Shearar uploaded a new version of Kernel to project The Inbox:
>>>>> http://source.squeak.org/inbox/Kernel-fbs.735.mcz
>>>>>
>>>>> ==================== Summary ====================
>>>>>
>>>>> Name: Kernel-fbs.735
>>>>> Author: fbs
>>>>> Time: 30 January 2013, 6:33:47.078 pm
>>>>> UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc
>>>>> Ancestors: Kernel-fbs.734
>>>>>
>>>>> Actually, return a Message, and find out the receiver of the Message from the signalercontext.
>>>>>
>>>>> Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
>>>>>
>>>>> =============== Diff against Kernel-fbs.734 ===============
>>>>>
>>>>> Item was added:
>>>>> + ----- Method: ContextPart>>asMessage (in category 'converting') -----
>>>>> + asMessage
>>>>> +       | sender selector args |
>>>>> +       sender := self sender.
>>>>> +       selector := sender method selector.
>>>>> +       args := Array new: selector numArgs.
>>>>> +       1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
>>>>> +       ^ Message selector: selector arguments: args.!
>>>>>
>>>>> Item was removed:
>>>>> - ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
>>>>> - asMessageSend
>>>>> -       | sender selector args |
>>>>> -       sender := self sender.
>>>>> -       selector := sender method selector.
>>>>> -       args := Array new: selector numArgs.
>>>>> -       1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
>>>>> -       ^ MessageSend receiver: self receiver selector: selector arguments: args.!
>>>>
>>>> <snip>
>>>>
>>>> Diffs serve as a helper for reviewers. To that end, the diffs ought to
>>>> actually show what changes would be applied to trunk should the change
>>>> be accepted. This diff, for instance, shows the removal of
>>>> #asMessageSend and the addition of #asMessage, but really the change
>>>> applied to trunk will be just the addition of #asMessage.
>>>>
>>>> In other words when something undergoes a few rounds of review (and
>>>> I'd think this should be the _norm_) the reviewer must reconstruct a
>>>> series of diffs to get an idea of how trunk will change.
>>>>
>>>> Wouldn't it be better to diff against trunk rather than against the
>>>> mcz's ancestor? (*)
>>>>
>>>> frank
>>>
>>> You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
>>
>> OK, but if we do that then we lose ancestry. I know what you're
>> hinting at, and I'd also like to see the equivalent of a git squash -
>> "take these versions in this branch and squish them together so that
>> the main line only sees a single commit". Right now that's pretty
>> onerous: it'd be a manual task, fraught with opportunities to mess up.
>> Er, actually, am I talking nonsense? Given some series of mczs, once
>> the chain/latest has passed peer review, I could
>>
>> * load the latest versions into a clean up-to-date image
>> * file out the versions (so we flush the ancestry)
>> * load the fileouts into a clean up-to-date image
>> * commit to trunk, with suitable commit messages.
>>
>> That's nearly automatable, except for the commit messages.
>>
>>> We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
>>
>> *ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?
>
> Sorry, I obviously meant
>
> MCHttpRepository
>     location: 'http://source.squeak.org/ss'
>     user: ''
>     password: ''

Also, how do I load it? It looks like it at least depends on Seaside.
Any chance of an Installer script?

>> frank
>>
>>> - Bert -


More information about the Squeak-dev mailing list