Squeak 6 kernel changes, ContextPart+MethodContext -> Context

> Hi All,
>
>     another change planned for Squeak 6 is eliminating ContextPart &
> MethodContext in favor of Context.  In reviewing the (very few) changes
> necessary I came across the following:
>
> MethodContext>>printString
> "Answer an emphasized string in case of a breakpoint method"
>
> ^(self method notNil and: [self method hasBreakpoint])
> ifTrue:[(super printString , ' [break]') asText allBold]
> ifFalse:[super printString]
>
> Seriously?  I don't object to modifying [Method]Conext>>printOn: to include
> [break] but having printString answer a text seems completely broken to me,
> and overriding printString is a hack; printOn: being the operative method
> for producing self-descriptions.  Should we nuke it and add [break] to
> printOn:? Or...?
>
> _,,,^..^,,,_
> best, Eliot
>

> On 29.03.2017, at 23:16, Levente Uzonyi <[hidden email]> wrote:
>
> On Wed, 29 Mar 2017, Eliot Miranda wrote:
>
>> Hi All,
>>    another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context.  In reviewing the (very few) changes
>> necessary I came across the following:
>> MethodContext>>printString
>> "Answer an emphasized string in case of a breakpoint method"
>> ^(self method notNil and: [self method hasBreakpoint])
>> ifTrue:[(super printString , ' [break]') asText allBold]
>> ifFalse:[super printString]
>> Seriously?  I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken
>> to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions.  Should we nuke it and add
>> [break] to printOn:? Or...?
>
> Nuke it. AFAIK breakpoints never worked.

>
>> On 29.03.2017, at 23:16, Levente Uzonyi <[hidden email]> wrote:
>>
>> On Wed, 29 Mar 2017, Eliot Miranda wrote:
>>
>>> Hi All,
>>>    another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context.  In reviewing the (very few) changes
>>> necessary I came across the following:
>>> MethodContext>>printString
>>> "Answer an emphasized string in case of a breakpoint method"
>>> ^(self method notNil and: [self method hasBreakpoint])
>>> ifTrue:[(super printString , ' [break]') asText allBold]
>>> ifFalse:[super printString]
>>> Seriously?  I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken
>>> to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions.  Should we nuke it and add
>>> [break] to printOn:? Or...?
>>
>> Nuke it. AFAIK breakpoints never worked.
>
> which?
>
>>
>> Levente
>>
>>> _,,,^..^,,,_
>>> best, Eliot
>>

> Levente
>
> On Wed, 29 Mar 2017, Tobias Pape wrote:
>
>>
>>> On 29.03.2017, at 23:16, Levente Uzonyi <[hidden email]> wrote:
>>> On Wed, 29 Mar 2017, Eliot Miranda wrote:
>>>> Hi All,
>>>>   another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context.  In reviewing the (very few) changes
>>>> necessary I came across the following:
>>>> MethodContext>>printString
>>>> "Answer an emphasized string in case of a breakpoint method"
>>>> ^(self method notNil and: [self method hasBreakpoint])
>>>> ifTrue:[(super printString , ' [break]') asText allBold]
>>>> ifFalse:[super printString] Seriously?  I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken
>>>> to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions.  Should we nuke it and add
>>>> [break] to printOn:? Or...?
>>> Nuke it. AFAIK breakpoints never worked.
>>
>> which?
>>
>>> Levente
>>>> _,,,^..^,,,_
>>>> best, Eliot
>>>
>

>
> Levente
>
> On Wed, 29 Mar 2017, Tobias Pape wrote:
>
>>
>>> On 29.03.2017, at 23:43, Levente Uzonyi <[hidden email]> wrote:
>>> The one which allows you to break at any instruction. There is "toggle break on entry", which does nothing but recompile your method with `self break` at the start. I find that feature hardly useful.
>>
>> Well, there's WrappedBreakpoint, which can do that without recompiling…
>>
>>> Levente
>>> On Wed, 29 Mar 2017, Tobias Pape wrote:
>>>>> On 29.03.2017, at 23:16, Levente Uzonyi <[hidden email]> wrote:
>>>>> On Wed, 29 Mar 2017, Eliot Miranda wrote:
>>>>>> Hi All,
>>>>>>  another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context.  In reviewing the (very few) changes
>>>>>> necessary I came across the following:
>>>>>> MethodContext>>printString
>>>>>> "Answer an emphasized string in case of a breakpoint method"
>>>>>> ^(self method notNil and: [self method hasBreakpoint])
>>>>>> ifTrue:[(super printString , ' [break]') asText allBold]
>>>>>> ifFalse:[super printString] Seriously?  I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken
>>>>>> to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions.  Should we nuke it and add
>>>>>> [break] to printOn:? Or...?
>>>>> Nuke it. AFAIK breakpoints never worked.
>>>> which?
>>>>> Levente
>>>>>> _,,,^..^,,,_
>>>>>> best, Eliot
>

> On 31.03.2017, at 15:46, Bert Freudenberg <[hidden email]> wrote:
>
> On Thu, Mar 30, 2017 at 12:01 AM, Tobias Pape <[hidden email]> wrote:
>
> > On 29.03.2017, at 23:56, Levente Uzonyi <[hidden email]> wrote:
> >
> > Inserting `self half` is still superior.
>
> If i want to half myself, sure ;)
>
> Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
>
> I'd like to have proper breakpoints that are as convenient as "self halt" but don't modify the method source.
>

>
> A confirmation dialog would be nice if a wrapped method is saved and the break is still in the source.
>
> Am 31.03.2017 15:47 schrieb "Bert Freudenberg" <[hidden email]>:
> On Thu, Mar 30, 2017 at 12:01 AM, Tobias Pape <[hidden email]> wrote:
>
>> On 29.03.2017, at 23:56, Levente Uzonyi <[hidden email]> wrote:
>>
>> Inserting `self half` is still superior.
>
> If i want to half myself, sure ;)
>
> Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
>
> I'd like to have proper breakpoints that are as convenient as "self halt" but don't modify the method source.
>
> - Bert -
>